How do you make sure a website stays fast and available even when millions of people try to visit it at the same time? That is the core problem Elastic Load Balancing (ELB) and Auto Scaling solve together, and it is one of the most heavily tested topics on the SOA-C02 exam. Understanding these two services is critical because they are the backbone of high-availability architecture in AWS — your ability to design, configure, and troubleshoot them will determine whether your applications survive traffic spikes or crash.
Jump to a section
A food truck rally serves hundreds of hungry customers who arrive at unpredictable times and in unpredictable numbers. The rally organiser's primary job is to keep customers happy by making sure no single truck gets overwhelmed while others sit idle, and that enough trucks are operating to meet demand without wasting food or fuel.
The organiser sets up a central ordering station — the load balancer. Customers line up here, and the station directs each person to the truck that is currently least busy. If a truck's queue gets too long, the station sends new customers elsewhere. If a truck breaks down, the station stops sending people there and distributes its customers to the remaining trucks. This is exactly how an Application Load Balancer distributes incoming web traffic across multiple servers.
But what happens when a massive lunchtime crowd arrives? The organiser has a fleet of reserve trucks parked nearby. When the waiting time at the main station exceeds a set threshold, she radios the reserve trucks to start cooking and join the rally. When the rush ends and trucks are standing idle, she sends the extras back to the depot. This is Auto Scaling — automatically adding or removing server capacity based on real-time demand, ensuring you never pay for trucks you do not need and never leave customers waiting too long.
Let us start with the fundamental problem every web application faces: too many users at once. Without help, a single server can only handle a limited number of simultaneous connections. When that limit is exceeded, new visitors see errors, pages load slowly, or the server crashes entirely. Elastic Load Balancing (ELB) and Auto Scaling are the two AWS services designed to prevent this.
Elastic Load Balancing is a service that automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances (virtual servers), containers, or even on-premises servers. The 'load balancer' sits in front of your servers and acts as a single point of contact for users. When a user requests your website, the request goes to the load balancer, which then forwards it to one of the healthy servers behind it. This distribution prevents any single server from becoming a bottleneck.
AWS offers three types of load balancers, and the SOA-C02 exam expects you to know the differences: the Application Load Balancer (ALB), the Network Load Balancer (NLB), and the Classic Load Balancer (CLB). The ALB operates at the application layer (Layer 7 of the OSI model), meaning it can inspect the content of web traffic — it can route requests based on URL path, hostname, or query string parameters. For example, you could send all requests for \/images to one group of servers and \/api to another. The NLB operates at the transport layer (Layer 4), handling millions of requests per second with extremely low latency by routing based on IP address and port number. The CLB is the older generation; AWS recommends migrating away from it because ALB and NLB offer more features and better performance.
A load balancer also performs health checks. It regularly sends a small test request to each target (for example, pinging a specific URL like \/health). If a target does not respond correctly within a configured timeout period, the load balancer marks it as unhealthy and stops sending traffic to it. Once the target recovers and passes health checks again, traffic resumes. This ensures users never accidentally visit a broken server.
Now, Auto Scaling. Auto Scaling is a service that automatically adjusts the number of EC2 instances in a group — called an Auto Scaling group (ASG) — based on conditions you define. The ASG has a minimum, maximum, and desired capacity. For example, you might set minimum to 2 (so you always have at least two servers running), maximum to 10 (so you never spend more than necessary), and desired capacity to 2 (the starting number). When CPU utilisation across your instances rises above, say, 70 per cent for five minutes, Auto Scaling can launch additional instances from a launch template (a blueprint specifying the Amazon Machine Image, instance type, security groups, and so on). When utilisation drops, Auto Scaling terminates instances to save costs.
There are three main scaling policy types: simple scaling, step scaling, and target tracking scaling. Simple scaling is the oldest — you define a CloudWatch alarm, and when it triggers, the ASG adds or removes a fixed number of instances. Step scaling allows more granularity: you can say 'if CPU is between 70 and 80 per cent, add 2 instances; if CPU is above 80 per cent, add 5 instances,' which gives faster response to larger spikes. Target tracking is the easiest and most modern: you pick a metric and a target value (like average CPU at 60 per cent), and AWS automatically adjusts the number of instances to keep the metric close to that target, much like a thermostat maintains a room temperature.
These two services are designed to work together. You register the Auto Scaling group as the target for your load balancer. As Auto Scaling adds or removes instances, the load balancer automatically discovers the new instances and begins routing traffic to them. The health checks performed by the load balancer also feed into the Auto Scaling group: if the load balancer marks an instance unhealthy, the ASG can terminate it and replace it with a fresh one. This combination creates a self-healing, cost-efficient, and scalable architecture.
1. Create a Launch Template
A launch template is a blueprint for new EC2 instances. It specifies the AMI (operating system), instance type, security groups, key pair, and user data (startup script). You cannot create an Auto Scaling group without one. AWS recommends launch templates over the older launch configurations because templates support versioning and more features.
2. Create a Target Group
A target group is a logical grouping of targets (EC2 instances, IP addresses, or Lambda functions) that the load balancer will route traffic to. You configure a health check path (e.g., \/health), interval, timeout, and unhealthy threshold. The load balancer will only send traffic to targets that pass these health checks.
3. Create an Application Load Balancer
You configure the ALB with a name, scheme (internet-facing or internal), and listeners (the ports and protocols the ALB listens on, like HTTP:80 or HTTPS:443). You associate it with one or more subnet IDs across different Availability Zones. You then define a default action: forward requests to your target group.
4. Create an Auto Scaling Group
You define the ASG with a name, the launch template from step 1, the VPC and subnets (choose at least two Availability Zones), and the desired/minimum/maximum capacities. You attach the target group from step 2, so new instances are automatically registered. You then add a scaling policy — target tracking based on Average CPU is a good starting point.
5. Test and Monitor
Generate traffic to the ALB's DNS name. Verify that traffic is distributed across instances using the CloudWatch metrics for the ALB (RequestCount, ActiveConnectionCount) and the ASG (GroupMinSize, GroupMaxSize, GroupDesiredCapacity). Check that health checks pass and that scaling activities occur. Use the 'Activity History' tab of the ASG to see launch and termination events.
Imagine you work as a junior cloud administrator for a company called ShopFast, an online retailer. ShopFast runs a web application on a fleet of Amazon EC2 instances behind an Application Load Balancer. Your job is to ensure the website stays up during the Black Friday sale, when traffic might increase tenfold in minutes.
You begin by creating a launch template. This template specifies the Amazon Machine Image (AMI), which is the operating system and pre-installed software. You choose an Amazon Linux 2 AMI, an instance type of t3.medium, and configure the security group to allow HTTP and HTTPS traffic from the load balancer only. You also include a script in the user data section that installs the web application and joins the instance to the Auto Scaling group.
Next, you create an Auto Scaling group with a minimum capacity of 3, a maximum of 20, and a desired capacity of 3. You attach the ALB target group to the ASG, so every new instance automatically registers with the load balancer. You configure a target tracking scaling policy based on average CPU utilisation at 50 per cent. You also set up a scheduled scaling action: for Black Friday, from 6 AM to 10 PM, you increase the minimum capacity to 10 so the site has a running start before the rush.
As Black Friday begins, you monitor the CloudWatch dashboards. You see that CPU utilisation climbs to 60 per cent. Auto Scaling responds by launching two new instances. A few minutes later, utilisation settles back to 50 per cent. At 10 PM, traffic drops off, and Auto Scaling gradually terminates the extra instances until you are back to the scheduled minimum of 10. The ALB health checks catch a misconfigured instance that fails the \/health endpoint; it is marked unhealthy and automatically replaced. The site stays fast and responsive all day, and you did not have to manually add or remove a single server.
Key tasks you perform as a SysOps administrator include:
Creating and maintaining launch templates or launch configurations (though AWS now recommends launch templates).
Configuring load balancer listeners and rules for path-based routing.
Setting up CloudWatch alarms to trigger scaling actions.
Adjusting health check thresholds and intervals to match application behaviour.
Testing scaling policies with load generators before big events.
Troubleshooting instances that are marked unhealthy despite being functional (often a misconfigured health check path or security group).
The SOA-C02 exam loves to test Elastic Load Balancing and Auto Scaling in scenarios that require you to choose the correct combination of services, interpret health check behaviours, and understand what happens when configurations conflict. Expect 6-10 questions on these topics, often scenario-based.
Key topic areas and how they are tested:
Types of load balancers: You must know when to use ALB versus NLB. The exam will give you a scenario like 'application needs to route based on HTTP header' — answer is ALB. 'Ultra-low latency for a TCP-based game' — answer is NLB. The Classic Load Balancer appears in legacy scenarios; the exam expects you to know why it should be avoided.
Sticky sessions (session affinity): ALB supports sticky sessions using cookies. The exam might ask you to enable this for a stateful application. Trap: sticky sessions can cause uneven load distribution if not paired with proper scaling.
Cross-zone load balancing: When enabled (default for ALB), the load balancer distributes traffic evenly across all targets in all Availability Zones. Disabling it can cause imbalances. The exam tests that you know how to enable this for NLB to avoid uneven distribution.
Connection draining (deregistration delay): When an instance is deregistered from the target group, the load balancer stops sending new requests but allows in-flight requests to complete within a configurable time (default 300 seconds). The exam traps you by asking what happens when you remove an instance without draining — active connections drop.
Auto Scaling cooldowns and warm-up: After a scaling activity, there is a cooldown period (default 300 seconds) during which the ASG does not launch or terminate additional instances. The exam tests that you understand this prevents flapping. Warm-up time for target groups is a separate concept to make sure the load balancer does not overwhelm new instances.
Scaling policies: You must differentiate between simple, step, and target tracking. The exam frequently asks which policy type is easiest to maintain — answer is target tracking.
Lifecycle hooks: These pause instance launch or termination so you can run custom actions (e.g., install software, download logs). The exam tests that you know lifecycle hooks need a custom notification via SNS or a Lambda function to complete.
Termination policy: The ASG has a default termination policy that selects the instance with the oldest launch configuration, then the one closest to the next billing hour, and so on. You may be asked to choose a custom termination policy to protect specific instances.
Common traps:
Confusing the target group with the Auto Scaling group. The target group is where the load balancer sends traffic; the ASG manages instance count.
Forgetting that an ASG can be attached to multiple load balancers, but a load balancer can only be associated with one ASG per target group.
Assuming that an instance launched by Auto Scaling automatically survives a health check failure — it does not. The instance is marked unhealthy and terminated.
Mixing up the health check types: ELB health checks vs EC2 instance status checks. ELB health checks check the application; EC2 status checks check the underlying hypervisor.
Elastic Load Balancing automatically distributes incoming traffic across multiple targets to prevent any single server from being overwhelmed.
AWS offers three load balancer types: ALB for HTTP/HTTPS traffic with advanced routing, NLB for ultra-low latency TCP/UDP traffic, and CLB as a legacy option to avoid.
Auto Scaling groups maintain a specified minimum, maximum, and desired number of EC2 instances, launching and terminating instances automatically based on demand.
Target tracking scaling policies are the simplest and most recommended type, as they automatically adjust capacity to maintain a target metric (e.g., 60% CPU utilisation).
Integrating Auto Scaling with a load balancer creates a self-healing architecture: the load balancer's health checks trigger instance replacement by the Auto Scaling group.
Connection draining (deregistration delay) allows in-flight requests to complete before an instance is removed, preventing user disconnections.
Always deploy Auto Scaling instances across at least two Availability Zones to achieve high availability.
Lifecycle hooks let you run custom actions during instance launch or termination, but require an SNS topic or Lambda function to complete the hook.
These come up on the exam all the time. Here's how to tell them apart.
Application Load Balancer
Operates at Layer 7 (application layer), inspecting HTTP headers and content.
Supports path-based and host-based routing rules.
Offers features like SSL termination, sticky sessions, and WebSockets support.
Network Load Balancer
Operates at Layer 4 (transport layer), routing based on IP and port only.
Capable of handling millions of requests per second with ultra-low latency.
Preserves the client IP address, making it ideal for TCP/UDP applications.
Simple Scaling Policy
Requires you to create a CloudWatch alarm explicitly.
Adds or removes a fixed number of instances when the alarm triggers.
Has a cooldown period; can cause a slower reaction to changing demand.
Target Tracking Scaling Policy
No need to create a separate CloudWatch alarm; AWS creates and manages it for you.
Adjusts capacity dynamically to keep a chosen metric at a target value (e.g., 60%).
Simpler to manage and recommended by AWS for most use cases.
Connection Draining (Deregistration Delay)
Starts when an instance is deregistered from the target group.
Allows in-flight requests to complete before the instance is taken out.
Configurable from 0 to 3600 seconds.
Health Check Grace Period
Starts when an instance is launched by Auto Scaling.
Prevents the load balancer from marking a new instance as unhealthy before it finishes starting up.
Configurable per Auto Scaling group, not per target group.
Lifecycle Hook (Launch)
Pauses instance launch after the instance is running.
Useful for installing additional software, running configuration management.
Instance stays in 'Pending:Wait' state until you complete the hook.
Lifecycle Hook (Terminate)
Pauses instance termination before the instance is stopped.
Useful for downloading logs, backing up data before instance deletion.
Instance stays in 'Terminating:Wait' state until you complete the hook.
Mistake
You only need one large EC2 instance behind a load balancer — just make the instance bigger.
Correct
Scalability and high availability require multiple instances across multiple Availability Zones. A single large instance is a single point of failure; if it crashes, the entire application goes down regardless of the load balancer.
This mistake comes from thinking 'vertical scaling' (bigger instance) is the only answer. The exam emphasises 'horizontal scaling' (more instances) for resilience.
Mistake
Auto Scaling and Elastic Load Balancing are separate and have no effect on each other's operation.
Correct
They are tightly integrated. The load balancer performs health checks on instances, and an unhealthy instance is automatically terminated by the ASG. The load balancer also distributes traffic to all newly launched instances without manual registration.
Newcomers often study each service in isolation, missing the crucial interplay that the exam loves to test.
Mistake
The Classic Load Balancer is perfectly fine — it does everything the new ones do.
Correct
The CLB lacks features like path-based routing, host-based routing, and native HTTP/2 support. AWS recommends using ALB or NLB instead. The exam considers CLB legacy and tests your ability to choose the modern alternative.
Many older tutorials and blog posts still reference CLB, so beginners assume it is current.
Mistake
If I set my Auto Scaling group's minimum to 1, my application is highly available.
Correct
High availability requires at least 2 instances spread across different Availability Zones. A single instance in one AZ fails if that AZ experiences an outage.
The term 'high availability' is overused; beginners think one server can somehow be 'available' even if it is the only one.
Mistake
The load balancer will always route traffic equally to all instances.
Correct
Equal distribution depends on the routing algorithm. ALB uses a round-robin algorithm, but if you enable sticky sessions or if cross-zone load balancing is disabled (default for NLB), distribution can become uneven.
Beginners assume 'balancing' means perfect equality always, but real-world traffic patterns and session affinity can skew distribution.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. If you attach the Auto Scaling group to a target group, any instance launched by the ASG is automatically registered with the load balancer. When an instance is terminated, it is automatically deregistered.
The load balancer will stop routing traffic to all instances, and users will see a 503 Service Unavailable error. Auto Scaling will detect the unhealthy instances (if the health check grace period has passed) and terminate them, launching new ones in their place.
Yes. With an Application Load Balancer, you can add multiple listeners (e.g., port 443 for your main app and port 8080 for an admin panel). You can also use path-based routing rules to send \/api/* traffic to one target group and \/website/* to another.
An internet-facing load balancer has a public DNS name and can route traffic from the internet to your instances. An internal load balancer has a private IP address and is only accessible from within your VPC, often used for communication between application tiers.
Check that your CloudWatch alarm is in ALARM state, that the scaling policy is correctly configured, and that your launch template is valid (e.g., the AMI exists, the instance type is available). Also ensure the ASG has not reached its maximum capacity and that there are no service quotas limiting instance launches.
Desired capacity is the number of instances the ASG tries to maintain at any given time. Minimum capacity is the lower boundary; the ASG will never reduce the count below this number, even during scaling in. For example, minimum=2, maximum=10, desired=4 means the ASG starts with 4 instances and will not scale below 2.
You've just covered Elastic Load Balancing and Auto Scaling — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?