Interactive scalable VPC topology and load balancing
Grow a multi-tier VPC by planning nonoverlapping address capacity, AZ subnet tiers, route ownership, target capacity, and the correct Layer 7, Layer 4, or appliance load-balancing strategy.
LESSON GOALS
By the end, you can
01
Quantify topology growth before drawing
Inventory Regions, AZs, tiers, peak ENIs and IPs, container or Lambda scaling, hybrid and peer CIDRs, protocols, static-IP needs, HTTP rules, inspection, failure scope, and growth horizon. Reserve nonoverlapping CIDR space and calculate usable addresses after AWS reservations and infrastructure consumption. A subnet name does not make it public; its associated route and resource addressing create the path. A larger CIDR added later cannot repair overlap with on-premises or every connected VPC.
Place public front doors only where internet reachability is required. Put application and data tiers in private subnets across enough AZs, and associate the intended route table with each subnet. Trace longest-prefix route at every routing domain and both forward and return controls. Plan route-table, target, and ENI growth before scale events. Centralization reduces management copies but can create throughput, route, cost, and failure concentration; distribute where the stated availability or path requirement decides.
02
Choose load balancer by protocol and function
ALB is Layer 7 for HTTP and HTTPS with host, path, and other HTTP-aware routing. NLB is Layer 4 for TCP, UDP, TLS, static-IP-oriented entry, and transport requirements. Gateway Load Balancer inserts and scales network virtual appliances transparently; it is not ordinary application ingress. Choose from protocol and function rather than a claim that one is universally faster.
Place targets across AZs and ensure target security controls, listener, health checks, ports, and routes align. Load balancer capacity cannot rescue exhausted target subnets or a database bottleneck. Health evaluation must keep routing state separate from application delivery. ALB documentation describes fail-open routing when every registered target is unhealthy: it sends requests to those targets despite health. An empty ALB target group instead has no registered target to receive the request; do not infer the all-unhealthy behavior from an empty registration set.
NLB documentation has two explicit fail-open conditions: all targets are unhealthy in all enabled Availability Zones, and the target group is empty. The empty-group condition still supplies no target and therefore no application endpoint; “fail open” describes the NLB routing mode, not a successful business response. Fixtures must record registration count, per-AZ health, routing decision, connection result, and application result separately. Capacity planning also includes target connections, long-lived flow distribution, draining, and enough surviving target capacity after an AZ failure.
03
Scale routes connectivity and controls coherently
For two directly connected nonoverlapping VPCs, peering can be simple but is nontransitive and requires routes on both sides. Transit Gateway fits a growing hub-and-spoke topology where attachment and centralized route-table management reduce a peering mesh. Neither choice overrides security groups, NACLs, DNS, or destination authorization. A shared services design needs explicit propagation and isolation, not one flat route domain.
The visual should progressively reveal Region, AZs, CIDRs, subnets, routes, load balancer, targets, SGs, NACLs, and connectivity. Inject IP exhaustion, wrong route association, asymmetric return, and target failure. Evaluate first failed gate and repair minimally. Security is not color coding: every permit or deny needs protocol, port, source, and direction. Performance is measured end to end; cost follows valid topology. Leave address and route headroom and test an AZ loss before calling the network scalable.
Load-balancer health behavior must be tested with registration state visible. For ALB, every registered target being unhealthy can produce fail-open routing, whereas an empty ALB group has no target. For NLB, both all-unhealthy-across-enabled-AZs and empty-group states are documented fail-open conditions; the empty case still cannot deliver an application response because there is no endpoint. Build fixtures for one healthy target, all registered targets unhealthy, and zero registered targets, then display routing mode, connection outcome, and application response independently. Health endpoints should validate the minimum dependency needed to serve while avoiding sensitive details. Address growth has a parallel cost test: larger subnets are not billed for empty addresses, but NAT, inspection, cross-AZ paths, load-balancer capacity, and idle surviving targets can be. Keep security-group references narrow enough that scaling adds authorized targets without opening an entire VPC CIDR.
DECISION TABLE
Compare the architecture constraints
| requirement | choose | because | reject |
|---|---|---|---|
| HTTP host/path routing | ALB | Layer 7 rules decide | NLB lacks HTTP-aware routing |
| TCP/UDP or static IP entry | NLB | Layer 4 transport decides | ALB does not satisfy raw transport |
| Transparent appliance fleet | GWLB | Appliance insertion decides | ALB/NLB are not equivalent inspection fabric |
| Many transitive VPC spokes | Transit Gateway | Hub routing scales management | Peering is nontransitive mesh |
GUIDED WORKED SCENARIO
Reason from the stated constraints
This is a guided example, not a question to memorise. The knowledge check uses new situations to test the same reasoning.
A VPC /20 has /24 app subnets in two AZs. Containers grow from 80 to 700 tasks; one subnet exhausts IPs, return traffic uses the wrong inspection route, and HTTPS needs host routing. One target group is all unhealthy.
Requirements
- Support 700 tasks with 30% IP headroom
- Survive one AZ loss
- Route HTTPS by hostname
- Keep inspection paths symmetric and diagnose fail-open targets
Reasoning path
- Calculate per-AZ ENI demand and allocate larger nonoverlapping app subnets.
- Associate route tables explicitly and trace return through stateful inspection.
- Choose ALB for host rules and spread targets.
- Treat all-unhealthy routing as degraded and evaluate application response.
Why it wins
- It repairs address, route, and load-balancer constraints together.
- It preserves ELB fail-open nuance instead of equating unhealthy with no route.
Why the alternatives lose
It does not meet HTTP host-routing requirement.
Becomes correct when: Layer 4 protocol or static IP is decisive.No ENIs can be allocated and AZ headroom remains absent.
Becomes correct when: Subnet has measured spare addresses.It supplies IPs but violates AZ survival.
Becomes correct when: Only single-AZ development use is required.ARCHITECTURE VISUAL · TEXT MODE
Inspect the model
An ordered packet table includes subnet capacity, route association, inspection symmetry, ALB listener, target registration, health state, and application result.
saa-viz-network-path-labKNOWLEDGE CHECK
Answer one question at a time
Pass every question to complete this lesson. Each answer includes reasoning before you continue.
ALB, NLB, GWLB decisive boundaries?
Reveal reasoning
HTTP-aware routing, Layer 4/static transport, and appliance insertion.
Compare ALB and NLB when all registered targets are unhealthy and when registration count is zero. What routing and application observations differ?
Change one decisive constraint: Ingress changes from host-routed HTTPS to raw TCP and requires static entry IP addresses. Which architecture now wins, and what observable result proves the reversal?
Before reveal in saa-viz-network-path-lab, predict the first failed gate for the original interactive scalable vpc topology and load balancing case, then trace the observed branch and minimal repair.
Reveal reasoning
Commits to an outcome first, follows the visual gate order, separates routing or control state from business response, and repairs the earliest violated requirement.
PRIMARY SOURCES
Verify the claims
- primaryWhat is Amazon VPC?aws-net-vpc · retrieved 2026-07-29
- primaryWhat is Elastic Load Balancing?aws-compute-elb · retrieved 2026-07-29
- primaryWhat is an Application Load Balancer?aws-elb-application-load-balancer · retrieved 2026-07-30
- primaryWhat is a Network Load Balancer?aws-elb-network-load-balancer · retrieved 2026-07-30
- primaryWhat is a Gateway Load Balancer?aws-elb-gateway-load-balancer · retrieved 2026-07-30
- primaryControl traffic to your AWS resources using security groupsaws-vpc-security-groups · retrieved 2026-07-30
- primaryControl subnet traffic with network access control listsaws-vpc-network-acls · retrieved 2026-07-30
- primaryWhat is VPC peering?aws-vpc-peering-overview · retrieved 2026-07-30
- primaryWhat is AWS Transit Gateway?aws-net-tgw · retrieved 2026-07-29
- primaryAlb Health Checksaws-alb-health-checks · retrieved 2026-07-30
- primaryNlb Health Checksaws-nlb-health-checks · retrieved 2026-07-30