In my last post, I covered what Amazon Web Services (AWS) is. In this post, I’ll cover some of the more popular services that provide the majority of the utility and benefits. If your company starts using AWS, it’s highly likely that you’ll be using one or more of the following services:
Amazon Simple Storage Service (Amazon S3)
Amazon S3 is where many AWS customers begin. It’s a simple Write Once Read Many (WORM) object store that lets users securely, durably, and cost-effectively store assets in a Region. “Write once” means that an object cannot be changed after it is written, and “read many” means that multiple copies of the object are made.
So, when users access the file, many users can retrieve the file quickly (by doing parallel reads across many disk heads). When a user puts an object into Amazon S3, multiple copies of that object are made on multiple servers across multiple AZs. This means that the file is highly durable and data loss is nearly impossible.
Amazon S3 is especially well suited for storing and serving static web assets like HTML, CSS, JavaScript, and image files. When users load a web page in their browser, the browser makes a remote call every time it hits a CSS, JavaScript, and image tag. If Amazon S3 is used to serve those assets, it can typically serve the assets much faster than your company website, which now runs much faster since it’s only serving HTML.
Amazon Elastic Compute Cloud (EC2) and Amazon Elastic Block Store (EBS)
It’s estimated that most customers spend north of 70% of their AWS bill on Amazon EC2 instances alone.
Amazon EC2 is likely to be at the heart of your AWS deployment. At its essence, Amazon EC2 is simply a virtual server that contains a hardware footprint (known as an “instance type”) and a software footprint (known as an Amazon Machine Image or “AMI”). There are currently 18 instance types available, with varying amounts of CPU, RAM, and local storage. Some even offer SSD disks.
You’ll typically start out with an Amazon-provided vanilla basic that is OS only (both Linux and Windows supported), and then you will install and configure your application into that AMI. Amazon gives you the ability to burn a custom AMI (also known as a “golden image”) of your software, and then, for instance, you can use that image to deploy other servers of that type (think of a farm of web servers, all configured exactly the same, sitting behind a load balancer).
Amazon also now offers a “Marketplace” that contains thousands of vendor-provided AMIs that you can launch. The Marketplace can be a great way to evaluate a particular piece of software before deciding to purchase. Many companies use Amazon EC2 with Auto Scaling (discussed later) to allow their web apps to automatically scale up to and serve variable peak demand, while automatically scaling down to very small numbers of servers (which saves money) during low usage times like nights and weekends.
Although most of the instance types come with some local disk, that disk is volatile and tied directly to the instance’s lifetime. If, like most AWS customers, you need a persistent disk that exists independent of instance lifetime, you’ll soon be using Amazon EBS.
Amazon EBS functions nearly the same as a physical 3.5-inch disk that you would install directly into a server.
You first provision the size (and optionally I/O throughput) of the volume, and then you attach one or more volumes to a single Amazon EC2 instance, format them, and use them for Amazon EC2-accessible storage. Amazon EBS is very fast—in most cases faster than even local disk—and a user could even stripe multiple volumes together for very fast reads and writes. Amazon EBS is a great place to store database data, but if you’re looking for a database, AWS has an even better option.
Amazon Relational Database Service (Amazon RDS)
Amazon RDS is a fully managed, administration-free install of MySQL, Oracle, or SQL Server. Like many AWS managed services, the user gives up some control (like fine-tuning performance) in exchange for having an easy-to-use, scalable database.
With Amazon RDS, a user provisions a server type (similar to the Amazon EC2 instance types) and receives a client interface URL against which they can interact with their database. The exposed interface can then be used to create, insert into, and query database tables.
Like Amazon EC2, the user can resize their instance up or down and can attach security groups—stateful, easy– to-configure firewalls that limit access to the resource.
With Amazon RDS, setting up weekly or daily database backups is as simple as using a checkbox in the web GUI. For MySQL particularly, Amazon RDS allows quick, easy setup of Slaves and Read Replicas, allowing your database layer to be fault tolerant and scale up with read volume.
Auto Scaling, Elastic Load Balancing, and Amazon CloudWatch
With the popularity of smartphones and tablets, more users are increasingly creating greater demands on websites and the back-end servers. There’s also arguably more variability in the minute-to-minute load on a website, with bursts of traffic from email drops and press releases becoming trickles of traffic later on that evening when users are in bed.
Non-cloud websites would have dealt with that traffic by over-provisioning and under-utilizing large farms of servers, configured for the expected peak demand, plus maybe 10%. The problem with these architectures was not only the waste associated with powering and cooling (say, 100 servers at night when you only need two), but also with an even worse scenario of not keeping ahead of demand (having perhaps 100 servers when you really need 200).
Auto Scaling solves this problem by dynamically growing and shrinking the number of servers you need based on the real-time demand. Auto Scaling typically involves three services: Auto Scaling groups, Amazon CloudWatch alarms, and Elastic Load Balancing.
You simply preconfigure your Auto Scaling group to absolute maximums, minimums, Amazon EC2 instance types, and AMI, and then set up several Amazon CloudWatch alarms to monitor metrics (like load balancing requests), and dynamically add and remove instances from the group (and from the load balancing rotation).
As your Elastic Load Balancing then sees request volume increase and decrease, it fires the preconfigured Amazon CloudWatch alarms, which then immediately add capacity to or take capacity from your web tier. No more underutilization, and most importantly, no more serving 404s to users because you don’t have enough servers to deal with their requests.
This content was adapted from the Global Knowledge white paper Amazon Web Services: An Overview.
Related Courses
AWS Essentials
Architecting on AWS
Developing on AWS