My first goal was to use Amazon Glacier to provide off-site backup of all of the data I'm already backing up locally. The iTinker network includes three Synology network attacked storage devices, one dedicated to shared data including a multimedia library, one that is my primary VMware datastore, and a third dedicated to backup. Synology makes it very easy to backup data to cloud storage providers, including Amazon Glacier. I've been very happy with this particular backup strategy and my introduction to AWS.
When I first looked at the AWS console I was overwhelmed by the range of services offered. I still am.
I had been considering upgrading the iTinker.net VMware resources. I thought about getting more powerful host hardware that would support more datacenter memory and networking capacity in particular. Then I decided that instead of adding more physical infrastructure I would supplement my network in the cloud.
Amazon's documentation is wonderful. After reviewing Getting Started with AWS I was off to the races. AWS virtual computers are called "instances" and the web service that provides the computing capacity is known as the Amazon Elastic Compute Cloud or more commonly, "EC2". Instances live in an Amazon Virtual Private Cloud, usually just called a "VPC".
Amazon's documentation and online wizards make it easy to start building a network that can include both public and private computers. In less than thirty minutes I had built a public facing web server with a blogging tool on a linux platform and then, just to complete the exercise, I did the same thing on a Windows Server 2012 platform. All of this was well within the constraints of the free tier.
After learning about Amazon security groups (which serve as a way to implement traditional firewall services) and route tables (which identify routing rules for networks and sub-networks independent of any particular computer), I decided to deploy a VPC with the following characteristics.
- The VPC will have two sub-networks, one public facing and one private.
- The private subnet will make use of Network Address Translation to allow private instances to access internet resources without being exposed to the internet more generally.
- The public subnet will include a device to allow me to administer the private instances, a so-called bastion.
- The VPC will include a site-to-site virtual private network connection to the current iTinker.net network so that computers on the current network and in the AWS VPC can connect without additional software. And yes, I realize that once this element is in place I don't need the bastion, but it's a learning exercise.
Amazon provides many wizards to automatically create a great deal (nearly all) of what I seek. For example, the VPC creation wizard will create a VPC with public and private subnets, a NAT gateway and hardware VPN where my only task would be to attach the VPC VPN to my existing network. Nevertheless, in order to understand things better, I will build by hand elements that I find particularly interesting.
Finally, I note that Amazon typically provides several ways to solve any given problem with various pros and cons of any approach and some guidance to help make good choices. I will tend to build things to minimize cost and trade off ease of implementation or maintenance or capacity or high availability. In a production environment I'd certainly rethink many of the decisions.
My next post will discuss the NAT instance I built. After that I will get into virtual private networking issues.