Study ANS-C01 load balancing for ALB, NLB, GWLB, target health, protocol fit, inspection paths, high availability, and traffic steering.
Load-balancing questions on ANS-C01 are really path-control questions. AWS is testing whether you can place the right control point between clients and targets, match it to the protocol layer, preserve availability across zones or Regions, and avoid breaking inspection or security requirements.
The official task statement for this objective is to design solutions that integrate load balancing to meet high availability, scalability, and security requirements. That is broader than “pick ALB or NLB.” You need to reason about layer 7 application routing, layer 4 transport forwarding, layer 3 appliance insertion, health behavior, target type, client IP requirements, TLS placement, and how the load balancer fits with Route 53, CloudFront, Global Accelerator, WAF, and Gateway Load Balancer endpoints.
| Design question | What ANS-C01 wants you to notice |
|---|---|
| What layer owns the decision? | ALB is layer 7, NLB is layer 4, GWLB is layer 3 appliance insertion. |
| What is the protocol? | HTTP routing cues point toward ALB; TCP/UDP and static endpoint cues point toward NLB. |
| Where is security enforced? | WAF is web-layer filtering, security groups and NACLs are network controls, GWLB inserts appliances. |
| How is health proven? | Target health, zone behavior, endpoint health, and Route 53 or Global Accelerator health decisions can differ. |
| What must see the original client? | Client IP preservation, proxy headers, and TLS termination choices affect downstream controls. |
| Is traffic north-south or east-west? | Internet entry, private service exposure, inspection VPCs, and service-to-service routing have different answers. |
If you choose a load balancer before answering those questions, you are usually guessing.
| Requirement | Strongest first fit | Why it wins |
|---|---|---|
| Host-based routing, path-based routing, redirects, fixed responses, HTTP headers, or web authentication | Application Load Balancer | The decision depends on HTTP request content. |
| Web application needs AWS WAF at the regional entry point | Application Load Balancer | ALB integrates with web-layer controls. |
| TCP, UDP, TLS passthrough, very high connection scale, or static IP-style endpoint needs | Network Load Balancer | The decision is at the transport layer, not the HTTP layer. |
| Preserve a simple layer 4 path to targets while scaling across zones | Network Load Balancer | NLB forwards connections without requiring HTTP awareness. |
| Insert third-party firewalls, IDS/IPS, or deep-packet inspection appliances transparently | Gateway Load Balancer | GWLB combines a transparent gateway with load balancing across appliances. |
| Global users need static anycast entry before regional ALB/NLB endpoints | Global Accelerator plus regional load balancers | Global Accelerator handles global network entry; ELB handles regional distribution. |
| Cacheable HTTP content should be served near users before reaching the regional load balancer | CloudFront plus ALB or another HTTP origin | CloudFront is the edge delivery layer; ALB remains the regional application entry. |
Keep the control points separate. Many wrong answers collapse all traffic management into one load balancer.
flowchart LR
C["Client"] --> G["Global layer: Route 53, CloudFront, or Global Accelerator"]
G --> L["Regional load balancer: ALB, NLB, or GWLB path"]
L --> H["Health and routing decision"]
H --> T["Targets or appliances"]
T --> O["Logs, metrics, traces, and flow evidence"]
The key exam habit is to ask which layer owns the failing or optimized decision: DNS, edge, regional load balancer, appliance path, target health, or observability.
| Feature or clue | ALB | NLB | GWLB |
|---|---|---|---|
| OSI layer | Layer 7 | Layer 4 | Layer 3 gateway plus appliance load balancing |
| Main traffic type | HTTP and HTTPS | TCP, UDP, and TLS-style transport paths | IP packets through virtual appliances |
| Common exam clue | host/path routing, HTTP headers, redirects, authentication, WAF | static IP-style access, TCP/UDP, TLS passthrough, high performance | inline inspection, third-party firewall fleet, transparent appliance insertion |
| Target thinking | target groups for app services, containers, IPs, Lambda in many web patterns | target groups for transport-level services and private connectivity patterns | appliance targets that inspect traffic and return it to the path |
| Wrong-answer smell | chosen for raw TCP/UDP just because it is “web-facing” | chosen for host/path routing that requires HTTP awareness | chosen as a normal web load balancer |
Do not choose by service popularity. Choose by the protocol and the control point.
A load balancer answer is not complete until it explains how unhealthy targets stop receiving traffic and how the path behaves when an Availability Zone, Region, target group, or appliance fleet has a problem.
| Failure condition | Strong design response |
|---|---|
| One target instance fails | Target group health checks remove it from service. |
| One Availability Zone has target or network issues | Multi-AZ load balancer placement and healthy targets in other zones matter. |
| One Region is impaired | Pair regional load balancers with Route 53 failover or Global Accelerator, depending on speed and protocol needs. |
| One inspection appliance fails | GWLB target health and appliance fleet scaling must keep the path available. |
| A deployment sends bad traffic to a target group | Weighted, blue/green, or canary-style target-group routing may be relevant. |
| Clients still reach a bad endpoint | Check health-check scope, DNS caching, Global Accelerator endpoint health, and target group registration. |
ANS-C01 often makes more than one answer sound available. Prefer the answer that proves how failure is detected and how traffic moves away from it.
Load balancing and security are linked, but not interchangeable.
| Requirement | Stronger answer | Weaker answer |
|---|---|---|
| Filter HTTP requests by URI, header, or managed web rule | AWS WAF with CloudFront or ALB | Security group only |
| Inspect all traffic through a third-party firewall fleet | GWLB with symmetric routing through appliances | ALB or NLB by itself |
| Keep an origin from being bypassed | Restrict direct origin access and require traffic through the intended edge/load-balancer path | Add WAF but leave direct public access open |
| Preserve TLS end-to-end to targets | Use a design that matches TLS termination or passthrough requirements | Terminate at the wrong layer without noticing compliance constraints |
| Publish one private service to many consumers | PrivateLink backed by an NLB-style service pattern | Broad VPC peering or public exposure |
When the prompt says “security,” identify whether it means web filtering, network segmentation, encrypted transport, private exposure, or appliance inspection.
| Integration | When it appears | Exam cue |
|---|---|---|
| Route 53 plus ALB/NLB | DNS-level steering or failover to load balancer DNS names | Name-resolution policy and health checks matter. |
| CloudFront plus ALB | Global HTTP delivery with regional application routing | Edge cache/TLS/WAF before app routing. |
| Global Accelerator plus ALB/NLB | Static anycast entry and fast regional shift | Network-layer global entry before regional load balancing. |
| WAF plus ALB or CloudFront | Web application request filtering | URI/header/body/bot-style clues. |
| GWLB plus GWLB endpoints | Centralized or distributed inspection VPC | Traffic must be transparently steered through appliance fleets. |
| PrivateLink plus NLB-backed endpoint service | Private producer-consumer service exposure | Consumers need private access without broad routing. |
The exam frequently combines two of these. The strongest answer usually assigns each service one job instead of asking one service to solve the whole path.
| Scenario | Strong first design |
|---|---|
Public web application with /api and /static paths routed differently |
ALB, possibly behind CloudFront |
| Regional TCP service that partners allow-list by fixed addresses | NLB, possibly behind Global Accelerator for global static entry |
| UDP service with global users and regional failover needs | Global Accelerator with regional NLB or endpoints |
| Centralized inspection before workloads in multiple VPCs | GWLB endpoint path to appliance VPC, with route-table symmetry |
| Customer VPCs need private access to one provider service | PrivateLink endpoint service pattern backed by NLB |
| HTTP app requires managed web rules and DDoS-aware edge design | CloudFront or ALB with WAF, plus Shield Advanced where the resource profile justifies it |
| Stem clue | Eliminate first | Keep in play |
|---|---|---|
| host-header or path routing | NLB as the primary router | ALB |
| TCP or UDP, no HTTP semantics | ALB as the main fit | NLB |
| third-party firewall insertion | ALB/NLB alone | GWLB and route-table design |
| static anycast global entry | regional ALB DNS only | Global Accelerator with regional endpoints |
| cacheable global HTTP content | NLB as CDN | CloudFront plus regional origin |
| private service publishing to consumers | broad peering by reflex | PrivateLink with endpoint service |
| WAF rule match on URI/header | NACL-only answer | WAF on CloudFront or ALB |
When a load-balancing scenario describes broken traffic, use this order:
This sequence prevents the common mistake of changing security rules before proving the listener, target health, and routing path.
A company runs a public HTTPS application in two AWS Regions. The application needs host-based routing inside each Region. Global users should connect through static anycast IP addresses, and traffic should move away from a Region quickly if all regional targets become unhealthy. Which design is strongest?
Answer: Use Global Accelerator with regional ALBs.
Why: The scenario combines two layers. Static anycast global entry and fast regional movement point to Global Accelerator. Host-based HTTPS routing inside each Region points to ALB. Route 53 simple records do not provide the same static anycast entry or fast endpoint health behavior. CloudFront is not the main answer because the stem emphasizes static IP entry and regional endpoint failover, not HTTP caching. GWLB is for appliance insertion, not normal public web routing.
Choose ALB when the decision depends on HTTP. Choose NLB when the decision depends on TCP, UDP, TLS passthrough, static endpoint behavior, or private service publishing. Choose GWLB when the decision is transparent appliance insertion. Add CloudFront, Route 53, Global Accelerator, WAF, or PrivateLink only when their layer has a separate job in the path.
Continue with 1.4 Network Observability by Design to make the network path measurable before it fails.