I am often asked by C-levels, directors and managers about the ins and outs of Amazon Web Services. They’re not looking for the essential nuances of scripting with the Elastic Compute Cloud API, they’re just interested in the overview of how the ‘cloud’ works.
When first explaining AWS to managers (or anyone else) it’s better to talk in concepts than concrete terms. I have also found it beneficial to try to make the discussion tangible with familiar terms. Using terms like “Elastic IP” draws quizzical looks, but calling it a publicly accessible IP address helps people get a better overall understanding of the concepts before using AWS terms for things.
hierarchical organization
At a very high level, you can think of EC2 as a global computing environment. Within EC2 there are geographic regions that can be thought of as data centers. Within these data centers are clusters of computers that in AWS parlance are called Availability Zones:
– EC2 (think: cloud)
—— Regions (think: data center)
————- Availability Zones (think: computer cluster)
Virtual machines
Within an Availability Zone, we can create virtual machines from pre-defined or custom Amazon Machine Images, or AMIs. An AMI can be thought of as a snapshot of the machine that you can upload and run within the cloud in an Availability Zone. Each time you take an AMI and start it, it is called an Instance of the AMI. You can take an AMI and start it multiple times, each time you create a new instance.
Instances are virtual machines that are running, and I really mean virtual. If precautions are not taken, these virtual machines can cease to exist and cause great consternation. So you really don’t want to think of an Instance as something robust and persistent. It is simply a unit of computational resources.
virtual hard drives
To help keep your data intact even when an Instance dies, you can use a number of different AWS services, but one of the most common is Elastic Block Store, or EBS. Think of EBS like a hard drive. You can create a 1GB to 1TB EBS and ‘install’ it on any of your virtual machine instances. So if you have an instance running your website and you want to make sure the database stays healthy even if the instance goes away, you can use an EBS “hard drive”. In the AWS vernacular, you created an EBS volume and mounted it to an instance.
Other virtual storage
There are other services you could have used besides EBS to maintain this imaginary database of yours. For example, SimpleDB, or SDB, is a perfectly reasonable substitute and would be preferable in certain situations. However, SDB is a specific service for basic database delivery, while EBS is a generalized storage solution. There is also the Relational Database Service, or RDS, which provides robust database services beyond SDB. The choice of service often depends on the needs of the solution.
virtual backup
If we want to protect the data we now have on our EBS volume, we’re not out of the woods yet because even hard drives can fail. We’ll want to back this up to more stable storage. For this we can use the Simple Storage Solution, or S3 for short. You can think of S3 as a readily available tape backup. It allows you to have up to 100 data directories on your tape. Each of these directories is called a bucket in the S3 world. Because it’s a good stable storage system, you’ll want to back up your EBS volume(s) to S3 periodically. And, if you’ve customized your Instance, you’ll also want to save a new image to S3. This way, if your carefully customized Instance or EBS volume fails for some reason, you can get them out of their S3 backup fairly quickly and back up and running.
robust security
Well, all of this would be pointless if we didn’t have good security to make sure our solution would get hacked. Two concepts are used in AWS for security reasons. The first is a set of keys that allows you and your developers to gain access to your systems. These are public/private key pairs and digital certificates required to securely log in to the Instance. The second, called the security group, can be thought of as a firewall setting. You create a security group that defines how external entities such as web browsers, remote desktops, ftp, email, etc. – may or may not access your Instance.
virtual router
In order to serve our website to the public, we will need to have a permanent public IP address that we can assign to our Instance. To do this we use an Elastic IP, or EIP. It is ‘elastic’ because although it is a fixed public IP on the Internet, it can be assigned to any of our Instances within AWS. This is a huge advantage because if that Instance dies and we activate a new Instance, we can move the EIP to this new Instance and minimize site outages.
Cloud scalability
Our site is up and running on our Instance, our data is safe on an EBS volume, we have S3 backups, very secure given our engineers access, and we have our site publicly accessible. Everything is going well up to the point where we discover an increase in traffic from other parts of the world. Our site appears to be popular in a geographical region distant from the region in which we set up our system. For example, we may have established our website in the US, but we get 50% of our visits from Europe. The performance of our site for our European visitors will not be as good as we would like. Fortunately, we can bring our site to these users through the content delivery network or CDN.
On AWS, CloudFront provides the CDN services. This service takes your static content and replicates it closer to where you have a high volume of users, making your site delivery much faster.
Conclusion
I hope this helps anyone who is interested in AWS and just needs a manager’s overview of how it all works from a conceptual perspective. Please note that AWS is an ever-evolving system and new services and capabilities are added regularly.
Resources
To learn more about Amazon Web Services, visit these important links:
- Amazon Web Services
- Technical Documentation for AWS