Elastic Load Balancing and Route 53

AWS Cloud & DevOps Engineering · Lesson 12 · AWS Application Platform

Lesson Overview

Module 1 left TechLearningPro with a Multi-AZ Auto Scaling group, private subnets, security groups, and a progress API that can be replaced when a guest dies. That fleet is still invisible to learners until something healthy accepts HTTPS from the internet and something authoritative answers DNS for the board hostname. Elastic Load Balancing and Amazon Route 53 are that edge: traffic distribution, health-aware target selection, TLS termination patterns, and DNS records that point humans at the right Regional endpoint without hardcoding Elastic IPs into runbooks.

This lesson opens Module 2—AWS Application Platform. You will choose among Application Load Balancer and Network Load Balancer for the progress API shape, wire target groups to the ASG you already understand from Compute Services: EC2, AMIs and Auto Scaling, design health checks that match failure domains instead of thrashing replacements, and place Route 53 records with routing policies that match product intent. Later, Amazon CloudFront and Edge Delivery moves static and edge concerns outward; here you make Monday’s board reachable without abandoning least privilege from Security Groups, NACLs and VPC Connectivity.

TechLearningPro’s teaching shape: learners resolve a hostname, land on a TLS listener, hit only healthy progress API targets across two Availability Zones, and fail closed when health collapses—while budgets watch ALB hours and unused Classic leftovers never appear.

Learning Objectives

By the end of this lesson you will be able to:

1. Explain what Elastic Load Balancing solves for a Multi-AZ ASG that Module 1 already sized.
2. Compare Application Load Balancer (ALB) and Network Load Balancer (NLB) selection criteria without brochure trance.
3. Describe listeners, rules, target groups, and target registration for HTTP/HTTPS progress APIs.
4. Design health checks that detect application failure without coupling to every dependency outage.
5. Place load balancers in public subnets while keeping instance targets private, with security group matrices that match.
6. Terminate TLS at the load balancer with certificates from ACM patterns, without inventing cipher folklore.
7. Explain sticky sessions trade-offs and why TechLearningPro prefers sticky-free progress APIs.
8. Use Route 53 hosted zones and record types (A/AAAA alias, CNAME, TXT) for platform hostnames.
9. Choose routing policies—simple, weighted, latency, failover, geolocation—only when the product story needs them.
10. Distinguish alias records to ALB versus CNAME to public DNS names, and why alias matters at the zone apex.
11. Tag load balancers and DNS change tickets so Cost Explorer and change audit stay attributable.
12. Troubleshoot 502/503/504 and unhealthy targets with a disciplined checklist.
13. Avoid Classic Load Balancer for new work and refuse invented listener features.
14. Clean up lab ALBs, target groups, Route 53 test records, and ACM certificates you created for labs.
15. Connect this edge to the Well-Architected review habits from AWS Well-Architected Framework and Cost Basics.

Prerequisites

• Module 1 complete in concept: VPC with public and private subnets across two AZs, ASG with launch template, security groups, IAM instance profiles, budgets.
• Networking Fundamentals for AWS and Amazon VPC Architecture for subnets, route tables, and internet gateways.
• Ability to launch or reuse a small Multi-AZ ASG serving a simple HTTP health path (even a static nginx or a minimal progress stub).
• Sandbox account with a budget alert before creating load balancers—ALB hours are a classic forgotten cost.
• Optional domain you control in Route 53, or a public hosted zone for a lab subdomain; if you lack a domain, practice ALB DNS name and document how alias would attach later.
• No secrets in user data; certificates via ACM in the same Region as the ALB for Regional ALB HTTPS listeners (verify current ACM Regional vs edge certificate rules in docs when you implement).

Detailed Core Concepts

Why load balancing exists for TechLearningPro

Without a load balancer, operators are tempted to put Elastic IPs on instances, teach learners a brittle hostname, and pray the instance stays healthy. Auto Scaling then becomes theater: new instances have no traffic path, and DNS TTLs fight replacement. Elastic Load Balancing gives a stable DNS name (and, with Route 53 alias, a stable product hostname), distributes connections or requests across registered targets, and removes unhealthy targets from rotation based on health checks you define.

The progress API is a classic ALB workload: HTTP/HTTPS, path-based routing later for /api/progress versus static lesson assets (or CloudFront for static), and host-based routing when multiple apps share an edge. NLB appears when you need extreme performance, static IP characteristics, or non-HTTP protocols—useful awareness, not the default for the Monday board.

Elastic Load Balancing family (stable intent)

Application Load Balancer operates at Layer 7 for HTTP and HTTPS. It understands host headers, paths, query strings, and HTTP methods for listener rules. It integrates tightly with target groups of instances, IP targets, and later Lambda targets. Idle timeouts, sticky cookies, redirects, and fixed responses are ALB-shaped tools. For TechLearningPro’s browser and mobile clients talking REST/JSON to the progress API, ALB is the default Module 2 choice.

Network Load Balancer operates at Layer 4 (TCP/UDP/TLS where supported). It preserves client source IP in common patterns, supports very high connection rates, and can provide static addresses per AZ. Choose NLB when the protocol is not HTTP, when you front something that must see client IPs without proxy protocol gymnastics on ALB, or when partner systems demand NLB-specific behaviors. Do not pick NLB because it “sounds faster” for a JSON board API that never measured ALB as a bottleneck.

Gateway Load Balancer steers traffic through virtual appliances (firewalls, inspection). Mention it for interview completeness; do not deploy it for the progress API lab.

Classic Load Balancer is legacy. New designs should use ALB or NLB. If you inherit Classic, plan migration; do not expand it.

Exact feature matrices (HTTP/2, gRPC, mutual TLS, dualstack, cross-zone settings) evolve—verify the current ELB documentation for your Region before asserting a capability in a design review.

Listeners, rules, and target groups

A listener accepts connections on a protocol and port (for example HTTPS:443). On ALB, listener rules evaluate conditions and forward to a target group, redirect, or return a fixed response. Default rules catch unmatched traffic—often a 404 fixed response is safer than forwarding unknown hosts to the progress API.

A target group defines how to reach backends: protocol/port, health check settings, deregistration delay, stickiness, and target type (instance, IP, Lambda). The ASG registers and deregisters instances into the target group automatically when you attach the target group to the ASG’s load balancer settings. That attachment is how Module 1 cattle become Module 2 reachable cattle.

Health checks probe a path, port, and protocol. Success codes, interval, timeout, healthy/unhealthy thresholds, and matcher ranges matter. A check that hits / which returns 302 to a login page may flap if matchers expect 200. A check that opens a database connection on every probe couples AZ failure of RDS to mass target replacement—bad for the board. Prefer a local /health or /ready that confirms process liveness and critical local config, with deeper dependency checks exposed as metrics rather than LB kill switches—unless product explicitly wants traffic off when the database is down (sometimes correct for write APIs; document it).

TLS and certificates

For HTTPS listeners, attach a certificate. AWS Certificate Manager (ACM) issues and renews public certificates when DNS or email validation succeeds. For an ALB in a Region, use an ACM certificate in that same Region (edge/CloudFront certificates have their own Regional rules—covered next lesson). Redirect HTTP:80 to HTTPS:443 with an ALB redirect action so learners never bookmark cleartext. Security policies (TLS versions and cipher suites) are selected from AWS-managed policy names—pick a current recommended policy from documentation; do not invent cipher lists in YAML.

TLS termination at the ALB means instances can speak HTTP on an internal port if the security group only allows the ALB SG—common and acceptable when the VPC is trusted per your threat model. End-to-end TLS (ALB to instance HTTPS) is stricter; use it when compliance demands encryption in transit on every hop. Either way, never place long-lived private keys in instance user data.

Stickiness and session affinity

ALB can issue cookies so a client returns to the same target. TechLearningPro’s progress state belongs in RDS/DynamoDB/cache from Module 1—not in guest memory. Prefer sticky-free design. Stickiness masks bad architecture until an AZ drains and sessions die anyway. If a legacy lesson player requires affinity, document it as technical debt with an expiry, set stickiness duration deliberately, and keep ASG health graceful with deregistration delay so in-flight posts finish.

Cross-zone load balancing and capacity math

Cross-zone load balancing distributes traffic evenly across targets in all enabled AZs rather than only within the AZ that received the connection. Defaults differ by load balancer type and age of account settings—verify current default for ALB/NLB in docs when you design capacity. With uneven target counts per AZ, cross-zone on avoids hot AZs. Data transfer charges can apply for cross-AZ bytes—measure; do not invent rates. Capacity planning: ASG min across AZs must still meet Monday floor after one AZ loss if that is your reliability promise.

Route 53 as authoritative DNS for the platform

Amazon Route 53 is AWS’s DNS service: public and private hosted zones, health checks, routing policies, and domain registration (registration is optional; you can use an external registrar with Route 53 hosted zones). For TechLearningPro, a public hosted zone for learn.example.com (illustrative) holds records for app, api, and later CloudFront aliases.

Alias records are Route 53-specific extensions that map a name to AWS resources such as ALBs, CloudFront distributions, and S3 website endpoints without the zone-apex CNAME limitation. Prefer alias A/AAAA to the ALB DNS name for api.techlearningpro.example style names. Alias to ALB tracks the load balancer’s changing IP addresses automatically.

Routing policies (conceptual map—confirm details in current docs):

• Simple: one record, one target—fine for a single Regional ALB.
• Weighted: split traffic for canaries or blue/green DNS experiments; combine carefully with application deploy strategy (Module 3 deployment lessons deepen this).
• Failover: primary/secondary with Route 53 health checks—useful for multi-Region DR stories, overkill for a single-Region lab.
• Latency: send users to the Region with lowest latency among answers you publish—multi-Region product decision.
• Geolocation / geoproximity: compliance or localization routing—product and legal driven.
• Multivalue answer: returns multiple healthy IPs with basic health—different tool than ALB.

DNS is not a substitute for application health at the target group. Route 53 health checks probe endpoints you configure; they add cost and complexity. For Module 2 single-Region progress API, simple alias to ALB plus ALB target health is usually enough.

Private hosted zones and split DNS awareness

Private hosted zones associate with VPCs so internal names resolve inside the VPC. Useful for internal admin APIs. Do not put the learner-facing board only on a private zone. Hybrid split-horizon designs need careful record parity; interview topic, not the first lab.

Security group matrix for ELB

Typical pattern:

• ALB security group: allow 443 (and 80 if redirect) from 0.0.0.0/0 or from CloudFront prefix lists when locking origins later; egress to target ports.
• Instance security group: allow target port only from the ALB security group ID, not from the world.
• Deny SSH from the world; continue Session Manager habits from Module 1.

NACLs remain coarse; do not open ephemeral port ranges carelessly. Health checks originate from the load balancer nodes—ensure SG allows the ALB SG on the health port.

Cost drivers without fake prices

ALB/NLB charge for load balancer hours and for Load Balancer Capacity Units (LCU) or equivalent processed units depending on type—check current pricing pages. Idle ALBs in forgotten labs bill continuously. Route 53 charges for hosted zones and queries—usually smaller than ALB for labs, still real. ACM public certificates for use with AWS integrated services are commonly no additional charge for the certificate itself when used with ELB/CloudFront—verify current ACM pricing notes. Always set budgets before creating ALBs.

Quotas and soft limits awareness

Accounts have quotas on load balancers per Region, target groups, targets per group, and rules per listener. Exact numbers change and may be adjustable—look up Service Quotas for your account. Design reviews should not invent “the ALB max is X” from memory of an old blog.

Architecture and Design Diagrams

Learner path to Multi-AZ progress API:

mermaidCopy
flowchart TB
  User["Learner browser / mobile"]
  R53["Route 53 public hosted zone\nalias A/AAAA → ALB"]
  ALB["Application Load Balancer\nHTTPS listener :443"]
  TG["Target group\nhealth /health"]
  ASG["Auto Scaling group\nprivate subnets AZ-a + AZ-b"]
  RDS["RDS / cache\nsystem of record"]
  User --> R53 --> ALB --> TG --> ASG
  ASG --> RDS

Security group intent:

textCopy
Internet → ALB SG :443
ALB SG → Instance SG :8080 (health + app)
World ↛ Instance SG
Operator → SSM Session Manager (no SSH :22 from 0.0.0.0/0)

DNS alias versus instance IP anti-pattern:

mermaidCopy
flowchart LR
  Good["api.example alias → ALB DNS"]
  Bad["api.example A → Elastic IP on one instance"]
  Good --> Stable["Survives ASG replace"]
  Bad --> Fragile["Dies with the pet"]

Failover conceptual (multi-Region later):

mermaidCopy
flowchart TB
  DNS["Route 53 failover policy"]
  Primary["Primary Regional ALB"]
  Secondary["Secondary Regional ALB"]
  HC["Route 53 health check"]
  DNS --> Primary
  DNS --> Secondary
  HC --> DNS

Technical Explanation

Request flow through an ALB

1. Client resolves the product hostname via Route 53 alias to the ALB’s DNS name, receiving current addresses for the load balancer nodes.
2. TLS handshake completes at the ALB listener using the ACM certificate.
3. Listener rules match host/path; the forward action selects a target group.
4. ALB selects a healthy target using its routing algorithm (confirm current algorithm details in docs—commonly round robin-like for ALB with adjustments for least outstanding requests in some modes).
5. ALB opens or reuses a connection to the target, may add X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port so the app knows the original client context.
6. Target responds; ALB returns the response to the client.
7. Concurrently, health checkers probe targets; failures beyond thresholds mark unhealthy and stop new routing to that target. ASG health integration can replace the instance.

Understanding X-Forwarded-For matters for rate limiting and audit logs. Trust only when requests come from the ALB; applications that trust client-supplied forwarded headers from the open internet can be spoofed if the app port is reachable another way—hence SG lockdown.

Deregistration delay and deployments

When Auto Scaling or a deploy deregisters a target, deregistration delay keeps existing connections draining for a configured time. Too short: interrupted progress POSTs. Too long: slow deploys. Align with typical request duration of the progress API. Combine with connection draining mindset and ASG lifecycle hooks later for richer deploy control (Module 3).

Target types

Instance targets use the instance ID and the primary ENI port—natural for ASG. IP targets register VPC IPs—useful for certain container networking modes and appliances. Lambda targets let ALB invoke functions—preview for serverless lessons; not required for the EC2 progress tier. Mixing mental models without need creates operational fog.

ALB access logs and connection logs

ALB can emit access logs to S3 for request-level forensics and connection logs for TLS troubleshooting. Enable in staging when debugging 4xx/5xx storms; lifecycle the bucket prefixes so log storage does not quietly dominate Cost Explorer. Do not log authorization headers into custom app logs carelessly.

HTTP/2, WebSockets, and gRPC awareness

ALB supports modern protocol features for many workloads—verify current support lists before promising WebSockets for a live teaching lab or gRPC for an internal tool. If the lesson player needs long-lived WebSocket connections, confirm idle timeout settings: ALB idle timeout defaults may disconnect quiet sockets; raise deliberately within documented limits or use an architecture suited to long-lived streams.

Path-based and host-based routing for platform growth

TechLearningPro may later route api. host to progress, media. to a different target group, and /legacy path to a maintenance fixed response. Rules are evaluated in priority order. Keep rule count understandable; an unreadable rule forest is an outage generator. Prefer CloudFront behaviors for global static/media edge control in the next lesson rather than stuffing every concern into one ALB.

NLB when you truly need it

NLB preserves source IP by default in many TCP modes, which helps allowlists that cannot parse X-Forwarded-For. It integrates with PrivateLink as a Network Load Balancer endpoint service pattern in advanced networking modules. For a public HTTPS learning API, ALB plus proper header trust is usually clearer. If a partner demands NLB TLS listeners, read the current NLB TLS documentation for certificate attachment and target protocol choices—do not assume ALB rule features exist on NLB.

Route 53 change safety

DNS changes propagate based on TTLs and resolver caches. Lower TTL before a planned cutover, change records, raise TTL after stability. Alias to ALB already abstracts IP churn. Document who can change production records; use IAM policies and change tickets. Accidental deletion of a hosted zone is a Sev-1—protect with careful IAM and possibly AWS Config or SCP strategies later.

Health checks at two layers

ALB target health keeps traffic on living progress processes. Route 53 health checks decide whether a DNS answer should be returned for multi-target policies. Using Route 53 health checks to flip an entire Region requires a secondary that can actually serve—otherwise failover is a self-own. Single-Region Module 2: invest first in ALB/ASG health quality.

IPv6 and dualstack

ALB and Route 53 can participate in dualstack designs where enabled. Learners on IPv6-only networks increasingly appear. If you enable dualstack, test both stacks; half-configured dualstack creates mysterious client failures. Confirm current dualstack ALB and alias AAAA behaviors in documentation when you enable them.

Practical Implementation or Design Walkthrough

Problem

Expose a Multi-AZ progress API stub behind an ALB with HTTPS (or HTTP-only in sandbox if certificate setup is blocked—document the gap), register the ASG into a target group with a sensible /health check, create a Route 53 alias (or document the ALB DNS name as interim), prove failover by failing health on one AZ’s targets, and clean up.

Steps

1. Budget alert. Confirm an AWS Budgets alert exists for the sandbox before creating an ALB. Tag everything Project=tlp-lesson12, Owner=<you>, Environment=sandbox.
2. Baseline compute. Ensure an ASG spans two private subnets with min ≥ 2, launch template with instance SG that will later allow only the ALB SG. Application listens on an unprivileged port (for example 8080) and serves GET /health → 200 with a small JSON body. Do not put secrets in user data.
3. ALB subnets. Create an internet-facing ALB in two public subnets (one per AZ) with an ALB security group allowing 443/80 inbound as planned.
4. Target group. Create an IP or instance target group for HTTP:8080 (match your app), health check path /health, healthy threshold and interval that tolerate boot time with ASG grace. Attach to ASG.
5. Listener. Add HTTPS:443 with ACM certificate if available; else HTTP:80 for lab only and write an ADR that production requires HTTPS. Add redirect rule when both exist.
6. Security groups. Instance SG inbound 8080 source = ALB SG only. Remove any temporary world-open app ports from Module 1 labs.
7. DNS. In Route 53, create alias A record from your lab hostname to the ALB. If no domain, capture the ALB DNS name in the deliverable and show the console clicks you would use for alias.
8. Success test. curl -v the hostname or ALB DNS; expect 200 from /health and a sample progress read path.
9. Failure tests. (a) Stop the app process on one instance via Session Manager; confirm target becomes unhealthy and traffic continues on the other AZ. (b) Security group deny from ALB to instances; confirm failures and restore. (c) Optional: wrong health path → all unhealthy → 503; fix path.
10. Evidence. Screenshots or CLI describe output for ALB, target health, listener, alias record; redact account IDs if sharing externally.
11. Cleanup. Delete Route 53 lab records (not the whole org zone unless it is lab-only), delete ALB, delete target group after ASG detachment, remove lab certificates if unused, scale ASG to 0 or delete lab ASG per your Module 1 cleanup ethic. Confirm with tagged inventory.

Illustrative CLI orientation (verify flags against current AWS CLI reference)

Use the AWS CLI patterns you learned in lesson 4. Illustrative shapes—not a promise of exact option names forever:

bashCopy
# Illustrative: describe target health after setup
aws elbv2 describe-target-health --target-group-arn "$TG_ARN"

# Illustrative: list load balancers with your tag filter via resourcegroupstaggingapi or console
aws elbv2 describe-load-balancers

Prefer console for first learning if CLI flags confuse; graduate to CLI/IaC in Module 3. Never paste real certificate private keys into shell history.

Deliverable

Architecture diagram; SG matrix; health check settings; DNS record type explanation; test evidence for success and two failures; cleanup confirmation; note that unit prices were looked up or explicitly marked illustrative.

Enterprise Real-World Scenarios

TechLearningPro: Monday board without a stable name

Before ALB, a pilot used an Elastic IP on a single instance. Auto Scaling launched replacements that nobody could reach. Monday board errors spiked while DNS still pointed at a stopped pet. Fix: internet-facing ALB, ASG target group attachment, Route 53 alias, instance SG locked to ALB SG. Reliability became a design property again.

Health check that deleted the fleet

A team pointed ALB health at /api/progress/deep which queried RDS. During a database maintenance window, every target failed health, ASG replaced instances in a loop, and launch storms exhausted IPs. Fix: shallow /health for LB; deep checks as CloudWatch metrics and alarms; maintenance runbook disables aggressive replace or raises thresholds deliberately.

Weighted DNS canary without application readiness

Route 53 weighted records sent five percent of learners to a new Region with an empty database replica story. Progress appeared to “reset.” DNS weight is not a substitute for data replication design. Canary at the ALB/target group or deploy layer with shared data plane first; multi-Region DNS only with a real DR data plan (later modules).

NLB for vanity performance

A platform team replaced ALB with NLB for “lower latency” without measuring. They lost host-based routing and tidy HTTPS redirects, then rebuilt ALB in front of NLB complexity. Lesson: measure, then choose; ALB is the progress API default until evidence says otherwise.

Forgotten ALB in Cost Explorer

Sandbox ALBs from a hackathon sat for months. Lesson 11-style Explorer review found ELB among top services. Cleanup saved more than micro-right-sizing EC2. Module 2 rule: every ALB lab ends with deletion or an explicit owner and expiry tag.

Best Practices

• Prefer ALB for HTTP/HTTPS progress and board APIs; use NLB when protocol or PrivateLink requirements demand it.
• Keep targets in private subnets; put the ALB in public subnets for internet-facing apps.
• Source instance SG rules from the ALB security group ID, never from 0.0.0.0/0 on app ports.
• Use ACM certificates and HTTP→HTTPS redirects for learner-facing hosts.
• Design shallow health checks for load balancer kill switches; observe deep dependencies separately.
• Attach target groups to ASGs rather than manually registering pets.
• Use Route 53 alias records to ALB for zone apex and tidy Regional hostnames.
• Lower DNS TTL before cutovers; document owners for hosted zone changes.
• Enable access logs when debugging or for security baselines; lifecycle the log bucket.
• Tag ALB, target groups, and related S3 log buckets for Cost Explorer.
• Set deregistration delay to match in-flight progress writes.
• Prefer sticky-free apps with external session/state stores.
• Verify cross-zone and dualstack settings against current docs and cost implications.
• Budget before create; delete idle load balancers the same day labs end.
• Refuse Classic Load Balancer for new TechLearningPro services.
• Treat DNS failover as a multi-Region product decision, not a lab flex.
• Align idle timeouts with WebSocket or long-poll needs only when those features are real.
• Record evidence of target health during game days for Well-Architected reliability answers.

Common Mistakes and Anti-Patterns

World-open instance SG because “the ALB needs to reach it.” Symptom: scanners hit the app port directly. Cause: misunderstanding SG sources. Fix: allow only ALB SG; verify with a probe from a throwaway public IP that should fail.

Health check path returns 301/302 and matcher expects 200. Symptom: all targets unhealthy, ALB 503. Cause: redirecting health URL. Fix: dedicated /health that returns 200 without auth redirect; adjust matcher only with intent.

Registering one instance Elastic IP in Route 53 as an A record. Symptom: outages on replace. Cause: pet DNS. Fix: alias to ALB; ASG-owned targets.

Idle timeout too low for slow progress exports. Symptom: intermittent client failures on large reports. Cause: default idle timeout. Fix: raise within documented ALB limits or redesign for async export (SQS/Step Functions later).

Leaving lab ALBs running. Symptom: Cost Explorer ELB line grows. Cause: no cleanup. Fix: delete ALB and target groups; budget alerts.

Using Route 53 failover to nowhere. Symptom: DNS points to a secondary that cannot serve data. Cause: incomplete DR. Fix: do not configure failover until secondary is real; use simple alias until then.

Stickiness to hide in-memory sessions. Symptom: AZ loss drops “logged-in” learners. Cause: session affinity debt. Fix: externalize session/progress state.

Inventing ALB “features” from memory (fake rule types, fake quotas). Symptom: designs that cannot be built. Cause: outdated blogs. Fix: current ELB user guide as source of truth.

TLS policy set to ancient minimums “for compatibility” without review. Symptom: security findings. Cause: copy-paste from old templates. Fix: choose a current AWS-managed security policy name from docs.

Open HTTP listener without redirect in production. Symptom: cleartext tokens risk. Cause: lab settings promoted. Fix: redirect and HSTS at application or edge when appropriate (CloudFront/WAF lessons deepen edge headers).

Troubleshooting and Design Review

Targets show unused or unhealthy. Check: ASG attached to target group; instance port listening; SG path ALB→instance; NACLs; health path and matcher; subnet routing (private instances need no public IP when ALB is in public subnets with correct target type); grace period vs boot time.

502 Bad Gateway. Often ALB reached a target that closed oddly or app crashed mid-request. Check app logs via CloudWatch or Session Manager; target health; keep-alive mismatches.

503 Service Temporarily Unavailable. No healthy targets, or capacity zero. Check ASG desired, health storm, failed deploys.

504 Gateway Timeout. Target did not respond before ALB timeout. Optimize app, raise idle timeout carefully, or async the work.

Client cannot resolve hostname. Route 53 record missing, wrong hosted zone, registrar NS not pointing to Route 53, or local DNS cache. Dig/nslookup against Route 53 name servers.

HTTPS certificate warnings. Wrong cert attached, missing SAN for hostname, client hitting ALB DNS name with cert for product name only—use the alias hostname clients expect.

Only one AZ receives traffic. Unexpected cross-zone setting, targets only registered in one AZ, or subnet misconfiguration for the ALB.

Design review exit criteria: internet-facing ALB across two AZs; targets private; SG matrix documented; health check shallow and evidenced; Route 53 alias or explicit interim DNS; HTTPS plan; tags and budget; cleanup owner.

Interview Questions and Answers

Q1. ALB vs NLB for a JSON progress API?

ALB: Layer 7 routing, host/path rules, natural HTTPS learner APIs. NLB: Layer 4, source IP preservation patterns, non-HTTP or extreme connection scenarios. Default ALB unless requirements say otherwise.

Q2. Why alias to ALB instead of CNAME to ALB DNS at apex?

Zone apex cannot be a CNAME in standard DNS. Route 53 alias supports apex mapping to ALB. Alias also avoids extra lookup fees in Route 53’s model for AWS targets—confirm current billing notes when asked about cost.

Q3. How should security groups be set between ALB and EC2?

ALB SG allows client ports from the internet (or CloudFront). Instance SG allows app port only from ALB SG ID.

Q4. What makes a good target health check?

Fast, local, stable status code, independent enough not to couple every dependency outage to mass replaces, aligned with ASG grace periods.

Q5. Where should TLS terminate?

Commonly at ALB with ACM. End-to-end TLS when policy requires. Never store private keys in user data.

Q6. How does ASG integrate with ELB?

ASG registers instances into target groups; ELB health can drive ASG replacement when configured. Deregistration delay drains connections.

Q7. When do you use Route 53 failover?

When you have a real secondary endpoint and health checks that reflect user-visible health—typically multi-Region DR—not as decoration on a single ALB.

Q8. Why might you see 503 after a deploy?

All targets unhealthy due to bad health path, failed app boot, SG mistake, or desired capacity zero.

Q9. Sticky sessions—yes or no for TechLearningPro?

Prefer no; store progress in shared data stores. Stickiness is temporary debt for legacy apps.

Q10. What cost traps appear with ELB?

Idle load balancer hours, LCU/processed capacity units under load, cross-AZ transfer when relevant, forgotten access log storage. Look up current pricing; do not quote memorized rates.

Q11. Classic Load Balancer in a new design?

No for new work; migrate inherited Classic to ALB/NLB with a plan.

Q12. How do X-Forwarded-* headers interact with security?

Apps must treat them as trustworthy only from the load balancer hop; lock down direct access so clients cannot spoof by hitting instances.

Hands-On Exercises

Budget alert and lab hygiene (required)

Before any ALB create: open Budgets (or confirm existing sandbox budget), ensure email delivery works, tag planned resources. After the lab: delete ALB, listeners are removed with it, delete unused target groups, remove lab DNS records, scale down compute, verify tagged inventory is empty. Capture before/after notes for Cost Explorer within a few days if billing delay allows.

Exercise A: Multi-AZ route and failover documentation

Build the walkthrough above. Document target health before and after stopping the app on one instance. Prove remaining AZ serves /health. Rubric weight ideas: SG correctness 25%, health design 20%, DNS explanation 15%, failure tests 20%, cleanup 20%.

Exercise B: Redirect and fixed response

Add HTTP→HTTPS redirect (or simulate with HTTP fixed response explaining HTTPS requirement if cert blocked). Add a rule that returns 404 fixed response for unknown hosts. Test with a forged Host header.

Challenge

Write an ADR: single-Region ALB + Route 53 simple alias now versus multi-Region failover. Include data plane prerequisites you refuse to hand-wave. Budget constraint: no second Region resources in sandbox this week—design on paper with honesty.

Worked narrative: TechLearningPro progress API edge day

The platform team meets at 10:00. They confirm budgets. They create tlp-progress-alb in public subnets subnet-a-public and subnet-b-public (illustrative IDs). Target group tlp-progress-tg health checks /health every 30 seconds with a timeout under the interval, healthy threshold 3, unhealthy threshold 2—exact numbers chosen for lab stability, not as universal gospel. ASG tlp-progress-asg already has min 2. They edit the instance SG to allow 8080 only from sg-alb. Listener HTTPS attaches arn:aws:acm:... certificate for api.lab.example (illustrative ARN shape). Route 53 alias record created. Curl from a laptop returns 200. They use Session Manager to stop systemd on one host; target health goes unhealthy; curl still 200. They restore the service. They enable access logs to s3://tlp-lab-alb-logs/lesson12/ with lifecycle expiration measured in days, not years. They leave the ALB up only if the next lesson needs it the same afternoon; otherwise they delete it before signing off.

Deep dive: choosing healthy threshold and intervals

Short intervals detect failure faster but increase probe traffic and flapping risk on GC pauses. Long intervals leave dead targets in rotation longer. Thresholds debounce single blips. For progress API labs, err toward stability while learning. For production, game-day the values: inject 500s on /health and measure time-to-remove and time-to-recover. Record the values in the runbook. Do not copy a random Terraform module’s health settings without reading them.

Deep dive: ALB rules as a tiny router

Host header api.lab.example → progress TG. Host static.lab.example → might later be CloudFront-only (do not create a second origin story here without need). Path /maintenance → fixed response 503 with JSON message during incidents. Priority numbers must be unique; gaps allow inserts. Document the rule table in the same repo that will later hold IaC. Console-only rule forests drift.

Deep dive: Route 53 resolver behavior for operators

When a change “does not work,” ask: which resolver are you using? Corporate DNS may cache aggressively. Test against the hosted zone’s delegated name servers. Confirm NS records at the registrar. Confirm you edited the correct account’s hosted zone in a multi-account org. Confirm the record name is fully qualified as you intend (api vs api.lab.example). These operational questions prevent false ALB debugging.

Deep dive: cross-zone and AZ loss math

Promise: survive one AZ loss with remaining capacity ≥ Monday floor. If min=2 and both instances land in one AZ due to bad subnet list, you already failed. ASG subnets must include both AZs. With cross-zone load balancing enabling even distribution, still ensure each AZ can carry floor traffic after loss—otherwise you need capacity headroom, not only even spreads. Write the math in the ADR: “floor 100 RPS; one AZ loss; each AZ sized for 100 RPS at peak.”

Deep dive: certificates and hostname discipline

Clients validate certificates against the hostname they requested. Teaching learners to hit the raw ALB DNS name while the certificate only lists the product alias produces scary browser warnings and trains bad habits. Always demonstrate the alias hostname. For labs without a domain, use HTTP on ALB DNS deliberately and state that TLS naming is incomplete—do not pretend.

Extended scenario: blue/green at DNS versus at target groups

DNS weighted cutover is coarse and TTL-bound. Target group weighted forwarding on a single ALB (where supported by your deploy approach) or separate ALBs with shared data stores can be tighter. Module 3 deployment lessons will expand blue/green and canary. This lesson’s job is to refuse DNS magic as a substitute for healthy target groups and shared state.

Extended scenario: compliance review asks for TLS everywhere

Security asks for encryption in transit from ALB to instance. You install certificates on instances or use self-signed with ALB HTTPS backend, managing trust bundles. Operational cost rises. Alternative: private-only backend HTTP plus strict SG and VPC controls may be accepted risk for some tiers—document the threat model. Do not silently ignore the ask; write the ADR.

Extended troubleshooting playbook

1. Can you resolve DNS? 2. Can you TCP connect to 443 on ALB? 3. Does TLS handshake succeed? 4. Does listener rule match? 5. Are any targets healthy? 6. Does SG allow ALB to target? 7. Does the app respond on the instance locally via Session Manager curl to localhost? 8. Do access logs show the request? Stop guessing between steps 1 and 8 out of order.

Interview story to practice aloud

“We put the progress API behind an ALB across two public subnets, instances stayed private, health checked /health, and Route 53 alias pointed the API hostname at the ALB. We proved AZ failure by stopping the app on one side. We did not put Elastic IPs in DNS, we did not open instance SG to the world, and we deleted the lab ALB so Cost Explorer stayed honest.”

Operator cadence

Weekly: unused ELB inventory by tag; target health dashboards; certificate expiry (ACM renews public certs when validation remains valid—confirm status). Monthly: review listener rules for dead paths; revisit idle timeouts; confirm HTTP redirect still present. After each game day: store target health screenshots with the incident ticket.

Connection to Module 1 pillars

Reliability: Multi-AZ targets and health. Security: SG matrix and TLS. Cost: ALB hours and log lifecycle. Operational excellence: runbooks for 503 and DNS. Performance: measure before jumping to NLB. Sustainability: delete idle balancers.

Connection to upcoming lessons

CloudFront will front static lesson media and can put WAF at the edge later. Lambda and API Gateway offer another entry path for event-driven progress webhooks. Containers on ECS can become ALB targets with different target types. The edge pattern you learn here transfers: stable name, health, least privilege, cleanup.

Student self-check

Can you explain alias versus CNAME? Can you draw the SG matrix from memory? Can you name two causes of 503? Did you set a budget? Did you clean up? Did you avoid fake prices and fake quotas? If not, finish before claiming Module 2 progress.

Lab cleanup checklist (copy into your notes)

• Detach ASG from target groups / remove load balancer association as needed for delete order
• Delete ALB
• Delete target groups
• Delete lab Route 53 records
• Delete unused ACM lab certificates if appropriate
• Delete access log prefix or bucket if lab-only
• Scale down or delete lab ASG/instances
• Verify no Elastic IPs left from experiments
• Budget alert left enabled for Module 2 continuation

Optional stretch: host-based multi-app edge

Add a second target group for a simple “status page” app and a listener rule on a second hostname. Prove rule priority. Remove the stretch resources in cleanup—stretch is how accidental permanent cost appears if forgotten.

Notes on documentation currency

Listener rule condition keys, NLB TLS behaviors, dualstack defaults, and pricing dimensions change. When your homework cites a setting, link the AWS documentation page you checked and the date. This course grades honesty over memorized folklore.

Extended best practice: naming and tagging dictionary

Name load balancers tlp-<env>-<app>-alb, target groups tlp-<env>-<app>-tg, security groups tlp-<env>-<app>-alb-sg. Tags: Project, Owner, Environment, Service=progress-api, CostCenter per org dictionary. DNS records should appear in the change ticket with the same Service tag narrative. Consistent naming makes cleanup scripts and Explorer filters boring—in the good way.

Extended mistake: using the ALB as a WARP gateway for admin

Do not punch temporary admin paths through the public ALB with weak auth because Session Manager “was hard.” That path becomes permanent. Keep operator access on SSM; keep ALB for learner traffic.

Final synthesis for the Monday board

Learner DNS lookup → Route 53 alias → ALB HTTPS → healthy private instances in two AZs → progress reads/writes via Module 1 data stores. Failure of one instance or AZ does not require a human rewriting DNS. Cost is visible. Security groups do not expose the app tier to the world. That is the Module 2 starting line.

Lesson Summary

Elastic Load Balancing turns a Multi-AZ ASG into a reachable, health-aware service. Route 53 gives the platform durable names through alias records without pet Elastic IPs. ALB is the default for TechLearningPro’s HTTP progress APIs; NLB waits for Layer-4 requirements. Shallow health checks, tight security groups, ACM-backed TLS, budgets, and ruthless lab cleanup keep the edge honest. Next, CloudFront extends delivery toward the learner’s network edge for static and cached content while origins stay protected.

Amazon CloudFront and Edge Delivery continues the path from Regional ALB toward global edge behaviors, caching, and origin protection.

Further Reading

• What is Elastic Load Balancing?
• Application Load Balancers
• Network Load Balancers
• Target group health checks
• Amazon Route 53 Developer Guide
• Choosing a routing policy
• AWS Certificate Manager
• ELB pricing — verify live; do not hardcode rates
• Route 53 pricing — verify live