Study guide
Technical reference and lesson notes
Purpose of This Lesson
This lesson reviews the AWS Auto Scaling and Elastic Load Balancing features most likely to appear in architecture and troubleshooting questions. The central design pattern is to combine dynamically scaled compute capacity with a load balancer that distributes traffic across healthy targets and Availability Zones.
Key Concepts
EC2 Auto Scaling and Auto Scaling Groups
Amazon EC2 Auto Scaling provides horizontal scaling by launching and terminating EC2 instances automatically. An Auto Scaling Group (ASG) manages a collection of instances as a single unit and maintains the desired capacity within configured minimum and maximum limits.
Auto Scaling can respond to:
- CloudWatch metrics and application demand
- EC2 instance health status checks
- Elastic Load Balancing target health checks
- Scheduled capacity changes
Scaling policies determine how the ASG responds to changing demand. Scaling out adds instances; scaling in removes instances.
Auto Scaling Health Checks
An ASG can use two important categories of health checks:
- EC2 health checks: Use EC2 system and instance status information.
- ELB health checks: Use ELB target health in addition to EC2 health checks.
The health check grace period is the time after instance launch during which Auto Scaling does not replace an instance because of a failed health check. This allows time for operating system startup, application initialization, and registration with the load balancer.
A grace period that is too short can cause healthy-but-not-yet-ready instances to be replaced repeatedly. A period that is too long can delay recovery from genuinely unhealthy instances.
Monitoring Granularity
Monitoring settings affect how quickly scaling policies can react and whether additional charges apply:
| Monitoring option | Granularity | Charge | Notes |
|---|---|---|---|
| ASG group metrics | 1 minute | No additional charge | Must be enabled manually |
| EC2 basic monitoring | 5 minutes | No additional charge | Default instance-level monitoring |
| EC2 detailed monitoring | 1 minute | Charges apply | Useful when scaling decisions require faster metrics |
Scaling policies based on instance-level metrics may require detailed monitoring when five-minute data is not responsive enough for the workload.
Auto Scaling Operational Controls
- Cooldowns: Primarily associated with simple scaling policies. They prevent another scaling action before the effect of the previous action can be observed.
- Termination policies: Influence which instances are selected first during scale-in.
- Scale-in protection: Prevents selected instances from being terminated during scale-in. This is useful for instances performing important work, but it can prevent the ASG from reaching its desired capacity if too many instances are protected.
- Standby state: Temporarily removes an in-service instance from active service while keeping it within the ASG. It can be used for maintenance, troubleshooting, or updates.
- Lifecycle hooks: Pause an instance during launch or termination so custom actions can run. Examples include installing software after launch or allowing an instance to finish processing before termination.
Elastic Load Balancing
Elastic Load Balancing distributes incoming traffic across registered targets, such as:
- EC2 instances
- IP addresses
- Containers
- Lambda functions, where supported by the load balancer type and target group configuration
A load balancer improves availability by routing requests to healthy targets. It can be deployed across multiple Availability Zones, but only one subnet per Availability Zone can be enabled for a particular load balancer.
For an ELB subnet, plan for at least a /27 subnet with at least eight available IP addresses so the load balancer has room to scale. A subnet that is technically large enough but nearly exhausted can create operational problems.
Internet-Facing and Internal Load Balancers
An internet-facing load balancer has publicly reachable nodes and requires a public subnet in each enabled Availability Zone. It can route traffic to targets using their private IP addresses, including instances in private subnets.
An internal load balancer has private IP addresses and is reachable only through private network connectivity, such as within a VPC or through connected networks.
The targets do not need to be in the same subnet as the load balancer. The important requirements are appropriate routing, security group or network ACL rules, and target registration.
Load Balancer Types
| Load balancer | Primary layer and protocol | Best-fit scenarios | Important characteristics |
|---|---|---|---|
| Application Load Balancer (ALB) | Layer 7; HTTP/HTTPS | Web applications, path- or host-based routing, microservices, containers, Lambda targets | Application-aware routing and HTTP features |
| Network Load Balancer (NLB) | Layer 4; TCP/UDP | Non-HTTP applications, high-performance traffic, ultra-low latency, static IP requirements | Supports static IP addresses and VPC endpoint services |
| Gateway Load Balancer (GWLB) | Layer 3 | Firewalls, IDS/IPS, traffic inspection, and other virtual appliances | Uses GENEVE encapsulation on port 6081 |
Choose an ALB when routing decisions depend on HTTP attributes such as hostnames or URL paths. Choose an NLB when the application requires TCP/UDP handling, very low latency, or static IP addresses. Choose a GWLB when traffic must be transparently directed through a fleet of security or inspection appliances.
Cross-Zone Load Balancing
Cross-zone load balancing determines whether each load balancer node can send traffic to targets in every enabled Availability Zone:
- Enabled: Each node distributes traffic across targets in all enabled AZs.
- Disabled: Each node distributes traffic only to targets in its own AZ.
For ALB, cross-zone load balancing is always enabled. For NLB and GWLB, it is disabled by default and must be considered explicitly during design.
If cross-zone balancing is disabled and target counts are uneven across AZs, traffic distribution may be uneven. If it is enabled, traffic can cross AZ boundaries, which may have cost or data-transfer implications depending on the architecture.
Exam-Relevant Takeaways
- Auto Scaling is horizontal scaling: it adds or removes EC2 instances rather than making one instance larger.
- An ASG manages instances collectively and maintains capacity within its configured limits.
- ELB health checks allow an ASG to replace instances that are running at the EC2 level but not serving application traffic correctly.
- The health check grace period prevents premature replacement during startup.
- ASG group metrics are one-minute metrics and must be enabled manually.
- Internet-facing load balancers require a public subnet in every enabled AZ, even when their targets are in private subnets.
- Only one subnet per AZ can be associated with a load balancer.
- ALB is the usual choice for HTTP/HTTPS and Layer 7 routing.
- NLB is the usual choice for TCP/UDP, ultra-low latency, static IP addresses, or VPC endpoint services.
- GWLB is designed for virtual network appliances and uses GENEVE on port
6081. - ALB always uses cross-zone load balancing; NLB and GWLB have it disabled by default.
Architecture Decision Guide
| Requirement | Recommended choice | Reason |
|---|---|---|
| Route HTTP requests by host or URL path | ALB | Layer 7 request-aware routing |
| Distribute traffic to containers or Lambda using HTTP/HTTPS | ALB | Supports these target patterns and application protocols |
| Support TCP or UDP applications | NLB | Layer 4 protocol support |
| Provide static load balancer IP addresses | NLB | Designed for stable IP address requirements |
| Expose a service through a VPC endpoint service | NLB | Supports endpoint service integrations |
| Insert firewalls or inspection appliances into traffic flows | GWLB | Built for virtual appliance fleets |
| Add or remove EC2 capacity based on demand | ASG | Automated horizontal scaling |
| Run setup or cleanup tasks during instance lifecycle changes | ASG lifecycle hook | Pauses launch or termination workflows |
| Temporarily remove an instance for maintenance | ASG standby | Takes an instance out of service without immediately removing it from the group |
Common Exam Traps
- Confusing an internet-facing load balancer with public targets: The load balancer can be public while the EC2 targets remain in private subnets.
- Putting an internet-facing ELB in private subnets: It needs a public subnet in each enabled AZ so its nodes can receive internet traffic.
- Assuming every load balancer uses Layer 7 routing: NLB is Layer 4, while GWLB is used for IP traffic and appliance insertion.
- Forgetting the health check grace period: A newly launched instance can be replaced before initialization completes if the grace period is too short.
- Treating ASG cooldowns as a universal solution: Cooldowns are associated with simple scaling policies; other policy types use their own evaluation and stabilization behavior.
- Assuming cross-zone balancing is always enabled: It is always enabled for ALB, but disabled by default for NLB and GWLB.
- Ignoring ELB subnet capacity: A subnet should be at least
/27and have at least eight available IP addresses for load balancer scaling. - Confusing scale-in protection with permanent protection: Protection affects ASG scale-in decisions; it does not make an instance immune to every possible termination or failure.
Real-World Engineer Notes
- Use ELB target health checks that test meaningful application readiness, not merely whether a process is listening on a port.
- Align the health check grace period with real startup time, including bootstrapping, package installation, configuration retrieval, and application warm-up.
- Distribute ASG capacity across multiple AZs and ensure each AZ has appropriate subnets and routing.
- Keep enough free IP capacity in ELB subnets. Subnet exhaustion can prevent scaling even when the application has sufficient compute capacity.
- Use lifecycle hooks carefully. A hook that never completes can leave instances stuck in a pending or terminating state.
- When using NLB or GWLB without cross-zone balancing, maintain balanced target capacity across AZs to avoid uneven utilization.
- For scale-in-sensitive workloads, design for graceful shutdown and use lifecycle hooks or deregistration delays so in-flight work is not abruptly interrupted.
Quick Reference Summary
- ASG: Automatically launches and terminates EC2 instances.
- Scaling model: Horizontal; scale out and scale in.
- Health checks: EC2 checks by default; ELB checks can add application target health.
- Grace period: Delay before newly launched instances are evaluated for replacement.
- ALB: HTTP/HTTPS, Layer 7, host/path routing, containers, and Lambda targets.
- NLB: TCP/UDP, low latency, static IPs, and VPC endpoint services.
- GWLB: Virtual appliances, IP traffic, GENEVE port
6081. - Internet-facing ELB: Public subnet in each enabled AZ; targets may remain private.
- Subnet planning: One subnet per AZ, at least
/27, with eight available IP addresses. - Cross-zone: Always enabled for ALB; disabled by default for NLB and GWLB.
Flashcards
- What does EC2 Auto Scaling primarily provide? — Horizontal scaling by launching and terminating EC2 instances.
- What is an Auto Scaling Group? — A logical collection of EC2 instances managed and scaled together.
- What is the purpose of the health check grace period? — It gives a newly launched instance time to initialize before Auto Scaling acts on failed health checks.
- What additional health information can an ELB health check provide? — Whether the instance is actually serving healthy application traffic, in addition to EC2 status checks.
- Which load balancer supports host- and path-based HTTP routing? — Application Load Balancer.
- Which load balancer is appropriate for TCP or UDP traffic and static IP requirements? — Network Load Balancer.
- Which load balancer is designed for firewalls and intrusion detection appliances? — Gateway Load Balancer.
- What protocol and port does GWLB use between the load balancer and virtual appliances? — GENEVE on port
6081. - Can an internet-facing load balancer route to private EC2 instances? — Yes. The load balancer has public nodes and routes to the targets’ private addresses.
- How many subnets per AZ can be enabled for one ELB? — One.
- What is ASG standby state used for? — Temporarily taking an in-service instance out of active service for maintenance or troubleshooting.
- What do lifecycle hooks enable? — Custom actions during instance launch or termination.
- Which ELB types have cross-zone load balancing disabled by default? — NLB and GWLB.
- What does termination protection do in an ASG? — Prevents protected instances from being selected for ASG scale-in termination.
Practice Questions
Question 1
A company hosts a web application on EC2 instances in private subnets across three Availability Zones. The application must be accessible from the internet and distribute HTTPS requests using URL paths. Which design is most appropriate?
A. Internal NLB in the private subnets
B. Internet-facing ALB in public subnets, targeting the private EC2 instances
C. Internet-facing GWLB in private subnets
D. Public EC2 instances with an internal ALB
Correct answer: B
Explanation: An ALB supports HTTPS and Layer 7 path-based routing. An internet-facing ALB requires a public subnet in each enabled AZ, while its targets can remain in private subnets.
Question 2
An application uses a proprietary UDP protocol and requires very low latency and static IP addresses for client allowlisting. Which load balancer should be selected?
A. ALB
B. NLB
C. GWLB
D. CloudFront only
Correct answer: B
Explanation: NLB operates at Layer 4, supports UDP, is optimized for low latency, and supports static IP address requirements. ALB is intended for HTTP/HTTPS application-layer routing.
Question 3
An ASG repeatedly terminates newly launched instances because the application takes several minutes to install dependencies and become ready. Which change most directly addresses the problem?
A. Enable termination protection on all instances
B. Increase the ASG health check grace period
C. Disable ELB health checks permanently
D. Decrease the cooldown period
Correct answer: B
Explanation: The health check grace period prevents Auto Scaling from acting on failed health checks while an instance initializes. It should be long enough for the application to become healthy, but not so long that real failures are hidden.
Question 4
A company deploys an NLB across two AZs. Cross-zone load balancing is left at its default setting, but one AZ has twice as many registered targets as the other. What is the likely result?
A. Each NLB node distributes traffic only to targets in its own AZ, potentially causing uneven utilization
B. The NLB automatically enables cross-zone balancing
C. The NLB sends all traffic to the AZ with more targets
D. The NLB converts into an ALB when target counts differ
Correct answer: A
Explanation: Cross-zone load balancing is disabled by default for NLB. Each node generally distributes traffic among targets in its own AZ, so uneven target capacity can produce uneven traffic and utilization.
Question 5
A security service provider wants to transparently insert a fleet of virtual firewalls and intrusion prevention appliances into customer traffic flows. Which AWS service is designed for this use case?
A. ALB
B. NLB
C. GWLB
D. Auto Scaling Group without a load balancer
Correct answer: C
Explanation: GWLB is designed to distribute traffic across virtual appliances such as firewalls and IDS/IPS systems. It uses GENEVE encapsulation on port 6081 for appliance communication.