Amazon CloudFront & Route 53

Overview

Two services sit between the internet and your AWS infrastructure for almost every production workload: Amazon Route 53 resolves domain names to addresses, and Amazon CloudFront caches and delivers content from edge locations physically close to end users. They are complementary by design — Route 53 sends users to the right CloudFront distribution or regional endpoint, and CloudFront takes over from there, serving content without touching the origin whenever the cache allows.

Understanding both services means understanding where requests go before they ever reach an EC2 instance, an ALB, or an S3 bucket. That edge layer is where latency is won or lost, where DDoS attacks are absorbed, where TLS is terminated, and where traffic is intelligently shifted between regions.

CloudFront Architecture

CloudFront operates through a globally distributed network of over 600 Points of Presence (PoPs). These PoPs fall into two tiers:

Edge locations are the outermost tier — the nodes physically closest to end users. There are hundreds of them across every major city and region. TLS termination, caching, and response serving all happen here. A cache hit at an edge location means the request is satisfied entirely within the PoP — the origin is never contacted.

Regional edge caches sit between the edge locations and the origin. They are fewer in number but have significantly larger storage capacity. When content is evicted from an edge location cache (because it has not been requested recently enough to stay warm), the regional edge cache may still have a copy. This adds a second cache layer that can absorb misses before they propagate all the way to the origin, reducing origin load and latency for moderately popular content.

Origins are the sources CloudFront fetches from on a cache miss. Supported origin types:

A single CloudFront distribution can have multiple origins and route different request paths to different origins using cache behaviors.

Distributions and Cache Behaviors

A distribution is the top-level CloudFront configuration entity. It is identified by a domain name like d1abc2defg3.cloudfront.net, which you typically alias to your own domain via Route 53.

Cache Behaviors

A cache behavior is a rule that matches a URL path pattern and defines how CloudFront handles matching requests. Every distribution has a default cache behavior (pattern *) and can have any number of additional path-specific behaviors, evaluated in order of specificity — longer, more specific patterns take precedence.

Common behavior configurations:

Cache Keys

The cache key determines whether an incoming request matches a stored cached object. The default cache key is the URL path alone. Cache policies extend the cache key to include:

• Specific query strings (e.g., include ?version but not ?utm_source)
• Specific HTTP headers (e.g., Accept-Language for content negotiation)
• Specific cookies (e.g., a theme selection cookie)

Every dimension added to the cache key reduces cache hit rates by fragmenting the cache space. The rule is to include only what the backend actually uses to generate different responses. A query string the origin ignores should not be in the cache key.

Origin Request Policy

Separate from the cache key is the origin request policy, which controls what CloudFront forwards to the origin on a cache miss. This decoupling matters: you can forward an authentication header to the origin (so it can validate the request) without including that header in the cache key (which would fragment the cache by auth token). The origin receives what it needs; the cache key stays narrow.

TTL and Cache-Control

Three TTL settings define caching duration:

Best practice: set Cache-Control: max-age=31536000, immutable on content-hashed static assets (JavaScript bundles, CSS files, image files with hash in filename). Set Cache-Control: no-store or short max-age on dynamic or user-specific responses.

Origin Access Control

When S3 is the origin, users should never be able to bypass CloudFront and reach the S3 bucket URL directly. Direct S3 access circumvents caching, WAF inspection, signed URL enforcement, and CloudFront logging.

Origin Access Control (OAC) is the current mechanism for restricting S3 bucket access to CloudFront only. It replaces the legacy Origin Access Identity (OAI), which lacked support for SSE-KMS encryption, all HTTP methods, and newer S3 regions.

Setup:

1. Create an OAC in CloudFront and associate it with the S3 origin on your distribution.
2. Add an S3 bucket policy that grants s3:GetObject (and any other required actions) to the cloudfront.amazonaws.com service principal, conditioned on the specific distribution ARN.
3. Block all public access on the S3 bucket.

The bucket now rejects every request that does not carry a valid signature from your specific CloudFront distribution. No direct S3 URL will return content.

OAC supports SSE-KMS encrypted buckets, POST and DELETE methods (for upload use cases), and works with all S3 regions including newer ones not supported by OAI.

Signed URLs and Signed Cookies

For private, access-controlled content — paid video, time-limited downloads, subscriber-only files — CloudFront provides two mechanisms:

Both are cryptographically signed using a CloudFront key pair managed via CloudFront Key Groups. The signature includes:

• Expiration timestamp (requests after expiry receive 403)
• Optional IP address restriction (requests from other IPs receive 403)
• The URL or path pattern being authorized

Signed URLs are generated server-side in your application and handed to the client. CloudFront validates the signature on every request. If the signature is invalid, tampered, or expired, CloudFront returns 403 without contacting the origin.

Common use case: video streaming with HLS or DASH. The manifest file is served via a signed URL. Segment files under /stream/* are protected by a signed cookie set when the user authenticates.

CloudFront Functions vs Lambda@Edge

CloudFront offers two execution environments for running code at the edge, with meaningfully different capabilities:

CloudFront Functions are the right choice for lightweight, high-frequency transformations that must execute on every single request with zero perceptible latency overhead. Lambda@Edge is the right choice when you need the full capability of Lambda — external API calls, heavy computation, access to full request and response bodies, or logic that must fire on origin requests/responses rather than viewer events.

WAF Integration

Attach an AWS WAF WebACL to a CloudFront distribution to inspect all HTTP/HTTPS requests at the edge before they reach your origin or your regional infrastructure. When WAF is attached to CloudFront, it is deployed globally — evaluated at every edge location, not just in one AWS region.

WAF rules can:

• Block or allow requests by source IP or CIDR range (IP sets)
• Block traffic from specific countries (geo match)
• Rate-limit requests per IP address per time window — for example, block any IP sending more than 100 requests in 5 minutes (effective against credential stuffing and application-layer floods)
• Match and block common exploit patterns: SQL injection, cross-site scripting, path traversal (AWS Managed Rules Core Rule Set)
• Block requests matching known-bad IP reputation lists (Tor exit nodes, botnets, scanners)
• Run Bot Control managed rules to distinguish legitimate crawlers from malicious scrapers

Requests that match a Block rule return a 403 (or a custom error page) at the edge. They never reach the ALB, EC2, or application. Count mode lets you run rules in observation mode first to see impact before switching to block — essential before enabling any new rule group in production.

Global Accelerator vs CloudFront

These two services are frequently confused because both involve edge infrastructure. They solve different problems:

CloudFront reduces load on your origin and cuts latency by serving cached content. Global Accelerator improves path quality — traffic travels over the AWS backbone instead of the public internet, which reduces jitter and improves consistency for non-cacheable content. They are not mutually exclusive. A CloudFront distribution in front of Global Accelerator endpoints is a valid architecture for applications that need both caching and stable IPs.

Route 53 Overview

Route 53 is four services in one:

1. Authoritative DNS: answers queries for domains you own
2. Domain registrar: purchase and manage domain registrations directly through AWS
3. Health checker: continuously monitors endpoint health via HTTP, HTTPS, and TCP probes
4. Traffic router: applies routing policies to direct queries based on latency, geography, weight, or health

Route 53 is built on anycast infrastructure with name servers distributed globally. AWS guarantees 100% availability for the DNS resolution function — it is the only AWS service with a 100% SLA.

Hosted Zones

A hosted zone is the container for DNS records for a domain. Every domain you manage in Route 53 has a hosted zone.

Private hosted zones are used for internal service names (api.internal.corp.com), split-horizon DNS (same name resolves differently inside vs outside the VPC), and service discovery in microservice architectures.

Record Types

Alias Records

Alias records are a Route 53 extension with no direct equivalent in standard DNS. They map a name directly to an AWS resource. Key differences from CNAME:

Use Alias whenever pointing to an AWS resource. Use CNAME only when pointing to a non-AWS hostname.

Route 53 Routing Policies

Routing policies determine how Route 53 answers queries when multiple records exist for the same name.

Weighted Routing in Practice

Weighted routing is the standard mechanism for gradual traffic migration — shifting traffic from one version of a service to another without a hard cutover:

• Old version: weight 90
• New version: weight 10

Route 53 sends approximately 10% of queries to the new version. After validation, adjust weights incrementally. Weight 0 removes a record from rotation entirely without deleting it — useful for draining an endpoint before maintenance.

Failover Routing

Failover requires a health check on the primary record. Route 53 continuously evaluates the health check. When the primary fails, Route 53 automatically stops returning the primary record and returns the secondary instead. DNS TTL determines how quickly clients pick up the change — keep TTLs low (60 seconds) on failover records to minimize failover time.

Route 53 Health Checks

Health checks run independently of DNS records. Route 53 sends probes from multiple AWS locations globally (currently over 15 locations). A check is healthy when a configurable majority of probing locations can reach the endpoint.

Configuration options:

• Probe interval: 30 seconds (standard) or 10 seconds (fast — additional cost)
• Failure threshold: number of consecutive failures before marking unhealthy (default 3)
• String matching: verify that a specific string appears in the HTTP response body

Health checks are required for Failover routing and strongly recommended for Weighted, Latency, Geolocation, and Multivalue Answer policies to prevent traffic from routing to unhealthy endpoints.

Private Hosted Zones and Hybrid DNS

Private hosted zones resolve internal names within associated VPCs. The VPC must have two settings enabled:

• enableDnsSupport = true — enables the Route 53 Resolver in the VPC
• enableDnsHostnames = true — assigns DNS names to EC2 instances

A private hosted zone can be associated with VPCs in other AWS accounts using RAM (Resource Access Manager), enabling centralized internal DNS across a multi-account organization.

Route 53 Resolver for Hybrid Environments

On-premises networks connected via Direct Connect or VPN need to resolve AWS private hosted zone names, and AWS resources may need to resolve on-premises internal DNS names. Route 53 Resolver handles this through endpoints:

Resolver rules define the forwarding: “queries for corp.internal should be forwarded to 10.0.1.10.” Rules can be shared across accounts with RAM.

End-to-End Request Flow

References

• Amazon CloudFront Developer Guide
• CloudFront Origin Access Control
• CloudFront Functions vs Lambda@Edge
• Amazon Route 53 Developer Guide
• Route 53 routing policies
• Route 53 Resolver for hybrid networks
• AWS Global Accelerator documentation