MattCASmith

Having worked on serveral projects involving Amazon Web Services (AWS) recently, but always at arm’s length, I decided to get a bit more hands-on. At worst this would give me a more practical grounding in managing cloud instances, and at best it would give me a useful resource for future coding projects. So I got to work and set up an account to play around with some of Amazon’s services.

The nice thing about the platform is the AWS Free Tier offering. This is automatically applied to all new users’ accounts and gives free access to many services, at least for the first 12 months. The ins and outs of what’s included and what’s not are a bit complex, but the headline is that unless you deploy anything particularly computationally expensive, you’re not likely to incur any costs within your first year.

To help my learnings sink in, I’m going to write a few posts detailing how to perform basic tasks, beginning with setting up an EC2 instance (more on what that is later). But before you get started, make sure you have the basics covered - namely registering for an account, choosing a strong, unique password, and activating two-factor authentication, as you should for all your accounts. Once you’ve completed all of that, log in to the AWS Management Console to get started.

AWS basics series

1. Deploying a virtual network and server
2. Deploying and connecting to a SQL database

Configuring a Virtual Private Cloud (VPC)

Virtual Private Clouds (VPCs) are Amazon’s way of organising your cloud resources. They are essentially internal IP address ranges where servers and other entities can be deployed, with settings for various levels of internal and external communication via firewall-esque rules and the deployment of subnets. Before we deploy our server, we need to create a VPC for it to sit in.

AWS provides a VPC by default, but for the sake of experience I’ll set up a new VPC for our server by clicking Create VPC, giving it the name server-deployment, and assigning the internal IP address range 10.0.0.0/24. It’s as simple as that - click Create VPC and AWS will instantly deploy it.

Servers must sit on subnets within VPCs, so head back to the VPC Dashboard and click Subnets, then Create Subnet. I’ll call mine subnet-a, put it in the server-deployment VPC, and assign the IP address range 10.0.0.0/24 to the subnet. This will assign the whole VPC IP address range to a single subnet, but that’s not an issue for this example as we’ll only be deploying a single server.

Now we have a VPC and a subnet, we need to create a path from the subnet to the internet so we can access our server. Click on Internet Gateways in the VPC Dashboard sidebar, create a new Internet Gateway (mine is called server-internet-gateway) and attach it to your VPC. Then click Route Tables in the sidebar, select the Route Table for your VPC, click on the Routes tab, and select Edit Routes. A route that sends all traffic with the destination 0.0.0.0/0 to the new Internet Gateway will allow the server to reach the internet, which is not always desirable but is necessary for direct access in this case.

Setting up an Elastic Compute Cloud (EC2) instance

Now let’s create a Windows server within our VPC, and configure it in such a way that we can access it from outside of AWS. Servers within AWS are called Elastic Compute Cloud (EC2) instances, so to deploy one we’ll need to navigate to the EC2 Dashboard and click Launch Instance.

Here we’ll be presented with a list of what AWS calls Amazon Machine Images (AMIs). Each AMI is essentially the equivalent of a gold image in an on-premise environment. We can select from a variety of images (if you’re using AWS Free Tier, those that are included free of charge are indicated), but for the purposes of this example I’ll select the Microsoft Windows Server 2019 Base AMI.

Next we’re asked to choose an instance type. This screen essentially shows a huge list of options for the number of CPUs, amount of RAM, and network performance that our server should have. We only have one option within AWS Free Tier - the t2.micro instance type - so we’ll go with that.

Then we’re given the opportunity to choose some settings for our instance. The important thing here is that the Network setting is set to server-deployment - the VPC we created in the last section. We also need to choose a subnet - that will be subnet-a (10.0.0.0/24) in my case. Be sure to enable public IP assignment if you need to be able to access the server from the internet. We can also set up network interfaces and assign IP addresses here, but I’ll stick with the default and let AWS handle it.

The next screen allocates storage to the server in the form of an Elastic Block Store (EBS), which essentially functions as a hard drive volume. Again, our options under AWS Free Tier are limited to a 30GB General Purpose SSD. It’s also a good idea to encrypt our volume for an additional layer of protection.

Next up are tags, which allow us to categorise assets to help to manage costs, billing, and so on. As I’m deploying a lone server and will soon be terminating it, I won’t add any tags.

The next step is crucially important. Security Groups essentially function as firewalls for EC2 instances. As any good firewall configuration should, they default to deny all. We’ll need to use Remote Desktop Protocol (RDP) on TCP port 3389 to access our server, so I’ll create a new Security Group called rdp-admin and allow incoming connections on that port - but we don’t want this to be exposed to the whole internet, so I’ll restrict access to my IP address (which is handily a preset AWS option).

Click Review and Launch and you’ll have one last chance to check everything is in order before pulling the trigger and deploying your server. When you click Launch, you’ll be given the opportunity to create a new key pair, which you’ll use to decrypt the password to access the server. Name your key pair (I’ll call mine win-server-admin, download the .pem private key file, and keep it somewhere safe.

Congratulations - you’ve deployed Windows Server 2019 in the AWS cloud!

Connecting to the Windows server

If you return to the EC2 dashboard and click on Instances, you’ll now be able to see your server running in AWS. That’s great - but it’s just a number in a management dashboard. How do we actually use it?

As I previously mentioned, the answer lies with RDP - a protocol that allows us to access another Windows computer remotely and interact with it as though we’re sat in front of it using the mouse and keyboard. To prepare to connect, open the Remote Desktop Connection app in your Windows PC (click Start and type RDP to find it) and enter your EC2 instance’s public IP address in the Computer field.

Back on your EC2 instance’s page on the AWS dashboard, click Connect and then switch to the RDP Client tab. Then select Get Password and upload the .pem private key file you downloaded earlier to decrypt the password. When you click Connect to start the session, the default username is Administrator and you’ll be able to copy and paste the password to authenticate and connect to the server.

Once you’re finished and the RDP client has done its thing, you should see your Windows Server 2019 desktop. You can now use your cloud server as though it was a physical computer on your desk.

You can now use your virtual server for whatever your heart desires - just make sure you remember to stop it on the EC2 Dashboard whenever you’re finished using it so you don’t incur any extra costs.

This was, of course, a very simple deployment. Setting up an enterprise-scale AWS environment would require much more planning and architecture design to ensure efficiency and security. However, a simple VPC and server is a good starting point, and this is something I’ll build on in a few more posts that will cover the deployment of commonly used AWS services like databases and S3 buckets.