Category: Cloud & Infrastructure Tags: amazon-cloudfront content-delivery-network edge-caching

What Is CloudFront?

By Oleksandr Andrushchenko — Published on — Modified on
0 0

Amazon CloudFront is a content delivery network (CDN) from AWS that accelerates the delivery of websites, APIs, images, videos, downloads, and other content. Instead of every request traveling directly to an application's origin server, CloudFront routes requests through its global edge infrastructure. When a requested response is cached, CloudFront can return it without contacting the origin.

CloudFront also acts as a reverse proxy between users and backend infrastructure. It supports HTTPS, request routing, caching policies, private origins, signed URLs, AWS WAF integration, and edge functions. However, placing CloudFront in front of an application does not automatically improve every request. Performance and correctness depend on cache keys, TTLs, forwarded headers, origin configuration, and how personalized content is handled.

Table of Contents

What Amazon CloudFront Provides

A traditional application often serves content from one AWS Region. Users close to that Region may experience good response times, but geographically distant users introduce additional network round trips and latency.

CloudFront uses distributed edge infrastructure to bring content closer to viewers. Frequently requested responses can be served from caches instead of repeatedly retrieving the same data from S3, an Application Load Balancer, API Gateway, or another origin.

Common CloudFront Use Cases

CloudFront is useful when applications need global content delivery, centralized HTTPS handling, caching, or controlled access to origin infrastructure.

  • Static websites: HTML, JavaScript, CSS, fonts, and images.
  • User-generated media: Avatars, thumbnails, and downloadable files.
  • REST APIs: HTTPS routing, selected response caching, and integration with security controls.
  • Software downloads: Distributing large versioned artifacts.
  • Video delivery: Delivering streaming manifests and media segments.
  • Private content: Restricting access using signed URLs or cookies.
  • Multi-origin applications: Routing different URL paths to static and dynamic backends.

For example, a system design blog can store images, stylesheets, and JavaScript bundles in S3 while a FastAPI application renders articles and user-specific pages. CloudFront can serve the static files from its cache and forward dynamic requests to the application origin.

The broader architecture of globally distributed content delivery is covered in What Is a CDN?.

CloudFront vs. S3, Load Balancers, and API Gateways

CloudFront is not a replacement for application hosting or durable object storage. Its role is to deliver, route, cache, and protect HTTP content in front of existing origins.

Service Primary Responsibility Typical Use
Amazon CloudFront Global content delivery and edge proxy CDN, HTTPS, caching, edge security
Amazon S3 Durable object storage Images, downloads, application assets
Application Load Balancer Regional application request distribution Routing to ECS or EC2 services
Amazon API Gateway API management and integrations HTTP APIs, authorization, throttling
Route 53 DNS resolution and routing policies Connecting domain names to endpoints

These services frequently work together. Route 53 resolves the domain, CloudFront receives the HTTPS request, and the configured origin provides content when it is not already available in the edge cache.

How Amazon CloudFront Works

A CloudFront distribution is the configuration that connects viewer-facing delivery with one or more origins. It determines which requests are allowed, where requests are forwarded, which responses may be cached, and which security or transformation rules apply.

A distribution is globally accessible, but its origins can remain in specific AWS Regions or supported external locations.

Distributions, Origins, and Cache Behaviors

The main CloudFront components are:

  • Distribution: The delivery configuration exposed through a CloudFront domain name or custom domain.
  • Origin: The backend providing content, such as S3, an ALB, API Gateway, or a supported custom HTTP server.
  • Cache behavior: A set of path-matching rules controlling origin routing, allowed methods, caching, and request policies.
  • Cache policy: Defines which request values affect caching and controls TTL boundaries.
  • Origin request policy: Controls additional headers, cookies, and query strings forwarded to the origin.
  • Response headers policy: Adds or modifies supported response headers sent to viewers.

Suppose a distribution serves both a website and an API:

https://example.com/assets/*  -> S3 origin
https://example.com/images/*  -> S3 origin
https://example.com/api/*     -> API origin
https://example.com/*         -> Web application origin

Different behaviors can use different cache policies. Static assets may remain cached for months, while authenticated API endpoints may have caching disabled.

CloudFront evaluates ordered cache behaviors according to path matching priority before using the default behavior. A careless path pattern can route sensitive requests to the wrong origin or apply the wrong cache policy.

Cache Hit, Cache Miss, and Origin Requests

When a viewer requests an asset, CloudFront determines whether a usable response exists for the corresponding cache key.

If the response is already cached and fresh, CloudFront serves it as a cache hit. Otherwise, it requests the content from the origin, possibly revalidating an expired cached response.

For example:

  1. A browser requests /assets/app.4f1a9c.js.
  2. CloudFront selects the matching cache behavior and computes the cache key.
  3. CloudFront checks whether an eligible cached response exists.
  4. On a miss, CloudFront retrieves the object from S3.
  5. CloudFront returns the response and may cache it according to policy.
  6. Later requests with the same cache key can reuse the response until expiration or invalidation.

CloudFront also supports request collapsing for eligible simultaneous requests sharing the same cache key. If multiple viewers request one uncached object, CloudFront can reduce redundant requests to the origin while the original fetch is in progress.

Cache behavior can vary across locations and cache layers. Seeing a cache hit in one geographic location does not guarantee that every other location already has that object cached.

Cache Keys and Request Forwarding

A cache key determines which requests are considered equivalent. For example, should these URLs share one cached response?

/products?page=1
/products?page=2

/profile
/profile (with another user's session cookie)

/assets/logo.svg?utm_source=newsletter
/assets/logo.svg?utm_source=social

The first two requests may require different responses. The personalized profile pages must not share a public cache entry. The two logo URLs probably can share one response because the marketing parameter does not affect the image.

CloudFront can include selected headers, cookies, and query strings in the cache key. Each unnecessary variation reduces the likelihood of a cache hit.

For example, forwarding every tracking parameter into the cache key can produce thousands of cache entries representing identical content.

Cache policies and origin request policies must be designed together. The origin may need a header for application logic without that header necessarily needing to distinguish cached objects.

Never cache authenticated responses across users unless the cache key and authorization model explicitly guarantee isolation. For most authenticated APIs, disabling shared response caching is the safer starting point.

CloudFront Caching Strategies

CloudFront cache performance depends on how the application controls freshness. If content is cached too briefly, the origin receives unnecessary traffic. If content is cached too long, users may see outdated content after an update.

A practical cache strategy usually distinguishes immutable assets, mutable documents, public API responses, and private user-specific content.

TTL, Cache-Control, and Revalidation

CloudFront caching policies define minimum, default, and maximum TTL values. Origin response headers such as Cache-Control and Expires also influence how long objects are cached.

For example, a versioned JavaScript bundle can be cached aggressively:

Cache-Control: public, max-age=31536000, immutable

This is appropriate when the URL changes whenever the file content changes.

A mutable HTML document needs a different policy:

Cache-Control: public, max-age=0, must-revalidate

This instructs caches to revalidate before reusing the response, subject to the CloudFront cache policy and HTTP caching behavior. If CloudFront's minimum TTL is greater than zero, it may retain a response for that minimum period even when the origin specifies restrictive caching headers.

For sensitive or personalized content, use private or no-store as appropriate and avoid cache policies that force shared caching despite the application's intent.

Remember that browser caching and CloudFront edge caching are separate layers. A CloudFront invalidation does not force a browser to discard a file already cached locally with a long freshness lifetime.

Invalidation vs. Versioned Assets

CloudFront invalidations remove cached copies of specified paths from the distribution's edge caches. They are useful when an existing URL must serve new content before its normal cache lifetime expires.

For example, after updating a mutable home page, an application might invalidate:

aws cloudfront create-invalidation \
  --distribution-id E1234567890ABC \
  --paths "/index.html" "/"

However, routinely invalidating all static assets after every deployment is usually unnecessary.

A better approach for JavaScript, CSS, and images is to generate content-hashed filenames such as app.a1b2c3.js. Each build produces new URLs for changed content while old URLs remain valid for clients using previous page versions.

Then only the HTML entry point needs a short freshness policy or explicit invalidation. Immutable assets can remain cached for a long time without presenting stale content at an unchanged URL.

Dynamic Content and API Caching

CloudFront can proxy dynamic API requests even when caching is disabled. In that mode, it still provides an HTTPS endpoint, request routing, and supported security integrations.

For a FastAPI application, public catalog endpoints may be cacheable while account and payment endpoints should normally bypass shared caching.

Endpoint Recommended Policy Reason
/assets/app.hash.js Long TTL Immutable versioned content
/images/logo.svg Moderate or long TTL Shared public asset
/api/public/articles Short TTL when safe Shared public response
/api/me No shared caching User-specific response
/api/orders with authentication No shared caching Authorization and changing data

CloudFront also supports caching configured error responses. A backend 404 or 500 may remain visible for a configured interval after the origin has recovered. Review error caching settings when diagnosing unexpectedly stale failures.

Security, Private Origins, and Edge Computing

CloudFront is frequently the public entry point for an application. Its security design must address both viewer access and the separate connection between CloudFront and its origins.

HTTPS on the viewer-facing domain is necessary, but it is not sufficient if users can bypass CloudFront and reach sensitive origin content directly.

Origin Access Control for Private S3

Origin Access Control (OAC) allows CloudFront to send signed requests to a private S3 bucket. The bucket policy grants the CloudFront distribution permission to retrieve specific objects while public S3 access remains blocked.

A secure setup uses:

  • A private S3 general-purpose bucket.
  • S3 Block Public Access enabled.
  • Bucket owner enforced object ownership, where appropriate.
  • CloudFront Origin Access Control with request signing enabled.
  • A bucket policy restricted to the CloudFront distribution ARN.

This is different from using an S3 static website endpoint. An S3 website endpoint must be configured as a custom origin and cannot use OAC in the same manner as the S3 REST endpoint.

OAC is the preferred modern approach for suitable S3 origins; the older Origin Access Identity mechanism has more limitations.

For S3 permissions and object storage design, see What Is Amazon S3?.

Signed URLs and Signed Cookies

CloudFront can restrict viewer access to private content using signed URLs or signed cookies.

A signed URL authorizes a specific resource according to the configured policy and expiration conditions. Signed cookies are useful when a user needs access to multiple protected assets, such as a collection of video segments or downloads.

Do not confuse CloudFront signed URLs with S3 presigned URLs. A CloudFront signed URL authorizes access through CloudFront; an S3 presigned URL authorizes a supported S3 request directly.

For private CloudFront delivery, use trusted key groups and secure private-key management. A valid signature should be only one part of the authorization workflow: the application must decide who is entitled to receive a signed URL or cookie.

Signed access does not prevent an authorized user from copying content after downloading it, and a shared valid signed URL can be used by another person until it expires or is otherwise restricted.

AWS WAF, CloudFront Functions, and Lambda@Edge

CloudFront integrates with AWS WAF to help inspect and block unwanted web requests. Supported controls include managed rule groups, rate-based rules, IP filtering, and application-specific request matching.

CloudFront also supports edge execution through CloudFront Functions and Lambda@Edge.

  • CloudFront Functions: Best for lightweight, latency-sensitive request or response changes such as URL normalization, header manipulation, and simple redirects.
  • Lambda@Edge: Supports more complex request or response processing that may require additional computation, supported libraries, or network access.

CloudFront Functions run with a lightweight JavaScript runtime, while Lambda@Edge uses Lambda functions deployed through the required AWS Region and replicated to edge locations.

For example, a CloudFront Function can redirect an old URL or normalize a request path before CloudFront chooses the relevant cache entry. Lambda@Edge can support more complex origin request transformation and integration patterns.

Edge functions are not replacements for a complete application backend. Keep security-sensitive logic, cache behavior, allowed headers, and function execution stages aligned with documented CloudFront restrictions.

Production Design Example: SaaS Website and API

Consider a SaaS platform that publishes public content, accepts authenticated API requests, and stores user-uploaded images. The application uses FastAPI, PostgreSQL, S3, and a CloudFront distribution.

The system needs globally fast static content delivery while preventing personalized or authenticated responses from entering a shared public cache.

Multi-Origin CloudFront Architecture

A production architecture can use the following components:

  • Route 53: Resolves the application's domain name to CloudFront.
  • CloudFront distribution: Terminates viewer HTTPS, chooses cache behaviors, and forwards requests.
  • Private S3 origin: Stores JavaScript, CSS, images, and other public static assets.
  • Origin Access Control: Restricts S3 object retrieval to authorized CloudFront origin requests.
  • FastAPI origin: Serves rendered pages and dynamic API requests.
  • PostgreSQL: Stores transactional and user-specific data.
  • AWS WAF: Applies supported web security rules.
  • CloudWatch and access logs: Support request-level and distribution-level diagnostics.

The behaviors might route /static/* and /images/* to S3, while /api/* and dynamic HTML pages use the application origin.

Static assets can receive long TTLs with content-hashed filenames. Public HTML can use a shorter TTL, while user-specific endpoints disable shared caching and forward the required authentication information.

For any Lambda, API Gateway, or regional application origin, verify that its endpoint is accessible through a supported CloudFront origin configuration and that the origin cannot be abused through an unintended bypass path.

Failure Scenarios and Cache Safety

Suppose a developer changes a cache behavior so that /api/me is cached using only the URL path, even though responses depend on session cookies.

The first user's profile response could be cached and served to another user. This is a serious authorization and data-isolation failure, not merely a performance bug.

The safe default is to disable shared caching for authenticated responses. Only enable it after designing cache keys and verifying that authorization boundaries cannot be crossed.

A second failure occurs during a frontend deployment. New HTML references app.newhash.js, but the new JavaScript file has not yet been uploaded to S3. CloudFront retrieves a 404, potentially caches the error, and clients fail to load the page.

Deploy versioned static assets before publishing the HTML that references them. Retain old assets long enough to support users with previously cached pages, and monitor asset error rates after release.

This approach avoids relying on a global invalidation to repair every deployment mistake.

Ready-to-Use Example: CloudFront with Private S3

This example creates a private S3 bucket, CloudFront Origin Access Control, an S3 bucket policy granting the distribution read access, and a CloudFront distribution with an HTTPS endpoint.

A Python deployment script generates an HTML page and a content-hashed CSS file, uploads the stylesheet first, and then updates the HTML entry point. This provides a practical static-site deployment workflow using versioned assets.

1. Project Setup

Install Terraform, Python 3, and the AWS CLI. Configure AWS credentials with permissions to create S3 and CloudFront resources and to upload the demonstration files.

Create the following structure:

cloudfront-demo/
  main.tf
  outputs.tf
  requirements.txt
  deploy.py

The example uses the CloudFront-assigned domain name, such as d123456abcdef8.cloudfront.net, so a custom domain and ACM certificate are not required.

CloudFront itself is globally distributed. The S3 origin is created in us-west-2, but viewers access content through the global CloudFront network.

2. Provision S3 and CloudFront with Terraform

Create main.tf:

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "us-west-2"
}

# -------------------------------------
# Private S3 origin
# -------------------------------------

resource "aws_s3_bucket" "site" {
  bucket_prefix = "sysdespro-cloudfront-demo-"

  tags = {
    Environment = "development"
    ManagedBy   = "terraform"
  }
}

resource "aws_s3_bucket_public_access_block" "site" {
  bucket = aws_s3_bucket.site.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_ownership_controls" "site" {
  bucket = aws_s3_bucket.site.id

  rule {
    object_ownership = "BucketOwnerEnforced"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "site" {
  bucket = aws_s3_bucket.site.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

# -------------------------------------
# CloudFront Origin Access Control
# -------------------------------------

resource "aws_cloudfront_origin_access_control" "site" {
  name = "sysdespro-cloudfront-demo-oac"

  description = "Signed access to a private S3 origin"

  origin_access_control_origin_type = "s3"
  signing_behavior                  = "always"
  signing_protocol                  = "sigv4"
}

# -------------------------------------
# Cache policy
# -------------------------------------

resource "aws_cloudfront_cache_policy" "site" {
  name = "sysdespro-demo-origin-cache-control"

  comment = "Honor origin caching headers"

  min_ttl     = 0
  default_ttl = 0
  max_ttl     = 31536000

  parameters_in_cache_key_and_forwarded_to_origin {
    enable_accept_encoding_gzip   = true
    enable_accept_encoding_brotli = true

    headers_config {
      header_behavior = "none"
    }

    cookies_config {
      cookie_behavior = "none"
    }

    query_strings_config {
      query_string_behavior = "none"
    }
  }
}

# -------------------------------------
# CloudFront distribution
# -------------------------------------

resource "aws_cloudfront_distribution" "site" {
  enabled             = true
  is_ipv6_enabled     = true
  default_root_object = "index.html"

  comment = "Private S3 static site"

  origin {
    domain_name = aws_s3_bucket.site.bucket_regional_domain_name
    origin_id   = "private-s3-origin"

    origin_access_control_id = (
      aws_cloudfront_origin_access_control.site.id
    )
  }

  default_cache_behavior {
    target_origin_id = "private-s3-origin"

    viewer_protocol_policy = "redirect-to-https"

    allowed_methods = [
      "GET",
      "HEAD"
    ]

    cached_methods = [
      "GET",
      "HEAD"
    ]

    compress = true

    cache_policy_id = aws_cloudfront_cache_policy.site.id
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }

  tags = {
    Environment = "development"
    ManagedBy   = "terraform"
  }
}

# -------------------------------------
# Allow only this distribution to read
# objects from the private bucket.
# -------------------------------------

data "aws_iam_policy_document" "site" {
  statement {
    sid = "AllowCloudFrontRead"

    actions = [
      "s3:GetObject"
    ]

    resources = [
      "${aws_s3_bucket.site.arn}/*"
    ]

    principals {
      type = "Service"
      identifiers = [
        "cloudfront.amazonaws.com"
      ]
    }

    condition {
      test     = "StringEquals"
      variable = "AWS:SourceArn"

      values = [
        aws_cloudfront_distribution.site.arn
      ]
    }
  }
}

resource "aws_s3_bucket_policy" "site" {
  bucket = aws_s3_bucket.site.id
  policy = data.aws_iam_policy_document.site.json

  depends_on = [
    aws_s3_bucket_public_access_block.site
  ]
}

The bucket is private, and CloudFront signs its origin requests using SigV4. The bucket policy grants s3:GetObject only to the CloudFront service principal when the request originates from the specified distribution ARN.

The custom cache policy has a minimum TTL of zero and honors origin cache headers within its configured maximum TTL. It does not vary caching on viewer cookies, arbitrary headers, or query strings because this demonstration serves only public static files.

Do not reuse that policy unchanged for authenticated APIs, localized content, or files whose representations depend on query parameters.

Create outputs.tf:

output "bucket_name" {
  description = "Private S3 origin bucket."
  value       = aws_s3_bucket.site.id
}

output "distribution_id" {
  description = "CloudFront distribution ID."
  value       = aws_cloudfront_distribution.site.id
}

output "distribution_domain" {
  description = "Public CloudFront hostname."
  value       = aws_cloudfront_distribution.site.domain_name
}

output "site_url" {
  description = "HTTPS URL of the demonstration website."
  value       = "https://${aws_cloudfront_distribution.site.domain_name}"
}

3. Publish Versioned Assets with Python

Create requirements.txt:

boto3

Create deploy.py:

import hashlib
import os

import boto3
from botocore.config import Config


BUCKET = os.environ["S3_BUCKET"]
REGION = os.getenv("AWS_REGION", "us-west-2")

s3 = boto3.client(
    "s3",
    region_name=REGION,
    config=Config(
        retries={
            "mode": "standard",
            "max_attempts": 5,
        }
    ),
)


def build_site() -> tuple[str, bytes, bytes]:
    css = b"""
body {
    font-family: system-ui, sans-serif;
    max-width: 760px;
    margin: 80px auto;
    padding: 0 24px;
    line-height: 1.7;
}
h1 { font-size: 2.5rem; }
p { color: #444; }
"""

    # Create a filename tied to the actual content.
    digest = hashlib.sha256(css).hexdigest()[:12]
    css_key = f"assets/site.{digest}.css"

    html = f"""


    
    
    
    


    Hello from Amazon CloudFront!

This page is stored in a private S3 bucket.

The stylesheet uses a content-hashed filename.




"""

    return css_key, css, html.encode("utf-8")


def upload_object(
    key: str,
    body: bytes,
    content_type: str,
    cache_control: str,
) -> None:
    s3.put_object(
        Bucket=BUCKET,
        Key=key,
        Body=body,
        ContentType=content_type,
        CacheControl=cache_control,
    )

    print(f"Uploaded s3://{BUCKET}/{key}")


def main() -> None:
    css_key, css, html = build_site()

    # Upload immutable assets before publishing HTML.
    upload_object(
        key=css_key,
        body=css,
        content_type="text/css; charset=utf-8",
        cache_control=(
            "public, max-age=31536000, immutable"
        ),
    )

    # HTML can change without changing its URL.
    # Require caches to revalidate before reuse.
    upload_object(
        key="index.html",
        body=html,
        content_type="text/html; charset=utf-8",
        cache_control=(
            "public, max-age=0, must-revalidate"
        ),
    )

    print("Deployment completed")


if __name__ == "__main__":
    main()

The script uploads the CSS file using a content-hashed filename. If its contents change, the hash changes and the application receives a new asset URL.

The HTML document is uploaded last. This ensures the stylesheet is already present before a new page begins referencing it.

Because the HTML uses max-age=0 with revalidation, CloudFront will check freshness according to the configured cache behavior instead of treating the entry point as a long-lived immutable asset.

The example has only two files, but the same deployment principle applies to compiled frontend bundles containing dozens or hundreds of versioned assets.

4. Deploy and Verify Cache Behavior

Provision the infrastructure and upload the generated website:

# Configure AWS credentials beforehand.
export AWS_REGION="us-west-2"

# Initialize Terraform.
terraform init

# Validate and review resources.
terraform fmt
terraform validate
terraform plan

# Create S3 and CloudFront.
terraform apply

# Set runtime variables.
export S3_BUCKET="$(terraform output -raw bucket_name)"
export CF_DOMAIN="$(terraform output -raw distribution_domain)"
export CF_DISTRIBUTION_ID="$(
  terraform output -raw distribution_id
)"

# Prepare Python.
python3 -m venv .venv
source .venv/bin/activate

pip install -r requirements.txt

# Upload assets and HTML.
python deploy.py

# Test viewer HTTPS.
curl -I "https://$CF_DOMAIN/"

# Request the page.
curl -fsS "https://$CF_DOMAIN/"

The first request to an uncached object commonly produces a cache miss. Subsequent requests to the same asset may return a cache hit, depending on the selected edge cache and request conditions.

Inspect headers such as x-cache, age, and cache-control. These help explain whether the response was served from a cache or requested from the origin.

For example, after the first page loads, locate the generated stylesheet path in the HTML and request it repeatedly to observe its caching behavior.

# Show the HTML and locate the versioned CSS URL.
curl -fsS "https://$CF_DOMAIN/" | grep stylesheet

# Inspect a known path copied from the HTML.
# Replace the example hash with the actual generated one.
curl -I \
  "https://$CF_DOMAIN/assets/site.examplehash.css"

# A direct anonymous S3 request should not
# be able to fetch private objects.
aws s3api get-bucket-public-access-block \
  --bucket "$S3_BUCKET"

# Inspect the configured origin access control.
aws cloudfront get-distribution \
  --id "$CF_DISTRIBUTION_ID" \
  --query "Distribution.DistributionConfig.Origins.Items"

The stylesheet URL in the second command is illustrative; use the actual hash printed by the publishing script or shown in the HTML.

CloudFront distribution deployment and global configuration propagation are not instantaneous. Check the distribution's deployment status before diagnosing a newly created or updated configuration as permanently unavailable.

5. Updates, Invalidation, and Cleanup

After changing the CSS or HTML generator, rerun python deploy.py. A changed stylesheet receives a new URL, and the new HTML points to it.

If you must replace content immediately at an existing path, use a targeted invalidation:

# Invalidate the HTML entry point.
aws cloudfront create-invalidation \
  --distribution-id "$CF_DISTRIBUTION_ID" \
  --paths "/" "/index.html"

# Check distribution status.
aws cloudfront get-distribution \
  --id "$CF_DISTRIBUTION_ID" \
  --query "Distribution.Status"

# Clean up disposable S3 objects first.
aws s3 rm "s3://$S3_BUCKET" --recursive

# Remove CloudFront, OAC, bucket, and policies.
terraform destroy

Invalidation is useful for urgent replacement, but it should not be the primary release mechanism for immutable assets. Content-hashed filenames provide clearer deployment boundaries and reduce cache-coordination problems.

CloudFront distribution deletion can involve deployment state changes and may take additional time to complete. Terraform handles the supported resource lifecycle, but an origin bucket must be empty before it can be deleted.

This example creates billable AWS resources. Do not run destructive cleanup against a production origin bucket or distribution.

Performance, Monitoring, and Cost

CloudFront performance is determined by both the global edge network and application-specific caching choices. A distribution with an ineffective cache key can achieve a poor cache hit ratio even while serving a large amount of traffic.

Cost depends on delivery volume, viewer requests, optional security and edge features, and the amount of traffic that still reaches backend systems.

Cache Hit Ratio and Operational Metrics

The cache hit ratio measures how frequently CloudFront can satisfy eligible requests from cached responses. A higher hit ratio often means fewer requests to the origin, although the ideal value depends on the application.

For example, a public image library might reasonably target a high hit ratio, while an authenticated API with caching disabled should not be evaluated using the same expectation.

Useful signals include:

  • Requests: Total viewer request volume.
  • Bytes downloaded: Data delivered to viewers.
  • Cache hit rate: Proportion of eligible requests served from caches.
  • 4xx error rate: Client-side and access-related HTTP failures.
  • 5xx error rate: Origin and delivery failures.
  • Origin latency: Time required to retrieve uncached content.
  • Invalidation volume: Frequency and scope of cache purge operations.
  • WAF activity: Blocked or challenged requests, when WAF is enabled.

CloudFront supports standard logging, real-time logs for supported configurations, and integration with CloudWatch metrics.

When investigating incorrect caching, inspect the cache behavior, cache key, forwarded request attributes, origin response headers, and viewer response headers together. Looking at only the origin's Cache-Control header is often insufficient.

Common Mistakes

Frequent CloudFront mistakes include:

  • Caching authenticated responses with a shared key: Personalized data can leak between users.
  • Forwarding every query parameter: Unnecessary cache variations reduce cache hits.
  • Setting a nonzero minimum TTL for sensitive responses: CloudFront can retain responses despite restrictive origin headers.
  • Leaving the S3 origin public: Users can bypass CloudFront and origin-level security controls.
  • Using an S3 website endpoint with OAC: The origin configuration is incompatible.
  • Using immutable caching with unchanged filenames: Browsers continue using outdated files.
  • Publishing HTML before new assets: Clients request files that are not yet available.
  • Invalidating only CloudFront while ignoring browser caches: Some users still receive stale content.
  • Confusing signed S3 URLs with CloudFront signed URLs: The wrong authorization mechanism is applied.
  • Ignoring error caching: Temporary origin errors remain visible after the origin recovers.
  • Not validating custom origin headers and TLS: CloudFront-to-origin requests fail unexpectedly.
  • Assuming cache hit ratio alone represents application health: Dynamic failures or authorization bugs remain undetected.

Production Checklist

Before using CloudFront for an important application, verify that:

  • Cache behaviors route each path to the intended origin.
  • Private S3 origins use OAC and restrictive bucket policies.
  • Viewer and origin HTTPS requirements are correctly configured.
  • Cache keys include only attributes that change the response.
  • Authenticated endpoints cannot share personalized cached responses.
  • Static assets use versioned filenames and appropriate long TTLs.
  • Mutable HTML uses short freshness or revalidation rules.
  • Origin request policies forward required authentication and application headers.
  • Deployments upload new assets before updating referring HTML.
  • Invalidation and emergency rollback procedures are documented.
  • Origin access bypass risks are reviewed.
  • AWS WAF and response security headers are configured where needed.
  • Cache hit ratio, error rate, latency, and traffic cost are monitored.
  • Infrastructure changes are tested before global distribution updates.

Frequently Asked Questions

CloudFront is both a content delivery network and an HTTP reverse proxy, which is why it can accelerate static files as well as participate in dynamic application architectures.

What Is Amazon CloudFront Used For?

Amazon CloudFront is used to deliver websites, images, videos, APIs, downloads, and other HTTP content through a global edge network. It provides caching, HTTPS delivery, routing, private content access, and supported security integrations.

What Is the Difference Between CloudFront and S3?

Amazon S3 stores objects durably, while CloudFront caches and delivers content to viewers through its global infrastructure.

An S3 bucket can serve as a CloudFront origin. The bucket remains responsible for storing the objects, while CloudFront retrieves them on cache misses and delivers them to users.

Can CloudFront Serve Dynamic APIs?

Yes. CloudFront can forward requests to dynamic origins, including supported application servers, load balancers, and API endpoints.

Caching can be disabled for authenticated or rapidly changing responses while CloudFront continues providing HTTPS routing and supported security features.

How Long Does CloudFront Cache Content?

The duration depends on the cache policy, origin response headers, and applicable error-cache settings. Different cache behaviors can use different TTL policies within the same distribution.

CloudFront invalidations can remove cached paths earlier, but they do not automatically remove copies already stored in users' browser caches.

Can CloudFront Serve Private Content?

Yes. CloudFront supports signed URLs and signed cookies for controlling viewer access. Private S3 origins can also use Origin Access Control so users cannot retrieve protected origin objects directly without authorization.

These mechanisms address different boundaries: signed viewer access restricts who can receive content through CloudFront, while OAC controls CloudFront's access to the S3 origin.

Is Amazon CloudFront Free?

Eligible AWS accounts and workloads may receive Free Tier allowances, credits, or other applicable pricing benefits. Outside those allowances, costs depend on data delivery, requests, and optional features or pricing plans.

Production estimates should include origin costs, invalidation usage, logging, security services, and traffic distribution by geography.

Conclusion

Amazon CloudFront is a globally distributed content delivery and HTTP proxy service that improves content delivery performance, reduces unnecessary origin requests, and provides centralized routing and security capabilities.

It works particularly well with private S3 origins and versioned static assets, but it can also support dynamic APIs, personalized applications, signed content, and multi-origin routing. The key engineering decisions involve cache keys, response freshness, authorization, deployment order, and origin protection.

Production CloudFront deployments should treat caching as an application correctness decision, not merely a performance optimization. A high cache hit ratio is valuable only when cached responses are safe, fresh enough, and delivered to the correct viewers.

Key Takeaway: CloudFront moves content delivery closer to users while reducing traffic to origin infrastructure. Use precise cache policies, private origins, immutable asset versions, and safe handling of dynamic responses to gain performance without compromising security or correctness.

Explore these additional articles for practical guidance on reverse proxies, distributed caching, cloud infrastructure, deployment pipelines, and scalable application delivery.

Author

Oleksandr Andrushchenko

Oleksandr Andrushchenko

Software Engineer & Solution Architect
Nov 03, 2025 6 261
Want more articles like this?

Show your appreciation for Oleksandr Andrushchenko.

Your support helps them keep creating and sharing.

Related articles

Comments (0)