ExamFinch.com My Study

Study guide

5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting

Practice this exam

AWS Certified CloudOps Engineer – Associate SOA-C03

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Monitoring & Observability Infrastructure

1.1 Configuring Workload Observability 1.2 CloudWatch Agent Architecture & Deployment 1.3 Metric Alarms, Anomaly Detection & Composite Alarms

2 Chapter 2: Alarms, Dashboards & Event-Driven Remediation

2.1 CloudWatch Dashboards & Multi-Account Visibility 2.2 Notification Architecture & Alarm Invocation 2.3 Amazon EventBridge Rules, Event Buses & Troubleshooting 2.4 Automated Remediation with Systems Manager & Lambda

3 Chapter 3: Performance Optimization for Compute, Storage & Databases

3.1 EC2 & Compute Performance Optimization 3.2 Amazon EBS Performance Metrics & Volume Tuning 3.3 S3 Performance Strategies & Data Transfer 3.4 Shared Storage (EFS/FSx) & Database Performance

4 Chapter 4: Compute & Database Scalability and Elasticity

4.1 EC2 Auto Scaling Policies & Elasticity 4.2 Auto Scaling Advanced Operations: Warm Pools & Lifecycle Hooks 4.3 Dynamic Scalability Through Caching 4.4 Managed Database Scaling: RDS, Aurora & DynamoDB

5 Chapter 5: High Availability, Fault Tolerance & Load Balancing

5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting 5.2 Route 53 Health Checks & DNS Failover 5.3 Multi-AZ Architecture & Fault-Tolerant Deployments

6 Chapter 6: Backup, Data Protection & Disaster Recovery

6.1 Centralized Backup Automation & AWS Backup 6.2 Database Restore Strategies & RTO/RPO Management 6.3 Storage Versioning, Replication & Immutability 6.4 Disaster Recovery Patterns & Multi-Region Resilience

7 Chapter 7: Infrastructure as Code with CloudFormation & AWS CDK

7.1 CloudFormation Foundations & Resource Modeling 7.2 Managing Stacks, Drift Detection & Change Sets 7.3 Infrastructure as Code with AWS CDK 7.4 Identifying & Remediating Deployment Failures

8 Chapter 8: Multi-Account Provisioning, Containers & Third-Party IaC

8.1 Golden Images with EC2 Image Builder & Amazon ECR 8.2 Multi-Account & Multi-Region Resource Sharing 8.3 Deployment Strategies & Container Deployments 8.4 Third-Party Automation with Terraform & Git Workflows

9 Chapter 9: Systems Manager & Event-Driven Operations Automation

9.1 AWS Systems Manager Core Management & Run Command 9.2 Systems Manager Patch Manager & Session Manager 9.3 Event-Driven Operations Automation

10 Chapter 10: Identity, Access Management & Governance

10.1 Advanced IAM Policies, Roles & Policy Conditions 10.2 Auditing Access with CloudTrail Lake & IAM Access Analyzer 10.3 Multi-Account Security: Organizations, SCPs & Identity Center 10.4 Compliance Enforcement with AWS Config & Conformance Packs

11 Chapter 11: Data Security, Encryption & Vulnerability Management

11.1 Data Classification & Amazon S3 Security 11.2 Encryption at Rest with AWS Key Management Service (KMS) 11.3 Encryption in Transit with AWS Certificate Manager (ACM) 11.4 Secrets Management & Centralized Security Findings

12 Chapter 12: VPC Architecture, Endpoints & Network Protection

12.1 VPC Core Architecture, Subnetting & High Availability NAT 12.2 Private Network Connectivity: VPC Endpoints & Peering 12.3 Network Protection & Edge Security Auditing

13 Chapter 13: DNS, Route 53 Routing & Content Delivery

13.1 DNS Architecture & Route 53 Resolver for Hybrid Clouds 13.2 Route 53 Advanced Routing Policies & Query Logging 13.3 Global Content & Service Distribution: CloudFront & Global Accelerator

14 Chapter 14: Network Troubleshooting, Traffic Analysis & Hybrid Connectivity

14.1 VPC Configuration Troubleshooting & Analysis Tools 14.2 Network Traffic Analysis: VPC Flow Logs & Log Analytics 14.3 CloudFront Caching & Hybrid Connectivity Troubleshooting

5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting

Key Takeaways Explain This Topic AI

ALB operates at Layer 7 supporting path, host, header, and query routing, WebSockets, gRPC, and TLS termination with SNI, while NLB operates at Layer 4 routing TCP, UDP, and TLS at ultra-low latency with one static IP address per enabled AZ (AWS-assigned or a customer-allocated Elastic IP).

Target group health checks evaluate protocol, port, path, interval, timeout, and consecutive thresholds, with configurable HTTP match codes (200-299 vs 200,301,302) to prevent redirect-based false-positive failures.

Deregistration delay (default 300s) drains active connections during target removal, requiring reduction to 15-30s in fast container deployments (ECS/EKS) or extension for long-lived batch streams.

Cross-zone load balancing is always active and free on ALB, but disabled by default on NLB where inter-AZ data transfer fees apply upon enablement to prevent uneven AZ target loading.

Common ELB troubleshooting includes HTTP 502 (invalid backend response, premature target TCP close, or TLS cipher mismatch), HTTP 503 (no healthy targets or full surge queue), and HTTP 504 (backend response exceeding ALB idle timeout, default 60s).

Last updated: September 2026

5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting

CloudOps Blueprint Focus: AWS Certified CloudOps Engineer – Associate (SOA-C03) candidates must configure, manage, and troubleshoot Elastic Load Balancing (ELB) architectures. This requires deep proficiency in differentiating Application Load Balancer (ALB) and Network Load Balancer (NLB) capabilities, tuning target group health checks, managing connection draining lifecycles, understanding cross-zone load balancing cost dynamics, and rapidly resolving HTTP 502, 503, and 504 operational failures.

Load Balancer Architectural Comparison: ALB vs. NLB

Elastic Load Balancing automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers (Amazon ECS/EKS), IP addresses, and AWS Lambda functions. Modern AWS infrastructure relies primarily on two specialized load balancers:

Application Load Balancer (ALB): Functions at the application layer (OSI Layer 7). ALB inspects application-layer payloads and HTTP/HTTPS headers, enabling advanced content-based request routing. It natively supports modern web protocols including HTTP/2, gRPC, and WebSockets. ALB integrates directly with AWS WAF for web application firewall inspection, authenticates users via Amazon Cognito or OpenID Connect (OIDC) identity providers, and terminates TLS certificates managed by AWS Certificate Manager (ACM) with Server Name Indication (SNI) for multi-domain hosting.

Network Load Balancer (NLB): Functions at the transport layer (OSI Layer 4). NLB is engineered for ultra-high performance, capable of processing millions of requests per second with sustained single-digit sub-millisecond latencies. Operating at Layer 4, NLB routes raw TCP, UDP, and TLS connections without inspecting application-layer HTTP payloads. A defining operational capability of NLB is its provision of a single, static IP address per enabled Availability Zone - either AWS-assigned or a customer-allocated Elastic IP (EIP). These are zonal addresses, not anycast addresses; anycast entry points are an AWS Global Accelerator capability. This makes NLB the mandatory choice when clients require deterministic firewall IP whitelisting or when exposing services privately via AWS PrivateLink (VPC Endpoint Services).

  • Architectural Attribute Application Load Balancer (ALB) Network Load Balancer (NLB)
  • OSI Operating Layer Layer 7 (Application) Layer 4 (Transport)
  • Supported Protocols HTTP, HTTPS, gRPC, WebSockets TCP, UDP, TCP_UDP, TLS
  • Addressing & IPs Dynamic DNS (IPs change frequently) One static IP per enabled AZ (AWS-assigned or Elastic IP)

Routing Capabilities Host, Path, HTTP Header, Query, Method, Source CIDR Flow hash (Source IP/Port, Dest IP/Port, Protocol)

  • Target Types instance , ip , lambda , alb instance , ip , alb
  • Latency Profile Low (milliseconds) Ultra-low (sub-millisecond)
  • TLS Termination & SNI Supported (ACM, multiple certs via SNI) Supported (Zero-overhead hardware acceleration)
  • Client IP Preservation Appends X-Forwarded-For header Native (Preserved at packet level or Proxy Protocol v2)
  • AWS PrivateLink Integration Target behind an NLB Direct native Endpoint Service integration
  • AWS WAF Support Native ALB listener integration Requires ALB target or CloudFront front-end
  • Target Types & Cross-Resource Routing

Target groups define where traffic is directed. Both ALB and NLB support:

instance : Routes traffic to EC2 instances specified by their Instance IDs. The instance primary network interface (eth0) receives traffic.

ip : Routes traffic to static private IPv4 or IPv6 addresses. This enables routing to ECS tasks in awsvpc networking mode, on-premises physical servers connected via AWS Direct Connect or Site-to-Site VPN, and secondary ENIs.

alb : Allows an NLB to register an Application Load Balancer as a target. This powerful architectural pattern combines NLB static IP addressing and PrivateLink connectivity with ALB Layer 7 routing and AWS WAF security.

lambda : Supported exclusively by ALB, transforming HTTP requests directly into JSON payloads that invoke serverless AWS Lambda functions.

Target Group Health Checks & Configuration Parameters

ELB periodically sends health check pings to registered targets to determine their availability. Only targets in an healthy state receive client traffic. Health check parameters must be tuned carefully to avoid premature target failover while quickly isolating degraded backends.

Essential Health Check Settings

HealthCheckProtocol & HealthCheckPort: The network protocol (HTTP, HTTPS, TCP) and destination port. By default, ELB uses traffic-port (the port where the target receives traffic), but a dedicated management port can be specified.

HealthCheckPath: (ALB and HTTP/HTTPS NLB) The specific URI path requested by the load balancer. Best practice requires a lightweight, dedicated health endpoint (e.g., /healthz or /status ) that checks core operational dependencies (such as local process execution) without running expensive, blocking database queries that could exhaust backend connection pools.

HealthCheckIntervalSeconds: The elapsed time between consecutive health check probes (range: 5–300 seconds; default: 30 seconds for ALB, 10 or 30 seconds for NLB).

HealthCheckTimeoutSeconds: The maximum duration the load balancer waits for a target response before marking that probe a failure (range: 2–120 seconds; default: 5 seconds). The timeout value must always be strictly less than the interval.

HealthyThresholdCount: The number of consecutive successful health checks required before transitioning an unhealthy target back to healthy (range: 2–10; default: 5 for ALB/NLB).

UnhealthyThresholdCount: The number of consecutive failed health checks required to transition a healthy target to unhealthy (range: 2–10; default: 2).

Matcher (HTTP Codes): Configures expected HTTP status codes. The default is 200 . CloudOps engineers can configure ranges (e.g., 200-299 ) or comma-delimited lists (e.g., 200,301,302 ).

Warning

The HTTP 301/302 Redirect Health Check Trap: A frequent operational incident occurs when an application team enforces an HTTP-to-HTTPS redirect rule on backend web servers. If the ALB sends health check pings over HTTP on /health and expects a 200 response, the server returns 301 Moved Permanently or 302 Found . Because 301 / 302 does not match 200 , the ALB marks every backend instance unhealthy , resulting in an immediate HTTP 503 outage. To resolve this, configure the matcher to 200,301,302 or perform health checks directly over HTTPS. # Inspect target health and diagnostic error reasons

  • aws elbv2 describe-target-health \
  • -target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/web-tg/a1b2c3d4e5f6g7h8
  • Connection Lifecycle: Deregistration Delay & Sticky Sessions
  • Deregistration Delay (Connection Draining)

When a target is deregistered—either manually during maintenance or automatically by an Auto Scaling group during a scale-in event—the load balancer enters the deregistration delay phase (formerly connection draining): Target Deregistered ---> New Requests Stopped ---> In-Flight Requests Complete ---> Target Deregistered / Terminated

[ Event Initiated ] [ Immediate Cutoff ] [ Draining Window: 0 - 3600s ] [ Instance Safe to Stop ]

The load balancer immediately ceases forwarding new connections to the deregistering target.

The load balancer keeps existing, in-flight TCP connections open, allowing backend processes to complete outstanding transactions.

Once all in-flight requests finish or the configured deregistration delay timeout expires (default: 300 seconds / 5 minutes; range: 0–3,600 seconds), the target transitions from draining to unused , and Auto Scaling safely terminates the instance.

Operational Tuning: For containerized microservices running on Amazon ECS or EKS where REST requests execute in under 500 milliseconds, a 300-second draining delay causes deployment rollouts to stall for 15–20 minutes. CloudOps engineers tune the delay down to 15–30 seconds , drastically accelerating continuous deployments without dropping client requests. Conversely, for workloads with large batch file uploads or long-lived streaming connections, increasing the delay up to 1,800 seconds prevents abrupt client disconnections.

Sticky Sessions (Session Affinity)

Sticky sessions bind a client session to a specific backend target instance:

ALB Duration-Based Cookies: The ALB generates an encrypted cookie named AWSALB with a configurable duration (1 second to 7 days). Subsequent requests presenting this cookie route to the original target.

ALB Application-Based Cookies: The application generates its own session cookie. The ALB issues a companion cookie named AWSALBAPP that mirrors the application cookie's lifespan.

NLB Target Group Stickiness: NLB enforces stickiness at Layer 4 by hashing the client's source IP address and destination port, directing repeat connections from that IP to the same target.

Operational Risks of Session Stickiness: Stickiness introduces traffic hot spots . If a large corporate customer accesses the system through a unified forward proxy or NAT gateway, all corporate users share the same IP/cookie, concentrating massive traffic onto a single backend instance. This overwhelms the target while sibling instances remain idle, and prevents Auto Scaling from evenly balancing the cluster.

Cross-Zone Load Balancing Mechanics & Cost Optimization

Cross-zone load balancing determines how load balancer nodes distribute client traffic across target instances located in multiple Availability Zones within an AWS Region: [ Internet Clients ]

  • |
  • +------------+------------+
  • | |
  • [ ALB Node AZ-1 ] [ ALB Node AZ-2 ]
  • | |
  • (Cross-Zone: Always ON) (Cross-Zone: Always ON)
  • | |
  • +-----+-----+ +-----+-----+
  • | | | | | |
  • [Inst] [Inst] [Inst] [Inst] [Inst] [Inst]
  • (AZ-1) (AZ-1) (AZ-1) (AZ-2) (AZ-2) (AZ-2)

Application Load Balancer: Cross-zone load balancing is always enabled at the load balancer level and cannot be disabled. Requests received by an ALB node in AZ-1 are evenly distributed across all registered, healthy targets in AZ-1 and AZ-2. AWS charges no inter-AZ data transfer fees for cross-zone load balancing on ALBs.

Network Load Balancer: Cross-zone load balancing is disabled by default at the target group level. When disabled, an NLB node in AZ-1 forwards traffic strictly to targets located in AZ-1. If AZ-1 contains 2 instances and AZ-2 contains 8 instances, each instance in AZ-1 receives 25% of overall regional traffic, while each instance in AZ-2 receives only 6.25%, leading to severe CPU exhaustion in AZ-1. Enabling cross-zone balancing on NLB balances traffic evenly (10% per instance across all 10 instances). However, standard inter-AZ data transfer fees ($0.01/GB in each direction) apply when NLB nodes route packets across AZ boundaries. # Enable cross-zone load balancing on an NLB target group

  • aws elbv2 modify-target-group-attributes \
  • -target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/nlb-tg/b2c3d4e5f6g7h8i9 \
  • -attributes Key=load_balancing.cross_zone.enabled,Value=true
  • Diagnostic Troubleshooting of ELB Error Codes

When applications fail, the load balancer emits status codes that isolate whether the fault resides in the load balancer infrastructure or the upstream backend targets.

HTTP Error Code Primary Root Causes Diagnostic CloudWatch Metrics Operational Remediation

HTTP 502 Bad Gateway Target returned an invalid/malformed HTTP response; target closed TCP connection prematurely with a TCP RST/FIN; backend keep-alive timeout is shorter than ALB idle timeout; TLS cipher suite/protocol mismatch. HTTPCode_ELB_502_Count ; HTTPCode_Target_5XX_Count Ensure backend keep-alive timeout is greater than ALB idle timeout (default 60s); check application server crash logs; verify TLS cipher compatibility.

HTTP 503 Service Unavailable Target groups contain zero healthy targets; all targets are failing health checks; target group is completely empty; ALB surge queue / connection capacity saturated. HTTPCode_ELB_503_Count ; HealthyHostCount (drops to 0); UnHealthyHostCount Inspect target health check failures; review backend application logs; verify security groups permit ALB health check traffic on target port.

HTTP 504 Gateway Timeout Backend target failed to respond before the ALB idle timeout period expired; application database query hung or locked; external third-party API call timed out. HTTPCode_ELB_504_Count ; TargetResponseTime Increase ALB idle timeout if legitimate long-running query; optimize backend SQL queries, indexing, and connection pools.

The HTTP 502 Keep-Alive Race Condition

A classic SysOps/CloudOps problem occurs when an ALB maintains persistent TCP connections to backend web servers (e.g., NGINX, Apache, Node.js). ALB has a default idle timeout of 60 seconds . If the backend web server has an idle keep-alive timeout set to 60 seconds or lower (e.g., 15 seconds in Node.js or 60 seconds in Apache), the backend target may initiate a TCP FIN/RST packet at the exact millisecond the ALB dispatches an incoming client request on that reused socket. The ALB detects the closed socket and immediately returns HTTP 502 Bad Gateway to the client. Resolution: Always configure the backend server's keep-alive timeout to be higher than the ALB idle timeout (e.g., 65–75 seconds on the target when ALB is set to 60 seconds).