Networking & Content Delivery
Virtual networks, connectivity, DNS, load balancing, and edge caching that carry traffic to and between workloads.
Amazon API Gateway
Fully managed front door for APIs — handles auth, throttling, and routing so your backend doesn't have to.
- Clients only ever hit the gateway — it authenticates, throttles, then forwards to Lambda, an HTTP endpoint, or another AWS service
- Three types: REST (full feature set), HTTP (same job, ~70% cheaper, fewer features), WebSocket (server can push to clients)
- Handles auth, throttling, caching, stages (dev/test/prod), and CloudWatch logging for you — API keys, usage plans, caching, WAF and private endpoints are REST-only
- Limits: 10 MB payload, 29s integration timeout (raisable on Regional/private REST APIs), 10,000 RPS per account per Region
Exam triggers
Phrases and scenarios that point here.
- "Front door", "single entry point", "expose Lambda to the internet", "publish an API at scale"
- Meter, throttle, or monetize per customer → API keys + usage plans (REST APIs)
- Serverless web/mobile backend → API Gateway + Lambda + DynamoDB, the classic three-service answer
- Server needs to push to clients without polling → WebSocket API
Not this service
- Plain HTTP/HTTPS load balancing to EC2 or containers, no API features needed → ALB
- GraphQL instead of REST → AppSync
Use cases
- Fronting Lambda with a public REST API so a mobile app never holds AWS credentials or talks to AWS services directly
- Giving each partner their own API key and rate limit, so one partner's runaway script can't starve everyone else
- Wrapping a legacy EC2 or on-prem backend in a modern HTTPS API without touching its code — TLS, auth and throttling bolted on at the edge
- Running v1 and v2 as separate stages and canarying a small slice of traffic onto the new one before cutting over
- WebSocket API for a live dashboard or chat, where the server pushes updates instead of the browser polling every five seconds
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon CloudFront
Global CDN that caches and delivers your content from edge locations close to your users.
- Viewers hit the nearest of CloudFront's hundreds of edge locations — on a cache hit, your origin never sees the request
- Edge locations are not Regions or AZs: far more of them, and they only cache and terminate connections, they don't run your workloads
- Origin can be anything reachable over HTTP — S3, ALB, EC2, API Gateway, or a server that isn't on AWS at all
- Caches static and dynamic content; default TTL is 24 hours, and updates go live via an invalidation or a new versioned filename
- Doubles as the security front door: HTTPS, free Shield Standard DDoS protection, WAF, geo restriction, signed URLs/cookies, and OAC to keep an S3 bucket private
Exam triggers
Phrases and scenarios that point here.
- "Global users", "reduce latency worldwide", "customers far from the Region say it's slow" → CloudFront
- "Reduce load on the origin" or "lower data transfer costs out of S3/EC2" → put CloudFront in front of it
- "Protect a public website from DDoS" or "block bad requests before they reach the server" → CloudFront + Shield/WAF at the edge
- "Only paying subscribers" → signed URLs/cookies; "only these countries" → geo restriction
Not this service
- Non-HTTP traffic (TCP/UDP, gaming, VoIP) or a fixed set of static IPs → AWS Global Accelerator
- Speeding up uploads into S3 → S3 Transfer Acceleration (same edge network, opposite direction)
- Caching database queries or session data inside a Region → ElastiCache
Use cases
- Static site or SPA hosted in S3 — the bucket stays private behind OAC, CloudFront is the only public door, and HTTPS on your own domain comes free
- One ALB in Singapore serving users in Frankfurt and Dallas without standing up a second Region — TLS terminates at the edge and the rest rides the AWS backbone
- Game patches, installers, and firmware downloads, where thousands of people pull the same 2 GB file from the edge cache instead of hammering your origin
- Subscription video, where each viewer gets a signed URL that works for them and expires before it can be shared around
- Security front door for an on-prem or non-AWS origin — WAF and Shield filter traffic at the edge before it reaches a server you can't easily scale
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon Route 53
Managed DNS and domain registration that answers queries, checks endpoint health, and steers users to the right one.
- A hosted zone holds one domain's records — public zones answer the internet, private zones answer only the VPCs you attach them to
- Eight routing policies: simple, weighted, latency, failover, geolocation, geoproximity, multivalue answer, IP-based
- Alias records point at AWS resources, work at the zone apex where CNAME is illegal, and are free to query
- Health checks + failover routing give automatic DNS-level failover — but resolvers cache answers, so TTL, not AWS, decides how fast it flips
- Exam convention: "the only AWS service with a 100% availability SLA." The current SLA is credit-tiered, with credits starting the moment a hosted zone dips below 100% — flag the gap, answer the convention
Exam triggers
Phrases and scenarios that point here.
- "Lowest latency for global users" → latency routing. "Users in Germany must be served from Frankfurt for legal reasons" → geolocation. Performance vs. law is the whole distinction
- "Send 10% of traffic to the new version" / blue-green / canary → weighted routing
- "Automatically fail over to a standby Region if the primary is down" → health checks + failover routing
- "Point the root domain (example.com) at an ELB, CloudFront, or S3 website" → alias record, never CNAME
- "Resolve internal service names inside the VPC only" → private hosted zone
Not this service
- Caching content close to users to speed up delivery → CloudFront
- Spreading requests across targets inside one Region → Elastic Load Balancing
- Static anycast IPs and failover that ignores DNS caching → Global Accelerator
Use cases
- Launching a site end to end — register the domain, alias the apex at a CloudFront distribution, alias www at the same target: no CNAME workarounds and no query charges
- Canary releases where rollback is a record edit, not a redeploy — weighted records push 5% at the new stack and drop it back to 0 the moment error rates move
- Warm-standby DR across Regions: a health check watches the primary ALB and the failover record promotes the standby before anyone gets paged
- Private hosted zones for internal naming, so services call payments.internal.acme instead of a hardcoded IP, and the name resolves nowhere outside the VPC
- Geolocation routing driven by contracts rather than performance — a media catalog that must serve a different origin per country because licensing says so
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon VPC
Your own logically isolated virtual network in AWS, where you control the IP range, subnets, routing, and firewalls.
- Regional: a VPC spans every AZ in one Region, but each subnet lives in exactly one AZ — 5 VPCs per Region by default (soft limit)
- Public subnet = has a route to an internet gateway. Private subnet = no IGW route; outbound-only internet via a NAT gateway sitting in a public subnet
- Security groups are stateful, attach to resources, allow rules only. NACLs are stateless, attach to subnets, and can explicitly deny
- CIDR must be /16 to /28 and can't be shrunk later; AWS reserves 5 IPs in every subnet; every Region ships a default VPC whose subnets are already public
Exam triggers
Phrases and scenarios that point here.
- "Logically isolated", "our own IP range", "private subnet", "not reachable from the internet" → VPC
- Instances need to download patches but must never accept inbound traffic → NAT gateway, not an internet gateway
- Block one specific attacking IP range → NACL (deny rules). Allow the app tier to reach the DB tier → security group
- Reach S3 or DynamoDB without touching the internet → gateway VPC endpoint (free)
Not this service
- Connecting many VPCs and accounts hub-and-spoke → Transit Gateway
- A private, dedicated physical line from your data center → Direct Connect (a VPC alone doesn't reach on-prem)
Use cases
- Classic three-tier web app: load balancer in public subnets, app servers and the database in private subnets, so the database has no route to the internet at all
- Meeting a compliance requirement that customer data never crosses the public internet — everything on private IPs, AWS service calls via VPC endpoints
- Lift-and-shift from a data center, where you pick a CIDR that doesn't collide with the existing corporate range before joining the two with VPN or Direct Connect
- Environment isolation without spinning up extra accounts: separate dev/staging/prod VPCs so a sloppy dev security group can't reach production
- Spreading subnets across multiple AZs so losing one AZ takes out one subnet, not the whole application
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS Client VPN
Managed OpenVPN endpoint that lets individual users reach VPC and on-premises resources from their own devices.
- Endpoint is associated with VPC subnets — each association is an ENI in one AZ; associate a second AZ for HA
- Auth modes: mutual certificate, Active Directory, or SAML — certificate auth can be layered on top of either user-based mode
- Access needs both a route and an authorization rule — a route on its own grants nothing
- Split-tunnel is off by default, so every packet from the client, including personal browsing, comes through your VPC
- Limits: client CIDR /22–/12 and immutable after creation, 10 routes, 50 authorization rules, 5 endpoints per Region
Exam triggers
Phrases and scenarios that point here.
- "Remote employees", "work from home", "individual laptops need access to private subnets"
- Access must differ per user or per group → Client VPN authorization rules, not Site-to-Site VPN
- Existing corporate AD or SAML IdP must gate VPN access → AD Connector or IAM Identity Center integration
- "Managed", "scales with users", "no VPN appliance to patch" paired with remote-user wording
Not this service
- A whole office or data center needs connectivity → Site-to-Site VPN
- Dedicated, consistent private bandwidth → Direct Connect
- Shell or port access to instances with no VPN at all → Systems Manager Session Manager
Use cases
- On-call engineers reaching private RDS, ElastiCache, or OpenSearch endpoints straight from a laptop, retiring the bastion fleet and its SSH keys
- Contractors placed in their own SAML group mapped to a single authorization rule, so they reach the one CIDR they're paid to touch and nothing else
- Full tunnel plus a NAT Gateway so all remote-worker traffic egresses from one Elastic IP — the shape SaaS vendors and partner allowlists ask for
- Laptop → VPC → Transit Gateway → Site-to-Site VPN, giving remote staff on-premises access without shipping anyone a hardware appliance
- Short-lived surge access — office outage, acquisition onboarding, a contractor sprint — where the association is torn down the day the work ends
Commonly confused with
Verified against AWS documentation · 2026-08-24
AWS Direct Connect
Dedicated private fiber link between your datacenter and AWS that bypasses the public internet.
- Private, not encrypted — DX only guarantees the traffic never touches the internet, not that anyone can't read it
- Dedicated: 1/10/100/400 Gbps ordered from AWS. Hosted: 50 Mbps–25 Gbps ordered from a partner
- Traffic rides a VIF — private → VPC, public → AWS public endpoints (S3, DynamoDB), transit → Transit Gateway. A Direct Connect Gateway fans one VIF out to VPCs in any Region
- Weeks to months to provision; 99.9% SLA on one link, 99.99% only with two links at two DX locations
Exam triggers
Phrases and scenarios that point here.
- "Consistent", "predictable latency", "dedicated bandwidth", "must not traverse the public internet" → Direct Connect
- "Needs to be working next week" or "lowest cost" → Site-to-Site VPN; DX can't be provisioned that fast
- Traffic over DX must be encrypted → IPsec VPN over a public VIF, or MACsec on 10/100/400 Gbps dedicated links
- One circuit reaching many VPCs, or VPCs in other Regions → Direct Connect Gateway; reaching a TGW → transit VIF (1 Gbps minimum)
- "Maximum resiliency" / 99.99% → two connections at two separate DX locations, not two ports in one building
Not this service
- Encrypted tunnel over the internet, up in an hour → Site-to-Site VPN
- Connecting VPCs to each other → Transit Gateway or VPC peering
- Private S3 access from inside a VPC → Gateway VPC endpoint
- One-time bulk move of petabytes with no existing circuit → Snow Family
Use cases
- App tier in AWS talking to a database or mainframe that legally or practically can't move — the failure mode is jitter, not throughput
- Steady high-volume egress back to a datacenter (nightly replicas, backup restores) where internet egress rates dominate the AWS bill
- Latency-sensitive traffic — VDI, SIP/voice, trading feeds — where an internet VPN's variable round-trip time is itself the outage
- An auditor or regulator requiring a documented path that never crosses the public internet
- Sustained large-file movement (video dailies, genomics batches, DataSync jobs) that outgrows a VPN tunnel's ~1.25 Gbps ceiling
Commonly confused with
Verified against AWS documentation · 2026-08-24
AWS Global Accelerator
Two static anycast IPs that pull user traffic onto the AWS global network at the nearest edge and route it to the closest healthy Region.
- Gives you 2 static anycast IPs as a fixed front door — users hit the nearest edge location, then traffic rides the AWS backbone instead of the public internet
- Endpoints are ALB, NLB, EC2, or Elastic IP, in one Region or many — it sits in front of load balancers, it doesn't replace them
- Health checks pull an unhealthy endpoint out in under a minute, with no DNS TTL to wait out because the IPs never change
- Works for any TCP or UDP traffic and caches nothing — this is routing, not content delivery
Exam triggers
Phrases and scenarios that point here.
- "Static IP addresses" for a multi-Region app, or IPs a customer must allow-list in their firewall
- Non-HTTP traffic — gaming (UDP), VoIP, IoT — needing lower latency → Global Accelerator, not CloudFront
- "Fast regional failover" or "clients cache DNS too long" → Global Accelerator, not Route 53 failover
- "Improve performance for global users" on dynamic content that can't be cached
Not this service
- Caching static content at the edge — images, video, JS → CloudFront
- DNS-level routing with weighted, latency, or geolocation records → Route 53
Use cases
- Multiplayer game servers, where players in Jakarta and São Paulo connect to the same two IPs, join the AWS backbone at their local edge, and get less jitter than the open internet gives them
- Active/passive DR across two Regions — a client that cached DNS an hour ago still lands in the healthy Region, because the entry IPs never moved
- A B2B API whose enterprise customers allow-list your IPs in their firewalls, so you can change Regions or swap load balancers without raising a change request on their side
- Lifting an on-prem app with hardcoded IPs into AWS — BYOIP lets you bring your own /24 so client configs are never touched
- Region rollouts using the traffic dial: send 10% to the new Region, watch the dashboards, dial up or roll back instantly with no DNS changes
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS PrivateLink
Private, one-way connectivity from your VPC to a service — no internet gateway, NAT, or peering.
- An interface endpoint is an ENI with a private IP in your subnet; DNS points the service hostname at it, so app code doesn't change
- Consumer-initiated only — the provider answers requests but can never open a connection back into your VPC
- Works across accounts and overlapping CIDRs because nothing is routed; there is no peering, no route table entry, no IP coordination
- Gateway endpoints (S3 and DynamoDB only) are a route table entry, are free, and are NOT PrivateLink — this is the #1 exam trap
- Limits: TCP only, one ENI per AZ per endpoint, 50 interface/GWLB endpoints per VPC (adjustable), 10 Gbps per AZ scaling to 100 Gbps
Exam triggers
Phrases and scenarios that point here.
- "Without traversing the public internet", "no internet gateway or NAT gateway" → interface endpoint
- A SaaS vendor must expose its service privately to customer VPCs → endpoint service behind an NLB
- Two VPCs with overlapping CIDRs need to share one service → PrivateLink, because peering is impossible
- Cheapest private access to S3 or DynamoDB from a private subnet → gateway endpoint, not interface
- On-premises over Direct Connect or VPN needs private access to an AWS API → interface endpoint (gateway endpoints don't work from outside the VPC)
Not this service
- Bidirectional, any-port reachability between two VPCs → VPC Peering or Transit Gateway
- Free private access to S3 or DynamoDB from inside the VPC → Gateway endpoint
- General outbound internet access for OS patching or third-party APIs → NAT Gateway
Use cases
- Reaching a vendor SaaS (Snowflake, Datadog, MongoDB Atlas) from private subnets while the VPC has zero egress path to the internet
- Publishing an internal platform service — shared auth, payments, feature flags — to other business units whose VPCs all sit on the same 10.0.0.0/16, where peering is off the table. Watch for the source-IP gotcha: your targets see the NLB's IPs unless you enable Proxy Protocol v2
- Stripping the NAT Gateway out of a compliance-heavy account entirely, then adding interface endpoints only for the APIs the workload actually calls (STS, KMS, Secrets Manager, SSM) and locking each one down with an endpoint policy
- Cutting NAT data processing on chatty container fleets — ECS/EKS tasks pull through ecr.api and ecr.dkr interface endpoints, with layer downloads riding the free S3 gateway endpoint
- Giving an on-premises data centre private access to SQS, Kinesis, or Secrets Manager over Direct Connect instead of routing API calls out to the public endpoints
Commonly confused with
Verified against AWS documentation · 2026-08-24
AWS Site-to-Site VPN
Managed IPsec tunnels connecting an on-premises network to a VPC over the public internet.
- Two halves: a customer gateway (your on-prem device) and a virtual private gateway (one VPC) or transit gateway (many VPCs)
- Every connection ships two tunnels in two AZs — AWS-to-on-prem prefers one; true active/active needs transit gateway + ECMP
- Static routes or BGP — BGP gives automatic failover; static means someone edits a route table during an outage
- Limits: 1.25 Gbps per tunnel standard, 5 Gbps with Large Bandwidth Tunnels (transit gateway or Cloud WAN only), ~140,000 pps per tunnel
Exam triggers
Phrases and scenarios that point here.
- "Encrypted", "IPsec", "over the internet", "data center to VPC"
- "Needed within hours" or "temporary" hybrid link → VPN; Direct Connect has weeks-to-months lead time
- Backup or failover path for Direct Connect → Site-to-Site VPN as the secondary
- Many branch offices reaching many VPCs → VPN onto a transit gateway, not one VGW per VPC
Not this service
- Dedicated circuit, predictable latency, traffic never touching the internet → Direct Connect
- Individual remote employees on laptops → AWS Client VPN
- VPC-to-VPC connectivity inside AWS → VPC peering or Transit Gateway
Use cases
- Standby path for Direct Connect — the VPN sits configured and idle, and BGP moves traffic onto it the moment the circuit drops, with no one paged
- Branch and edge sites too small to justify a cross-connect — retail stores, clinics, factory floors — each terminating on one shared transit gateway
- Migration bridge, where on-prem app servers keep talking to a database replicating into RDS across the tunnel until cutover, then the VPN is deleted
- Vendor or partner access into a private subnet when the vendor's appliance only speaks IPsec and nothing should be exposed publicly
- Pilot-light DR, where a standby VPC carries only replication traffic and the tunnel is cheap enough to leave running year-round
Commonly confused with
Verified against AWS documentation · 2026-08-24
AWS Transit Gateway
Regional hub-and-spoke router that connects VPCs, VPNs, and Direct Connect through one gateway instead of a peering mesh.
- Regional and highly available by design — attach once, route everywhere; VPC peering never routes through a middle VPC
- Each attachment associates with one TGW route table but can propagate into many — this is how prod and dev stay isolated on a single gateway
- Does not fix overlapping CIDRs, and security group references don't cross the gateway between spokes
- Limits: 5,000 attachments, 10,000 routes, 20 route tables per TGW; 50 Gbps burst per VPC attachment
Exam triggers
Phrases and scenarios that point here.
- "Hundreds of VPCs", "simplify the peering mesh", "central hub", "transitive routing"
- One Direct Connect or VPN shared by every VPC → attach it to the TGW, not a VGW per VPC
- Dev and prod must both reach shared services but never each other → multiple TGW route tables, one gateway
- Private connectivity between two Regions → TGW peering attachment (static routes only, no BGP)
Not this service
- Expose one service to many consumers, or the CIDRs overlap → PrivateLink
- Two VPCs, stable topology, heavy traffic → VPC peering (no hourly charge, no per-GB processing)
Use cases
- Killing a peering mesh — at 10 VPCs you're maintaining 45 connections and every new account means 10 more route table edits; one attachment per VPC ends that
- Shared services hub, where DNS resolvers, domain controllers, and patch/artifact repos sit in one VPC every workload reaches while the workload VPCs stay invisible to each other
- Hybrid consolidation — one Direct Connect gateway plus a backup Site-to-Site VPN on the TGW serves the whole estate, instead of a virtual private gateway and tunnel pair per VPC
- Centralized egress and inspection, where spokes default-route to a single firewall/NAT VPC so you run one NAT Gateway pair instead of one per VPC (appliance mode keeps flows symmetric across AZs)
- Multi-Region DR — peer the TGWs in each Region so failover VPCs and on-premises stay reachable over the AWS backbone without standing up new tunnels
Commonly confused with
Verified against AWS documentation · 2026-08-24
Elastic Load Balancing
Managed load balancer that spreads incoming traffic across healthy targets in multiple Availability Zones.
- One DNS name in front of many targets — health checks decide who gets traffic, unhealthy targets are skipped automatically
- ALB = Layer 7 (HTTP/HTTPS), routes on path, host, or header. NLB = Layer 4 (TCP/UDP/TLS), extreme performance, static IP per AZ
- GWLB = Layer 3 gateway that fronts third-party firewall and inspection appliances. CLB = previous generation
- Regional, not global: you enable AZs and ELB puts a node in each. Auto Scaling registers and deregisters instances for you; ACM certs terminate HTTPS at the load balancer
- Reality check: CLB inside a VPC still runs and isn't retired, but AWS labels it previous generation and recommends migrating — treat it as the legacy option, never the right answer for a new build
Exam triggers
Phrases and scenarios that point here.
- "Distribute traffic", "single point of contact", "survive an AZ failure" → ELB across multiple AZs
- Route /api and /images to different backends, or host-based routing for microservices → ALB
- "Static IP for partner allow-listing", "millions of requests per second", "UDP", "lowest latency" → NLB
- All traffic must pass a third-party firewall appliance before reaching workloads → GWLB
Not this service
- Add or remove capacity as demand changes → EC2 Auto Scaling (ELB spreads traffic, it never creates servers)
- Cache and serve content close to users at the edge → CloudFront
Use cases
- Public web app where an internet-facing ALB fronts an Auto Scaling group spanning two AZs — one instance dies and users never notice
- Three-tier setup: internet-facing ALB for the web tier, internal ALB for the app tier, so app servers never need a public IP
- Path-based routing where /api, /admin, and /static hit different target groups behind one domain and one certificate
- Game server or IoT broker on raw TCP/UDP where partners need a fixed IP to allow-list in their own firewall → NLB
- Rolling deploys: new instances register and start taking traffic once health checks pass, old ones drain in-flight connections before shutdown
Commonly confused with
Verified against AWS documentation · 2026-09-09