Optimizing the Stack Template

My working stack, that is able to connect to the instance, has the following design template:

Overview of Design Template -No adjustments

My first focus in refining this stack is to remove any objects that are useless due to not being connected in the system.

This includes two EC2-route tables that aren’t attached within the VPCs, and two of the three elastic IPs, as they were also not necessary.

The updated template is as follows:
Updated Design template

I had originally thought that that the unattached security groups could also be removed from the VPCs, but when I attempted to rebuild the stack, there were dependency errors that forced me to put the security groups back into the JSON script.

My next step was to personalize the stack. This has been done by renaming the stack’s instance. I renamed it to “StackInstance” for easy identification.
EC2 renamed-Stack

My final attempt in optimizing the template, was to organize the stack instance to automatically connect with the elastic IP. This was done by using the following JSON script from: AWS::EC2::EIPAssociation

“Type”: “AWS::EC2::EIPAssociation”,
“Properties”: {
“AllocationId”: String,
“EIP”: String,
“InstanceId”: String,
“NetworkInterfaceId”: String,
“PrivateIpAddress”: String

This however, was unsuccessful as I couldn’t determine what was required for AllocationId, and so I have left it as a manual set-up.

That was every further adjustment done upon the CloudFormer template.

Connecting to the Stack’s Instance

Now that the stack’s instance is at a lower charge rate, I will try to connect to the t2.micro instance.

My first attempt resolved in the following error:

003 Still not able to access _Error

The first thing that I noticed, was that I didn’t have a public IP attached to the instance.
003 CFTemplate EC2 Instance Info

When I looked into the elastic IP section of the EC2 service, there were none there. As these are important in allowing me to connect to the RDGW instance, I added the JSON script for elastic IPs into the CloudFormer Template that I was using. The reason that they weren’t there, was because I had accidentally left them out during the CloudFormer template stack creation process.

When I ran the CloudFormer stack again, the RDGW instance still didn’t have a public IP, however, the elastic IPs had been created, so it was only a matter of manually associating the IP to the instance.

I then tried to connect again, but the connection still failed, with the same error response showing.

I considered then, that it may be an issue with the security groups attached to the stack’s VPC. My initial response was to adjust the JSON script as set all of the security groups’ ingress IPs to This action was taken because I wanted to make everything open as a means of determining whether or not the failure to connect was due to the security groups. My next attempt to connect was still unsuccessful, which determined that it was not a security issue. Because this was ruled out, I replaced the security group IPs back to their original addresses for best practice purposes.

My next consideration was to utilize my other CloudFormer template that only had the single VPC in its design. This was to determine whether there may have been a CloudFormer template construction issue that was resulting in the connection failure. This however, was not the case as the single VPC template also failed to connect.

My final attempt, was to change the WiFi connection that I was using. This is because NMIT has to potential networks, both with different firewall settings, and the connection that I use has been known to not allow a remote connection to occur. This also, was unsuccessful, as was my attempt with my home network.

With all of these potential connection errors having been ruled out, I sought help from my classmates as to the design template of their successful stacks, as this would enable me to compare my stack’s design template and see the difference in design that was causing my connection error. While helping me with providing their design template, one of the classmates suggested that I try create a new CloudFormer template from the Microsoft’s Quick Start, Scenario 3, and create the stack to be completely open to any RDP IP addresses.

I did as he suggested, and during the creation of the initial stacks from that are based from scenario 3, and set the Network Configuration for ‘Allowed Remote Desktop Gateway External Access CIDR’ to
005 Specify Details NS AZ_Options

Once the stack results were organized through the CloudFormer, I ran the new template, removing any of the errors in the JSON script that were causing the stack to rollback. Once the stack was complete, I attached an elastic IP to the instance, and attempted to connect to it. The result was successful.
01 ADDS RDP Success

The previous failures were due to a discrepancy from the remote desktop gateway external access CIDR that had been set-up with the creation of the stacks prior to CloudFormer. Once that had been resolved, the connection was available.

Final Budget Report: 09/06/2017

As the semester comes to a close, so does my budgeting for this course.

Of the $100 USD credits for Amazon Web Services, I have $79.35.

Looking over the past months, my expenditure has been:
Monthly Report Graph

This can be represented as proportions of the credits, as follows:
Visual Monthly Report


In terms of projects, the QwikLabs assignment was for the most of March, Dinostore was during April, and AD-DS has been from the start of May. This is stated in the table below.
Project Billing

The discrepancy between my expenditure and my credits occurs because my expenditure is based upon my billing list which updates more frequently than the credit amount in my account.

The reason for the large cost involved with the Dinostore project is due to my lack of experience with AWS’ RDS, which I accidentally left running for multiple hours and hence the increased charge. This was not the only reason however, as I did often purposefully run RDS during the course of the project.


This assignment of budgeting has been beneficial for myself in gaining knowledge and habits for keeping account of my money on the Amazon Web Services platform. These skills will be able to be transferred and utilized within other aspects of my study, future career, and personal life for goals that involve financial oversight.


Budget Update: 09/06/2017

This budget update is the final update for AD-DS. As my instance has been changed to a t2.micro, there has been very little expense involved with this project.

The table below shows the billing costs for this project.

In order to determine how this budget update compares to the prior ones, I have organized certain service actions into the spreadsheet below.
ADDS Billing
This shows that there aren’t any outlying costs within my budget, which is expected as I haven’t done anything different from the previous weeks.


In conclusion, I originally expected the budget for the Active Directory project to be higher than what has resulted. This is good from a financial perspective, but does also imply that I still need to gain the knowledge and experience required to accurately predict the financial scope of this type of project.




Changing Instance Size in Stack Template

The Microsoft Quick Start template provides an enterprise instance of t2.large in its formatting, which costs more than what is needed for this project. This has been adjusted in the CloudFormer template by replacing the “t2.large” with “t2.micro”.

003 Instance size change

The template was able to run with this smaller instance, which is beneficial for me as I now don’t need to be as concerned with the costs involved for the instance, especially as it charges the same, per hour or part hour.



CloudFormer Template: Virtual Private Clouds

After having successfully created the stack from the cloud template, I have been unable to adjust it to that of the Quick Start diagram, I have however, managed to adjust my first template so that it successfully creates a stack also.

This provides me with two different templates, one that creates a single VPC and one that creates two VPCs.

001 1VPC

Stack with Single VPC


Stack with Two VPCs

My original purpose was to have multiple VPCs, so I will be using that specific template for further design adjustments.


Cloud Computing: Case Studies

The following case studies are from Amazon Web Services’ Customer Success Stories.

Yellow New Zealand Case Study
Yellow New Zealand is a New Zealand based company that originally provided New Zealand homes and businesses with a print book containing residential and business addresses. With the increase of digital technology, Yellow moved to become an internet based company, and in 2015, they moved their business onto the cloud platform, AWS.

The cloud infrastructure manager of Yellow New Zealand, Rob Hayden, states that AWS was chosen as their cloud service provider because of its “industry experience, flexibility of service, enhanced security, and platform maturity.”

Yellow New Zealand employs the use of Amazon Web Services’ AWS CloudFormation, AWS Lambda, Amazon EC2 Container Service, AWS Identity and Access Management, and Amazon ElastiCache in running its business through the cloud. It bases its platform in the Sydney, Australia region (Asia Pacific -Southeast) with its data centre located in Auckland, New Zealand.

The benefits for Yellow New Zealand in moving its business to a cloud service provider such as AWS, are as follows. Firstly. the AWS cloud provider, Yellow New Zealand do not need to spend their time and money on a physical server environment, as that responsibility belongs to AWS. Secondly, Yellow New Zealand desired fast service delivery, which has been able to be implemented as a continuous-delivery model through the adoption of a cloud based environment such as AWS. Thirdly, as Yellow New Zealand is an address business, they desired for a service that provided scaling, while keeping a high quality of delivery. This was able to be resolved through the Amazon ElastiCache mixed with code optimizations, which provided rapid response time, with the rest of the AWS services enabling the needed capacity for the business’ requirements. Finally, the employment of the cloud service provider has provided Yellow New Zealand an environment for the migration of further applications from local infrastructure to cloud infrastructure, which enables Yellow New Zealand the capacity for further growth with reduced costs.

National Instruments Case Study
National Instruments (NI) is a business that was founded in 1976, and is headquartered in Austin, Texas. NI provides technology and technology solutions around the world, in many different industries.

One item of technology that NI provides its customers is a software development environment called LabVIEW. LabVIEW contains a module called FPGA which enables the building of re-programmable silicon chips into applications. One of the limitations of an FPGA design is that it must be compiled before it is deployed, which can be very resource intensive and time intensive. As the company grew, the need for greater infrastructure increased, and the FPGA compilations became more compute intense, which resulted in motivating the NI LabVIEW team to consider cloud computing as a viable resource.

NI’s FPGA team used AWS’s EC2 on-demand instances to host their compilation service. AWS is also able to be used by the team for testing and internal development, and the AWS auto-scaling feature and EC2 Spot instances, all of which assist in reducing computing costs for testing product features. The principle cloud architect at NI stated that the reason for using AWS  as their cloud service provider, was due to the evaluation that “AWS is simpler than other cloud environments, gave [NI teams] more control, and didn’t force [NI teams] to apply updates that would break compatibility.” NI’s teams also determined that they were able to create products through AWS without the need for specialist training or hiring an expert, which results in low expenses for they company.

The benefits of using cloud computing for NI are as follows:

  • AWS provides faster auto-scaling than NI’s local scaling process, which reduces the time response to increased workload. This is beneficial to NI as it results in less wait time for their customers.
  • The utilization of AWS’s Amazon EC2 Spot Instances for FPGA development and testing, saves the company 10 times the cost that would have incurred from on-demand testing.
  • The use of the Spot Instances saves NI approximately 85-90% in costs, which results in more investment into product testing and quality.
  • The use of cloud computing has saved NI from increasing their internal infrastructure, a project that would have cost them around $1 million.
  • The use of cloud computing for running testing and development has increased NI’s agility as their test workloads often vary, and AWS’s auto-scaling eliminates the need for unnecessary costs involved with idle servers.

The AWS cloud environment provides NI with the capacity for growth in extending cloud computing to its other development environments, and for exploring and experimenting with different tools and products.


Cloud service providers like AWS are able to assist national and international businesses in reducing costs, increasing accessibility, and increasing speed. For Yellow New Zealand, costs were reduced because they didn’t need to build a physical server, the move from a physical address book to one based online increased Yellow New Zealand’s availability and accessibility for its customers, and the use of AWS’s ElastiCache enabled faster response time for their websites. For National Instruments, costs were reduced as Amazon’s storage service meant that they didn’t need to invest in increasing their own server, the accessibility of their products was increased through the use of AWS’ auto-scaling that was faster than their previous version, and the speed for customers was increased due to the reduced wait-time with the auto-scaling service.