Study guide
Technical reference and lesson notes
Purpose of This Lesson
AWS architecture questions often describe a requirement—such as UDP support, static IP addresses, cross-Region recovery, or session continuity—and expect you to select the correct Elastic Load Balancing and EC2 Auto Scaling design.
The key is to match the load balancer type, scaling policy, and state-management approach to the application’s traffic pattern and availability requirements.
Key Concepts
Choosing an Elastic Load Balancer
AWS provides several load balancer types with different protocol, routing, and appliance-integration capabilities:
- Application Load Balancer (ALB): Operates at Layer 7 and supports HTTP and HTTPS. It provides content-based routing, host- and path-based routing, HTTP features, and integration with targets such as EC2 instances, containers, and Lambda functions.
- Network Load Balancer (NLB): Operates at Layer 4 and supports TCP, TLS, and UDP. It is designed for high-performance, low-latency traffic and can provide static IP addresses.
- Gateway Load Balancer (GWLB): Distributes traffic to virtual network appliances such as firewalls, intrusion detection systems, and intrusion prevention systems. It uses GENEVE encapsulation and is intended for transparent appliance insertion rather than ordinary application load balancing.
High Availability for Web Applications
For a highly available web application:
- Deploy EC2 instances across multiple Availability Zones.
- Place them in an EC2 Auto Scaling group.
- Register the instances with an ALB.
- Configure health checks so unhealthy instances are removed from service and replaced by the Auto Scaling group.
The ALB itself is regional and uses enabled Availability Zones. The Auto Scaling group should also be configured to distribute capacity across multiple Availability Zones.
UDP and Low-Latency Traffic
ALBs do not support UDP listeners. Applications such as gaming, telemetry, and some real-time services that require UDP should generally use an NLB with a UDP listener.
An NLB is also appropriate when the architecture prioritizes very low connection latency or Layer 4 forwarding instead of HTTP-aware routing.
Static IP Addresses for Load-Balanced Applications
ALB DNS names resolve to load balancer IP addresses that can change. Clients should use the DNS name rather than hardcoded ALB addresses.
When external systems require IP allowlists, an NLB can provide a static IP address per enabled Availability Zone. An NLB can also use Elastic IP addresses for its nodes, subject to the design and regional constraints of the deployment.
Use static addresses only when the requirement genuinely comes from an external firewall, partner, or network policy. Otherwise, DNS-based access is usually more flexible.
Cross-Region Disaster Recovery for EC2 Auto Scaling
An EC2 Auto Scaling group is regional and cannot span multiple AWS Regions. For cross-Region disaster recovery, create a separate recovery design in the target Region.
A cost-conscious warm or pilot-light pattern can include:
- A recovery-region Auto Scaling group configured with desired capacity of zero or another intentionally low standby capacity.
- Launch templates and application configuration replicated to the recovery Region.
- Amazon Machine Images and EBS snapshots copied to the recovery Region.
- Automation using services such as AWS Lambda, Amazon Data Lifecycle Manager, or other operational tooling.
- A process that increases capacity and updates routing when a disaster occurs.
The recovery-region ASG is not automatically populated by the primary-region ASG. The recovery process must handle data replication, AMI availability, configuration, networking, DNS or routing changes, and any required dependency recovery.
Step Scaling Versus Target Tracking
Auto Scaling policies should reflect how traffic changes and what the application needs.
Step scaling applies different capacity adjustments based on the size of a metric breach. For example:
- A modest alarm breach might add two instances.
- A much larger breach might add ten instances.
This is useful when a large traffic spike requires a disproportionately large response.
Target tracking scaling attempts to maintain a selected metric near a target value. It is useful when the goal is to keep workload per instance within a predictable operating range.
For an EC2 fleet behind an ALB, the Auto Scaling group can use the predefined ALBRequestCountPerTarget metric. This represents the average number of requests handled per target over a period and can help scale capacity based on application demand rather than only CPU utilization.
Target tracking automatically creates and manages the underlying CloudWatch alarms. It may be less suitable when the application needs highly customized scale-out and scale-in behavior.
Session State and Instance Failure
Applications should avoid storing user session state only in local instance memory or on ephemeral local storage. If a request is routed to a different instance after failure, the new instance cannot access that local session.
A shared session store can preserve authentication or session information across instances. Common choices include:
- Amazon DynamoDB: Durable, highly available, and suitable for key-value session records.
- Amazon ElastiCache: Very low latency and useful when session access speed is critical. The selected engine and persistence requirements should be considered.
The application must be designed to read and write session state consistently. Load balancer stickiness can keep a client connected to the same target temporarily, but it is not a substitute for shared state because the target can fail and stickiness can reduce load-distribution flexibility.
Scaling Virtual Network Appliances
Security and inspection appliances often need to process traffic transparently while scaling horizontally. A Gateway Load Balancer distributes traffic across appliance instances and supports centralized insertion of firewalls, IDS/IPS systems, and similar virtual appliances.
The appliances should be deployed across multiple Availability Zones and managed with an appropriate scaling and health-check strategy. GWLB is not the normal choice for routing HTTP requests to application servers; it is designed for appliance traffic flows.
Exam-Relevant Takeaways
- Use ALB for HTTP/HTTPS applications that require Layer 7 routing and application-aware features.
- Use NLB for UDP, TCP/TLS Layer 4 traffic, very low latency, or static IP requirements.
- Use GWLB to distribute traffic across virtual network and security appliances.
- An EC2 Auto Scaling group is regional; create a separate ASG in another Region for disaster recovery.
- A recovery-region ASG with desired capacity zero avoids running standby instances, but it does not eliminate recovery-time tasks.
- Use cross-Region AMI and EBS snapshot copies to support instance recovery.
- Use step scaling when the capacity adjustment should vary according to the magnitude of the metric breach.
- Use target tracking when the objective is to maintain a workload metric near a target, such as ALB requests per target.
- Store session state in a shared service such as DynamoDB or ElastiCache when users must remain authenticated after an instance failure.
- ALB addresses are dynamic; do not use ALB IP addresses as permanent allowlist entries.
Architecture Decision Guide
| Requirement | Recommended design | Reason |
|---|---|---|
| Highly available HTTP/HTTPS web service | ALB + EC2 Auto Scaling across multiple AZs | Provides Layer 7 routing, health checks, and elastic capacity |
| UDP traffic to EC2 targets | NLB with a UDP listener | ALB does not support UDP |
| External clients require static allowlisted addresses | NLB with static or Elastic IP addresses | NLB supports static addresses per enabled AZ |
| EC2 disaster recovery in another Region | Separate recovery-region ASG plus replicated AMIs/snapshots | ASGs cannot span Regions |
| Large traffic spikes require larger capacity jumps | Step scaling policy | Capacity changes can vary by breach magnitude |
| Maintain a consistent request load per instance | Target tracking using ALB requests per target | Automatically adjusts capacity toward a target workload |
| Preserve sessions when targets fail | Shared session store such as DynamoDB or ElastiCache | Session data is available to replacement targets |
| Horizontally scale IDS/IPS or firewall appliances | Gateway Load Balancer | Designed for transparent appliance distribution |
Common Exam Traps
- Choosing ALB for UDP: ALB supports HTTP and HTTPS, not UDP. Select NLB for UDP listeners.
- Assuming ALB has permanent IP addresses: ALB is accessed through DNS; its resolved addresses can change.
- Assuming one ASG can span Regions: Auto Scaling groups are regional. Cross-Region recovery requires a separate ASG and supporting resources.
- Confusing step scaling with target tracking: Step scaling uses different adjustments for different alarm ranges. Target tracking tries to maintain a metric near a target value.
- Treating desired capacity of zero as a complete DR solution: The ASG still needs a valid launch template, AMI, networking, permissions, application configuration, and a runbook or automation process.
- Using load balancer stickiness as durable session storage: Stickiness does not protect session state when the target fails and can create uneven distribution.
- Using GWLB as a general-purpose application load balancer: GWLB is for virtual network appliances, not ordinary HTTP application routing.
- Assuming target tracking guarantees immediate scaling: Scaling reacts to observed metrics and configured cooldown or warmup behavior; it cannot instantaneously provision and initialize application capacity.
Real-World Engineer Notes
- Enable load balancer and Auto Scaling health checks that reflect meaningful application health, not merely whether a process is listening on a port.
- For NLB static IP designs, deploy nodes in multiple Availability Zones and ensure every allowlisted address is covered by partner firewall rules.
- A cross-Region recovery plan should include DNS or routing failover, secrets, IAM permissions, VPC components, security groups, quotas, certificates, observability, and dependent data stores.
- Test the recovery process regularly. An untested AMI-copy or scale-out workflow may fail because of stale configuration, missing dependencies, or insufficient Regional quotas.
- Session records should have expiration or cleanup behavior. DynamoDB TTL or an appropriate cache expiration policy can prevent abandoned sessions from accumulating.
- Scaling on ALB request count can be more representative than CPU for applications whose work per request is relatively consistent. If request complexity varies widely, combine metrics or use a custom application metric.
- For appliance architectures, verify routing symmetry and failure behavior. Stateful inspection appliances may require a design that keeps both directions of a flow on the appropriate appliance path.
Quick Reference Summary
- ALB: Layer 7, HTTP/HTTPS, host/path routing, no UDP, dynamic IPs.
- NLB: Layer 4, TCP/TLS/UDP, low latency, static IP support.
- GWLB: Transparent distribution of firewalls, IDS/IPS, and other virtual appliances.
- Multi-AZ web pattern: ALB + EC2 Auto Scaling group across AZs.
- Cross-Region EC2 DR: Separate ASG in the recovery Region; replicate AMIs and snapshots.
- Step scaling: Different capacity changes for different metric-breach ranges.
- Target tracking: Maintain a metric near a target, including ALB requests per target.
- Session continuity: Store session state outside individual EC2 instances.
Flashcards
- Q: Which Elastic Load Balancer supports UDP listeners?
A: Network Load Balancer.
- Q: Why is an ALB a poor choice when a partner requires static IP allowlisting?
A: ALB IP addresses can change; clients should normally use the ALB DNS name.
- Q: Can an EC2 Auto Scaling group span multiple AWS Regions?
A: No. An ASG is regional, so cross-Region recovery requires a separate ASG.
- Q: What is a common low-cost configuration for a recovery-region ASG?
A: Desired capacity of zero, with launch templates, AMIs, snapshots, and automation ready to scale out during recovery.
- Q: When is step scaling appropriate?
A: When the required capacity adjustment should increase as the metric breach becomes more severe.
- Q: What does target tracking attempt to do?
A: Maintain a selected metric near a configured target value.
- Q: Which predefined metric can scale an ASG based on ALB workload per instance?
A: ALBRequestCountPerTarget.
- Q: Why should session state be stored outside an EC2 instance?
A: A replacement or alternate instance must be able to retrieve the user’s session after a target failure.
- Q: Which AWS load balancer is designed for virtual firewalls and IDS/IPS appliances?
A: Gateway Load Balancer.
- Q: Why is load balancer stickiness not a complete session-persistence solution?
A: A sticky target can fail, and stickiness does not provide durable shared session data.
Practice Questions
Question 1
A multiplayer gaming application runs on EC2 instances in several Availability Zones. Clients send real-time game traffic over UDP, and the application requires the lowest practical network latency. Which design is most appropriate?
A. ALB with an HTTPS listener
B. ALB with a TCP listener
C. NLB with a UDP listener
D. GWLB with an HTTP listener
Correct answer: C.
Explanation: NLB supports UDP and provides Layer 4, low-latency load balancing. ALB does not support UDP, and GWLB is intended for virtual network appliances.
Question 2
A business partner will connect to a public application only from IP addresses that have been permanently allowlisted in its firewall. The application is deployed across multiple Availability Zones. Which load balancer should the architect select?
A. ALB, because it automatically provides static public IP addresses
B. NLB, using static or Elastic IP addresses for its nodes
C. GWLB, because it preserves application IP addresses
D. ALB with manually discovered DNS-resolved addresses
Correct answer: B.
Explanation: NLB supports static IP addressing per enabled Availability Zone, making it suitable for external allowlisting. ALB addresses can change and should not be manually hardcoded.
Question 3
An EC2 application uses an Auto Scaling group in us-east-1. The company requires recovery in us-west-2 but wants to avoid paying for running standby instances. Which approach best supports this requirement?
A. Attach the same ASG to both Regions
B. Create a second ASG in us-west-2 with desired capacity zero and replicate the required AMIs and snapshots
C. Configure the primary ASG to launch instances automatically in us-west-2
D. Use ALB cross-Zone load balancing to provide cross-Region recovery
Correct answer: B.
Explanation: ASGs are regional. A second ASG can be maintained in the recovery Region with no running instances, while AMIs, EBS snapshots, configuration, and recovery automation are replicated.
Question 4
An application behind an ALB should add capacity so that the average number of requests handled per target remains near a selected value. Which Auto Scaling policy is most appropriate?
A. Target tracking using ALBRequestCountPerTarget
B. Step scaling based only on the number of Availability Zones
C. Scheduled scaling with no workload metric
D. Simple scaling based on NLB static IP utilization
Correct answer: A.
Explanation: Target tracking can use ALBRequestCountPerTarget to adjust the ASG toward a desired request load per target.
Question 5
A company runs stateful IDS/IPS virtual appliances and needs to distribute inspection traffic across multiple appliance instances as demand increases. Which AWS service is designed for this architecture?
A. Application Load Balancer
B. Network Load Balancer
C. Gateway Load Balancer
D. Route 53 weighted routing
Correct answer: C.
Explanation: GWLB is designed to insert and scale virtual network appliances such as firewalls and IDS/IPS systems. It is purpose-built for appliance traffic flows rather than ordinary application request routing.