Amazon CloudFront Key Features
AWS Global Infrastructure
The AWS Cloud spans 117 Availability Zones within 37 Geographic Regions, with announced plans for 13 more Availability Zones and 4 more AWS Regions in New Zealand, the Kingdom of Saudi Arabia, Chile, and the AWS European Sovereign Cloud.
Global Edge Network
Reliable, low latency and high throughput network connectivity
Network Connectivity and Backbone
Amazon CloudFront peers with thousands of Tier 1/2/3 telecom carriers globally, is well connected with all major access networks for optimal performance, and has hundreds of terabits of deployed capacity. CloudFront edge locations are seamlessly connected to AWS Regions through the fully redundant AWS network backbone. This backbone is comprised of multiple 400GbE parallel fibers across the globe and interfaces with tens of thousands of networks for improved origin fetches and dynamic content acceleration.
Amazon CloudFront has three types of infrastructure to securely deliver content with high performance to end users:
CloudFront Regional Edge Caches (RECs) are situated within AWS Regions, between your applications’ web server and CloudFront Points of Presence (POPs) and embedded Points of Presence. CloudFront has 13 RECs globally.
CloudFront Points of Presence are situated within the AWS network and peer with internet service provider (ISP) networks. CloudFront has 700+ POPs in 100+ cities across 50+ countries.
CloudFront embedded Points of Presence are situated within internet service provider (ISP) networks, closest to end viewers. In addition to CloudFront POPs, there are 900+ embedded POPs across 300+ cities in North America, Europe, and Asia.
Security
Availability
Origin Shield
Web applications often need to contend with spikes in traffic during peak periods of activity. By using Amazon CloudFront, the volume of application origin requests is automatically reduced. Content is stored in CloudFront’s edge and regional caches and only fetched from origins when needed. The load on application origins can be further reduced by using Origin Shield to enable a centralized caching layer. Origin Shield optimizes cache hit ratios and collapses requests across regions leading to as few as one origin request per object. This reduced traffic to your origins helps increase the availability of your applications.
Enabling redundancy for origins
CloudFront supports multiple origins for backend architecture redundancy. CloudFront’s native origin failover capability automatically serves content from a backup origin when the primary origin is unavailable. The origins set up with origin failover can be any combination of AWS origins like EC2 instances, Amazon S3 buckets, or Media Services, or non-AWS origins like an on-premises HTTP server. Additionally, you can implement advanced origin failover capabilities with CloudFront and Lambda@Edge.
Edge computing
CloudFront Functions
Amazon CloudFront offers programmable and secure edge CDN computing capabilities through CloudFront Functions and AWS Lambda@Edge. CloudFront Functions is ideal for high scale and latency sensitive operations like HTTP header manipulations, URL rewrites/redirects, and cache-key normalizations. These types of short running, lightweight operations support traffic that is often unpredictable and spiky. For example, you can use CloudFront Functions to redirect requests to language specific versions of your site based on the Accept-Language header of the incoming request. Because these functions execute at all of CloudFront’s edge locations, they can scale instantly to millions of requests per second with minimal latency overhead, typically under one millisecond. You can also utilize CloudFront KeyValueStore, a global, low-latency, key value data store to store and retrieve lookup data from within CloudFront Functions. CloudFront KeyValueStore makes CloudFront Functions more customizable by allowing independent data updates.
Lambda@Edge
AWS Lambda@Edge is a general-purpose serverless compute feature that supports a wide range of computing needs and customizations. Lambda@Edge is best suited for computationally intensive operations. This could be computations that take longer to complete (several milliseconds to seconds), take dependencies on external 3rd party libraries, require integrations with other AWS services (e.g., S3, DynamoDB), or need networks calls for data processing. Some of the popular advanced use cases include HLS streaming manifest manipulation, integrations with 3rd party authorization and bot detection services, server-side rendering (SSR) of single-page apps (SPA) at the edge and more.
Real-time metrics and logging
Real-time metrics
Amazon CloudFront is integrated with Amazon CloudWatch, and automatically publishes six operational metrics per distribution, which are displayed in a set of graphs in the CloudFront console. Additional, granular metrics are available with simple click on the console or via API.
Standard and real-time logging
CloudFront provides two ways to log the requests delivered from your distributions: Standard logs and Real-time logs. Standard logs are delivered to the Amazon S3 bucket of your choice (log records are delivered within minutes of a viewer request). When enabled, CloudFront will automatically publish detailed log information in a W3C extended format into an Amazon S3 bucket that you specify. CloudFront real-time logs are delivered to the data stream of your choice in Amazon Kinesis Data Streams (log records are delivered within seconds of a viewer request). You can choose the sampling rate for your real-time logs—that is, the percentage of requests for which you want to receive real-time log records.
DevOps friendly
Continuous deployment
Continuous deployment with CloudFront gives you a high level of deployment safety. You can now deploy two separate but identical environments—blue and green, and enable simple integration into your continuous integration and delivery (CI/CD) pipelines with the ability to roll out releases gradually without any domain name system (DNS) changes. It ensures that your viewer gets a consistent experience through session stickiness by binding the viewer session to the same environment. Additionally, you can compare the performance of your changes by monitoring standard and real-time logs and quickly revert to the previous configuration when a change negatively impacts a service. Typical use cases for this feature include checking for backward compatibility, post-deployment verification, and validating new features with a smaller group of viewers.
Cost effective
What's new
Automated HTTP validated public certificates with Amazon CloudFront
AWS Certificate Manager (ACM) announces automated public TLS certificates for Amazon CloudFront. CloudFront customers can now simply check a box to receive required public certificates to enable TLS when creating new CloudFront content delivery applications. ACM and CloudFront work together to automatically request, issue and associate the required public certificates with CloudFront. ACM will also automatically renew these certificates as long as the certificate is in use and traffic for the certificate domain is routed to CloudFront. Previously, to set up a similar secure CloudFront distribution, customers had to request a public certificate through ACM, validate the domain, and then associate the issued certificate with the CloudFront distribution. This option remains available to customers.
ACM uses a domain validation method commonly referred to as HTTP, or file-based validation, to both issue and renew these certificates. Domain validation ensures that ACM issues the certificates only to domain users who are authorized to acquire a certificate for the domain. Network and certificate administrators can still use ACM to view and monitor these certificates. While ACM automatically manages the certificate lifecycle, administrators can use ACM’s Certificate lifecycle CloudWatch events to monitor certificate updates and publish the information to a centralized security information and event management (SIEM) and/or enterprise resource planning (ERP) solution.
To learn more about this feature, please refer to our documentation. You can learn more about ACM here and CloudFront here.
Announcing SaaS Manager for Amazon CloudFront
Today, AWS announces CloudFront SaaS Manager, a new Amazon CloudFront feature designed to efficiently manage content delivery across multiple websites for Software-as-a-Service (SaaS) providers, web development platforms, and companies with multiple brands/websites. CloudFront SaaS Manager provides a unified experience, alleviating the operational burden of managing multiple websites at scale, including TLS certificate management, DDoS protection, and observability.
CloudFront SaaS Manager introduces reusable configuration settings, eliminating redundant configurations and allowing customers to maintain consistent settings across their websites. This not only saves time but also reduces the potential for errors in configuration. With CloudFront SaaS Manager, customers benefit from optimal CDN and security defaults, ensuring high performance and secure protections following AWS best practices. Additionally, CloudFront SaaS Manager can automate requesting, issuing, and associating TLS certificates with CloudFront through a simplified AWS Certificate Manager (ACM) integration. This addresses the growing complexity in certificate management, security policy enforcement, and cross-account synchronization that companies face as their customer base expands.
Find more information on using CloudFront SaaS Manager here, on the Amazon CloudFront SaaS Manager page, and in the Amazon CloudFront Developer Guide.
Amazon CloudFront now supports Anycast Static IPs
Amazon CloudFront introduces Anycast Static IPs, providing customers with a dedicated list of IP addresses for connecting to all CloudFront edge locations worldwide.
Typically, CloudFront uses rotating IP addresses to serve traffic. Customers implementing Anycast Static IPs will receive a dedicated list of static IP addresses for their workloads. CloudFront Anycast Static IPs enables customers to provide a dedicated list of IP addresses to partners and their customers for enhancing security and simplifying network management across various use cases. For example, a common use case is allow-listing the static IP addresses in network firewalls.
CloudFront supports Anycast Static IPs from all edge locations. This excludes Amazon Web Services China (Beijing) region, operated by Sinnet, and the Amazon Web Services China (Ningxia) region, operated by NWCD. CloudFormation support will be coming soon. Learn more about Anycast Static IPs here and for more information, please refer to the Amazon CloudFront Developer Guide. For pricing, please see CloudFront Pricing.
Amazon CloudFront announces Anycast Static IPs support for apex domains
Amazon CloudFront announces Anycast Static IPs support for apex domains, enabling customers to easily use their root domain (e.g., example.com) with CloudFront. This new feature simplifies DNS management by providing just 3 static IP addresses instead of the previous 21, making it easier to configure and manage apex domains with CloudFront distributions.
Previously, customers had to create CNAME records to point their domains to CloudFront. However, due to DNS rules, root domains (apex domains) cannot point to CNAME records and must use A records or Route53's ALIAS records. With the new Anycast Static IPs support, customers can now easily configure A records for their apex domains. Organizations can maintain their existing DNS infrastructure while using CloudFront's global content delivery network to deliver apex domains with low latency and high data transfer speeds. Anycast routing automatically directs traffic to the optimal edge location, ensuring high performance content delivery for end users worldwide.
CloudFront supports Anycast Static IPs from all CloudFront edge locations. This excludes Amazon Web Services China (Beijing) region, operated by Sinnet, and the Amazon Web Services China (Ningxia) region, operated by NWCD. Standard CloudFront pricing applies, with additional charges for Anycast Static IP addresses. To learn more, visit the CloudFront Developer Guide for detailed documentation and implementation guidance.
AWS Lambda@Edge announces advanced logging controls
AWS Lambda@Edge now supports AWS Lambda’s advanced logging controls to improve how function logs are captured, processed, and consumed at the edge. This enhancement provides you with more control over your logging data, making it easier to monitor application behavior and quickly resolve issues.
The new advanced logging controls for Lambda@Edge give you three flexible ways to manage and analyze your logs. New JSON structured logs make it easier to search, filter, and analyze large volumes of log entries without using custom logging libraries. Log level granularity controls can switch log levels instantly, allowing you to filter for specific types of logs like errors or debug information when investigating issues. Custom CloudWatch log group selection lets you choose which Amazon CloudWatch log group Lambda@Edge sends logs to, making it easier to aggregate and manage logs at scale.
To get started, you can specify advanced logging controls for your Lambda functions using Lambda APIs, Lambda console, AWS CLI, AWS Serverless Application Model (SAM), and AWS CloudFormation. To learn more, visit the Lambda Developer Guide, and the CloudFront Developer Guide.
Amazon CloudFront supports VPC Origin modification with CloudFront Functions
In November 2024, CloudFront Functions introduced origin modifications, allowing you to conditionally change origin servers on each request. Starting today, you can now use this capability with VPC Origins and origin groups, enabling you to create even more sophisticated routing policies for your applications delivered from CloudFront.
You can now create dynamic routing policies that direct individual requests between any origin, including VPC Origins, by simply providing the ID for the origin. For example, you can automatically route each request to different applications by creating weights to send a certain percentage of traffic to multiple backend services, all without updating your distribution configuration. You can also create new origin groups dynamically, with the ability to set multiple origins with failover criteria. For example, you can create custom failover logic to update the primary and failover origins based on viewer location or request headers to ensure viewers have the lowest possible latency.
These features are now available within CloudFront Functions at no additional charge. For more information, see the CloudFront Developer Guide. For examples of how to use origin modification, see our GitHub examples repository.
AWS announces new edge location in the Kingdom of Saudi Arabia
Amazon Web Services (AWS) announces expansion in the Kingdom of Saudi Arabia by launching a new Amazon CloudFront edge location in Jeddah. The new AWS edge location brings the full suite of benefits provided by Amazon CloudFront, a secure, highly distributed, and scalable content delivery network (CDN) that delivers static and dynamic content, APIs, and live and on-demand video with low latency and high performance.
All Amazon CloudFront edge locations are protected against infrastructure-level DDoS threats with AWS Shield Standard that uses always-on network flow monitoring and in-line mitigation to minimize application latency and downtime. You also have the ability to add additional layers of security for applications to protect them against common web exploits and bot attacks by enabling AWS Web Application Firewall (WAF).
Traffic delivered from this edge location is included within the Middle East region pricing. To learn more about AWS edge locations, see CloudFront edge locations.
Amazon CloudFront announces origin modifications using CloudFront Functions
Amazon CloudFront now supports origin modification within CloudFront Functions, enabling you to conditionally change or update origin servers on each request. You can now write custom logic in CloudFront Functions to overwrite origin properties, use another origin in your CloudFront distribution, or forward requests to any public HTTP endpoint.
Origin modification allows you to create custom routing policies for how traffic should be forwarded to your application servers on cache misses. For example, you can use origin modification to determine the geographic location of a viewer and then forward the request, on cache misses, to the closest AWS Region running your application. This ensures the lowest possible latency for your application. Previously, you had to use AWS Lambda@Edge to modify origins, but now this same capability is available in CloudFront Functions with better performance and lower costs. Origin modification supports updating all existing origin capabilities such as setting custom headers, adjusting timeouts, setting Origin Shield, or changing the primary origin in origin groups.
Origin modification is now available within CloudFront Functions at no additional charge. For more information, see the CloudFront Developer Guide. For examples of how to use origin modification, see our GitHub examples repository.