All guides
Practice now
D2 · Resilient architectures

High availability: ASG, ELB and Multi-AZ

The standard high-availability architecture on AWS is: ELB + Auto Scaling Group + Multi-AZ. This pattern shows up in 26% of the exam (D2). You need to distinguish between (Multi-AZ) and performance scaling (more instances/replicas).

Icon-Architecture/48/Arch_Amazon-EC2-Auto-Scaling_48

Auto Scaling Groups

An maintains a set of instances, automatically adjusting capacity based on demand. It guarantees the right number of instances are always running to handle the load.

Minimum

The minimum number of instances. Always running even with no demand.

Desired

The current target number. The ASG will always try to keep this many.

Maximum

The maximum number. Never exceeded even if demand is higher.

Launch Template (recommended over Launch Configuration)

A Launch Template defines:

  • •AMI (the instance image)
  • •Instance type (t3.medium, m5.large...)
  • •Key pair for SSH
  • •Security Groups
  • •User data (bootstrap script)
  • •IAM Instance Profile

Advantages over Launch Configuration

  • ✓Versioning — multiple versions
  • ✓Support for mixed Spot + On-Demand
  • ✓Attributes inherited from another template
  • ✓AWS recommends LT over LC
Icon-Architecture/48/Arch_Amazon-EC2-Auto-Scaling_48

Scaling types

Target Tracking Policy

Recommended

The simplest type. You define a target metric (e.g. CPU at 50%) and AWS automatically adjusts instances to keep that value.

When: Default for most cases. E.g. "Keep average CPU at 60%".

Step Scaling Policy

Defines scaling steps based on a metric value. More control than Target Tracking.

When: "If CPU > 70%, add 2 instances. If CPU > 90%, add 4 instances."

Scheduled Scaling

Schedules capacity changes at known dates/times. For predictable patterns.

When: "Scale up to 10 instances on Mondays at 8am; scale down to 2 at 8pm."

Predictive Scaling

Machine Learning analyzes history and scales proactively before traffic arrives.

When: "Predictable traffic peaks daily at 12pm and 6pm."

Icon-Architecture/48/Arch_Elastic-Load-Balancing_48

: ALB, NLB and GLB

LBOSI layerProtocolKey featuresWhen to use
ALBL7HTTP/S, WebSocket, gRPCPath/host-based routing, sticky sessions, lambdas as targets, WAF integrationWeb apps, microservices, REST APIs
NLBL4TCP, UDP, TLSUltra-low latency, static IPs, IP targets, preserves client IPGaming, IoT, VoIP, high-performance TCP/UDP traffic
GLBL3/L4IP (GENEVE tunnel)Routes traffic to virtual appliances (firewalls, IDS/IPS)Network security with third-party appliances

Exam trap

ALB = L7 HTTP. NLB = L4 TCP/UDP + static IPs. If the scenario mentions "protocol non-HTTP", "static IPs" or "preserve client IP" — choose NLB. If it mentions "path routing", "host-based routing" or "microservices" — choose ALB.

Icon-Architecture/48/Arch_Amazon-EC2_48

Multi-AZ — high availability

Multi-AZ = for a . If one AZ fails, traffic/data is automatically redirected to another AZ. It's HA (High Availability), not scaling.

Multi-AZ in RDS

  • ✓Synchronous replication to a Standby in another AZ
  • ✓The Standby does NOT serve reads (it is not a Read Replica)
  • ✓Automatic failover in < 2 minutes
  • ✓Same DNS endpoint — the app config doesn't change
  • ✓RPO ≈ 0 seconds (synchronous)

Multi-AZ with ASG + ALB

  • ✓ASG distributes instances across AZs automatically
  • ✓ALB routes only to healthy instances
  • ✓If AZ-a fails, the ASG launches more instances in AZ-b
  • ✓Cross-Zone Load Balancing distributes evenly
  • ✓No extra configuration needed — this is the default behavior
Icon-Architecture/48/Arch_Amazon-EC2_48

Health checks and automatic replacements

ASG Health Check

The ASG checks the health of its instances. If an instance fails, it terminates it and launches a new one automatically. It can use EC2 status checks or ELB health checks.

The ELB health check is more thorough than the EC2 check — it detects application-level issues, not just VM-level ones.

Connection Draining (Deregistration Delay)

When the ALB is about to deregister an instance (e.g. scale-in), it waits for active connections to finish before terminating it.

Default: 300 seconds. Reduce it for instances handling short requests. Increase it for long-running requests.

Diagram: 3-tier Multi-AZ architecture

+ + ALB + ASG Multi-AZ + RDS Multi-AZ.

Did you get this topic?

Test what you just learned

A web application has an ALB with an Auto Scaling Group. During a code update, the team wants to replace instances gradually without downtime. Which type of ASG update should they use?

Ready to test "High availability: ASG, ELB and Multi-AZ"?

Put what you learned to the test with original SAA-C03 exam questions.

Start SAA-C03 mock exam

Unlimited mock exams with the Pro plan

Log in to track your progress.