ELB and Route 53 for SysOps

Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones. It monitors the health of registered targets and routes traffic only to healthy ones. ELB scales its capacity automatically in response to incoming traffic.

AWS offers three types of load balancers relevant to SOA-C02:

ALB and CLB support sticky sessions using a cookie. Duration-based stickiness uses an AWS-generated cookie (AWSALB) or application-generated cookie. The load balancer binds a user's session to a specific target for the duration of the cookie lifetime. This is useful for stateful applications but can cause uneven load distribution. NLB does not support sticky sessions natively; you must use an application-level mechanism.

When a target is deregistered (e.g., during scaling in), the load balancer stops sending new requests to it but allows in-flight requests to complete. Default deregistration delay is 300 seconds for ALB and NLB, configurable. For CLB, this is called connection draining, default 300 seconds. Set this value based on your application's maximum request processing time.

Route 53 is a highly available and scalable Domain Name System (DNS) web service. It translates domain names to IP addresses (A/AAAA records), CNAME records, alias records, etc. Route 53 also supports health checks and routing policies.

When a client queries Route 53 for a domain, Route 53 returns the appropriate record along with a Time-to-Live (TTL) value. The client and intermediate DNS resolvers cache this record for the TTL duration. Default TTL for Route 53 records is 300 seconds (5 minutes) unless specified. For alias records (pointing to AWS resources like ELB), TTL is managed by AWS and is typically 60 seconds.

Alias records are a Route 53 extension that allows you to point a domain to an AWS resource (ELB, CloudFront, S3 bucket, etc.) using the resource's DNS name. Unlike CNAME, alias records can be used at the zone apex (e.g., example.com). They are free and automatically update when the resource's IP changes. TTL is set by AWS (typically 60 seconds).

Route 53 health checks monitor the health of endpoints (IP addresses or domain names). You can associate health checks with records to enable failover routing. Health check types:

A common pattern is to create an alias record in Route 53 pointing to an ELB DNS name. This allows you to use Route 53 routing policies (weighted, latency, failover) with the load balancer as the target. For example, you can set up active-passive failover across regions: primary region ELB with health check, secondary region ELB as failover. If the primary health check fails, Route 53 automatically routes traffic to the secondary.

Configuring ALB with HTTPS

Configuring NLB with TCP

Route 53 Failover with ELB

You have an application deployed in us-east-1 and us-west-2. You want to route traffic to the closest region under normal conditions, but if one region fails, all traffic should go to the healthy region. Solution: Use Route 53 latency-based routing with failover? No, latency does not support failover. Instead, use a failover record with health checks on each region's ELB. Or use a weighted record with health checks (weights 0 and 100). The exam expects you to know that failover routing policy is the correct choice for active-passive failover.

You need to migrate from Classic Load Balancer to Application Load Balancer. Steps: Create ALB with target groups, register instances, configure listeners and rules, update DNS to point to ALB, then delete CLB. The exam may ask about preserving source IP: CLB does not preserve source IP (unless using Proxy Protocol). ALB uses X-Forwarded-For. NLB preserves source IP.

ELB and Route 53 are fundamental to building resilient applications on AWS. The SOA-C02 exam tests your ability to choose the correct load balancer type, configure listeners and target groups, set up health checks, and combine Route 53 routing policies with ELB for global traffic management. Memorize default values, understand the differences between ALB, NLB, and CLB, and practice with routing policies. Use the step-by-step and real-world sections below to solidify your understanding.

A large e-commerce company deploys its web application in three AWS regions: us-east-1, eu-west-1, and ap-southeast-1. They use Route 53 latency-based routing to direct users to the region with the lowest latency. Each region has an Application Load Balancer distributing traffic to an Auto Scaling group of EC2 instances. The ALB terminates SSL, offloading the CPU-intensive decryption from the instances. Health checks are configured on the ALB target group to monitor the application's /health endpoint. In production, they observe that during flash sales, traffic spikes cause some instances to become unhealthy. They set the deregistration delay to 120 seconds to allow in-flight requests to complete. They also enable sticky sessions (duration-based) to maintain user session data in memory. The Route 53 health checks monitor each ALB's DNS name every 30 seconds. If us-east-1 goes down, Route 53 automatically fails over to the next best region. This setup handles 50,000 requests per second during peak. A common misconfiguration is setting TTL too high (e.g., 300 seconds), causing slow failover. They use alias records with TTL of 60 seconds.

A financial services company runs a microservices application on Amazon ECS with Fargate. They use an internal ALB (scheme: internal) to route traffic between services. Each microservice has its own target group and listener rule based on path patterns (/api/users, /api/orders, etc.). The ALB is placed in private subnets with a security group that allows traffic only from the VPC CIDR. Health checks use HTTP on port 8080. They use Network Load Balancer for inter-service communication that requires TCP and ultra-low latency (e.g., for real-time data feeds). The NLB preserves source IP, allowing the downstream service to log the original client IP. They set up Route 53 private hosted zones for internal DNS resolution. Each service is registered with a weighted record set to distribute traffic across multiple ALBs. They monitor with CloudWatch and set alarms for increased error rates. A common issue is forgetting to update the security group for the NLB: NLB uses source IP preservation, so security groups must allow traffic from client IPs, not just the NLB subnet. They also ensure cross-zone load balancing is enabled to evenly distribute traffic.

A healthcare application must maintain 99.99% uptime. They deploy the application in us-east-1 (primary) and us-west-2 (secondary). An ALB in each region distributes traffic to instances in multiple AZs. Route 53 failover routing policy is used: primary record points to us-east-1 ALB, secondary to us-west-2 ALB. Each record has an associated health check that pings the ALB's DNS name every 30 seconds. If the primary health check fails (e.g., due to a regional outage), Route 53 automatically routes all traffic to the secondary region. They also use Route 53 health checks with a fast failure threshold (2 consecutive failures) to minimize downtime. To avoid false positives, they set the health check interval to 10 seconds (fast) and use a calculated health check that combines multiple endpoints. In the secondary region, they keep a minimum number of instances running to handle traffic, and use Auto Scaling to scale up on demand. They test failover quarterly by simulating a primary failure. A common mistake is not setting the resource record set's 'Evaluate Target Health' to Yes, which disables health check integration. Also, they ensure the secondary region's ALB is always healthy by keeping at least one instance running.