Lab 5: Adding EC2 Virtual Machines and Deploying the Web App

The lab script explains the initial step in this lab is “to create roles that access other amazon Services so that applications running on EC2 instances don’t have to have credentials baked into the code.”

In the IAM service, a policy can be created using the Policy Generator. This policy has the following settings:

Part 1
Effect: Allow
AWS Service: Amazon DynamoDB
Actions: deleteitem, describetable, getitem, putitem, updateitem
ARN: arn:aws:dynamodb:ap-southeast-2:[ACCOUNT NUMBER]:table/ASP.NET_SessionState

Part 2
Effect: Allow
AWS Service: Amazon SQS
Actions: deletemessage, deletemessagebatch, getqueueurl, receivemessage, sendmessage, sendmessagebatch
ARN: arn:aws:sqs:ap-southeast-2:[ACCOUNT NUMBER]:dinoorders

The policy is then named ‘DynamoSqsPolicy’
001 DynamoSQS Policy Generator

Again in IAM, a new role needs to be created. The role is called ‘WebServerRole’ and it’s AWS service roles are ‘Amazon EC2’, and it contains the customer managed policy of ‘DynamoSqsPolicy’.
002 IAM WebServerRole

Then in the EC2 service, a new instance can be created with the following settings:
Instance: Free tier Microsoft Windows 2012 R2 Base,
Type: General Purpose t2.micro (free tier available)
IAM Role: WebServerRole
Name: Web Server DSL5 18-4
Security Group: Create new security group

Name: WebRDPGroup
Description: Web or RDP access – created for lab web server ec2 instance
Input Protocol:
RDP -Location IP
HTTP -All Sources

003 WebRDP Instance
With this security group, I attached an already created key pair.

Also in the EC2, another instance needs to be created for the queuing server. Again, a free tier t2.micro Windows Server 2012 R2 Base instance is launched.
IAM Role: WebServerRole
Name: Queue Server DSL5 18-4
Security Group: Create new security group

Name: RDPGroup
Description: RDP access – created for lab queue server ec2 instance
Input Protocol:
RDP -Location IP

004 Queue Server Instance
I also used a previously created key pair for this security group.

For the web server instance, the remote desktop file is downloaded and the password decrypted using the key pair. Once connected to the server, IIS (including asp.Net 4.5 with developer files) HTTP connectors, and Windows authentication role services need to be installed.
005 Install IIS

In Visual Studio, the DinoStore needs to be published as file system which can be copied into the web server.
006 Publishing DinoStore Project

In the web server, the published dinostore file is copied into the folder \inetpub\wwwroot.  In the IIS manager the dinostore folder can be converted to an application by selecting the folder and pressing the ‘convert to application’ option.

007 Copying Files to wwwroot in RDP

Moving file into \wwwroot

008 Convert Dinostore File to Application

Converting file into an application



In order to allow instances in the RDP and WebRDP security groups to access the instances in the RDS security group, the security group created from the RDS is selected and in the inbound tab, two new rules need to be created. Both have type: All traffic, Protocol: All, and Source: Being their respective security group.
009 RDS Sec Group Access to RDPs

Once again in the web server, the Web.config file is opened in Notepad for editing. The DynamoDBSessionStoreProvider keys should be deleted from between their quotations. This also needs to occur for the keys below , then the file can be saved.

If internet explorer is opened in the web server, the link shows the following information, which are temporary credentials.
010 Temp Credentials from Role

In IIS Manager in the web server, the website needs to be selected from the left panel of the window, and the centre pane changed to ‘Content View’. From there, the ‘default.aspx’ can be right-clicked, and the option to ‘browse’ can be chosen. This leads to the DinoStore home page, of which, the various aspects such as login and buy can be used.
013 Dinostore Home on VM

The public DNS of the Web Server DSL5 needs to be tested on a public internet connection. This is done by copying the DNS into a new browser window on the desktop (rather than the web server itself). and adding on the website name to the end of the URL. In this scenario, both IP addresses, from the server and the browser, will be the same.
016 DinoStore Connection over Public IP

The next step is to setup the order processing app in the queue server. Before the file can be published, it needs to be ‘released’ from the DinoStore solution. This is done by selecting the ‘Net702.DinoStore.OrderProcessor’ from the Solution Explorer, then in the icon bar, placed directly below the Tool tab, is an option window that can be changed from debug to release. Once the solution has been released, it needs to be published before being copied into the Queue server’s cloud desktop.
017 Configuration Manager in VS

The OrderProcessor application needs to run at the server’s startup. This is done by copying the ‘setup’ executable found in the publication and pasting it within C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp. The application can then be run.
020 OP exe into Startup File

In the local server, the AWS DinoStore database needs to be opened in order to determine what orders are present in the order table.

Then in local browser, the cloud website can be opened for the purpose of logging in and purchasing some dinosaurs through the checkout.

While the DinoStore is open, the queue server needs to be ready to quickly access so that the OrderProcessor console can be seen. As the DinoStore purchase is made, there is a ‘Queue messages received: count is 1’ line that shows up on the console, followed by  a ‘Queue message(s) deleted’ line.
024 Polling Queue in QS VM after Order

Finally, the AWS DinoStore database is re-examined to check the new order that has been recorded in the order table.

I also faced a few challenges throughout the course of this lab as well.

My first challenge was easily enough solved, but it involved the internet explorer in the web server. When the internet explorer is first accessed in the remote desktop, it has high security settings that make it very hard to do anything in the browser. This problem was solved my checking online on how to reduce the browser’s security.

Another small problem that I had, was that I didn’t know where \inetpub\wwwroot was located. Due to my lack of familiarity with 2012 Windows version, I had trouble with locating it on my own. I solved this by looking at a classmate’s blog for assistance. One of their pictures showed the file path for wwwroot, which enabled me to access it for myself as well.

Another error that I faced, which caused some difficulties was attempting to run my converted file without realizing that I needed to manually convert another portion of the file. The folder that I copied from my local server into the web server contained the DinoStore information within another folder in it. When I converted my main folder to an application, I was unaware that the conversion had not reached folder that contained the DinoStore information. This resulted in the following error screen:
012 Parse Error

I managed to solve this when I was looking through the main folder in the IIS manager. I was attempting to check whether there were any other ‘default.aspx’ files or ‘web.config’ files that perhaps were being accessed instead of the ones that I had adjusted. From a technological perspective, my arrangement and organization of the DinoStore and DinoStore related files were poor, which could be considered as the main factor for this error’s occurrence. The ‘Net702.DinoStore’ folder within the ‘1-Net702.DinoStore’ folder was converted once I realized my mistake, and this solved the configuration error.


Introduction to Amazon Elastic Compute Cloud (EC2) with Windows Server

Introduction and Aim
The purpose of this QwikLabs session is to run a Windows server through an Amazon EC2 instance.
For more information on EC2, check out my blog ‘Introduction to Amazon Elastic Compute Cloud (EC2)‘.


  • Logging into the Amazon Management Console
  • Creating a Windows Server instance from an Amazon Machine Image (AMI)
  • Finding the instance in the Amazon Management Console
  • Logging into the instance


Logging into the Amazon Management Console
When logging into the Amazon services, I ensure that I am logging in through the website as this provides the access to my administration account but not my root account. This is healthy practice as a security measure and as a business technique. The next step is to check my region as not all AWS services are available in every zone. My zone is set to Sydney which is an optimal region for what this lab involves. As Sydney is the closest region to where I live, the latency is reduced, while still providing the resources that I require.


Create an Amazon EC2 instance running Windows server
The Windows server that will be run on the instance is Windows Server 2012 R2 Base, which is available on the free tier so I have no qualms about choosing it.

The next move is to run through the configuration steps:
>Configure Instance Details: Everything is kept as default.
>Add Storage: Everything is kept as default
>Tag Instance: A name is created for the tag to assist in easy identification
>Configure Security Group: Leave setting as ‘Create a new security group’ that has a rule for port 3389 open, which is RDP, remote desktop protocol.
>Review Instance Launch: This is a summary of the configuration choices
Review Instance Launch

The final step is choose or create a key pair, in which I choose my existing key pair. Once the instance has been launched, it is a matter of waiting until the instance state shows ‘running’.


Connect to your Amazon EC2 instance
In order to connect to the instance, I need an RDP client. I am able to obtain an RDP when I connect to the instance as I’m using a Windows computer already.
Connect to Instance Popup Window Ws

Once the RDP is downloaded, I can get a password which will be used for the Windows instance. The password is first acquired by me providing my private key, which grants me access to the encrypted password. The decrypted form of the password is used in the Windows instance.
InkedCon2Inst Get Password Ws_LI
(The above screenshot has the encrypted password and Key Name whited-out for security reasons).
Now that an RDP program is available and the password has been determined, I can complete the Windows server launch. The RDP is automatically connected to the server so all that is required is the password input. The result is as expected, a Windows 2012 instance is launched, and appears as follows in the slideshow below.

This slideshow requires JavaScript.


The Amazon EC2 is proficient at both Windows servers and Linux servers (which were used in the previous lab). It is interesting to me, that the Windows layout is far more application oriented compared to the command line that was the Linux server. This may be due to the different setups of the operating systems, and is something that I could potentially look into further.