Scalable Networks: CloudFront vs Global Accelerator, Transit Gateway, ALB vs NLB

Both services put user traffic onto AWS's global edge network close to the user and carry it to your origin over the AWS backbone instead of the public internet — and because both promise "better global performance," SAA-C03 makes you tell them apart constantly. The separation is what each actually does with the traffic.

Amazon CloudFront is a content delivery network: it caches content at edge locations. Static assets — images, video, downloads, JavaScript bundles — are served from the edge without touching the origin at all, which is both the latency win and an origin-offload win. CloudFront also accelerates dynamic, non-cacheable content by terminating connections at the edge and reusing optimized connections to the origin, so "CloudFront is only for static content" is a distractor claim. CloudFront speaks HTTP and HTTPS; its origins can be S3 buckets, load balancers, or any HTTP server.

AWS Global Accelerator does not cache anything. It gives you two static anycast IP addresses announced from every edge location: users connect to the nearest edge, and the accelerator routes the connection over the AWS backbone to the optimal healthy endpoint — an ALB, NLB, or EC2 instance in one or more Regions. Because it works at the connection layer, it carries TCP and UDP, including protocols that are not HTTP at all — game servers, VoIP, MQTT, custom TCP. Health checks make cross-Region failover near-instant, without waiting for DNS caches to expire.

The decision rule: cacheable or HTTP-based content → CloudFront; non-HTTP protocols, static IP requirements, or deterministic fast regional failover → Global Accelerator. "UDP," "gaming," "VoIP," "fixed IP addresses for firewall allowlisting," and "fail over between Regions in seconds" are Global Accelerator phrases; "reduce load on the origin," "serve images and video globally," and "cache at the edge" are CloudFront phrases.

The exam tests this as a straight selection, usually seasoning the stem with one disqualifying detail — a UDP port, or an enterprise customer who must allowlist fixed IPs — that eliminates CloudFront even when the workload otherwise sounds web-shaped.

Elastic Load Balancing questions are protocol questions in disguise: identify what the traffic is, and the load balancer picks itself.

The Application Load Balancer (ALB) operates at layer 7 and understands HTTP. That awareness is its entire value: it routes by path (/api/* to one target group, /images/* to another), by host header (multiple domains on one load balancer), and by other request attributes; it supports WebSockets, HTTP/2, and Lambda functions as targets. When a scenario describes microservices behind one entry point, content-based routing, or serverless HTTP backends, the ALB is the answer. Its trade-off: it terminates and inspects HTTP, so it is not built for raw-socket workloads.

The Network Load Balancer (NLB) operates at layer 4 and forwards TCP and UDP connections with ultra-low latency at extreme scale — millions of requests per second. It is the answer when the stem says any of: non-HTTP protocol, "millions of connections," "lowest possible latency," "static IP address per Availability Zone" or "attach an Elastic IP" (the ALB cannot do either), or "preserve the client source IP" at the connection level. NLB also supports TLS passthrough — forwarding encrypted traffic untouched so targets terminate TLS — which matters when compliance requires end-to-end encryption without the load balancer decrypting.

The Gateway Load Balancer (GWLB) is the specialist: it sits inline in the traffic path and distributes flows across a fleet of third-party virtual appliances — firewalls, intrusion detection and prevention systems, deep packet inspection — scaling and health-checking the appliance fleet for you. The trigger phrase is unambiguous: "inspect traffic with third-party security appliances" means GWLB, full stop.

One shared concept is worth recognizing: cross-zone load balancing, which lets a load balancer node in one Availability Zone send traffic to targets in every AZ rather than only its own. The ALB has it always on; the NLB has it off by default, and enabling it evens out traffic across unevenly sized target groups at the price of cross-AZ data transfer. A stem describing targets in one AZ receiving disproportionate traffic behind an NLB is pointing here.

The exam's favorite discriminators are the NLB-only features. A question that seems ALB-shaped until it mentions a fixed IP for customer firewall rules, a UDP workload, or single-digit-millisecond latency requirements has just switched its answer to NLB. Read the protocol and the IP requirement before admiring the routing features.

Network architectures fail to scale for a mundane reason: the address plan was too small or overlapped with something it later had to connect to. Task 3.4 tests this at design-review depth.

A VPC's CIDR block can range from /16 (65,536 addresses) down to /28. The scaling rule is to size for the future, not the present: address space is free, and re-addressing a live VPC is painful, so a /16 for a VPC that "only needs a few hundred addresses today" is prudent, not wasteful. Just as important, CIDR ranges must be non-overlapping across every VPC and on-premises network you might ever connect — VPC peering and hybrid routing cannot function between overlapping ranges, because a route can only point one way for a given prefix. An organization that gives every VPC 10.0.0.0/16 by default has built a fleet of networks that can never be peered; carving a company-wide IP plan (distinct ranges per VPC, per environment, per site) is the design answer.

Inside the VPC, subnets form tiers repeated across Availability Zones: public subnets for load balancers and NAT gateways, private subnets for application instances, isolated subnets for databases — one of each per AZ, so every tier survives an AZ failure. Subnets cannot be resized after creation, and AWS reserves five addresses in each, so tier sizing follows growth too: the application tier that will run large Auto Scaling groups gets the big subnets, and remember that every ENI consumes an IP — container platforms and Lambda-in-VPC configurations consume addresses far faster than an instance count suggests.

When a VPC does run out of addresses, recognize the escape valve: you can associate secondary CIDR blocks with an existing VPC and add subnets from the new range.

The exam tests this as cause-and-effect: a peering or VPN option that silently fails because ranges overlap, or a "cannot launch instances" symptom traced to subnet exhaustion. When two connectivity options differ only in that one requires re-addressing, the stem's CIDR details are the answer key.

Placement groups control where EC2 places instances relative to each other, trading latency against blast radius. There are exactly three strategies, and the exam maps each to a workload by keyword.

The trade-offs are the testable nuance. A cluster group buys latency by giving up resilience — everything sits in one AZ, close together, so an AZ or capacity event takes the whole workload; it can also hit insufficient-capacity errors, and launching all instances together (and using a single instance type) reduces that risk. A spread group is the opposite bet — maximum isolation, but capped at seven instances per AZ, so it cannot host a big fleet; that seven-instance limit is how the exam eliminates it in favor of partition groups for large distributed systems, which get failure isolation at scale by accepting isolation between partitions rather than between every instance.

Alongside placement, recognize enhanced networking: the Elastic Network Adapter (ENA) gives supported instance types higher packet-per-second throughput and lower, more consistent latency, and is the standard companion to a cluster placement group for HPC. The Elastic Fabric Adapter (EFA) goes further for tightly coupled HPC and machine-learning workloads using MPI-style communication — recognition level only.

Exam questions here are near-lookups: match the workload word (HPC, Kafka, "critical") to the strategy, then check the distractors against the seven-instance spread limit and the single-AZ cluster constraint.

Three services connect VPCs, and they answer three different questions. Getting them straight — especially the peering trap — is among the most reliably tested material in this task.

VPC peering is a private, one-to-one connection between two VPCs (same or different accounts and Regions). It is simple and has no bandwidth bottleneck, but it is strictly pairwise: peering is not transitive. If VPC A peers with B, and B peers with C, A still cannot reach C through B — ever. Full connectivity between N VPCs therefore needs a mesh of N×(N−1)/2 peering connections, plus route-table entries for every pair. Peering is right for a few VPCs with simple, stable relationships; it collapses under scale, and its CIDR ranges must not overlap.

AWS Transit Gateway is the hub-and-spoke answer: VPCs, Site-to-Site VPNs, and Direct Connect gateways all attach to one regional hub, and routing through the hub is transitive — any attachment can reach any other, governed by the transit gateway's route tables (which can also segment traffic, keeping production and development attachments apart). One attachment per VPC replaces the peering mesh, and the same hub concentrates hybrid connectivity. When a scenario says "dozens (or hundreds) of VPCs," "simplify network management," or "VPCs and on-premises must all reach each other," Transit Gateway is the answer.

AWS PrivateLink answers a narrower question: expose one service — an API or application fronted by a Network Load Balancer — to many consumer VPCs without connecting the networks at all. Consumers create interface endpoints in their own VPCs and reach the service privately; no routes are exchanged, nothing else in either VPC is reachable, and overlapping CIDRs do not matter, which peering and Transit Gateway cannot tolerate. It is the SaaS-provider pattern: "make our service privately consumable by hundreds of customer VPCs" is PrivateLink, not a hundred peering connections.

The exam tests this with the trap named above — a hub VPC peered to spokes, with someone expecting spoke-to-spoke traffic to flow — and with scale words that flip the answer from peering to Transit Gateway, or from network-to-network connectivity to PrivateLink when only one service needs sharing.

Task 3.4 revisits hybrid connectivity from a performance angle: not "how do we connect on premises to AWS" but "which link meets the throughput and consistency requirement."

AWS Site-to-Site VPN builds encrypted IPsec tunnels from your on-premises gateway to AWS over the public internet. It stands up in hours, costs little, and is encrypted by default — but its performance is the internet's performance: latency and jitter vary with conditions you do not control, and each tunnel tops out around 1.25 Gbps. VPN is the answer when the stem stresses speed of setup, low cost, or a temporary or backup link — and it is the standard failover for Direct Connect.

AWS Direct Connect is a dedicated physical connection from your network into AWS, at port speeds from 1 Gbps to 100 Gbps (with lower-rate hosted connections through partners). Because traffic never crosses the public internet, you get consistent latency and predictable bandwidth — the properties that matter for large steady data transfer, latency-sensitive hybrid applications, and workloads where internet variability is itself the problem. The costs are lead time (provisioning a physical circuit takes weeks) and price. Note the encryption nuance: Direct Connect is private but not encrypted by default; requirements for encryption in transit are met by running a VPN over the Direct Connect link or using MACsec — a detail the exam uses to separate otherwise-identical options.

The selection rule: consistent performance and big sustained throughput → Direct Connect; fast, cheap, encrypted, or temporary → VPN; maximum resilience → Direct Connect with a VPN standby. Both terminate naturally on a Transit Gateway when many VPCs need the hybrid link, which is how the previous section and this one combine in multi-VPC hybrid questions.

Exam stems telegraph the answer in the requirement clause: "consistent network performance," "predictable throughput for nightly multi-terabyte transfers," and "avoid the public internet" are Direct Connect; "within days," "minimal cost," and "encrypted over the internet" are VPN.

Two placement decisions finish the task statement: where users enter your architecture globally, and where resources sit relative to each other locally.

Globally, when an application runs full stacks in multiple Regions, Amazon Route 53 latency-based routing answers DNS queries with the Region that offers the lowest measured latency for that user — a US user resolves to us-east-1, a Singapore user to ap-southeast-1. It pairs with health checks so an unhealthy Region drops out of answers. Keep its lane distinct from its neighbors: latency-based routing sends users to the fastest Region; geolocation routing sends users from a specific location to a chosen endpoint (compliance and content-licensing scenarios, not performance); and Global Accelerator achieves a similar user-to-nearest-entry outcome at the network layer with static IPs and faster failover, without depending on DNS TTLs. A stem that says "route each user to the Region with the lowest latency" and offers DNS-based options wants latency-based routing; one that adds "static IPs" or "instant failover" has moved to Global Accelerator.

Locally, resource placement is a latency-versus-resilience trade. Traffic between resources in the same Availability Zone is the fastest and — at the concept level the exam tests — avoids the cross-AZ data transfer charges that inter-AZ traffic incurs. Chatty components, such as an application tier hammering a cache or a data-processing pipeline shuffling between nodes, benefit from same-AZ locality. But concentrating a workload in one AZ concedes availability, which is why the standard multi-tier design spreads every tier across at least two AZs and accepts the cross-AZ chatter as the price of surviving zone failure. The exam probes whether you can articulate the trade: a cost-review question may flag heavy cross-AZ transfer between an application and its cache (co-locate, or cache per AZ), while an availability question punishes the single-AZ design that a pure performance argument produced. State the business priority first; the placement follows.

Most Task 3.4 connectivity questions reduce to reading one constraint out of the stem and looking up the row. Internalize this table and the peering-mesh math, and the section becomes fast points.

Two cross-cutting facts to carry into any of these rows: peering is never transitive — no answer that routes A→B→C over peering connections is ever correct — and overlapping CIDRs disqualify both peering and Transit Gateway, leaving PrivateLink (or re-addressing) as the path. The exam tests the table with stems that satisfy two rows at once and a qualifier — LEAST operational overhead favors the hub; lowest cost between exactly two VPCs favors peering — so read the scale words and the qualifier together before choosing.

Scenario 1. A company runs a shared-services VPC (directory, logging, CI/CD) peered to twelve application VPCs. Application teams now need their VPCs to reach each other for service-to-service calls, and traffic from every VPC must also reach on-premises systems over an existing Direct Connect link. Engineers propose adding routes so application VPCs can reach each other "through" the shared-services VPC. What should the architect do?

Reasoning: The proposal fails on the fundamental rule: VPC peering is not transitive. No route table entry can make traffic from VPC A flow through the shared-services VPC to VPC B — the peering connection will not forward it. Making the mesh work with peering alone means adding a connection per VPC pair — twelve application VPCs plus shared services is dozens of connections, each with route-table maintenance — and peering still cannot carry the VPCs' traffic to Direct Connect. The answer is AWS Transit Gateway: attach all thirteen VPCs and associate the Direct Connect gateway, and every attachment reaches every other through the hub, with transit gateway route tables available to restrict any pairs that should not communicate. One hub replaces the mesh and solves the hybrid requirement in the same move.

Scenario 2. A multiplayer game studio hosts session servers behind Network Load Balancers in two Regions. The game client speaks a custom protocol over UDP. Players worldwide report inconsistent latency, and enterprise partners must allowlist fixed IP addresses in their firewalls. CloudFront or Global Accelerator?

Reasoning: Two facts each independently eliminate CloudFront: it serves HTTP/HTTPS only, and this workload is custom UDP; and it offers no fixed IP pair to allowlist. Global Accelerator matches every requirement: it carries TCP and UDP, provides two static anycast IPs that never change (satisfying the firewall allowlists), moves player traffic onto the AWS backbone at the nearest edge for consistent latency, and its health-check-driven routing fails over between the two Regions in seconds. Note the general lesson: "global users + performance" alone does not decide this pair — the protocol and the static-IP requirement do.

Scenario 3. A financial analytics firm runs a tightly coupled HPC simulation on 40 EC2 instances that exchange data constantly. Runs are taking too long, and metrics show node-to-node network latency dominates. What placement change helps most?

Reasoning: "Tightly coupled" plus "node-to-node latency" is the cluster placement group signature: pack the instances close together in one AZ for the lowest latency and highest throughput between them, on ENA-enabled (ideally EFA-equipped) instance types. A spread group is the opposite of what is asked — and cannot hold 40 instances per AZ anyway; a partition group targets failure isolation for distributed data systems, not latency. The accepted trade-off is resilience: the whole job sits in one AZ, acceptable for restartable batch simulations. Launch the full fleet at once with one instance type to reduce insufficient-capacity risk.