AWS SAA-C03: Content Delivery, Edge & Performance Optimization — Study Guide

By Laurynas Brazys · 15 July 2026 · #amazon #aws #saa-c03 #edge-cdn #certification #exam-prep #study-guide

Part of the AWS SAA-C03 Complete Study Guide. Practice these concepts with verified answers in the AWS/Amazon exam hub, or take timed practice tests on ExamRoll.io.

Amazon CloudFront: What It Is and Why It Helps

Amazon CloudFront is a globally distributed content delivery network built on 600+ points of presence. Its job is to terminate viewer TLS at the nearest edge and either serve cached responses immediately or proxy cache misses over AWS’s private backbone to the origin. The performance benefit is twofold: cache hits reduce round-trip time to single-digit milliseconds and offload the origin entirely, while cache misses still gain from optimized TLS/TCP termination at the edge, HTTP/2 and HTTP/3 support, keep-alive connection reuse to the origin, and backbone transit that avoids the noisy public internet.

A common misconception is that CloudFront only accelerates static assets. Placing an ALB behind CloudFront with a CachingDisabled policy still improves dynamic API performance because the viewer’s handshake completes at the local PoP rather than traversing the internet to the origin Region. Combine that with a mixed workload — say /static/* served from S3 and /api/* served from an ALB — and one distribution can handle both:

Distribution:
  Aliases: [www.example.com]
  ViewerCertificate: ACM cert in us-east-1
  Origins:
    - Id: s3-static
      DomainName: static-assets.s3.us-east-1.amazonaws.com
      S3OriginConfig:
        OriginAccessControlId: !Ref OAC
    - Id: alb-dynamic
      DomainName: alb-1234.us-east-1.elb.amazonaws.com
      CustomOriginConfig: { OriginProtocolPolicy: https-only }
  DefaultCacheBehavior:
      TargetOriginId: alb-dynamic
      CachePolicyId: CachingDisabled
      OriginRequestPolicyId: AllViewer
  CacheBehaviors:
    - PathPattern: /static/*
      TargetOriginId: s3-static
      CachePolicyId: CachingOptimized
    - PathPattern: /api/*
      TargetOriginId: alb-dynamic
      CachePolicyId: !Ref ShortTtlPolicy

Route 53 alias records then point www.example.com at the distribution’s d123.cloudfront.net — alias records are free and resolve directly to CloudFront’s anycast IPs.

Certificates Live in us-east-1

For any CloudFront distribution served on a custom domain, the viewer-facing TLS certificate in AWS Certificate Manager must be issued in us-east-1 (N. Virginia), regardless of where the origin bucket, ALB, or users are. CloudFront is a global service whose control plane is anchored in us-east-1; edge locations pull the certificate from that Region. Requesting an ACM certificate in eu-west-1 because your S3 bucket happens to live there is a broken pattern — the distribution will never see it.

aws acm request-certificate \
  --domain-name media.example.com \
  --validation-method DNS \
  --region us-east-1

If you terminate TLS a second time between CloudFront and an ALB origin, that origin-facing certificate lives in the ALB’s Region. Only the viewer certificate is us-east-1-locked. The same rule applies to API Gateway edge-optimized custom domains (which use an AWS-managed CloudFront distribution internally): the certificate must be in us-east-1. Regional API Gateway endpoints, in contrast, take a certificate from the API’s own Region.

Origin Access Control for S3 Origins

Fronting an S3 bucket with CloudFront while leaving the bucket public defeats the purpose: viewers bypass CloudFront by hitting the S3 REST endpoint directly, sidestepping WAF, geo-restrictions, signed URLs, and cache benefits — and potentially exposing data.

The modern solution is Origin Access Control (OAC), which replaces the legacy Origin Access Identity (OAI). OAC uses SigV4 signing, supports SSE-KMS, works in every S3 Region (including those launched after 2022), and supports dynamic requests. Block Public Access stays on, no ACLs are needed, and the bucket policy grants read access only to the CloudFront service principal, further constrained by the specific distribution ARN:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::media-example-com/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
      }
    }
  }]
}

OAI still functions but should be considered legacy — always pick OAC for new work.

Cache Correctness

Cache effectiveness turns on the Cache-Control and Expires headers the origin returns, combined with the CloudFront cache policy’s min/default/max TTLs. Fingerprinted, immutable assets should be cached aggressively; HTML shells that reference them should be short-lived so deployments propagate; authenticated JSON should not be cached at the shared CDN at all:

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300      # HTML that changes
Cache-Control: private, no-store                      # authenticated JSON

Two symmetric traps are common. First, if the origin emits no cache headers, CloudFront falls back to the distribution’s default TTL and can silently cache dynamic responses for hours. Second, blanket Cache-Control: no-cache on assets that should be cached forces every request back to the origin and defeats the CDN.

The most dangerous trap is caching personalized responses without proper headers. If /account/dashboard returns HTML specific to user A but the origin omits no-store and the cache policy doesn’t include an auth header or cookie in the cache key, the edge will happily serve user A’s page to user B. Either mark such responses private, no-store, or include the session identifier in the cache key and accept the lower hit ratio.

For a cost-optimization scenario where an Auto Scaling group of EC2 On-Demand instances serves static content, the correct redesign is to move the assets to S3, put CloudFront in front with OAC, and eliminate or shrink the ASG. This shifts cost from per-hour compute to per-request delivery, which is orders of magnitude cheaper for static workloads.

Signed URLs, Signed Cookies, and Geo-Restriction

CloudFront supports signed URLs (time-bounded, optionally IP-restricted access to a single object — a purchased video download, a one-off PDF link) and signed cookies (access to many objects matching a path pattern — an authenticated subscriber browsing a catalog). Both use a trusted key group whose public key is uploaded to CloudFront; the private key signs a policy specifying expiration, source IP range, or URL pattern.

https://d123.cloudfront.net/premium/movie.mp4
  ?Expires=1735689600
  &Signature=...
  &Key-Pair-Id=APKAI...

This is distinct from an S3 presigned URL, which bypasses CloudFront and grants direct bucket access. Pair CloudFront signed URLs with OAC and the bucket remains private end-to-end.

Geo-restriction enforces country-level allow-lists or block-lists at the distribution level, before requests hit the cache or origin. It uses the CloudFront-maintained GeoIP database and is the cheap, cache-bypass-proof mechanism for enforcing licensing embargoes. For finer logic (state-level, header combinations), reach for a CloudFront Function or Lambda@Edge; for a full rule engine, use WAF.

AWS Global Accelerator

Global Accelerator is not a CDN and does not cache. It provisions two static anycast IPv4 addresses (or BYOIP) advertised from AWS edge locations globally. Client TCP or UDP connections enter the AWS backbone at the nearest edge and are routed over AWS’s private network to the healthiest endpoint (ALB, NLB, EC2, or Elastic IP) in one or more Regions grouped into endpoint groups with traffic dials and weights.

The static IPs give three concrete benefits: clients and firewall allowlists never change even if the backend is re-architected; regional failover completes in seconds by shifting traffic across endpoint groups on health-check changes, bypassing DNS TTL propagation entirely; and the TCP handshake terminates at the edge with the long haul running on AWS’s backbone.

Choose Global Accelerator when:

• The protocol is non-HTTP: UDP for gaming or VoIP, MQTT, SIP, SFTP, custom TCP.
• You need static IPs for enterprise allowlisting or mobile apps that hardcode addresses.
• You need sub-minute regional failover for stateful active-active deployments.
• The workload is dynamic and non-cacheable, so a CDN offers little value.

Choose CloudFront when:

• Content is cacheable (images, video segments, static HTML, API responses with TTLs).
• You want edge compute via Lambda@Edge or CloudFront Functions.
• You need WAF, signed URLs/cookies, or field-level encryption at the edge.

Two traps to avoid. Picking CloudFront to “make our gaming servers faster globally” fails because gaming is UDP and non-cacheable — Global Accelerator is required. Conversely, picking Global Accelerator for a static website is expensive (fixed hourly fee plus per-GB) and forfeits caching — CloudFront would slash origin egress dramatically. For a globally distributed but single-Region HTTP API where users tolerate the latency, plain Route 53 latency-based routing may be sufficient and cheaper than either.

Route 53 Routing Policies for Global Traffic

Route 53 chooses which endpoint a client resolves to; CloudFront or Global Accelerator then handle the connection. Three policies dominate global architectures.

Latency-based routing measures actual network latency from the resolver’s location to each Region and returns the fastest. Use it for identical stacks in multiple Regions where you want users pulled to whichever Region is fastest right now.

Geoproximity routing is coordinate-based rather than latency-based: you declare the location (or AWS Region) of each endpoint, and Route 53 sends users to the geographically nearest. Its distinctive feature is a bias value (−99 to +99) that expands or shrinks the effective service area — useful for shifting traffic gradually during a Regional launch or draining a Region for maintenance. Geoproximity requires Route 53 traffic flow (traffic policies) and is typically paired with a regional NLB or ALB in each Region.

RecordSets:
  - Region: eu-west-1
    Endpoint: nlb-eu.example.internal
    Bias: +30       # expand EU service area during launch
  - Region: us-east-1
    Endpoint: nlb-us.example.internal
    Bias: 0
  - Region: ap-southeast-1
    Endpoint: nlb-ap.example.internal
    Bias: 0

Failover routing uses a primary/secondary pair tied to health checks. It is DNS-level failover, subject to TTL and resolver caching, so it is slower than Global Accelerator’s data-plane failover — pick failover routing for simple active-passive where a minute of DNS propagation is tolerable, and Global Accelerator when you need seconds.

These policies compose. A common global pattern: Route 53 latency or geoproximity records point at Global Accelerator (for TCP/UDP) or CloudFront (for cacheable HTTPS), with health-checked failover records underneath as a safety net. The layering is deliberate: Route 53 picks the Region, Global Accelerator or CloudFront picks the edge and the path across the backbone, and a regional load balancer picks the target inside the Region.

API Gateway Endpoint Types and Custom Domains

API Gateway offers three endpoint types with distinct topologies:

Edge-optimized endpoints wrap the API in an AWS-managed CloudFront distribution you cannot configure directly. That’s convenient for quick global reach but limiting when you want your own cache behaviors, WAF rules, or origin request policies. The idiomatic pattern for maximum control is a Regional endpoint fronted by a customer-managed CloudFront distribution.

Certificate placement follows CloudFront’s rule: edge-optimized custom domains require an ACM certificate in us-east-1; Regional endpoints require the certificate in the same Region as the API. HTTP APIs enforce TLS 1.2 minimum; REST APIs support security policies up to TLS 1.3.

ACM Certificates: Issued, Validated, Imported

ACM issues and auto-renews public TLS certificates at no cost and integrates directly with CloudFront, API Gateway, ALB, NLB, and other AWS services. Validation is either DNS validation (ACM gives you a CNAME to place in Route 53 or any DNS provider; while the record persists, ACM auto-renews forever) or email validation (manual click-through per renewal, fragile for automation). DNS validation is the correct default for anything production.

ACM-issued certificates cannot be exported and cannot be used outside integrated AWS services. When a regulatory or business requirement mandates a specific third-party CA — for example a REST API that must chain to a particular commercial issuer and enforce TLS 1.3 — you cannot use an ACM-issued certificate. Obtain the certificate from the required CA and import it into ACM, then attach it to a Regional API Gateway custom domain with a TLS 1.3 security policy.

The trap with imports is twofold: imported certificates do not auto-renew (re-import before expiry or the endpoint fails hard), and ACM does not validate the chain on import — a broken intermediate will only surface at handshake time from real clients. Test the full chain against a strict client before rollout.

S3 Transfer Acceleration vs. CloudFront

CloudFront optimizes downloads; S3 Transfer Acceleration optimizes uploads. Transfer Acceleration uses the same CloudFront edge network in reverse: PUTs enter at the nearest edge and ride the AWS backbone to the destination bucket’s Region. It shines when a globally dispersed set of users uploads sizable objects to a bucket in a single Region — field engineers worldwide uploading multi-gigabyte drawings to us-east-1, for example.

The two features coexist on the same bucket: enable Transfer Acceleration and expose a CloudFront distribution with OAC for downloads. For small objects or clients already near the bucket’s Region, Transfer Acceleration adds cost without benefit — use the S3 Transfer Acceleration speed comparison tool to measure before committing. Clients must use the s3-accelerate endpoint for the acceleration to engage.

AWS WAF for Layer 7 Protection

AWS WAF inspects HTTP(S) requests before they reach the protected resource. It attaches to CloudFront distributions, ALBs, API Gateway stages, AppSync APIs, Cognito user pools, App Runner services, and Verified Access instances. A web ACL contains rules that match on URI, headers, query strings, body (up to 8 KB by default, expandable to 64 KB on ALB/API Gateway), IP sets, and geolocation.

The most common building blocks are AWS Managed Rules: AWSManagedRulesCommonRuleSet and AWSManagedRulesKnownBadInputsRuleSet cover the OWASP top exploits; AWSManagedRulesSQLiRuleSet and XSS match statements handle injection. Custom rules add geo-match (country allowlists/blocklists for compliance), IP set matches, and rate-based rules — which count requests per source IP over a rolling five-minute window and block once a threshold is exceeded. Rate-based rules are the first line of defense against HTTP floods and credential stuffing:

{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 500,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority":0,"Type":"NONE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

Region rules matter. Web ACLs for CloudFront are global and must be created in us-east-1. Web ACLs for Regional resources (ALB, API Gateway, etc.) are created in the resource’s own Region.

To protect a static site on S3, you cannot attach WAF to the bucket — S3 is not a WAF-supported resource. The correct pattern is CloudFront + OAC in front of the bucket with the web ACL attached to the distribution. The bucket being unreachable except through CloudFront is what makes “inspect all traffic” true.

Firewall Manager for Multi-Account WAF Governance

Managing WAF one account at a time does not scale. Across an Organization, a team spins up a new ALB without attaching the corporate baseline and the compliance posture silently regresses. AWS Firewall Manager solves this with organization-wide policies enforced against in-scope accounts and resources.

Prerequisites: AWS Organizations with all-features enabled, a designated Firewall Manager administrator account, and AWS Config enabled in every member account. Policy types cover AWS WAF, AWS Shield Advanced, security groups (audit and usage), Network Firewall, Route 53 Resolver DNS Firewall, and third-party firewalls.

A WAF policy can enforce a “first” rule group (evaluated before application-owned rules), a “last” rule group (after), or replace the web ACL entirely. New ALBs or CloudFront distributions matching the resource scope automatically receive the corporate rule set, and non-compliant resources are flagged and — depending on remediation settings — automatically fixed. Whenever a scenario says “multiple accounts,” “centrally manage,” or “consistent WAF rules across the organization,” Firewall Manager is the answer, not per-account WAF.

Shield Standard vs. Shield Advanced

Assuming WAF alone stops DDoS is a critical mistake. WAF operates on requests that reach it — it’s excellent against application-layer floods, credential stuffing, and known exploit signatures — but large volumetric attacks at Layers 3/4 (SYN floods, UDP reflection) are absorbed by AWS Shield.

Shield Standard is on by default at no cost. It defends against common L3/L4 attacks automatically and applies to CloudFront, Route 53, and Global Accelerator, with basic protection for ELB, EC2, and other resources. It does not provide attack-specific visibility, Shield Response Team engagement, or cost protection.

Shield Advanced ($3,000/month per organization, one-year commitment) adds:

Assuming Shield Standard is sufficient for “large-scale DDoS with cost protection and expert response” is wrong precisely because Standard lacks visibility, cost protection, and SRT access. When the origin is EC2 behind an ELB and DNS is with a third party (so Route 53 alias tricks aren’t an option), the recommended pattern is to enable Shield Advanced on the ELB and front the application with CloudFront (also Shield Advanced-protected) to move the mitigation perimeter to the edge and shrink the attack surface reaching the Region.

The correct layered posture is: Shield for L3/L4 volumetrics, WAF for L7 filtering, CloudFront or Global Accelerator as the edge entry point that both services attach to, and Firewall Manager to enforce the policy across every account.

← Previous: Networking · All domains · Next: Databases →

Practice Content Delivery questions → · Timed practice on ExamRoll.io →

Browse Amazon →