Budget Update: 30/04/2017

The billing report in AWS only displays expenditure during the current month. For this month, the three main causes of expense have been the services; RDS, EC2, and KMS.

More detailed billing logs for each service are shown below.

This slideshow requires JavaScript.

When input into my AWS spreadsheet, I get the following results:

SpreadSheet Budget

 Spreadsheet documenting AWS billing services

Spreadsheet Percentage growth budget

 Spreadsheet calculating percentage growth between each budget update

The percentage growth between this budget update and the last one has dropped, which is indicative of me reaching the end of the DinoStore project and hence, using those services less frequently.

RDS Budgeting

As the end of the month has drawn closer, I’ve been receiving emails from AWS in regards to my RDS budget’s expiration.

AWS Expiration Message

When I designed the RDS budget, I designed it with the DinoStore project in mind. As the DinoStore project was due on the 29th of April, I set the budget to also finish at the end of the month.

So, with the RDS budget coming to an end, I decided that it would be a good time to check my monthly expenditure in comparison to the budgeted amount. My first look at the budget list showed the RDS forecast to be lower than what I expected, when also considering the RDS billing amount:

RDS All Regions

I considered that the underestimated RDS budget was likely due to an incorrect parameter that I had given it, so I adjusted it to focus on the availability zones; ap-southeast-2, and us-east-1, which correspond to Sydney and North Virginia.
Edit DinoStore RDS Budget

Once these adjustments had been made, the RDS budget showed a current expenditure of $9.28 USD, which matches the billing amount.
RDS Budget Details

Although, my adjustment were made at the end of the budget’s lifespan, the realization and application of correcting my budget will enable me to create a more accurate budget plan for my next project.
From an accounting perspective, rather than a technical one, the RDS budget allowance was an accurate prediction of expenditure for the DinoStore project. This knowledge may be able to be extrapolated into my next project in order to provide a reliable budget in relation to the project and its progress.

Lab 10: Configuring DNS with Route 53

I chose not to do this lab as it was optional due to it requiring me to register a domain name, which does not exist within the free tier.

This DinoStore project has already caused me quite a bit of expenditure (see latest budget report), and so I’ve decided not to cause any further expenditure for this project.

This project also took me longer than I anticipated, so I ran out of time to complete this one.

Lab 9: Enabling Auto Scale to Handle Spikes and Troughs

The lab script contains an excerpt from the AWS documentation in regards to auto scaling: “Auto Scaling is a web service designed to launch or terminate Amazon EC2 instances automatically based on user-defined policies, schedules, and health checks.”

Auto Scaling is found under the EC2 service.
001 Launch Configurations

The ‘Launch Configurations’ option needs to be selected, then clicking on ‘Create Auto Scaling Group’ followed by ‘Create Launch Configuration’.
The configuration needs to have the following specifications:

002 Choosing Web Server from my AMIs

My AMIs: DinoStoreWebServer
Instance: t2.micro
Name: scale-web
IAM Role:  WebServerRole
Security Group: WebRDPGroup
Key Pair: (I’m using an existing key pair)

003 Review Launch 1 of 2004 Review Launch 2 of 2
In ‘Create Auto Scaling Group’ a group needs to be created with the following specifications:

Group Name: scale-web-asg
Group Size: starting with two instances
Network: Default VPC
Subnet: Default subnets for each Availability Zone

005 Create Auto-Scaling Group

Advanced Details:
Receive traffic from ELB: DinoStoreLB
Health Check Type: ELB
006 Advanced details 9_1_c_v
Configure Scaling Properties:
Group remains at initial size
007 Auto-Scaling Policies
Tags-Name:ASG-WebServer, Tag instances


In the EC2 dashboard, the auto scaling information shows the instances launch, as does the instance screen.
The lab script makes mention that the manually created servers would usually be deleted before or after the set up of the auto scaling group. This would be because of their inability to scale.
The load balancer screen also shows the status of the instances in service.
012 AS w Two Instances

Using the load balancer URL, the DinoStore web site can be displayed. Upon refreshing the site, the internal IPs change.

This slideshow requires JavaScript.

For this all of my instances attached to the load balancer were utilized.

Then in the EC2 instance window, the web server and its image (the non auto-scaling instances) need to be terminated, before testing the DinoStore site refresh to check the number of IPs available.

This slideshow requires JavaScript.

The number of different IPs available dropped down to match the number of auto scale IP instances within the load balancer.

In order to test the auto scaling, one of the autoscale instances needs to be terminated, and then the EC2 instance window and the auto scaling groups window need to be checked for a new instance being automatically created.
020 AS Instances Starting with Available Space
After the new instance is in service, the DinoStore page again needs refreshing to check the number of IP addresses. (This has more than one new instance in progress as I was playing around with the settings and set the desired number of instances to five.)


The challenge I faced with this lab was due to my lack of knowledge that I can only have ten EC2 instances available at any one time. The auto scaling group ended up failing because of this limitation, which I had reached with the rest of my instances.
010 Auto-Scaling -Activity History w One Instance
In order to resolve this, I terminated any unnecessary instances.

Lab 8: Using ELB to Scale Applications.

The AWS documentation on elastic-load balancing states that “Elastic Load Balancing [is a scaled service that] automatically distributes your incoming application traffic across multiple EC2 instances. It detects unhealthy instances and reroutes traffic to healthy instances until the unhealthy instances have been restored. Elastic Load Balancing automatically scales its request handling capacity in response to incoming traffic.” This excerpt is stated at the top of the lab script to provide greater comprehension for action of Elastic-Load Balancing.

Elastic load balancing is found in the EC2 service, under ‘Load Balancers’. The load balancer created has the following specifications:

Load Balancer name: DinoStoreLB
Load Balancer Configuration: Kept as default
Security Group: WebRDPGroup
Ping Protocol: TCP (This influences the Load balancer choice at the start of the creation.)
Ping Port: 80
-Add the two web servers created in prior labs

002 Review ELB003 Review ELB Part 2

The instances are defined as being ‘Out of Service’ until the registration process finishes. Once registered, they are defined as being ‘In Service’.
005 New ELB Instances description

The load balancer public DNS is then copied and paste into a new tab with the website name as its suffix. This supplies the DinoStore site but cycles through the two different IPs belonging to the web server instances.

This slideshow requires JavaScript.

Removing one of the instances results in the load balancer only having the single IP address use, so there is no change to the IP address of the DinoStore site.

This slideshow requires JavaScript.

Once the removed instance is re-instated, the load balancer can now choose between using either IP again.

This slideshow requires JavaScript.


I didn’t find any challenges or difficulties in this lab. I did however, have to track back on my initial creation of the elastic IP as I had chosen the wrong type.

Not so much a challenge, but more of an interesting aside; I noticed that changes that were installed into the web server’s (IP DinoStore application weren’t immediately changed on my LabSix-WS instance (IP I concluded from this that the image is only as relevant as the time when it was taken. To resolve the discrepancies between my server and its image, I created a new image (IP, which was re-instated instead of the removed LabSix-WS image.
The lack of interchange of adjusted information between an instance and its image, does make me wonder how relevant images are for servers that are frequently updated, as a new image then also needs to be made in response to the update.

Lab 7: Using Elastic IPs

The Elastic IP option is found within the EC2 service.

In the Elastic IP window, ‘Allocate New Address’ is clicked, which supplies a new elastic IP.
001 Allocate Address

The new IP can then be selected and a right-click on it reveals the option to ‘Associate Adress’. The address associated with this is the Web Server instance.
002 Associate Address

The new IP address can then be copied and paste into a new browser tab, with /1-Net702.DinoStore/Net702.DinoStore/ added as a suffix. The internal IP for this DinoStore site is noted.
003 Internal IP

The IP address is then re-associated with the web server image. The IP re-association is allowed by clicking the ‘Reassociation’ option box in the IP Association popup window.

This IP is also copied and paste into a browser with the website suffix, and the internal IP noted.
004 Internal IP of AMI

I did not have any challenges or troubles with this lab.

Lab 6: Creating and using AMIs

The AMI’s used in this lab are created from pre-existing instances.

In EC2, the web server instance is made into an an image by right-clicking on the instance and choosing ‘Image->Create Image’.
001 Create image in Web Server Instance
For this image, the name is: DinoStoreWebServer, and the image description is: ‘Image of DinoStore website vm.’002 Image Format

The queue server is also made into an image, with it’s name being: DinoQueueServer, and it’s image description: ‘Image of DinoStore queue server vm.’

003 AMI Interface

The AMIs are conatined within the EC2 service.

Once created, the web server image is launched with the following specifications:

Type= t2.micro
(The subnet could be in different availability zone to spread instances around the region. This is potentially a good practice if the finances are available for it, however, in my case there is no need to change the region.)
IAM Role: WebServerRole
Tag (Name): LabSix-WS
Security Group: WebRDPGroup
Key Pair: Existing key pair

004 WS-AMI instance Review 1_2005 WS-AMI Instance Review 2_2

While waiting for the image to initialize, the original web server is opened in the local browser, taking note of the IP address.
WebRDP DNS in Browser

Once ready, the public DNS of the image is copied into a new tab in the browser, with the website name attached to the end of the URL. The IP address of this is also noted.
LabSix WS DNS in Browser

They have different IP addresses.

My only challenge with this lab was that I didn’t fully realize my website name. This meant that I was putting in /Net702.DinoStore/ and receiving this error:
007 Server Error On Local Browser

Or trying /1-Net702.DinoStore/ at the end of the DNS and receiving this message in my browser window:
008 WebRDP Server w LabSix DNS in Browser

Eventually I realized that as I was only using an image, I would be able to locate my website details from the original web server instance. When opening the RDP and connecting to DinoStore through IIS, I was able to determine that my website name was /1-Net702.DinoStore/Net702.DinoStore/ due to the folder within the folder when I had copied my DinoStore folder into the wwwroot file.