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

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.

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

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.