Amazon EC2 instance types, auto scaling and load balancers

Why this matters

Compute is the part of the bill most organisations notice first, and it is where the promises of the cloud are either kept or wasted. A company that moves its servers to AWS but sizes them for the busiest day of the year, runs them all month and puts them all behind nothing, has rented a data centre at a higher price. A company that picks the right kind of server, lets the fleet grow and shrink with demand, and spreads traffic across it, pays for what it uses and stays up when a server fails.

You do not need to build any of this to pass Cloud Practitioner, but you do need the vocabulary. A manager approving a budget should know why "memory optimized" costs more than "general purpose" and when it is worth it. A salesperson should be able to explain that elasticity is a feature you switch on, not something that happens by itself. A junior engineer will meet Auto Scaling groups and load balancers in their first week.

The exam tests this with short scenarios: a workload is described, and you pick the instance family, the service or the mechanism that fits. The clues are usually one or two words in the question.

The lesson

AWS compute services

Compute means the processing power that runs your software. AWS offers it in several forms, from servers you control completely to code that runs with no server in sight.

Amazon Elastic Compute Cloud (Amazon EC2) provides virtual servers, called instances. You choose an Amazon Machine Image (AMI), a template holding the operating system and any pre-installed software, and an instance type, which sets the processor, memory, storage and network capacity. You get full control of the operating system, and with it the responsibility for patching and securing it, as lesson 6 explains. Each instance runs in one Availability Zone, as lesson 13 describes.

Several other compute services trade some of that control for simplicity:

• Amazon Lightsail bundles a virtual private server, storage and networking for a predictable monthly price. It suits a simple website, a small business or a developer trying something out, without assembling many separate AWS services.
• AWS Batch runs large numbers of batch computing jobs, work that can be queued and processed without a person waiting for it, and provisions the compute those jobs need.
• AWS Elastic Beanstalk takes your application code and handles the provisioning, load balancing, scaling and monitoring for you, while leaving the underlying resources visible and adjustable.
• AWS Outposts puts AWS-managed infrastructure in the customer's own building, for workloads that must stay on premises but should use AWS services and tools.

Containers and serverless compute, including Amazon ECS, Amazon EKS, AWS Fargate and AWS Lambda, are the subject of lesson 15.

One point of confusion to clear early: "instance type" means the hardware profile of an instance. On-Demand Instances, Reserved Instances, Savings Plans and Spot Instances are ways of paying for instances, and they are covered in lesson 23. A question about what kind of workload fits which hardware is about instance types; a question about commitment and discounts is about purchasing options.

Choosing an Amazon EC2 instance type: general purpose, compute, memory, storage and accelerated

AWS groups instance types into families, each tuned for a different bottleneck. Within a family, sizes run from small to very large, so you choose the family for the kind of work and the size for the amount of it. Learn the families by what limits the workload.

• General purpose: a balance of compute, memory and networking. Use it when no single resource dominates, such as web servers, code repositories, small databases and development environments. It is the sensible default.
• Compute optimized: high-performance processors for compute-bound work, where the processor is the limit. Examples are batch processing, media transcoding, high-performance web servers, scientific modelling, high performance computing (HPC) and dedicated gaming servers.
• Memory optimized: large amounts of memory for workloads that process big data sets held in memory. Examples are in-memory databases, in-memory caches and real-time analytics on large data sets.
• Storage optimized: very high, sequential read and write access to large data sets on local storage, the disks physically attached to the host. Examples are data warehousing, distributed file systems and high-volume transaction processing.
• Accelerated computing: hardware accelerators such as graphics processing units (GPUs) that run certain calculations far faster than a general processor. Examples are machine learning training, graphics processing and video rendering.

Picking a bigger family than the workload needs costs money for nothing. A web server on a memory optimized instance pays for memory it never uses. Matching the instance to the real need is called rightsizing, and AWS Compute Optimizer can recommend sizes from observed usage. Lesson 5 covers rightsizing in more depth.

The scenario words to watch: "balance" points to general purpose; "high-performance processors", "batch" or "scientific modelling" to compute optimized; "in-memory" or "large data sets in memory" to memory optimized; "sequential read and write" or "data warehouse on local storage" to storage optimized; "GPU", "machine learning training" or "graphics" to accelerated computing.

Recognizing that auto scaling provides elasticity

Elasticity is the ability to acquire resources as demand rises and release them as it falls, automatically and quickly. It is one of the core benefits of the cloud, set out in lesson 1. The traditional alternative is to buy capacity months ahead for the demand you guess you will have, which means paying for idle servers most of the time, or running out at the peak if the guess was low.

Amazon EC2 Auto Scaling delivers elasticity for EC2. You create an Auto Scaling group, a collection of instances treated as one unit, and set three numbers:

• a minimum, the fewest instances the group will ever run;
• a maximum, a ceiling that caps cost;
• a desired capacity, the number it aims for right now.

Scaling policies then adjust the desired capacity. A policy can follow a metric from Amazon CloudWatch, such as average processor use, adding instances when it is high and removing them when it is low. It can follow a schedule, for example adding capacity before a known sale. Predictive scaling uses past patterns to add capacity ahead of a regular rise.

Auto Scaling groups also self-heal. If an instance fails its health check, the group terminates it and launches a replacement, keeping the desired number of instances healthy without an operator stepping in. A group can span several Availability Zones, so capacity lost in one is replaced in another.

AWS Auto Scaling is a separate service that sets up scaling across several kinds of resource at once, such as EC2 Auto Scaling groups, Amazon ECS services and Amazon DynamoDB tables, from one place.

Two contrasts the exam leans on. Adding more instances (scaling out) is what auto scaling does; replacing an instance with a bigger one (scaling up) is a different move and is not elastic in the same way. And a fixed fleet sized for the busiest day, or Reserved Instances bought for the peak, will cope with the peak but provide no elasticity: the capacity sits there, paid for, when demand is low.

Identifying the purposes of load balancers

A load balancer sits in front of a group of servers and spreads incoming requests across them. Elastic Load Balancing (ELB) is the AWS managed load balancing service. Its purposes are:

• Distributing traffic across multiple targets, such as EC2 instances, containers or IP addresses, so no single server is overwhelmed.
• Spanning Availability Zones, so the application survives the loss of one AZ.
• Health checks: the load balancer regularly tests each target and sends requests only to healthy ones. An instance that fails its health checks stops receiving traffic.
• A single point of contact: users reach one address, the load balancer's, rather than the address of any particular server. Servers can be added, removed or replaced behind it without users noticing.

ELB is a managed service, so AWS runs and scales the load balancer itself. It works within one Region.

ELB offers several load balancer types. An Application Load Balancer works with web traffic (HTTP and HTTPS) and can route requests by their content, such as sending requests for one path to one group of servers and another path elsewhere. A Network Load Balancer handles TCP and UDP traffic at very high performance. A Gateway Load Balancer places third-party virtual appliances, such as firewalls, in the path of traffic. At Cloud Practitioner level, knowing that these exist and that web traffic points to the Application Load Balancer is enough.

Load balancing and auto scaling are different jobs that are usually used together. Auto scaling changes how many instances there are; the load balancer decides which instance gets each request. When an Auto Scaling group is attached to a load balancer, each new instance it launches is registered automatically and starts receiving traffic once it passes its health checks.

Watch for wrong answers that borrow another service's job. Caching static content at edge locations is Amazon CloudFront. Recording the API calls made in an account is AWS CloudTrail. Encrypting EBS volumes is a storage setting. Copying data between Regions is replication. None of these is a purpose of a load balancer.

What the exam is really asking

Most questions in this area reduce to three questions of your own. What is the bottleneck? That picks the instance family. Does demand change? That points to auto scaling and elasticity. Must traffic be shared, or must failed servers be avoided? That points to a load balancer. If the business is small and wants a simple server at a predictable monthly price, the answer is Lightsail rather than assembling EC2 parts.