13.3 Global Content & Service Distribution: CloudFront & Global Accelerator

13.3 Global Content & Service Distribution: CloudFront & Global Accelerator

CloudOps Blueprint Focus: The AWS Certified CloudOps Engineer – Associate (SOA-C03) exam tests your ability to optimize global application performance, secure origin infrastructure, and design high-availability delivery architectures. CloudOps engineers must master Amazon CloudFront edge topology, protect origins using Origin Access Control (OAC) with KMS encryption, optimize caching efficiency using Cache and Origin Request policies, implement edge compute (CloudFront Functions vs. Lambda@Edge), and differentiate between CloudFront and AWS Global Accelerator for non-HTTP and static IP workloads.

---

Amazon CloudFront Global Architecture

Amazon CloudFront is a global Content Delivery Network (CDN) service that securely delivers data, videos, applications, and APIs to users with low latency and high transfer speeds. CloudFront terminates TLS connections close to viewers and caches content across a multi-tier global infrastructure:

1. Points of Presence (PoPs) / Edge Locations: More than 600 geographically distributed Points of Presence located in major metropolitan areas worldwide. Edge locations terminate viewer connections, inspect TLS certificates, evaluate AWS WAF rules, run CloudFront Functions, and serve cached responses.
2. Regional Edge Caches (REC): A mid-tier caching layer deployed across approximately 13 core AWS Regions. Regional Edge Caches possess significantly larger storage capacities than individual edge locations. When an edge location experiences a cache miss, it queries its nearest Regional Edge Cache before forwarding the request to the origin. RECs retain less frequently requested long-tail content, preventing cache evictions and reducing origin fetch volume.
3. Distribution Types: CloudFront supports Web Distributions delivering HTTP/1.1, HTTP/2, and HTTP/3 (over QUIC). Legacy RTMP distributions for streaming media are fully deprecated.

---

Origins & Origin Shielding

CloudFront acts as a reverse proxy in front of one or more Origins:

• Supported Origins: Amazon S3 buckets, Elastic Load Balancers (ALB/NLB), Amazon EC2 instances, AWS Elemental MediaStore, Amazon API Gateway, or custom on-premises web servers.
• Origin Groups & Failover: CloudFront supports Origin Groups containing a primary origin and a secondary origin. If the primary origin returns specific HTTP error status codes (e.g., 500, 502, 503, 504, or connection timeouts), CloudFront automatically fails over to the secondary origin.

Amazon CloudFront Origin Shield

When an application experiences high global request volumes across dozens of edge locations simultaneously, multiple edge locations and RECs may fetch the exact same object from the origin concurrently (the "thundering herd" phenomenon), causing origin performance degradation and high cross-region data transfer fees.

Origin Shield is an additional, centralized caching layer that you explicitly configure within the Regional Edge Cache closest to your origin:

• All cache misses from every edge location and Regional Edge Cache worldwide are routed through this single Origin Shield REC.
• The Origin Shield REC consolidates requests, serves cached content, and forwards only a single request to the origin for any cache miss.
• Operational Benefits: Origin Shield dramatically increases cache hit ratios, protects backend databases and application servers from traffic spikes, and minimizes cross-region data transfer egress costs.

+---------------------------------------------------------------------------------------------------+
|                                 CLOUDFRONT MULTI-TIER CACHING TOPOLOGY                            |
|                                                                                                   |
|  Global Viewers                                                                                   |
|        |                                                                                          |
|        v                                                                                          |
|  +-------------------------------------------------------------+                                  |
|  | Edge Locations (600+ Global PoPs)                           |  <-- Runs CloudFront Functions   |
|  | (Viewer TLS Termination, Caching, AWS WAF inspection)       |                                  |
|  +------------------------------+------------------------------+                                  |
|                                 | Cache Miss                                                      |
|                                 v                                                                 |
|  +-------------------------------------------------------------+                                  |
|  | Regional Edge Caches (RECs - 13 Global Hubs)                |  <-- Runs Lambda@Edge            |
|  | (Large-capacity caching for long-tail assets)               |                                  |
|  +------------------------------+------------------------------+                                  |
|                                 | Cache Miss                                                      |
|                                 v                                                                 |
|  +-------------------------------------------------------------+                                  |
|  | ORIGIN SHIELD (Designated Central REC)                      |  <-- Consolidates global fetches |
|  +------------------------------+------------------------------+                                  |
|                                 | Single Origin Fetch                                             |
|                                 v                                                                 |
|  +-------------------------------------------------------------+                                  |
|  | ORIGIN INFRASTRUCTURE (Amazon S3 / Application Load Balancer)|                                  |
|  +-------------------------------------------------------------+                                  |
+---------------------------------------------------------------------------------------------------+

---

Origin Access Control (OAC) vs. Legacy Origin Access Identity (OAI)

When using Amazon S3 as a CloudFront origin, public read access on the bucket must be completely disabled. To ensure that users access objects strictly through CloudFront, AWS previously used Origin Access Identity (OAI), which is now legacy and deprecated in favor of Origin Access Control (OAC).

Why OAI Is Deprecated

• No KMS CMK Support: OAI cannot download S3 objects encrypted with AWS KMS Customer Managed Keys (SSE-KMS); it only supports default SSE-S3 encryption.
• HTTP Method Limitations: OAI is restricted strictly to GET and HEAD requests; it does not support PUT, POST, or DELETE methods.
• Regional Incompatibility: OAI cannot be used in AWS Regions launched after December 2022 (e.g., ap-south-2, eu-central-2, me-central-1).

Origin Access Control (OAC) Capabilities

• Comprehensive Region Support: Supports all AWS Regions, both current and future.
• SSE-KMS Encryption Support: OAC natively passes the CloudFront distribution identity and AWS Signature Version 4 (SigV4) headers to AWS KMS, allowing CloudFront to decrypt S3 objects protected by Customer Managed Keys.
• Dynamic HTTP Methods: Fully supports dynamic writes (PUT, POST, PATCH, DELETE) to S3.
• Granular Least Privilege: Integrates with AWS IAM resource policies using service principals and explicit condition keys.

Configuring OAC with S3 Bucket Policies & KMS

To implement OAC, the CloudOps engineer creates an OAC profile in CloudFront, attaches it to the S3 origin, and configures an S3 Bucket Policy granting access exclusively to the CloudFront distribution ARN via aws:SourceArn:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::corp-production-assets/*",
      "Condition": {
        "StringEquals": {
          "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
        }
      }
    }
  ]
}

If the S3 bucket is encrypted using an AWS KMS Customer Managed Key, the KMS key policy must also authorize the CloudFront service principal:

{
  "Sid": "AllowCloudFrontKMSDecryption",
  "Effect": "Allow",
  "Principal": {
    "Service": "cloudfront.amazonaws.com"
  },
  "Action": ["kms:Decrypt", "kms:GenerateDataKey*"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
    }
  }
}

---

Cache Policies vs. Origin Request Policies

In modern CloudFront architectures, request processing behavior is decomposed into distinct, reusable policies:

Cache Policies

A Cache Policy defines what values from a viewer request are included in the Cache Key, as well as the object's Time-To-Live (TTL):

• Cache Key Elements: Headers, Cookies, and Query Strings. If an element is included in the cache key, CloudFront stores separate cached variations of the object for each distinct combination of values.
• Golden Rule of Caching: Minimize cache key parameters. Including unnecessary headers (e.g., User-Agent) creates thousands of unique cache keys for identical files, causing cache fragmentation and plummeting the Cache Hit Ratio to near zero.
• TTL Configuration: Defines Minimum TTL, Maximum TTL, and Default TTL (used when the origin does not return Cache-Control headers).

Origin Request Policies

An Origin Request Policy determines which viewer request headers, cookies, and query strings are forwarded to the origin on a cache miss, without including them in the Cache Key:

• Operational Power: Allows backend application servers to receive critical context (such as viewer device headers, custom authorization headers, or user session cookies) while maintaining a clean, unfragmented Cache Key.

Response Headers Policies

A Response Headers Policy instructs CloudFront to inject HTTP headers into the response sent to viewers without altering origin code. It is the architectural standard for enforcing security headers (such as Strict-Transport-Security [HSTS], Content-Security-Policy [CSP], and X-Frame-Options) and managing Cross-Origin Resource Sharing (CORS).

---

Edge Compute: CloudFront Functions vs. Lambda@Edge

CloudFront provides two serverless compute options at the edge to customize content delivery, enforce security, and manipulate HTTP traffic.

---

AWS Global Accelerator vs. Amazon CloudFront

Both services leverage AWS's global network infrastructure to improve application performance, but they solve fundamentally different operational problems.

AWS Global Accelerator Architecture

• Static Anycast IP Addresses: Global Accelerator provisions two static Anycast IPv4 addresses that act as fixed entry points for your application worldwide.
• Private Backbone Ingress: Anycast routes client traffic to the topologically closest AWS edge location. From the edge, traffic enters the AWS private fiber-optic backbone network directly, bypassing congested public internet transit providers.
• Direct Protocol Routing: Global Accelerator routes traffic directly to endpoints (Application Load Balancers, Network Load Balancers, or EC2 instances) across one or more AWS Regions.
• Zero Caching: Global Accelerator does not cache any content. It is purely a Layer 4 (TCP/UDP) and Layer 7 network transport accelerator.

Architectural Decision Matrix