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, and because the entry IPs never change, a Region can fail without any client re-resolving a name.

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.

Two NLB settings are tested in their own right. The listener protocol decides who holds the keys: a TCP listener passes the encrypted stream through untouched, so the targets terminate TLS and the certificate never leaves them (the answer when compliance says the load balancer must not decrypt); a TLS listener terminates TLS on the NLB itself, offloading the work but decrypting at the load balancer. Client IP preservation depends on the target type: it is on by default for instance targets, off by default for IP targets on TCP and TLS (you can turn it on), and always on for UDP and TCP_UDP. When preservation is not possible, proxy protocol v2 prepends the client address in a header, which only helps if the application parses that header. X-Forwarded-For is the ALB's (HTTP) equivalent; an NLB carrying raw TCP has no HTTP header to add it to. Targets are instances, IP addresses or an ALB; Lambda functions are an ALB-only target type.

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.

When you need the ALB's HTTP routing and fixed addresses, you do not have to choose: see the next section. 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.

An Application Load Balancer has no static IP addresses: its subnet mappings cannot take Elastic IPs and the addresses behind its DNS name change as it scales. (An Amazon VPC IPAM pool can narrow its public addresses to a block you own, but individual addresses still change.) When customers must allowlist fixed IPs and you still need layer-7 routing, put something with static addresses in front of the ALB rather than replacing it.

The difference that separates the first two rows: NLB-in-front-of-ALB gives static IPs per Region (a second Region means a second set of addresses and DNS-based failover), whereas Global Accelerator gives one address set that fronts every Region.

CloudFront VPC origins

A CloudFront VPC origin (available since November 2024) lets a distribution use an internal ALB, an NLB or an EC2 instance in a private subnet as its origin, so the origin has no public exposure and users can reach it only through CloudFront. The details that decide questions:

• The load balancer must be internal. An ALB's scheme (internet-facing or internal) is fixed at creation, so a public ALB is replaced by a new internal one, not converted.
• An NLB with TLS listeners is not supported as a VPC origin.
• The VPC must still have an internet gateway attached, even though origin traffic arrives privately and never uses it; the origin's subnets need no route to it.
• Lock the origin down by allowing inbound traffic only from the service-managed security group CloudFront-VPCOrigins-Service-SG, which represents your own distributions' VPC origins. The CloudFront origin-facing managed prefix list admits every CloudFront distribution, including other people's, so it is the weaker control.
• Origin access control (OAC) protects S3 bucket and Lambda function URL origins; it does not apply to load balancers or EC2.

Before VPC origins, the standard pattern was a public ALB restricted to CloudFront by the prefix list plus a secret custom header; that still works, but it leaves the ALB internet-facing.

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, remember what cannot change: neither a subnet's CIDR nor the VPC's primary CIDR can be resized after creation. The escape valve is to associate a secondary CIDR block with the existing VPC and create new subnets from it; workloads then launch into the new subnets with no re-addressing of what already runs. This is the usual fix when an Amazon EKS cluster, whose pods take IP addresses from the VPC, exhausts its subnets: add a secondary CIDR, create new private subnets from it in each AZ, and place pods there. The secondary range must also stay clear of every network you route to, just like the primary.

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. Peering also has no edge-to-edge routing: a VPC cannot use its peer's internet gateway, NAT gateway, virtual private gateway, VPN or Direct Connect connection. A hub VPC therefore cannot share its hybrid link with peered spokes. Note that a Direct Connect gateway does not fill that gap either: it connects VPCs to on premises, but it does not route traffic from one VPC to another.

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.

Two Transit Gateway mechanics keep a growing estate manageable. Route propagation: VPC attachments propagate their CIDRs into the transit gateway route tables, and VPN and Direct Connect gateway attachments propagate the on-premises routes they learn over BGP, so a new VPC is learned at the hub instead of being typed into every other VPC (each VPC's own route table still needs a route pointing at the transit gateway). Segmentation: associate each environment's attachments with its own transit gateway route table and propagate only what it may reach, such as the shared on-premises routes into both production and development tables, while production and development routes never meet.

The hub has costs that peering does not. Transit Gateway charges per attachment-hour and per GB processed; peering has neither charge (only normal data transfer). Traffic through the hub takes an extra hop, so a direct peering connection keeps the latency edge for one busy pair. And Transit Gateway does not tolerate overlapping CIDRs any better than peering does. Its justification is manageability and transitivity at scale, not price or latency.

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 standard tunnel tops out around 1.25 Gbps (ECMP across several tunnels on a transit gateway adds aggregate bandwidth, but each flow still rides one tunnel). Newer large-bandwidth tunnels of up to 5 Gbps, for transit gateway and Cloud WAN attachments, raise that ceiling but still ride the internet. 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.

Accelerated Site-to-Site VPN (available only for VPNs attached to a transit gateway) uses Global Accelerator so traffic enters AWS at the nearest edge location instead of crossing the internet all the way to the Region. It reduces the internet portion of the path, but the first leg is still the public internet and the per-tunnel limit is unchanged, so it improves VPN performance without giving Direct Connect's consistency. Do not confuse it with AWS Client VPN, which connects individual users' devices, not sites.

Backing up Direct Connect

A single Direct Connect connection is a single point of failure, and the right backup depends on what the backup must deliver:

• Cheapest automatic backup: a Site-to-Site VPN on the same virtual private gateway or transit gateway. Both paths advertise the same prefixes over BGP; AWS prefers the Direct Connect routes, and when Direct Connect fails BGP withdraws them and traffic moves to the VPN with no manual step. The backup runs at internet, VPN-tunnel performance.
• Backup that must match the primary's bandwidth and consistency: a second Direct Connect connection. Placing it at a different Direct Connect location survives the loss of a whole location; a second connection at the same location only covers a circuit or device failure. Two connections at each of two locations is the maximum-resilience design.

The selection rule: consistent performance and big sustained throughput → Direct Connect; fast, cheap, encrypted, or temporary → VPN; low-cost resilience → Direct Connect with a VPN standby; backup that must perform like the primary → a second Direct Connect at another location. 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 (put replicas in each zone and read from the local one), while an availability question punishes the single-AZ design that a pure performance argument produced. State the business priority first; the placement follows.

Zone-local reads need the right endpoint as well as the right node placement. In an Amazon ElastiCache (Valkey or Redis OSS) replication group, the reader endpoint is a DNS record that spreads connections across all replicas with no Availability Zone preference, so instances in one zone still read from replicas in the other. Reads stay inside a zone only when that zone holds a replica and the application targets that replica's own node endpoint rather than the shared reader endpoint. Writes still go to the primary, which lives in one zone, so cross-AZ traffic falls but does not disappear for a write-heavy workload.

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.