ExamFinch.com My Study

Study guide

CloudFront Behaviors, Origin Access, Edge Compute, and Global Accelerator

Practice this exam

AWS Certified Solutions Architect - Professional SAP-C02

Track your progress as you read

Finished sections get a check mark.

1 Introduction and SAP-C02 Exam Facts

Current SAP-C02 Exam Facts Exam Format, Scoring, and Retakes Candidate Profile and Four Exam Domains

2 Multi-Account Governance

Multi-Account Strategy, Account Topologies, and OU Hierarchies Service Control Policies, Inheritance, and Permission Guardrails Control Tower, Landing Zones, Central Logging, and Resource Sharing

3 Hybrid and Inter-VPC Connectivity

Transit Gateway, VPC Connectivity, and PrivateLink Direct Connect, VPN, and Hybrid Redundancy Hybrid DNS with Route 53 Resolver Segmentation, Traffic Monitoring, and Service Endpoints

4 Identity Federation and Cross-Account Access

IAM Identity Center, External IdPs, and Workforce Federation Cross-Account Roles, STS, and Resource Policies Permissions Boundaries, Delegated Administration, and Least Privilege at Scale

5 Data Protection, Encryption, and Compliance

KMS, Multi-Region Keys, Envelope Encryption, and Certificates Encryption in Transit, Security Groups, NACLs, and VPC Endpoints Centralized Audit, Security Hub, GuardDuty, Inspector, and Access Analyzer

6 Deployment, Compute, Containers, and Serverless

Infrastructure as Code, CI/CD, Change Management, and Rollback EC2 Families, Auto Scaling, and Managed Compute ECS, EKS, Fargate, and ECR at Enterprise Scale Lambda, Step Functions, API Gateway, and Configuration Management

7 Storage, Caching, and Edge Performance

S3 Storage Classes, Object Lock, Replication, and Access Paths EBS, EFS, FSx Family, and Storage Gateway CloudFront Behaviors, Origin Access, Edge Compute, and Global Accelerator ElastiCache, MemoryDB, DAX, and Buffering versus Cache versus Replicas

8 Purpose-Built and Global Databases

Aurora Storage, Replicas, and Global Database DynamoDB Keys, Global Tables, and DAX Purpose-Built Database Selection

9 Integration, Messaging, and Streaming

API Gateway Architectures Decoupled Messaging with Amazon SQS and Amazon SNS Event-Driven Design with Amazon EventBridge Streaming Analytics with Amazon Kinesis and Amazon MSK

10 Resilience and Disaster Recovery

Disaster Recovery Patterns Route 53 Routing and Application Recovery Controller Backup, Replication, and Service Quotas High Availability, Failover, Chaos, and Self-Healing

11 Operational Excellence and Automation

CloudWatch Centralized Telemetry Distributed Tracing with AWS X-Ray Systems Manager Automation Deployment Strategies and Auto-Remediation

12 Cost Optimization and Visibility

Cost Explorer, Budgets, CUR, and Allocation Tags Savings Plans, Reserved Instances, Coverage, and Sharing Spot, Mixed Auto Scaling, Compute Optimizer, and Storage Lens Data Transfer Modeling: NAT, Endpoints, CloudFront, and Hybrid

13 Improve Security and Performance

Secrets, Least Privilege Audits, and Traceability Config Rules, Patching, Backup, and Regulatory Controls Performance Tuning for Existing Workloads

14 Migration Assessment and Wave Planning

Seven Migration Strategies (7 Rs) and Workload Selection Application Discovery, Migration Hub, and Migration Evaluator Wave Planning, Prioritization, and Assessment Governance

15 Migration Tools and Data Transfer

AWS Application Migration Service (MGN) AWS DMS, SCT, and Change Data Capture Large-Scale Data Transfer and Landing-Zone Prerequisites

16 Target Architecture, Modernization, and Cutover

Selecting Compute, Storage, and Database Platforms for Migrated Workloads Container Modernization: ECS, EKS, Fargate, ECR, and Strangler Fig Serverless, Decoupling, Purpose-Built Databases, and Integration Services Cutover, Rollback, and Unscored Emerging AI Topics

CloudFront Behaviors, Origin Access, Edge Compute, and Global Accelerator

Key Takeaways Explain This Topic AI

CloudFront is an HTTP/HTTPS content delivery network with POPs and regional edge caches; cache behaviors bind path patterns to an origin, cache policy, origin request policy, and viewer protocol.

Origin access control (OAC) is the current way to keep an S3 bucket private: CloudFront signs SigV4 requests and the bucket policy allows only that distribution; OAC supports SSE-KMS and PUT/DELETE, which origin access identity (OAI) does not.

CloudFront Functions run JavaScript at viewer request/response in submilliseconds with no network access; Lambda@Edge supports Node.js and Python, origin triggers, network calls, and request bodies.

AWS Global Accelerator advertises static anycast IP addresses and accelerates TCP/UDP onto the AWS backbone without caching; use it for non-HTTP protocols, allowlisted IPs, and fast Regional failover, not as a CDN.

S3 website endpoints and some custom origins are not OAC S3 origins; an S3 website endpoint is configured as a custom origin, and VPC origins can keep ALB/NLB/EC2 off the public internet.

Last updated: September 2026

CDN versus anycast: two different professional tools

Amazon CloudFront is a content delivery network (CDN) . Viewers resolve a distribution domain, land on a nearby point of presence (POP) , and receive cached HTTP/HTTPS objects when the cache key hits. Unpopular objects may still hit a regional edge cache before the origin. Cacheable GET/HEAD (and optionally OPTIONS) can be served without touching your Region. PUT , POST , PATCH , and DELETE go to the origin. CloudFront reduces origin load and viewer latency for web and media.

AWS Global Accelerator is not a CDN. It advertises static anycast IP addresses (two IPv4 addresses, or dual-stack). Client traffic enters the AWS global network at the nearest edge, then rides the backbone to a healthy regional endpoint: Application Load Balancer (ALB) , Network Load Balancer (NLB) , EC2, or Elastic IP. There is no object cache and no HTML edge rewrite. The gain is path quality, static IPs for allowlists, and rapid health-based Regional failover for TCP and UDP.

SAP-C02 will offer both in the same question. If the payload is HTTP and cacheable (HLS segments, images, API GETs with a cache policy), CloudFront. If the payload is a binary trading protocol, UDP game traffic, VoIP, or “our partners allowlist two IPs forever,” Global Accelerator.

Cache behaviors and origin types

A distribution has one or more cache behaviors . Each behavior matches a path pattern ( /hls/* , /api/* , default * ) and sets:

  • Which origin (or origin group) to use
  • Cache policy (TTL, headers/cookies/query strings in the cache key)
  • Origin request policy (what to forward that is not in the cache key)
  • Viewer protocol (HTTPS-only versus redirect)
  • Allowed HTTP methods, compression, and trusted key groups for signed URLs/cookies

Normalize the cache key: forwarding every header destroys the hit ratio. Sort and lowercase query strings when order does not matter. Signed cookies protect a whole HLS tree; signed URLs protect a single object.

Origins CloudFront documents include:

  • Amazon S3 REST bucket ( bucket.s3.region.amazonaws.com ) with origin access control (OAC)
  • S3 Object Lambda access point alias (OAC required)
  • S3 Access Point or S3 Multi-Region Access Point (MRAP needs its own OAC pattern)
  • S3 website endpoint , which must be a custom origin —OAC/OAI do not apply, and you lose private-bucket SigV4
  • ALB , NLB , EC2 , AWS Lambda function URLs, Amazon API Gateway , MediaStore, MediaPackage
  • VPC origins so ALB/NLB/EC2 can stay in a private subnet and never sit on the public internet
  • Origin groups for origin failover (primary 404/5xx → secondary)

Dynamic origin selection can use CloudFront Functions or Lambda@Edge when the origin is already defined on the distribution; Lambda@Edge origin-request is the classic “look something up, then pick origin” path because Functions cannot make network calls.

Origin access control versus origin access identity

Keep media buckets private. OAC is the current control: CloudFront signs requests with SigV4 as the cloudfront.amazonaws.com service principal, and the bucket policy allows s3:GetObject (and write APIs if you use them) only when AWS:SourceArn is that distribution. Choose sign requests (always) so CloudFront-to-S3 is HTTPS.

AWS recommends OAC over legacy origin access identity (OAI) because OAC supports all Regions (including opt-in Regions after December 2022), SSE-KMS objects, and viewer PUT/DELETE through CloudFront. OAI does not. New buckets should use Bucket owner enforced object ownership. If you still need ACLs, Bucket owner preferred is the documented compromise.

Do not attach OAC to an S3 website endpoint origin. Do not leave the bucket policy with Principal: "*" and call it private because CloudFront exists—viewers will go around the CDN unless the bucket denies everything except the distribution.

CloudFront Functions versus Lambda@Edge

Both run in response to CloudFront events. They are not interchangeable.

  • Capability CloudFront Functions Lambda@Edge
  • Language JavaScript (ECMAScript 5.1-compliant; runtime 2.0 adds KeyValueStore) Node.js and Python
  • Triggers Viewer request, viewer response Viewer request/response and origin request/response
  • Duration Submillisecond Up to 30 seconds
  • Network / AWS SDK / request body No Yes
  • Scale Millions of requests per second About 10,000 requests per second per Region
  • Code size 10 KB 50 MB
  • KeyValueStore Yes (runtime 2.0) No

Use Functions for cache-key normalization, header inject/strip, URL rewrite/redirect, and validating a JSON Web Token (JWT) that is already on the request when you need no JWKS fetch. Use Lambda@Edge when you must call DynamoDB or an IdP, inspect the body, pick an origin with a network lookup, or run for more than a millisecond. Author Lambda@Edge in us-east-1 and publish a version; it replicates to regional edge caches. Functions deploy inside CloudFront and execute at POPs. A mature distribution often uses both: Functions on every viewer request, Lambda@Edge on origin events after a cache miss.

Global Accelerator versus CloudFront, anycast versus CDN

  • Question CloudFront Global Accelerator
  • Protocols HTTP/HTTPS (and WebSocket over HTTP) TCP and UDP (Layer 4)
  • Caching Yes (POP + regional edge cache) No
  • Edge compute Functions and Lambda@Edge None
  • Client entry Distribution domain / aliases Two static anycast IPs
  • Typical endpoints S3, ALB, custom HTTP origins ALB, NLB, EC2, Elastic IP
  • WAF association CloudFront-scoped Web ACL Attach WAF to the regional ALB instead

Best fit Global media, static sites, cacheable APIs Trading/FIX-like TCP, gaming UDP, partner IP allowlists, non-cacheable APIs

Anycast means the same IP is advertised from many locations; the internet delivers the packet to a nearby AWS edge, then Global Accelerator forwards on the backbone. A CDN stores copies of bytes. Anycast without a cache still helps non-HTTP flows because the slow part of the public internet is shortened. Global Accelerator health checks fail away from an unhealthy Region without waiting for DNS TTL. CloudFront origin groups fail over HTTP origins on specified status codes; that is origin failover, not a Layer 4 anycast fabric.

You can use both: CloudFront for /vod/* from S3, Global Accelerator for a TCP market-data feed to an NLB. S3 Transfer Acceleration also uses edge locations, but only to drag objects into one bucket ; it does not terminate viewer HTTP with cached segments.

Global media and trading sketches

VOD platform: S3 origin (Intelligent-Tiering or Standard), OAC, behaviors that cache /segments/* aggressively and forward /api/* to an ALB origin with a short TTL or caching disabled, CloudFront Functions to strip unused query strings, Lambda@Edge only if you must authorize against an external store on origin request. Trading firm: no CloudFront in front of the matching engine; Global Accelerator static IPs on the counterparty firewall, NLB in two Regions, failover on health checks. If the same firm also hosts a public status site, that site is CloudFront—do not force the matching engine through a CDN.