Edge Architecture — CloudFront and Global Accelerator

Edge architecture on ANS-C01 is the highest-stakes design lever in Domain 1: choose CloudFront when the workload is HTTP/S and benefits from caching, choose Global Accelerator when the workload is non-HTTP (TCP/UDP), latency-sensitive, or requires static anycast IPs that cannot ever change. A representative ANS-C01 question describes a multi-region SaaS API serving HTTPS traffic from ALBs in three regions plus a real-time multiplayer game server farm using UDP plus a static-asset-heavy single-page application plus a corporate customer who whitelists exactly two static IPs in their firewall. The candidate must compose CloudFront for the SPA, Global Accelerator for the game servers, and a careful Global-Accelerator-fronts-ALB pattern for the API to give the corporate customer the static IPs. That is a multi-edge-service composition decision that the exam expects you to make in 90 seconds.

This topic is Domain 1 (Network Design, 30 percent of the exam) Task Statement 1.1 in its entirety. The official ANS-C01 exam guide lists the knowledge bullets verbatim: "Design patterns for the usage of content distribution networks (for example, Amazon CloudFront)", "Design patterns for global traffic management (for example, AWS Global Accelerator)", and "Integration patterns for content distribution networks and global traffic management with other services (for example, Elastic Load Balancing [ELB], Amazon API Gateway)". Roughly 5 to 8 of the 65 exam questions touch this territory, and they almost always involve a service-selection trap and an integration nuance.

Why Edge Architecture Matters on ANS-C01 Domain 1

Latency to end users is the dominant factor in perceived application performance. Networks between user and AWS region are unpredictable: BGP path changes, congested transit providers, and routing detours add tens to hundreds of milliseconds. CloudFront and Global Accelerator both solve this problem from opposite directions. CloudFront caches content at 600+ Points of Presence (PoPs) so requests do not travel back to origin; Global Accelerator anycasts a static IP from those same edge locations and tunnels packets across the AWS backbone instead of the public internet.

The Specialty exam tests the discrimination between these two services because the field consequences of choosing wrong are large. Pick CloudFront for a UDP gaming workload and the application breaks. Pick Global Accelerator for a static asset CDN and you pay for non-cached traffic that should be cached. The mental model the exam rewards is CloudFront equals caching plus L7 features at edge; Global Accelerator equals fast L4 path plus static anycast IP.

Analogy 1 — Pizza Chain Outlets vs Express Delivery Highway

CloudFront is a global pizza chain with 600+ neighbourhood outlets — when a customer orders, the nearest outlet pulls a pre-made pizza off the shelf and delivers in 5 minutes. The original recipe (origin) lives at the central kitchen but most orders never reach it. Global Accelerator is a private express highway between every neighbourhood and the central kitchen — every order still has to be cooked at the central kitchen, but the truck never gets stuck in traffic. Static assets that don't change (images, JS bundles) belong on the pizza chain. Live cooking that must happen at the central kitchen (real-time gaming, payment APIs, voice chat) belongs on the express highway.

Analogy 2 — Public Library Branches vs Diplomatic Pouch

CloudFront acts like a network of branch libraries — every branch keeps copies of the most popular books, so a reader walks to the nearest branch and picks up the book instantly. The central library (origin) is rarely consulted because the branches keep their copies fresh. Global Accelerator acts like a diplomatic pouch — the document doesn't get cached anywhere, but it gets airlifted on a private jet that bypasses commercial flight delays. Files that benefit from copies-everywhere are CloudFront work. Documents that must reach a specific destination as fast as possible (real-time financial trades, IoT control commands) are diplomatic-pouch work.

Analogy 3 — Vending Machine Network vs Black Car Service

CloudFront is a chain of vending machines pre-stocked with the popular products: customers self-serve from the nearest machine, the warehouse only refills when stock runs low. CloudFront's cache invalidation is "send a refill notice to every machine telling it to discard old stock." Global Accelerator is a black car service: customers still need to be driven to the central restaurant, but the car uses VIP lanes that avoid every traffic jam. The car never carries food back to the customer's home — every request must travel to the kitchen. Pick the right service: CloudFront when most customers want what's already on the shelf; Global Accelerator when every customer must reach a specific destination quickly.

CloudFront Architecture — PoPs, Regional Edge Caches, and Origins

CloudFront is a globally distributed CDN with two cache tiers and a flexible origin model.

Points of Presence (PoPs)

A PoP is an edge location housing CloudFront cache servers, typically within 50 ms of major population centers. AWS operates 600+ PoPs across 100+ cities. When a user makes a request, DNS resolution returns a PoP IP near them; the PoP serves the cached response or fetches from the next tier.

Regional Edge Caches

Between PoPs and origins sits a smaller tier of larger caches called Regional Edge Caches (RECs), one per AWS region. PoPs that miss in their local cache check the REC; the REC has a much larger storage and longer TTL, absorbing the long tail of objects. This two-tier design protects origins from cache-miss storms.

Origins

An origin is the source of truth for content. CloudFront supports four origin types: S3 bucket (most common for static assets), S3 website endpoint (with website redirects and index documents), Application Load Balancer or any HTTP/S endpoint (custom origin, including EC2 with a public IP, on-premises servers, or third-party services), and MediaStore / MediaPackage for video workflows.

Distribution

A distribution is the CloudFront top-level resource. It has a unique domain name (d1234.cloudfront.net), one or more origins, one or more cache behaviors, a price class (which PoPs to use), TLS configuration, and WAF/Shield association.

Cache Behaviors — Path Pattern Ordering and Cache Keys

A distribution can have multiple cache behaviors, each tied to a path pattern (/api/*, /images/*, /static/*, etc.). The default cache behavior matches * (everything) and acts as a catch-all.

Path pattern ordering

CloudFront evaluates cache behaviors in the order they are listed, top to bottom. The first matching pattern wins. The default is always last. This ordering is one of the most-tested ANS-C01 traps — listing a more general pattern (/api/*) before a more specific pattern (/api/v2/*) means the specific one is unreachable.

Cache policy

A cache policy controls the cache key: which request attributes (query strings, headers, cookies) make a request distinct from another. A cache key including all query strings means ?utm_source=email and ?utm_source=twitter are cached separately, ballooning cache size. A cache key excluding query strings means both URLs share a cache entry, dramatically improving cache hit ratio for the same content.

The cache policy also sets minimum, maximum, and default TTLs. Origin can override default TTL via Cache-Control: max-age headers; the cache policy's max TTL bounds origin overrides.

Origin request policy

Separate from the cache policy, the origin request policy controls which request attributes are forwarded to the origin (even if not part of the cache key). For example: cache key excludes the Authorization header (so all users hit the same cache entry), but origin request policy forwards Authorization to the origin (so the origin can authenticate). This separation of concerns dramatically improves cache hit ratios for authenticated APIs.

Response headers policy

Newer feature: a response headers policy lets you add, modify, or remove response headers (CORS, security headers, custom headers) at the edge without origin code changes.

Origin Access — OAC vs OAI vs Public Origins

When the origin is S3, you typically want to lock the bucket so it can only be read via CloudFront, not directly. AWS provides two mechanisms.

Origin Access Identity (OAI) — legacy

OAI is the original CloudFront-to-S3 access mechanism. CloudFront has an "OAI principal" — a special canonical user. The S3 bucket policy grants s3:GetObject to the OAI canonical user. When CloudFront fetches from S3, it presents OAI credentials.

OAI works only with S3 buckets in the same partition (commercial) and with SigV2 signing — limitations that excluded GovCloud, China regions, and KMS-encrypted buckets in certain configurations.

Origin Access Control (OAC) — current recommended

OAC is the modern replacement. CloudFront signs origin requests with SigV4 using a service principal. The S3 bucket policy grants access via a service principal condition matching the CloudFront distribution ARN.

OAC supports all S3 features: SSE-KMS, GovCloud, China regions, S3 Object Lambda, and dynamic content origins. AWS recommends OAC for all new distributions; OAI is now legacy.

Custom origins (ALB, HTTP endpoints)

For non-S3 origins, CloudFront does not have OAC/OAI. Instead, you typically lock the origin via a shared secret in a custom header — CloudFront sends X-Origin-Verify: <secret> and the ALB's WAF (or origin application) rejects requests without it. AWS Secrets Manager can rotate this header automatically.

TLS at CloudFront — ACM, SNI, and the us-east-1 Constraint

CloudFront terminates TLS at the edge and re-encrypts to origin. ACM (AWS Certificate Manager) provides the public certificate.

The us-east-1 ACM requirement

Certificates used by CloudFront must be created in us-east-1 (N. Virginia), regardless of the origin's region. This is because CloudFront is a global service and uses the global certificate store anchored to us-east-1. A certificate in eu-west-1 cannot be attached to a CloudFront distribution.

TLS protocol and cipher policy

CloudFront supports TLS 1.0, 1.1, 1.2, and 1.3. AWS provides predefined security policies (e.g. TLSv1.2_2021, TLSv1_2019). Choosing a stricter policy (TLS 1.2 minimum) blocks older clients but improves security. ANS-C01 expects you to recognize compliance scenarios (PCI-DSS) that demand TLS 1.2+.

SNI vs Dedicated IP

SNI (Server Name Indication) is the modern default — CloudFront serves the cert based on the SNI hostname in the TLS Client Hello. Dedicated IP is a legacy option for clients that did not support SNI; it costs $600/month per distribution and is rarely needed today (only for clients on Windows XP / Android 2.x).

Origin TLS

CloudFront-to-origin TLS uses a separate cert chain (the origin's cert, validated by CloudFront). For ALB origins, ACM cert in the ALB's region is the standard. CloudFront supports custom CA certs via origin custom headers and validation toggles for self-signed origins (use cautiously).

Lambda@Edge vs CloudFront Functions — The Two Edge Compute Tiers

CloudFront supports two distinct edge-compute models. Knowing when to use each is one of the most-tested ANS-C01 distinctions.

Lambda@Edge

Lambda@Edge runs Lambda functions at CloudFront PoPs (technically: at Regional Edge Caches and PoPs, depending on trigger). Supports Node.js and Python runtimes; full Lambda capabilities (network calls, AWS SDK access, large libraries, up to 5 seconds for viewer triggers and 30 seconds for origin triggers). Memory up to 10 GB. Runtime cost is typical Lambda pricing plus a small edge premium.

Four trigger points:

• Viewer Request — runs when a user request arrives at the PoP, before cache lookup. Used for URL rewriting, A/B testing, auth header injection.
• Origin Request — runs when the cache misses and CloudFront is about to call origin. Used for origin selection, dynamic origin failover.
• Origin Response — runs when origin returns a response, before caching. Used for response transformation, header manipulation.
• Viewer Response — runs before sending response to user. Used for adding security headers, CORS, custom analytics.

Deployment is global — the function is replicated to every PoP automatically. Updates take 5–10 minutes to propagate.

CloudFront Functions

CloudFront Functions is a lighter-weight alternative for ultra-simple edge transformations. Supports JavaScript only (a subset of ES2020). Runtime is restricted: max 1 ms execution time, 2 MB memory, no network calls, no AWS SDK. Cost is roughly 1/6th of Lambda@Edge.

Two trigger points: Viewer Request and Viewer Response (no origin-side triggers).

Used for: URL rewriting, header manipulation, simple A/B testing routing, JWT verification (with embedded keys), URL signing checks, redirects, CORS injection.

When to use which

Use CloudFront Functions for sub-millisecond JavaScript transformations at viewer side. Use Lambda@Edge for anything requiring network calls (calling DynamoDB, API Gateway), origin-side logic, complex compute, or runtime languages other than JS.

Origin Failover — Origin Groups and Failover Criteria

CloudFront origin failover provides high availability when the primary origin fails.

Origin group

An origin group bundles a primary and a secondary origin. CloudFront sends traffic to primary; if the primary returns a configured failure status code, CloudFront retries against the secondary.

Failover criteria

Configurable HTTP status codes trigger failover: typically 4xx and 5xx (specifically 500, 502, 503, 504, 404, 403, 408, 416). When primary returns one of these, CloudFront automatically retries against secondary on the same request, transparent to the client.

Connection failures

Origin failover also triggers on connection-level failures (TCP timeout, DNS failure, TLS handshake failure). The retry logic gives effective sub-second cross-region failover for healthy paths.

Cache behavior of failed origin

CloudFront does not cache failure responses for long. Once primary recovers, subsequent requests go back to primary on the next cache miss.

Limitations

• Origin failover supports HTTP GET, HEAD, OPTIONS only (write methods are not retried, to avoid duplicate processing).
• Failover counts as one CloudFront request (no duplicate billing).
• Origin failover does not work with Lambda@Edge if the function modifies the request — order of evaluation matters.

Signed URLs and Signed Cookies — Private Content Distribution

CloudFront can serve private content using signed URLs or signed cookies; the signature controls who can access what and when.

Signed URLs

A signed URL embeds the signature in the URL itself: https://d123.cloudfront.net/movie.mp4?Expires=...&Signature=...&Key-Pair-Id=.... Used when each piece of content has a unique URL (one signed URL per object).

Use cases: streaming a single video, generating a one-time download link, RESTful API endpoints with per-object access control.

Signed cookies

A signed cookie is set on the client's browser; subsequent requests to the distribution include the cookie automatically. The cookie's signature authorizes access to multiple paths or wildcards: CloudFront-Policy=...; CloudFront-Signature=...; CloudFront-Key-Pair-Id=....

Use cases: granting access to a directory of HLS video segments, authenticating a user to many static assets at once, single-page applications with multiple lazy-loaded resources.

Trusted key groups vs trusted signers (legacy)

Modern: trusted key groups with public keys uploaded to CloudFront. Your application signs URLs/cookies with the corresponding private key.

Legacy: trusted signers using AWS account root credentials. Avoid — security anti-pattern.

Policy types

• Canned policy: a fixed expiration time and resource path. Smaller signature, simpler.
• Custom policy: supports IP address restriction, multiple paths, date ranges (start and end). Larger signature, more flexible.

Field-Level Encryption — End-to-End Confidentiality for Sensitive Fields

Field-Level Encryption (FLE) is a CloudFront feature that encrypts specific fields of an HTTP request at the edge, decrypted only by the origin's authorized key holder.

How it works

You define an encryption configuration: a public key (RSA), a list of fields to encrypt (by HTML form field names), and a content type (typically POST form data or JSON). When a user POSTs data through CloudFront, CloudFront identifies the named fields and encrypts them with the public key before forwarding to origin.

The origin server has the corresponding private key. Other systems in the request path (load balancers, application servers handling routing, log aggregators) see the encrypted ciphertext, not the plaintext.

Use cases

• PCI compliance: encrypt credit card numbers from edge to backend, so intermediate services and logs never see the PAN.
• HIPAA: encrypt PII fields (SSN, health record IDs) end-to-end.
• Defense in depth: even if logs leak, the sensitive fields are ciphertext.

Limitations

• Field names must be predictable (form field name or JSON key path).
• Maximum 10 encrypted fields per request.
• Adds processing latency (1–10 ms typical).
• Requires HTTPS for the request (FLE works on top of TLS).

CloudFront Geo-Restriction and WAF Integration

Geo-restriction (geo-blocking)

CloudFront has built-in country-based geo-restriction: allowlist (only certain countries) or denylist (block specific countries). Based on MaxMind GeoIP database lookup of viewer IP. Free, simple, applied before WAF evaluation.

Limitations of native geo-restriction

• Country-level only (not state, region, or city).
• IP-based, so VPN users bypass.
• No exception handling (cannot allow specific IPs in a blocked country).

For more granular control (state-level, ASN-based, exception lists), use WAF geo match rules instead, which are more flexible but cost per evaluation.

CloudFront + WAF

CloudFront integrates with AWS WAF via Web ACL association. The WAF Web ACL must be in scope CLOUDFRONT (global, hosted in us-east-1) — regional Web ACLs cannot attach to CloudFront. Rate limiting, IP reputation, bot control, and managed rule groups all work at the edge before requests reach origin.

Shield Standard and Advanced

CloudFront automatically benefits from Shield Standard (free, automatic DDoS protection at L3/L4). Shield Advanced ($3000/month) adds proactive DDoS engagement, cost-protection insurance, and SRT (Shield Response Team) access.

Global Accelerator Architecture — Anycast and the AWS Backbone

Global Accelerator is fundamentally different from CloudFront: it provides static anycast IPs and routes packets across the AWS backbone for non-cached, low-latency connections.

Static anycast IPs

Global Accelerator assigns two static anycast IPv4 addresses (or you can BYOIP) at provisioning time. These IPs are advertised from every AWS edge location globally via BGP anycast. A client's ISP routes packets to the topologically nearest edge.

Edge entry to backbone

Once a packet arrives at an AWS edge, Global Accelerator tunnels it across the AWS backbone network (fiber AWS owns) to the destination region, bypassing the public internet's congestion and routing inefficiency. This typically reduces latency by 30 to 60 percent for transcontinental traffic.

Endpoint groups

A Global Accelerator listener has one or more endpoint groups, one per AWS region. Each group lists endpoints (ALBs, NLBs, EC2 instances, Elastic IPs). Health checks per endpoint determine routing eligibility.

Traffic dial

Each endpoint group has a traffic dial (0–100 percent) controlling how much traffic flows to that region. Useful for capacity rebalancing, gradual region rollout, or disaster scenarios — you can dial down a region to 0 to drain it without changing DNS.

Endpoint weights

Within an endpoint group, each endpoint has a weight (0–255) controlling intra-region traffic distribution. Used for blue-green within a region or progressive endpoint rollout.

Client affinity

By default, Global Accelerator load-balances per packet (5-tuple hash). You can enable client affinity = SOURCE_IP to route all packets from the same source IP to the same endpoint, useful for session-stateful workloads.

Global Accelerator Endpoints — ALB, NLB, EC2, Elastic IP

Global Accelerator supports four endpoint types, each with different behaviors.

Application Load Balancer (ALB)

ALB endpoint can be internal or internet-facing. When ALB is the endpoint, Global Accelerator forwards to the ALB's IPs via the backbone. ALB performs L7 routing as usual.

Use case: HTTP/S APIs that need static anycast IPs (corporate firewall whitelists), or that cannot use CloudFront because the responses are not cacheable but benefit from edge entry to backbone.

Network Load Balancer (NLB)

NLB endpoint preserves source IP through Global Accelerator (with client IP preservation enabled at NLB target group level). Used for L4 workloads requiring real client IP visibility — IDS/IPS, geo-fencing, audit logging.

EC2 instance

Direct EC2 endpoint without a load balancer. Used for simple high-throughput single-server scenarios. Health check is the EC2 instance's reachability.

Elastic IP

EIP endpoint allows pointing Global Accelerator at any IP (including non-AWS systems via Direct Connect or VPN). Used for hybrid scenarios where the origin is on-premises.

Cross-region failover

Global Accelerator automatically routes around unhealthy endpoint groups. Health-check failures in one region cause traffic to shift to other regions within seconds — much faster than DNS-based Route 53 failover (which is bound by TTL).

CloudFront vs Global Accelerator — The Decision Matrix

The most-tested ANS-C01 question style: "given workload X, choose CloudFront or Global Accelerator". Use this matrix.

When to use both together

For HTTP/S workloads requiring both static IPs and edge caching, you can put Global Accelerator in front of CloudFront — but this is rare. More common: Global Accelerator for the API tier (static IPs for corporate firewall whitelists) and CloudFront for the static asset tier (caching), with both fronting different DNS names.

Integration Patterns — CloudFront with ALB, API Gateway, and S3

CloudFront in front of ALB

Most common pattern for dynamic web apps. ALB performs L7 routing to backend; CloudFront caches static portions and forwards dynamic requests. Use a shared secret custom header to lock down ALB to only accept CloudFront-originated requests; AWS Secrets Manager rotates the secret.

CloudFront in front of API Gateway

For HTTP APIs that benefit from edge caching (read-heavy GET endpoints) or edge auth (Lambda@Edge JWT verification). API Gateway already uses CloudFront under the hood for the public endpoint, but adding your own distribution lets you control caching, geo-restriction, and WAF.

CloudFront in front of S3

For static websites, downloads, video distribution. Use OAC to lock the bucket. Combine with signed URLs/cookies for private content.

CloudFront with Lambda function URLs

Newer pattern: serverless apps using Lambda Function URLs as the origin. CloudFront in front gives caching, custom domain, WAF, and edge compute.

Global Accelerator with ALB

Pattern for HTTPS APIs where the corporate customer requires whitelistable IPs. Global Accelerator provides 2 static anycast IPs; the customer's firewall whitelists those; traffic enters AWS backbone at the nearest edge and reaches the regional ALB with sub-100ms latency.

Global Accelerator with NLB for gaming

UDP gaming workload at port 7777. Global Accelerator with UDP listener, NLB endpoint group per region, NLB targets are EC2 game servers. Players connect to the static anycast IP; their packets enter at the nearest edge, traverse the AWS backbone to the regional NLB, and reach the game server with minimal jitter.

Performance and Cost Optimization Patterns

Cache hit ratio optimization

The single biggest CloudFront cost lever is the cache hit ratio. Higher hit ratio means fewer origin requests and less origin data transfer (which is much more expensive than CloudFront-to-user data transfer in many scenarios).

Techniques:

• Strip unnecessary query strings from cache key (e.g. utm_source does not change content).
• Strip unnecessary headers from cache key (e.g. User-Agent rarely changes content but explodes cache key cardinality).
• Use long origin TTLs and CloudFront max TTLs for static assets.
• Configure 5xx response caching for short periods to absorb origin storms during outages.

Price classes

CloudFront has price classes: All Edge Locations (full performance, highest cost), US, Canada, Europe (lower cost, lower latency in Asia/Africa), US, Canada, Europe, Asia (mid-tier). Use a smaller price class for cost-sensitive workloads where users are concentrated in specific regions.

Origin Shield

Optional layer between Regional Edge Cache and origin: a single regional shield cache that absorbs all REC misses globally. Reduces origin load by another factor of 5–10× for popular content. Costs an extra fraction of a cent per request but protects origin during traffic spikes.

Common Traps Recap — CloudFront and Global Accelerator on ANS-C01

Trap 1: ACM cert in any region works for CloudFront

Wrong. CloudFront requires the cert in us-east-1 specifically.

Trap 2: CloudFront supports UDP

Wrong. CloudFront is HTTP/HTTPS only. UDP requires Global Accelerator (or NLB directly).

Trap 3: Cache behaviors evaluated by best match

Wrong. Cache behaviors evaluated in listed order, first match wins. Specific patterns must precede general ones.

Trap 4: OAI works with KMS-encrypted S3

Mostly wrong. OAI uses SigV2 and has compatibility issues with KMS-encrypted S3 in some configurations. Use OAC.

Trap 5: Lambda@Edge is always the right edge-compute choice

Wrong. CloudFront Functions is faster and cheaper for simple JS transforms. Use Lambda@Edge only when you need network calls or non-JS runtime.

Trap 6: Origin failover handles POST requests

Wrong. Origin failover only retries safe methods: GET, HEAD, OPTIONS. POST/PUT do not failover.

Trap 7: Signed URLs and signed cookies are interchangeable

Wrong. URLs are per-object; cookies cover multi-object sessions. Pick by access pattern.

Trap 8: Field-Level Encryption replaces TLS

Wrong. FLE works on top of TLS, adding field-level confidentiality from intermediate AWS services (ALB, logs).

Trap 9: Global Accelerator caches content

Wrong. Global Accelerator does not cache. Pure L4 path acceleration.

Trap 10: Global Accelerator IPs change

Wrong. IPs are static for the lifetime of the accelerator. They are the entire point of the service for firewall-whitelist scenarios.

Trap 11: WAF Web ACL for CloudFront and ALB are interchangeable

Wrong. CloudFront requires scope CLOUDFRONT; ALB requires scope REGIONAL. They are separate Web ACLs even with identical rules.

Trap 12: CloudFront geo-restriction handles US states

Wrong. Native geo-restriction is country-level. State or city granularity requires WAF geo-match rules.

Trap 13: CloudFront automatically protects against L7 DDoS

Partial. Shield Standard provides automatic L3/L4 DDoS mitigation at edge. L7 (HTTP flood) requires WAF rate-based rules and ideally Shield Advanced.

Trap 14: Global Accelerator client affinity routes by user identity

Wrong. Client affinity is SOURCE_IP-based — routes by client IP, not user identity. Mobile users behind CGNAT may share a source IP and route together.

FAQ — Edge Architecture on ANS-C01

Q1: When should I use CloudFront vs Global Accelerator vs Route 53 latency-based routing?

CloudFront for HTTP/HTTPS with cacheable content — static assets, read-heavy APIs, video. Global Accelerator for non-HTTP (UDP, TCP) protocols, or for HTTP/S workloads needing static anycast IPs (corporate firewall whitelists), or for non-cacheable HTTP/S that still benefits from AWS backbone entry. Route 53 latency-based routing for simple multi-region traffic distribution where you want users to resolve to a regional endpoint and then connect directly without an edge service in between. Latency-based routing is cheaper than Global Accelerator but lacks the AWS backbone path advantage. Combined patterns are common: Route 53 for region selection + Global Accelerator for backbone-enhanced TCP, or Route 53 + CloudFront for HTTP with regional caching. ANS-C01 expects you to compose, not pick one.

Q2: How do I lock down an ALB to only accept CloudFront-originated requests?

Two-layer approach. First, use a CloudFront custom origin custom header (e.g. X-Origin-Verify) with a secret value, set on every CloudFront-to-origin request. Second, attach a WAF rule to the ALB requiring this header to match a specific value; reject requests missing it. AWS Secrets Manager rotates the secret on a schedule, and CloudFront automatically picks up the rotated value when you update the distribution. This pattern is standard for production deployments. Without this, the ALB is publicly reachable and bypasses CloudFront's WAF, defeating the purpose.

Q3: Why does CloudFront require ACM certificates in us-east-1?

CloudFront is a global service whose configuration is anchored in us-east-1. The certificate authority chain validation, the global edge configuration, and the distribution settings all sync from us-east-1 to all PoPs. ACM certificates are regional resources, so the global service requires its certs in the region that hosts global services, which AWS chose as us-east-1 for historical reasons. The exam loves this trap — "I created the certificate in eu-west-1 because the origin is there, but CloudFront refuses it". Answer: re-create the certificate in us-east-1; the origin region is irrelevant.

Q4: Can CloudFront Functions make calls to DynamoDB or another AWS service?

No. CloudFront Functions runs in a restricted runtime — no network calls, no AWS SDK, no fetch. It is designed for pure JavaScript transformations on the request and response. If you need to look up data (e.g. dynamic origin selection based on a user ID), use Lambda@Edge with the origin request trigger, which has full Lambda capabilities. Lambda@Edge can call DynamoDB, but be aware: you should call DynamoDB Global Tables in the nearest region from the PoP, otherwise added latency defeats the purpose of edge compute.

Q5: How does Global Accelerator pricing compare to CloudFront?

Global Accelerator costs $0.025 per accelerator-hour ($18/month) plus data transfer. The data transfer fee is a "Data Transfer-Premium" surcharge added on top of normal AWS data transfer ($0.015 to $0.105 per GB depending on source/destination region). CloudFront prices request count and data transfer out, with the data transfer being lower than direct origin transfer due to CloudFront's lower-cost edge-to-internet egress pricing. For HTTP/S cacheable workloads, CloudFront is dramatically cheaper because cache hits avoid origin transfer entirely. For non-HTTP workloads or non-cacheable workloads where you also need static IPs, Global Accelerator is the only option and the cost is justifiable. Always compute the per-request economics for your specific workload.

Q6: How do I implement origin failover for write-heavy APIs?

CloudFront origin failover only handles GET/HEAD/OPTIONS. For POST/PUT/DELETE, use Route 53 health-check failover with active-passive or active-active records, with low TTL (60s) for fast failover. Alternatively, use Global Accelerator which fails over endpoint groups in seconds based on health checks (no DNS TTL constraint). For mission-critical write APIs, Global Accelerator with multi-region NLB endpoints is the canonical pattern: sub-second failover, source IP preservation, no DNS caching to wait through.

Q7: What is the right way to serve a private SPA (single-page app) from S3?

Architecture: S3 bucket with private access only, CloudFront with OAC pointing at the bucket, CloudFront uses signed cookies for the SPA's resources. The user's first request hits a sign-in page (e.g. Cognito-fronted Lambda) that returns a signed cookie covering /app/*. Subsequent requests for HTML, JS, CSS, lazy-loaded chunks all carry the cookie and are authorized. Use signed cookies (not signed URLs) because the SPA loads dozens of resources — pre-signing each URL would be expensive and slow. The cookie can have an IP restriction (custom policy) for additional defense.

Q8: How does Global Accelerator handle TLS — can it terminate TLS?

No, Global Accelerator does not terminate TLS. It is a pure L4 service that forwards packets transparently. TLS handshake happens between the client and the backend endpoint (ALB, NLB, EC2). For HTTPS, the cert is on the backend ALB or NLB (or a TLS listener on NLB). This is a key difference from CloudFront, which always terminates TLS at edge. If you need TLS termination at edge for HTTPS, use CloudFront — Global Accelerator is for cases where you want raw TCP/UDP passthrough or where the application terminates TLS at backend (e.g., for end-to-end TLS to a backend that needs the original cert chain).

Q9: How do I handle CORS at the edge with CloudFront?

Two approaches. Modern: use a response headers policy with CORS configuration — CloudFront adds CORS headers to responses without origin code changes. Older: use Lambda@Edge viewer response trigger to inject Access-Control-Allow-Origin headers based on request origin. Or even simpler for static workloads: configure CORS on the S3 bucket directly and let CloudFront pass through. The response headers policy approach is the recommended modern pattern — declarative, no compute cost, no cold start.

Q10: When does it make sense to put CloudFront in front of an API Gateway?

Three scenarios. First, cache-heavy GET endpoints: even though API Gateway has its own cache, CloudFront's cache is at the PoP layer, much closer to users (lower latency, higher hit ratio). Second, edge auth at the viewer-request stage: Lambda@Edge can verify JWT before requests even reach API Gateway, reducing API Gateway invocation cost and improving latency. Third, WAF and geo-restriction at edge: while API Gateway supports WAF, putting WAF at CloudFront catches malicious traffic earlier in the pipeline. The trade-off: an extra network hop and an extra service to manage. For low-volume APIs, this complexity is unnecessary. For high-volume customer-facing APIs with cacheable subsets, the layered approach pays for itself. ANS-C01 expects you to identify which scenarios benefit and which do not.

Further Reading and Related Operational Patterns

• Amazon CloudFront Developer Guide
• AWS Global Accelerator Developer Guide
• Restricting access to S3 origins (OAC)
• Lambda@Edge developer guide
• CloudFront Functions developer guide
• CloudFront origin failover
• Signed URLs and signed cookies
• Field-Level Encryption
• Global Accelerator traffic dial

Once edge architecture with CloudFront and Global Accelerator is in place, the natural next operational layers on ANS-C01 are: Route 53 DNS — Public, Private, and Hybrid Architectures because edge services depend on DNS for client-side resolution and traffic steering policies; Elastic Load Balancing Design — ALB, NLB, GWLB because the edge services typically front load balancers and the ALB-vs-NLB choice interacts with TLS-termination decisions at edge; WAF, Shield, and DDoS Protection Architecture because edge services are the first line of defense and Shield/WAF integration is most natural at edge; and Network Monitoring and Logging Design for the observability layer covering CloudFront access logs, Global Accelerator flow logs, and edge metrics.

• Route 53 DNS — Public, Private, and Hybrid Architectures — ANS-C01 Study Notes
• Elastic Load Balancing Design — ALB, NLB, GWLB — ANS-C01 Study Notes
• WAF, Shield, and DDoS Protection Architecture — ANS-C01 Study Notes
• Network Monitoring and Logging Design — ANS-C01 Study Notes