AWS History and Timeline regarding Amazon CloudFront - Overview, Functions, Features, Summary of Updates, and Introduction

First Published:
Last Updated:

Last time, in the article "AWS History and Timeline regarding Amazon S3 - Focusing on the evolution of features, roles, and prices beyond mere storage", I traced the history of Amazon S3 and summarized its current feature list.
This time, I have created a historical timeline for Amazon CloudFront, the AWS global Content Delivery Network (CDN) that has evolved into a programmable edge computing platform spanning hundreds of Points of Presence (PoPs) worldwide.
Like before, I have compiled the major features of Amazon CloudFront, along with additions and updates, into a "Current Overview, Functions, Features of Amazon CloudFront" section near the end of this article.
I hope these will provide clues as to what has remained the same and what has changed in CloudFront, in addition to its current functions and concepts.

Background and Method of Creating Amazon CloudFront Historical Timeline

The reason I created a historical timeline for Amazon CloudFront this time is that CloudFront has been one of the longest-running AWS services - launched in 2008 - and has accumulated a remarkable range of capabilities far beyond a traditional CDN, including edge compute (Lambda@Edge, CloudFront Functions, and CloudFront Connection Functions), a key-value data store at the edge (CloudFront KeyValueStore), origin protection mechanisms (Origin Access Identity (OAI) and Origin Access Control (OAC)), Origin Shield, HTTP/3 over QUIC, gRPC delivery, VPC Origins, Continuous Deployment, Anycast Static IPs, SaaS Manager (multi-tenant distributions), and viewer mTLS.
I wanted to organize the information about Amazon CloudFront with the following approach.
  • Tracking the history of Amazon CloudFront and organizing the transition of updates
  • Summarizing the feature list and characteristics of Amazon CloudFront
This timeline primarily references the following blogs and document history regarding Amazon CloudFront.
There may be slight variations in the dates on the timeline due to differences in the timing of announcements or article postings in the references used.
The content posted is limited to major features related to the current Amazon CloudFront and necessary for the feature list and overview description.
In other words, please note that the items on this timeline are not all updates to Amazon CloudFront features, but are representative updates that I have picked out.

Amazon CloudFront Historical Timeline (Updates from November 18, 2008)

So, from here on, I have a timeline of the features of Amazon CloudFront.
The history of Amazon CloudFront exceeds 17 years at the time of writing this article, and the timeline is quite long, so please scroll faster if necessary.

For convenience, you can jump to a specific year using the year-anchor links below.

Jump to year: 2008 | 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | 2021 | 2022 | 2023 | 2024 | 2025 | 2026

* You can sort the table by clicking on the column name.
Date Summary
2008-11-18 Amazon CloudFront is launched (GA) as a self-service, pay-as-you-go content delivery web service with an initial footprint of 14 Edge Locations (eight in the United States, four in Europe, and two in Asia). At launch, origins must be Amazon S3 buckets, and TLS/SSL is not yet supported.
2009-05-18 CloudFront adds support for streaming distributions using the RTMP protocol for delivering media to Adobe Flash clients. (RTMP distributions were later deprecated; AWS stopped accepting new RTMP distribution creation on December 31, 2020.)
2009-11-11 CloudFront introduces private content, including signed URLs for expiring, restricted access to specific objects and Origin Access Identity (OAI) so that an Amazon S3 bucket can restrict access to a specific CloudFront distribution rather than being publicly readable.
2010-02-26 CloudFront supports HTTPS for the default cloudfront.net domain so that viewers can connect over TLS to the *.cloudfront.net domain.
2010-08-05 CloudFront introduces default root object support, similar to a directory index in a traditional web server.
2010-08-31 CloudFront introduces the invalidation API so that individual files (and, through later updates, wildcard paths) can be evicted from edge caches before their TTL expires.
2010-11-09 CloudFront reaches general availability (GA) with a 99.9% availability SLA and introduces custom origin support, allowing it to serve content from any HTTP server (Amazon EC2, on-premises, or other public origin) in addition to Amazon S3 buckets.
2011-02-15 CloudFront launches a new download distribution feature within the AWS Management Console that simplifies origin and behavior setup.
2011-06-08 CloudFront adds whole-site delivery (dynamic content) by improving cache behaviors, query string forwarding, and lower minimum TTLs, so CloudFront can sit in front of dynamic web applications rather than only static content.
2011-11-29 CloudFront launches Live HTTP Streaming using Adobe Flash Media Server on Amazon EC2, integrating live streaming with the CloudFront edge.
2012-06-11 CloudFront introduces Dedicated IP Custom SSL Certificates so that customers can use their own SSL/TLS certificate with their CloudFront distribution and serve HTTPS content over their own domain name (CNAME).
2012-09-04 CloudFront introduces logging to Amazon S3 at the request level for both download and streaming distributions.
2013-03-13 CloudFront introduces signed cookies in addition to signed URLs to control private content access for multiple objects per session.
2013-10-15 CloudFront introduces support for POST, PUT, DELETE, OPTIONS, and PATCH HTTP methods, completing the set so that CloudFront can be placed in front of REST APIs and web applications, not just static content.
2014-03-05 CloudFront launches Server Name Indication (SNI) Custom SSL at no additional certificate fee, allowing customers to use their own SSL certificate over a shared edge IP. CloudFront also adds an HTTP-to-HTTPS Redirect behavior. References: Amazon CloudFront Adds SNI Custom SSL and HTTP to HTTPS Redirect Features
2014-04-22 CloudFront introduces custom origin and request headers, allowing edge servers to inject specific headers into requests forwarded to the origin.
2014-12-11 CloudFront introduces wildcard alternate domain name (CNAME) support.
2015-01-29 CloudFront introduces AWS CloudTrail integration so that configuration changes to distributions and Origin Access Identities are recorded for audit.
2015-09-29 CloudFront announces integration with AWS Certificate Manager (ACM) so that ACM-issued certificates in us-east-1 can be deployed to CloudFront distributions at no additional cost.
2015-10-06 CloudFront announces integration with AWS WAF at AWS WAF's launch, allowing web ACLs (rate limits, IP block lists, SQL-injection rules, etc.) to be enforced at CloudFront edge locations before a request reaches the origin.
2016-09-06 CloudFront introduces HTTP/2 support for viewer connections, enabling multiplexed requests and header compression for modern clients.
2016-10-06 CloudFront introduces IPv6 support for viewer connections in supported edge locations.
2016-11-29 CloudFront announces Regional Edge Caches, a mid-tier caching layer between Edge Locations and origins that retains less popular objects longer to reduce origin load and tail latency.
2016-11-30 At AWS re:Invent 2016, AWS announces Lambda@Edge in preview, enabling Node.js Lambda functions to be triggered by CloudFront events (viewer request/response and origin request/response) at edge locations.
2017-07-17 Lambda@Edge becomes generally available (GA), supporting Node.js runtimes and the four CloudFront trigger points (viewer-request, viewer-response, origin-request, origin-response) for personalization, A/B testing, header rewriting, and bot mitigation. References: Lambda@Edge now Generally Available
2017-12-14 CloudFront introduces Field-Level Encryption, allowing sensitive HTTP form fields (such as credit card numbers) to be encrypted at the edge with a public key before being forwarded to the origin, where only a designated origin component can decrypt them with the corresponding private key.
2018-07-25 Lambda@Edge adds support for dynamic origin selection at the origin-request trigger, allowing a Lambda function to programmatically rewrite the target origin per request (for example, to swap between Amazon S3 and custom origins based on request attributes).
2018-11-20 CloudFront introduces Origin Failover so that a distribution can use an origin group with primary and secondary origins, automatically failing over on configurable HTTP status codes.
2019-05-15 CloudFront introduces security policies up to TLSv1.2_2019, raising the bar for cipher suites and protocol versions usable for viewer connections.
2019-11-05 CloudFront introduces real-time logs (preview), delivering access log records to Amazon Kinesis Data Streams within seconds for near real-time observability.
2020-02-27 Lambda@Edge adds support for the Node.js 12 and Python 3.8 runtimes in addition to existing Node.js runtimes, broadening the set of edge-compatible languages.
2020-07-22 CloudFront introduces Cache Policy and Origin Request Policy as separate, reusable resources, externalizing what used to be inline per-behavior settings so that a single policy can be referenced from multiple distributions and managed by Infrastructure as Code.
2020-08-31 CloudFront real-time logs become generally available, with per-cache-behavior configuration, sampling rate, and selectable fields.
2020-09-14 CloudFront announces Brotli compression support as an automatic, on-the-fly compression option in addition to gzip, reducing payload sizes for compatible browsers.
2020-10-20 CloudFront launches Origin Shield, a centralized caching layer in a single AWS Region that consolidates cache fills across all Regional Edge Caches to increase cache hit ratio and reduce origin load. References: Announcing Amazon CloudFront Origin Shield
2021-05-03 CloudFront Functions becomes generally available (GA) as lightweight JavaScript at every edge location, with sub-millisecond runtime, a process-based isolation model, no network or file system access, and triggers at viewer-request and viewer-response. Designed for high-scale URL rewrites, header manipulation, and cache-key normalization. References: Amazon CloudFront announces CloudFront Functions
2021-11-03 CloudFront Functions adds the builtin Crypto module subset (HMAC-SHA256, SHA-256 hashing, base64 encoding) so that token validation patterns (HMAC tokens, lightweight signed cookies) can be implemented without external libraries.
2022-08-15 CloudFront announces HTTP/3 (over QUIC) support for viewer connections in all edge locations at no additional cost, using the open-source Rust QUIC implementation s2n-quic. HTTP/3 requires viewer support for TLSv1.3 and SNI. References: Amazon CloudFront now supports HTTP/3 powered by QUIC
2022-08-25 CloudFront launches Origin Access Control (OAC), the successor to Origin Access Identity (OAI). OAC uses AWS Signature Version 4 (SigV4) to sign requests to S3 origins, supports SSE-KMS-encrypted buckets, supports all HTTP methods (GET, PUT, POST, PATCH, DELETE, OPTIONS, HEAD), and works in all current and future AWS Regions. References: Amazon CloudFront launches Origin Access Control (OAC)
2022-11-21 CloudFront launches Continuous Deployment, allowing a staging distribution to receive a percentage of live traffic (weight-based up to 15%) or header-based requests so that distribution configuration changes can be validated before full cutover. References: Amazon CloudFront launches continuous deployment support
2023-01-12 Lambda@Edge expands runtime support to Node.js 18.x, allowing edge functions to take advantage of newer JavaScript language features and improved fetch APIs.
2023-02-08 Origin Access Control (OAC) expands to support AWS Elemental MediaStore container origins, eliminating the need for shared-secret-based access control between CloudFront and MediaStore.
2023-11-21 CloudFront KeyValueStore (KVS) becomes generally available as a globally managed, low-latency key-value datastore that CloudFront Functions can read from within a function invocation, decoupling configuration data (such as redirect maps, feature flags, and A/B-test assignments) from function code. Initial limits: 5 MB per store, 1 store per function, 512-byte keys, 1 KB values. References: Introducing Amazon CloudFront KeyValueStore
2024-04-11 Origin Access Control (OAC) expands to support AWS Lambda Function URL origins and AWS Elemental MediaPackage v2 origins, allowing CloudFront to securely sign requests to these origins via AWS Signature Version 4 (SigV4) the same way it does for Amazon S3 origins. References: Amazon CloudFront now supports Origin Access Control (OAC) for Lambda function URL origins
2024-04-30 CloudFront Functions adds a new JavaScript runtime (cloudfront-js-2.0) with ECMAScript 2022 (ES13) features, additional CryptoSubtle APIs, and KVS read APIs.
2024-09-12 CloudFront announces embedded Points of Presence within Internet Service Provider (ISP) networks, expanding the global delivery footprint closer to end users than traditional edge locations.
2024-11-20 CloudFront launches VPC Origins, allowing Application Load Balancers (ALB), Network Load Balancers (NLB), and Amazon EC2 instances in private subnets to be used as CloudFront origins without requiring a public IP. References: Amazon CloudFront announces VPC origins
2024-11-20 CloudFront announces Anycast Static IPs, a dedicated list of 21 IPv4 addresses that serve traffic for a customer's CloudFront distributions across all edge locations. Initially designed for zero-rating agreements with telecom carriers and B2B applications that need to allow-list CDN egress IPs in outbound firewall rules. References: Amazon CloudFront now supports Anycast Static IPs
2024-11-21 CloudFront announces gRPC delivery support, so CloudFront can sit in front of gRPC application origins and pass through gRPC (over HTTP/2) requests to those origins, benefiting from edge TLS termination, AWS WAF protection, and AWS Shield Standard. References: Amazon CloudFront now supports gRPC delivery
2025-04-23 CloudFront announces VPC Origin modification with CloudFront Functions, allowing CloudFront Functions to dynamically choose or rewrite the target VPC origin per request. References: Amazon CloudFront supports VPC Origin modification with CloudFront Functions
2025-04-28 CloudFront launches SaaS Manager and multi-tenant distributions, a new distribution type that lets SaaS providers and web hosting platforms manage delivery for many tenant domains under a single, reusable configuration with per-tenant overrides (AWS WAF web ACL, TLS certificate, geographic restrictions). Includes connection groups, parameter-based per-tenant customization, automated AWS Certificate Manager (ACM) integration, and helper methods for CloudFront Functions to read tenant-specific parameters at the edge. References: Announcing SaaS Manager for Amazon CloudFront
2025-11-20 CloudFront Functions adds three new capabilities: edge location and Regional Edge Cache (REC) metadata exposed to the function context, raw (unparsed) query string retrieval, and advanced origin overrides, expanding the routing and observability decisions that can be made entirely inside a CloudFront Function. References: Amazon CloudFront announces 3 new CloudFront Functions capabilities
2025-11-24 CloudFront introduces viewer mTLS support and CloudFront Connection Functions. Viewer mTLS lets a distribution authenticate viewer client certificates against a managed trust store; Connection Functions are a specialized type of CloudFront Function that run during the TLS handshake and can validate certificate attributes, implement custom revocation checking (via CloudFront KeyValueStore), and apply IP-based or tenant-specific certificate policies.
2026-04-02 Amazon CloudWatch adds automatic enablement of CloudFront standard access logs to CloudWatch Logs, with organization-wide rules to ensure consistent telemetry across accounts. References: Amazon CloudWatch expands auto-enablement to Amazon CloudFront logs
2026-04-29 CloudFront launches invalidation by cache tag, letting customers attach comma-separated cache tags to responses via a configurable header and invalidate groups of related objects with a single request. Invalidations propagate under 5 seconds at P95. References: Amazon CloudFront now supports invalidation by cache tag
2026-05-01 CloudFront announces WebSocket support for VPC Origins, allowing real-time WebSocket applications hosted entirely on ALB/NLB/EC2 in private subnets to be exposed via CloudFront as the single secure front door. References: Amazon CloudFront Announces WebSocket Support for VPC Origins

Looking back at this timeline, CloudFront started in 2008 as a simple, Amazon S3-only static content delivery network and has since evolved into a programmable security and edge computing platform with multiple distinct compute models (CloudFront Functions, CloudFront Connection Functions, Lambda@Edge, and origin-side AWS Lambda), a globally-replicated key-value store (CloudFront KeyValueStore), an explicit private-network origin path (VPC Origins), a dedicated-IP option for allow-list-sensitive workloads (Anycast Static IPs), a multi-tenant distribution model for SaaS platforms (SaaS Manager), integrated AWS WAF and AWS Shield protection at the edge, and unified delivery for HTTP/1.1, HTTP/2, HTTP/3, gRPC, and WebSocket traffic.
The most consequential turning points are arguably (1) the 2014 SNI Custom SSL launch (making HTTPS practical without a per-distribution dedicated-IP fee), (2) the 2017 Lambda@Edge GA (CloudFront becomes programmable), (3) the 2021 CloudFront Functions GA combined with the 2023 CloudFront KeyValueStore GA (a second, cheaper edge compute model with a managed data plane), (4) the 2024 VPC Origins combined with the 2026 WebSocket-for-VPC-Origins update (CloudFront becomes the front door for private-subnet web applications), and (5) the 2025 SaaS Manager and viewer-mTLS / Connection Functions launches (CloudFront becomes a true multi-tenant SaaS edge platform with handshake-time custom authentication).
In this way, Amazon CloudFront is no longer just a CDN: it is the AWS-managed edge security and tenancy perimeter for modern web applications.

Current Overview, Functions, Features of Amazon CloudFront

From here, I will introduce the current list and overview of Amazon CloudFront features at the time of writing this article.
The functions of Amazon CloudFront can be broadly divided into content delivery (caching and origin connectivity), security (TLS / AWS WAF / OAC / signed URLs / Field-Level Encryption), edge compute (CloudFront Functions / Lambda@Edge / CloudFront KeyValueStore), and operations (real-time logs, continuous deployment, invalidation, monitoring).
Among these, edge compute (CloudFront Functions, Lambda@Edge, and the CloudFront KeyValueStore) is the area where CloudFront has changed most rapidly in the last several years - to the point that calling CloudFront "just a CDN" understates its current capability.

Distributions and Cache Behaviors

A CloudFront distribution is the top-level resource that customers create. Each distribution has a default cache behavior plus zero or more additional cache behaviors matched by path pattern. Cache behaviors control which origin is contacted, which HTTP methods are forwarded, whether query strings or headers are part of the cache key, whether CloudFront Functions or Lambda@Edge are associated with the four trigger points, whether an AWS WAF web ACL is attached, and which TLS policy is used.

This separation between "distribution-wide settings" (such as the default certificate, supported HTTP versions, price class, and WAF web ACL) and "per-behavior settings" (such as origin, methods, caching policy, and edge functions) is what allows a single CloudFront distribution to act both as a static site CDN and as a programmable API gateway in front of an Application Load Balancer or an AWS Lambda Function URL.

Cache Policies, Origin Request Policies, and Response Headers Policies

Per-behavior settings are externalized into three reusable policy resources rather than living only inside a distribution's JSON.
  • Cache policy defines what goes into the cache key (specific query strings, specific headers, specific cookies, or none of them), plus the default / minimum / maximum TTL values and whether gzip/Brotli compression is enabled. AWS provides several managed cache policies (such as Managed-CachingOptimized, Managed-CachingDisabled, Managed-CachingOptimizedForUncompressedObjects, Managed-Elemental-MediaPackage) that cover most static and streaming workloads without writing a custom policy.
  • Origin request policy defines which query strings, headers, and cookies are forwarded to the origin regardless of the cache key. This decoupling lets a distribution forward, for example, an Authorization header to the origin for personalization without making that header part of the cache key and thereby fragmenting the cache.
  • Response headers policy defines a set of HTTP response headers that CloudFront adds, overrides, or removes before sending the response to the viewer. Common usages include adding security headers (Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy), CORS headers, and custom headers for downstream analytics. Several managed response headers policies are available, including Managed-SecurityHeadersPolicy and Managed-CORS-With-Preflight.
Externalizing these as policies has two practical benefits. First, a single policy can be referenced by multiple distributions, so a change is rolled out everywhere by updating one resource. Second, this is the model that infrastructure-as-code tools (AWS CloudFormation, AWS CDK, Terraform) operate on; distribution definitions become smaller and version-controllable.

Origins: Amazon S3, VPC Origins, ALB, NLB, EC2, MediaPackage, MediaStore, Lambda Function URLs, and Custom Origins

CloudFront can fetch content from a wide range of origin types.
  • Amazon S3 origins - including private buckets protected by Origin Access Control (OAC), the recommended pattern since 2022.
  • VPC Origins (since 2024-11-20) - Application Load Balancers, Network Load Balancers, and Amazon EC2 instances in private subnets, without a public IP. As of 2026-05-01, VPC Origins also accepts WebSocket traffic.
  • AWS Elemental MediaPackage and MediaStore - for live and on-demand streaming workloads.
  • AWS Lambda Function URLs - supported by Origin Access Control since 2024-04-11.
  • Custom HTTP/HTTPS origins - any publicly reachable web server, including non-AWS endpoints.

Each origin can be a member of an origin group, enabling automatic failover between a primary and one or more secondary origins based on configurable status codes (such as 5xx errors), which is the foundation of multi-region active-active and active-passive web architectures.

For SaaS workloads where a single distribution configuration must front many tenant domains (and where each tenant may need a different TLS certificate, WAF web ACL, or origin path prefix), CloudFront also supports multi-tenant distributions via SaaS Manager (since 2025-04-28); see the dedicated section below.

Origin Failover Behavior in Detail

The origin group resource defines a primary origin, a secondary origin, and a failover criteria list. The failover criteria list is a set of HTTP status codes - typically 500, 502, 503, 504, and 404 - on which CloudFront will retry the request against the secondary origin instead of returning the failure to the viewer.

Two operational nuances are worth remembering. First, only idempotent request methods (GET, HEAD, OPTIONS) trigger origin failover; CloudFront will not retry a POST, PUT, PATCH, or DELETE against a secondary origin, because doing so could cause duplicate side effects. Second, the failover decision is per-request, not per-distribution, so a distribution can serve some viewers from the primary origin and others from the secondary origin at the same time. Combined with Amazon Route 53 latency-based or health-checked DNS routing, origin failover is a building block for multi-region active-active web architectures where the regional failover is opaque to the viewer.

A common pattern is to combine an origin group with Lambda@Edge at the origin-request trigger point so that the Lambda function rewrites the request URI or headers based on the chosen origin (for example, to handle a different bucket prefix in the secondary Amazon S3 origin).
For private Amazon S3 origins, CloudFront has supported two generations of origin protection.
  • Origin Access Identity (OAI) - the original 2009 mechanism using a CloudFront-managed identity in the Amazon S3 bucket policy.
  • Origin Access Control (OAC) - the 2022 successor that signs requests using AWS Signature Version 4 (SigV4), supports SSE-KMS-encrypted buckets, supports all HTTP methods (GET, PUT, POST, PATCH, DELETE, OPTIONS, HEAD), and is available in all current and future AWS Regions (OAI is limited to AWS Regions launched on or before December 2022).
Origin Access Control (OAC) is the recommended mechanism for all new deployments. Existing OAI-based distributions continue to function and can be migrated to OAC in-place. For a worked example of an OAC-based CloudFront + Amazon S3 + Route 53 + ACM setup, see "Indie Dev Guide: From Domain Acquisition to Live Site with AWS Route 53, S3, CloudFront, and ACM" on this site. For an OAI-based CloudFormation template that covers Lambda@Edge and AWS WAF as well, see "AWS CloudFormation Templates and AWS Lambda Custom Resources for Associating AWS Certificate Manager, Lambda@Edge, and AWS WAF with a Website on Amazon S3 and Amazon CloudFront Cross-Region".

Security: ACM, AWS WAF, AWS Shield, Signed URLs/Cookies, Field-Level Encryption, mTLS

CloudFront integrates with multiple AWS security services.
  • AWS Certificate Manager (ACM) in us-east-1 provides free public TLS certificates for CloudFront distributions (since 2015).
  • AWS WAF web ACLs can be attached to a distribution to apply managed rule groups, custom rules, rate-based rules, and bot/CAPTCHA controls at the edge.
  • AWS Shield Standard is included by default; AWS Shield Advanced can be enabled for enhanced DDoS protection and the Shield Response Team.
  • Signed URLs and signed cookies enable expiring, time-bound private content access at the object or session level.
  • Field-Level Encryption (since 2017) encrypts specific HTTP form fields at the edge using a public key, decryptable only by the designated origin component.
  • Mutual TLS (mTLS) for viewer connections (since 2025-11-24) lets CloudFront authenticate the viewer's client certificate against a managed trust store, and optionally run a CloudFront Connection Function during the TLS handshake to implement custom validation logic.

Mutual TLS (mTLS) Operational Patterns

Mutual TLS authentication on a CloudFront distribution lets the edge reject any viewer that does not present a client certificate signed by a trust store the distribution owns. The trust store is typically managed in AWS Private Certificate Authority or an external CA. Since 2025-11-24, customers can attach a CloudFront Connection Function to a distribution to extend the handshake-time validation logic beyond simple "is the certificate signed by a trusted CA" - for example, to enforce that a specific Subject Alternative Name is present, to look up the certificate serial number in a KVS-backed revocation list, or to vary the accepted CA set by client IP or distribution tenant. This is most useful in the following patterns.
  • B2B API gateway - the distribution sits in front of an Application Load Balancer or AWS Lambda Function URL and accepts only requests from partner services that have been issued a client certificate. Combined with VPC Origins, the origin is also isolated from the public internet, so mTLS becomes the actual authentication mechanism for the entire ingress path.
  • Device-to-cloud ingestion - fleets of IoT devices, kiosks, or POS terminals use a per-device client certificate (often provisioned via AWS IoT Core or a private CA). The edge rejects unknown devices before any compute is spent in the origin.
  • Internal-only application exposure - an enterprise places its internal applications behind CloudFront with mTLS so that only managed corporate endpoints (which carry a managed client certificate) can reach the application, replacing legacy VPN or ZTNA gateways for HTTP workloads.
Revoked certificates can be removed by updating the trust store CRL/OCSP configuration or by adding the serial number to a KVS-backed revocation list that a Connection Function consults during the handshake. Because mTLS verification happens at the edge, an attacker who lacks a valid client certificate cannot exhaust origin compute even under DDoS-style load.

CloudFront exposes several distinct edge compute capabilities, each at a different trigger point with different runtime characteristics. The mapping of trigger points to compute capabilities and runtime constraints is summarized in the following diagram.

Amazon CloudFront Edge Computing Stack
Amazon CloudFront Edge Computing Stack

CloudFront Functions

CloudFront Functions runs JavaScript at all CloudFront edge locations using a process-based isolation model designed for very high request rates and sub-millisecond runtime. It is triggered at viewer-request and viewer-response, has a hard runtime cap on the order of 1 millisecond, a code size limit on the order of 10 KB, and no network or file system access. Typical use cases include header manipulation, URL rewrites and redirects, cache-key normalization, lightweight authorization (such as HMAC or JWT validation), and A/B test cohort assignment.

For implementation patterns including A/B testing, geo routing, feature flags, and token validation, see "CloudFront KeyValueStore and Edge Functions Cookbook: A/B Testing, Geo Routing, Feature Flags, and Token Validation" on this site.

Lambda@Edge

Lambda@Edge runs full Node.js or Python AWS Lambda functions at a CloudFront Regional Edge Cache (not at every edge location) using the standard AWS Lambda execution model. It is triggered at all four CloudFront trigger points (viewer-request, viewer-response, origin-request, origin-response) and supports network access, much larger code, and runtimes up to 5 seconds for viewer triggers and 30 seconds for origin triggers. Typical use cases include heavy origin rewriting, server-side rendering, request enrichment from external APIs, image transformations, and bot mitigation logic that needs network reachability.

For an end-to-end CloudFormation example that combines Lambda@Edge, AWS Certificate Manager, AWS WAF, Amazon S3, and Amazon CloudFront cross-region, see "AWS CloudFormation Templates and AWS Lambda Custom Resources for Associating AWS Certificate Manager, Lambda@Edge, and AWS WAF with a Website on Amazon S3 and Amazon CloudFront Cross-Region". For the AWS Lambda side of the story, see "AWS History and Timeline regarding AWS Lambda - Overview, Functions, Features, Summary of Updates, and Introduction".

CloudFront KeyValueStore (KVS)

CloudFront KeyValueStore (KVS) is a globally managed, eventually-consistent key-value datastore that CloudFront Functions can read inside a function invocation. KVS exists to decouple configuration data from function code, so that updating a redirect map, feature flag, or A/B-test assignment does not require redeploying the function code. KVS is read-from-Function, write-from-public-API, and requires the cloudfront-js-2.0 runtime to be associated with the function. The current default quotas are 5 MB per individual key value store, 512 bytes per key, 1 KB per value, 1 store per function, up to 10 functions per store, and 50 stores per AWS account (the account-level limit is adjustable via Service Quotas). Compared to the launch-day limits, the most significant evolution is that a single store can now be shared across up to 10 functions, which simplifies the deployment of large CloudFront Functions estates where many functions need to read from a common dataset.

CloudFront Connection Functions

CloudFront Connection Functions (since 2025-11-24) are a specialized form of CloudFront Functions that run during the TLS handshake, not after an HTTP request has been parsed. They were introduced together with viewer mTLS GA so that customers can implement custom validation as part of the mTLS handshake itself. A Connection Function receives the client certificate, the mTLS configuration parameters, certificate revocation check results, and the client IP address, and returns a decision to allow, deny, or log the connection. Connection Functions share the same JavaScript runtime characteristics as standard CloudFront Functions (sub-millisecond runtime, 10 KB code size, 2 MB memory, no network access) and can read from CloudFront KeyValueStore inside the function, which makes them well suited to:
  • Certificate attribute validation - require specific Subject Alternative Name patterns, organizational units, or issuing CAs.
  • Custom certificate revocation - look up the certificate serial number in a KVS-backed revocation list rather than relying solely on CRL/OCSP.
  • IP-based or tenant-based certificate policies - apply different validation rules depending on client IP or distribution tenant.
Because Connection Functions reject unauthorized clients before any HTTP request is parsed, they reduce edge compute spent on doomed requests and provide a stronger DDoS shield in front of an mTLS-protected origin.

Caching Layers: Edge Locations, Regional Edge Caches, and Origin Shield

CloudFront has multiple physical caching layers between the viewer and the origin.
  1. Edge Locations (Points of Presence, PoPs) - the outermost layer, closest to the viewer.
  2. Regional Edge Caches - an intermediate caching layer (introduced 2016) that retains less popular objects longer, reducing tail latency for cache misses.
  3. Origin Shield - an optional centralized caching layer in a single AWS Region (introduced 2020) that consolidates cache fills across all Regional Edge Caches so that only one request per object reaches the origin.
For high-cardinality content or multi-CDN architectures, Origin Shield is especially effective at increasing the cache hit ratio and reducing origin operating cost.

Performance: Compression, HTTP Versions, gRPC, WebSocket

CloudFront supports a stack of viewer-facing protocols.
  • HTTP/1.1, HTTP/2 (since 2016), and HTTP/3 over QUIC (since 2022-08).
  • TLSv1.0 through TLSv1.3 with selectable security policies.
  • gzip and Brotli automatic on-the-fly compression for compatible Content-Type values and viewer Accept-Encoding values.
  • gRPC delivery (since 2024-11) for gRPC-over-HTTP/2 application origins.
  • WebSocket for persistent bidirectional connections, extended in 2026-05 to support VPC Origins.

IP Allocation: Default Rotating IPs vs Anycast Static IPs

By default, CloudFront serves traffic from a large pool of rotating IP addresses at each edge location, which is appropriate for the vast majority of public web workloads. For workloads that need predictable, allow-list-friendly source IPs, CloudFront also supports Anycast Static IPs (since 2024-11-20). When a distribution subscribes to an Anycast IP list, it is assigned a dedicated set of 21 IPv4 addresses that serve the customer's traffic from every CloudFront edge location worldwide. The two primary use cases are:
  • Zero-rating with telecom carriers - mobile carriers can exempt data delivered from a known set of CDN IPs from end-user data plan charges.
  • B2B allow-listing - enterprise customers whose outbound firewalls allow-list partner CDN IP ranges (a common but operationally fragile pattern) can be served stable IPs that do not change for the life of the distribution / Anycast IP list subscription.

For an end-to-end performance optimization checklist that includes CloudFront-side knobs (HTTP/3, Brotli, cache TTL, Early Hints), see "Web Performance Checklist for Core Web Vitals on AWS".

Observability and Operations

CloudFront provides multiple observability surfaces.
  • Standard access logs delivered to Amazon S3 (and, since 2026-04, automatically enabled to Amazon CloudWatch Logs with organization-wide enablement rules).
  • Real-time logs delivered to Amazon Kinesis Data Streams within seconds, configurable per cache behavior.
  • Amazon CloudWatch metrics for requests, errors, bytes, and cache hit ratio per distribution.
  • AWS CloudTrail for distribution and OAC/OAI configuration changes.
  • Invalidations, including invalidation by cache tag (since 2026-04), which lets customers attach Cache-Tag-style headers to responses and evict groups of related objects in one request.

Real-time Logs and Amazon Kinesis Integration

Real-time logs are configured per cache behavior on a distribution and let customers choose which subset of the access log record they want to stream, at what sampling rate, and into which Amazon Kinesis Data Stream.
  • Field selection - customers pick from a fixed set of fields including request method (cs-method), response status code (sc-status), URI stem and query (cs-uri-stem, cs-uri-query), edge result type (x-edge-result-type), TLS protocol, viewer country, and many more. Selecting only the fields a downstream consumer actually uses reduces both stream cost and downstream processing cost.
  • Sampling rate - any integer from 1 to 100 (percent) lets customers trade observability fidelity for cost. A 100% sample is appropriate for security-sensitive traffic; lower sample rates are fine for capacity planning and trend analysis.
  • Downstream consumers - the most common consumption patterns are: (1) Amazon Kinesis Data Streams → AWS Lambda for alerting and per-request enforcement, (2) Amazon Kinesis Data Streams → Amazon Data Firehose → Amazon S3 for long-term archive and Amazon Athena queries, and (3) Amazon Kinesis Data Streams → Amazon Data Firehose → Amazon OpenSearch Service for interactive dashboards.
The relationship between standard access logs and real-time logs is important to understand. Standard logs are batch-delivered to Amazon S3 (and, since 2026-04, automatically enabled to Amazon CloudWatch Logs); they have a higher per-record latency (minutes to tens of minutes) but include every request and are the canonical record for long-term storage. Real-time logs are stream-delivered to Amazon Kinesis Data Streams within seconds; they are the right choice for security alerting, on-the-fly business metrics, and any workload where "minutes ago" is too stale to act on.

The 2026-04 update that automatically enables CloudFront standard access logs to Amazon CloudWatch Logs with organization-wide rules is operationally significant for large enterprises, because it removes the requirement to per-account configure log destinations - a central security team can ensure that every CloudFront distribution in every member account in an AWS Organizations is logging to a known CloudWatch destination without touching each distribution individually.

Continuous Deployment

CloudFront Continuous Deployment (since 2022-11) allows a distribution configuration change to be staged on a parallel distribution that receives either a weighted percentage of live traffic (up to 15%) or a header-selected subset of traffic. This makes safe canary and blue/green deployment patterns feasible without bespoke DNS or origin-side traffic-splitting infrastructure.

SaaS Manager and Multi-Tenant Distributions

CloudFront SaaS Manager (since 2025-04-28) introduces a new distribution type called a multi-tenant distribution, designed for SaaS providers and web hosting platforms that need to deliver content for many tenant domains (often thousands or millions of subdomains and vanity domains) under a single, reusable configuration. The model consists of three resources:
  • Multi-tenant distribution - the shared template that defines origins, cache behaviors, security policies, and default settings.
  • Distribution tenants - per-tenant entities that inherit the multi-tenant distribution's configuration and can override specific settings (AWS WAF web ACL, TLS certificate, geographic restrictions) plus supply tenant-specific parameter values for origin paths, hostnames, or other placeholders.
  • Connection groups - the routing endpoint that serves content to viewers. A connection group can be shared across multiple tenants and controls IPv6 and Anycast IP list settings for those tenants.

The most significant operational benefits relative to managing one standard distribution per tenant are: automated AWS Certificate Manager (ACM) integration for per-tenant certificate provisioning and renewal, parameter-based customization that eliminates redundant configuration, and helper methods inside CloudFront Functions that let a function read the requesting tenant's parameter values at the edge - so that data-driven tenant routing (by hostname, JWT claim, or cookie) can be implemented entirely in a sub-millisecond function rather than at the origin.

Multi-tenant distributions and standard distributions coexist; the choice is per workload. For a small handful of customer domains, a standard distribution per tenant remains simpler. For a true SaaS platform pattern (10s to 1,000,000s of tenants, frequent tenant onboarding/offboarding, central security policy enforcement), multi-tenant distributions remove the per-tenant infrastructure ceiling that was the historical scaling pain point of CloudFront for SaaS use cases.

Comparison: CloudFront Functions vs. Lambda@Edge vs. Origin Lambda

A frequent design question is "which AWS Lambda execution model should I use at the edge or origin layer?" The following table compares the three options side by side.

* You can sort the table by clicking on the column name.
Dimension CloudFront Functions Lambda@Edge Origin Lambda (e.g., Lambda Function URL or behind ALB)
Trigger points viewer-request, viewer-response viewer-request, viewer-response, origin-request, origin-response Synchronous request to the origin (after CloudFront cache miss)
Runtime language JavaScript (ECMAScript subset; cloudfront-js-1.0 or cloudfront-js-2.0) Node.js (multiple versions), Python (multiple versions) All AWS Lambda-supported runtimes (Node.js, Python, Java, .NET, Go, Ruby, custom)
Maximum execution time ~1 ms 5 s (viewer triggers), 30 s (origin triggers) 15 minutes
Code size limit 10 KB 1 MB (viewer triggers), 50 MB (origin triggers, deployment package) 250 MB unzipped (10 GB container image)
Memory 2 MB (fixed) 128 MB (viewer triggers), up to 10,240 MB (origin triggers) Up to 10,240 MB
Network access from the function No (no HTTP, no socket, no file system) Yes (origin triggers can make outbound HTTP calls) Yes (full VPC access, public internet, AWS service APIs)
Where it runs Every CloudFront Edge Location (PoP) CloudFront Regional Edge Cache (not every PoP) Origin AWS Region
Cold start Sub-millisecond (no VM cold start, process-based isolation) Lambda-class cold start (tens to hundreds of milliseconds on first invocation in a region) Lambda-class cold start (cacheable via Provisioned Concurrency)
Pricing model Per million invocations (lowest-cost option per request) Per request + per GB-second of compute (higher per-request cost than CloudFront Functions) Standard AWS Lambda pricing (per request + per GB-second)
Access to CloudFront KeyValueStore Yes (read-only inside function) No No (use Amazon DynamoDB or other data stores)
Typical use cases URL rewrites, header manipulation, cache-key normalization, lightweight token validation (HMAC, JWT signature verification), A/B test cohort assignment, geo-based redirects Image resizing, server-side rendering, request enrichment via external API, response transformation, complex bot mitigation, dynamic origin selection Full application business logic, database access, third-party integrations, long-running computation, anything requiring more than ~30 s or more than ~50 MB of code

How to choose: the decision is usually a layered one rather than a binary one. The recommended rule of thumb is: "push the work as far to the edge as the runtime constraints allow, but not further."
  • If the work can be expressed in JavaScript, fits in 10 KB, and finishes in ~1 ms (typical for URL rewrites, header manipulation, cache-key normalization, simple authorization), use CloudFront Functions. It runs at every edge location, has no cold start, and is the cheapest per request.
  • If the work needs network access (to call an external API, look up data in a database, or fetch from another origin) or needs a bigger runtime (image resizing, complex authentication flows, server-side rendering), use Lambda@Edge. It is slower and more expensive per request than CloudFront Functions, but runs at Regional Edge Caches so it is still much closer to the viewer than the origin Region.
  • If the work is the actual business logic of the application - reading and writing the database, calling internal services, returning the dynamic content - use a normal origin Lambda (or any other origin) in your origin AWS Region. CloudFront sits in front and adds caching, TLS termination, AWS WAF, and DDoS protection.
The three layers are designed to compose. A common production pattern is: CloudFront Functions at viewer-request to normalize the cache key and reject obviously malformed requests; Lambda@Edge at origin-request to resize an image to the viewer-requested dimensions or to choose between multiple origins based on geo or feature-flag (read from CloudFront KeyValueStore); and a regular AWS Lambda Function URL behind Origin Access Control as the origin that runs the application's business logic. Each layer does only what it must, and the response is cached aggressively at the CloudFront edge so that subsequent requests for the same input never re-enter the lower layers.

Pricing Models

CloudFront offers two pricing models at the time of writing this article.
  • The traditional pay-as-you-go model billed per request and per gigabyte transferred, with separate line items for HTTPS requests, real-time logs, and edge compute invocations.
  • Flat-rate pricing plans that bundle a predictable monthly allowance with inclusions for selected features. For the current list of included features and any recent additions, refer to the AWS CloudFront pricing page.
For up-to-date pricing, please consult the AWS CloudFront pricing page directly (Amazon CloudFront pricing). This article does not include specific price numbers because public pricing for CloudFront has changed many times and any number quoted here would risk being stale.

Frequently Asked Questions about Amazon CloudFront

This section directly answers the most commonly asked time-based questions about Amazon CloudFront, formatted so that AI search agents and Reference Aggregation consumers can extract them as standalone Q&A units.

When did Amazon CloudFront launch?

Amazon CloudFront was launched (became generally available) on November 18, 2008, with an initial footprint of 14 Edge Locations (eight in the United States, four in Europe, and two in Asia). At launch, origins had to be Amazon S3 buckets, TLS/SSL was not supported, and the service was self-service and pay-as-you-go from day one. Since then, CloudFront has expanded to hundreds of Edge Locations and additional embedded Points of Presence inside Internet Service Provider networks worldwide; for the latest counts, see the AWS CloudFront features page.

When did CloudFront support HTTPS, Custom SSL Certificates, and SNI?

CloudFront added HTTPS for the default *.cloudfront.net domain on February 26, 2010. Dedicated IP Custom SSL Certificates (using a customer-owned certificate and CNAME) followed on June 11, 2012. SNI Custom SSL - which removed the dedicated-IP charge by leveraging the TLS SNI extension - launched on March 5, 2014, alongside an HTTP-to-HTTPS Redirect behavior. Since 2015-09, AWS Certificate Manager (ACM) issues free public TLS certificates that can be deployed to CloudFront distributions from us-east-1. The combination of SNI Custom SSL + free ACM certificates is what made HTTPS practical at scale for static sites and small APIs: before 2014, a per-distribution dedicated-IP fee made it prohibitively expensive to terminate HTTPS for many small distributions, and before 2015 customers had to source and renew their own certificates manually. Today, all three building blocks - SNI, ACM-issued certificate, and CloudFront - work together with zero additional certificate cost.

When did Lambda@Edge launch?

Lambda@Edge was first announced in preview at AWS re:Invent in November 2016 and reached general availability on July 17, 2017, with all four trigger points (viewer-request, viewer-response, origin-request, origin-response) available at GA. Dynamic origin selection at the origin-request trigger was added in July 2018, allowing functions to programmatically rewrite the target origin per request. Lambda@Edge supports Node.js and Python runtimes and runs at CloudFront Regional Edge Caches (not at every Edge Location). Common patterns at GA included server-side rendering, custom authentication, image transformation, A/B testing logic, header rewriting, and bot mitigation. Lambda@Edge cold-start and per-request cost characteristics are similar to standard AWS Lambda, which is the key practical difference from CloudFront Functions: when sub-millisecond runtime and very high throughput matter more than runtime flexibility, CloudFront Functions is the right primitive; when runtime flexibility and network access matter more than per-request cost, Lambda@Edge is.

When did CloudFront Functions launch?

CloudFront Functions became generally available on May 3, 2021, as a lightweight JavaScript runtime separate from Lambda@Edge. It uses a process-based isolation model rather than the virtual-machine-based isolation used by AWS Lambda and Lambda@Edge, has a sub-millisecond runtime cap, a 10 KB code size limit, and runs at every edge location. The cloudfront-js-2.0 runtime with newer ECMAScript features and KVS APIs was introduced in April 2024. CloudFront Functions is priced per million invocations and is typically an order of magnitude cheaper per request than Lambda@Edge for the same workload, which is why it is the recommended primitive for any workload that fits within its constraints (sub-millisecond, no network access, ≤ 10 KB of code). Common production patterns include cache-key normalization (lowercasing query string keys, sorting query parameters), URL rewrites and 301 redirects, viewer-country-based redirects, lightweight JWT signature verification, and feature-flag-based cohort assignment using CloudFront KeyValueStore reads.

When did Origin Access Control (OAC) launch (vs Origin Access Identity, OAI)?

Origin Access Identity (OAI) has been available since 2009 as the original way to restrict Amazon S3 origin access to a specific CloudFront distribution. Origin Access Control (OAC) launched on August 25, 2022 as its successor. OAC uses AWS Signature Version 4 (SigV4) signed requests, supports SSE-KMS-encrypted Amazon S3 buckets, supports all HTTP methods, and works in all current and future AWS Regions (whereas OAI does not extend to Regions launched after December 2022). OAC has subsequently been expanded to support AWS Elemental MediaStore (2023-02), AWS Lambda Function URL origins (2024-04), AWS Elemental MediaPackage v2 origins (2024-04), and other origin types. OAC is the recommended mechanism for all new deployments; see "Indie Dev Guide: From Domain Acquisition to Live Site with AWS Route 53, S3, CloudFront, and ACM" for a worked example.

When did CloudFront KeyValueStore (KVS) launch?

CloudFront KeyValueStore (KVS) became generally available on November 21, 2023, as a globally managed, low-latency key-value datastore that CloudFront Functions can read from inside a function invocation. Initial launch limits were 5 MB per store, 1 store per function, 512-byte keys, and 1 KB values. KVS exists to decouple configuration data (such as redirect maps or feature flags) from function code so that data updates do not require code redeployment. Before KVS, customers either had to bake their lookup data into the function code (limited to 10 KB and requiring a redeployment for every data change) or call out to an external service over the network (which is not possible from CloudFront Functions). KVS resolves both constraints: data is read from within the function with single-digit-millisecond latency at the edge, and the data plane is updated independently via the public API or AWS CLI. For concrete implementation patterns including A/B testing, geo routing, feature flags, and token validation, see "CloudFront KeyValueStore and Edge Functions Cookbook".

When did CloudFront support HTTP/3 (QUIC)?

HTTP/3 over QUIC support for viewer connections was announced on August 15, 2022, for all CloudFront edge locations at no additional cost. CloudFront's HTTP/3 implementation is built on s2n-quic, an open-source Rust implementation of QUIC. Clients must support TLSv1.3 and SNI; CloudFront automatically falls back to HTTP/2 or HTTP/1.1 if QUIC cannot be negotiated. The most important practical benefit of HTTP/3 is the elimination of head-of-line blocking at the transport layer (because QUIC multiplexes streams independently over UDP rather than over a single TCP byte stream), which translates to measurably better performance on lossy and high-latency networks. HTTP/3 is enabled per distribution via the "Supported HTTP versions" setting; no origin-side changes are required because past the edge location, CloudFront continues to use HTTP/1.1 to talk to the origin.

When did CloudFront add Origin Shield?

Origin Shield was launched on October 20, 2020, as a centralized caching layer in a single AWS Region that sits in front of the origin and consolidates cache fills across all Regional Edge Caches. Origin Shield works with any HTTP-accessible origin, including Amazon S3, ALB, Amazon EC2, AWS Elemental MediaPackage, AWS Elemental MediaStore, and third-party origins, and is particularly effective for high cache-hit ratios and multi-CDN architectures. Operationally, the customer chooses one of CloudFront's Regional Edge Caches as the Origin Shield Region for the distribution. After enablement, all origin fetches across all CloudFront edge locations are routed through that single Region first, so for any popular object that is served to many viewers across multiple Regions, only a single request reaches the origin per cache fill. Live and on-demand streaming workloads using AWS Elemental MediaPackage routinely see double-digit-percentage reductions in origin load after enabling Origin Shield, and CloudFront customers running multi-CDN architectures use Origin Shield to ensure that the origin sees one cache fill per object regardless of which CDN served the final response.

When did CloudFront support gRPC?

CloudFront announced gRPC delivery support on November 21, 2024. CloudFront determines that an incoming request is a gRPC request based on the Content-Type: application/grpc header and proxies the request to a configured gRPC origin over HTTP/2, while benefiting from edge TLS termination, AWS WAF protection, and AWS Shield Standard.

When did CloudFront SaaS Manager (multi-tenant distributions) launch?

CloudFront SaaS Manager launched on April 28, 2025, introducing a new distribution type called a multi-tenant distribution designed for SaaS providers and web hosting platforms. Multi-tenant distributions share a base configuration across many tenant domains while permitting per-tenant overrides for the AWS WAF web ACL, TLS certificate, and geographic restrictions. The model adds two related resources: distribution tenants (one per tenant domain, inheriting from the parent multi-tenant distribution and supplying parameter values) and connection groups (the routing endpoint that serves content to viewers, which can be shared across tenants and which controls IPv6 and Anycast IP list settings). Helper methods inside CloudFront Functions let a function read the requesting tenant's parameter values during a sub-millisecond invocation, so data-driven tenant routing (by hostname, JWT claim, or cookie) can be implemented entirely at the edge. SaaS Manager addresses the historical scaling pain point of "one standard distribution per tenant" that previously limited CloudFront in SaaS use cases.

When did CloudFront support viewer mTLS and Connection Functions?

Viewer mTLS and CloudFront Connection Functions launched together on November 24, 2025. Viewer mTLS lets a CloudFront distribution authenticate the viewer's client certificate against a managed trust store - typically backed by AWS Private Certificate Authority or an external CA - so that the edge rejects any viewer that does not present a valid client certificate before any HTTP request is parsed. CloudFront Connection Functions are a specialized form of CloudFront Functions that run during the TLS handshake itself rather than after the HTTP request has been parsed. They receive the client certificate, mTLS configuration parameters, certificate revocation check results, and the client IP, and they return a decision to allow, deny, or log the connection. Connection Functions share the runtime characteristics of standard CloudFront Functions (sub-millisecond runtime, 10 KB code, 2 MB memory, no network access) and can read from CloudFront KeyValueStore inside the handshake, which makes them well suited to certificate attribute validation, custom revocation lists, IP-based certificate policies, and per-tenant validation rules in multi-tenant distributions.

References:
Tech Blog with curated related content
AWS Documentation(Amazon CloudFront)
Document history - Amazon CloudFront
AWS Networking & Content Delivery Blog

Summary

In this article, I created a timeline of Amazon CloudFront's history and looked at a list of CloudFront's features and an overview.

Amazon CloudFront has evolved over more than 17 years from a single-purpose Amazon S3-fronted content delivery network into a programmable edge security and compute platform that fronts almost every kind of internet-facing AWS workload: Amazon S3 static sites, ALB/NLB-backed APIs in private subnets via VPC Origins, AWS Lambda Function URLs, AWS Elemental MediaPackage / MediaStore for streaming, gRPC and WebSocket applications, and entire SaaS platforms with thousands of tenant domains served from a single multi-tenant distribution.

The most consequential architectural shifts have been the 2014 SNI Custom SSL launch (which made HTTPS practical at scale on CloudFront), the 2017 Lambda@Edge GA and 2021 CloudFront Functions GA + 2023 CloudFront KeyValueStore GA (which together turned CloudFront into a real edge computing platform), the 2022 Origin Access Control (OAC) rollout (which is the recommended replacement for the long-standing Origin Access Identity), the 2024 VPC Origins + 2026 WebSocket-for-VPC-Origins combination (which lets CloudFront become the single secure front door for private-subnet web applications), and the 2025 SaaS Manager + viewer-mTLS + Connection Functions trio (which extends CloudFront into a true multi-tenant SaaS edge platform with handshake-time custom authentication).

I would like to continue to watch how Amazon CloudFront will provide what kind of features in the future, particularly around the evolution of edge compute (CloudFront Functions, Connection Functions, and the CloudFront KeyValueStore), AI traffic management, multi-tenant SaaS delivery patterns, and deeper integration with VPC-internal workloads.

Please note that there is also a timeline of the entire AWS service history, including services other than Amazon CloudFront. If you are interested, please check it out.

AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)

Written by Hidekazu Konishi