What's New?

Amazon CloudFront now supports Common Media Client Data (CMCD) fields in real-time logs

Posted On: Apr 9, 2024

Starting today, you can enable Common Media Client Data (CMCD) fields in your CloudFront real-time logs. You can select key client-side performance parameters and CloudFront delivery performance parameters in the same log record. This can help you correlate variations in Quality of Experience (QoE) for your viewers to CloudFront performance at the granularity of single viewer sessions, simplifying the troubleshooting of QoE issues that impact your viewers engagement.

CMCD is a standardized way for transmitting client-side performance data from your media player. The CMCD specification outlines a set of key-value pairs like bitrate, buffer length, object playback duration, measured throughput, and other key values that provide insight into the media player performance. Your media player can use the CMCD standard and send the performance parameters in the HTTP request headers or query string to CloudFront.

Previously, CloudFront logged CMCD parameters as part of the full query string log field, or the HTTP headers log field. Now, you can simply select to include specific CMCD parameters in your real-time logs and save on compute needed to search and extract the CMCD key-value pairs, and reduce the data set for your log analysis.

To enable CMCD in your CloudFront real-time logs, follow the developer guide. To learn more about using CMCD in a custom observability dashboard, refer to the Improving video observability with CMCD and CloudFront Blog. The real-time logs are charged based on the number of log lines that CloudFront publishes to your log destination, to learn more, visit the CloudFront pricing page.

AWS announces new edge location in Türkiye

Posted On: Feb 20, 2024

Amazon Web Services (AWS) announces expansion in Türkiye by launching a new Amazon CloudFront edge location in İstanbul. Customers in Türkiye can expect up to 30% improvement in latency and performance, on average, for data delivered through the new edge location. 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 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 EU region pricing. To learn more about AWS edge locations, see CloudFront edge locations.

Amazon CloudFront announces CloudFront KeyValueStore, a globally managed key value datastore

Posted On: Nov 21, 2023

Amazon CloudFront announces general availability of CloudFront KeyValueStore, a global, low-latency, key value datastore. KeyValueStore allows you to retrieve key value data from within CloudFront Functions making functions more customizable by allowing independent data updates. The key value data is available across all CloudFront edge locations and provides a highly efficient, in-memory, key-value store with fast reads from within CloudFront Functions. With KeyValueStore you can now implement lookup use cases such as feature flags, A/B testing, and storing environment variables with low latency.

CloudFront KeyValueStore is designed to easily scale to handle millions of requests per second without the need to scale up storage resources. You can create CloudFront KeyValueStore resources in the CloudFront console or using the CloudFront API/CLI. As part of this launch, CloudFront is also introducing a new runtime for CloudFront Functions, called cloudfront-js-2.0, which is required to enable KeyValueStore. This new runtime includes several JavaScript ES6 features such as support for async and await to allow asynchronous operations in your code.

For more information about pricing, visit the CloudFront pricing page. To learn more about CloudFront KeyValueStore, refer to the CloudFront KeyValueStore Launch Blog, CloudFront Developer Guide, JavaScript runtime features, or feature FAQs.

Amazon CloudFront announces unified security dashboard

Posted On: Nov 10, 2023

With the new security dashboard, you can now enable, monitor, and manage common security protections for your web applications directly from the Amazon CloudFront console. Built for customers that need unified management of their application delivery and security, the interactive security dashboard brings AWS WAF visibility and controls directly to your CloudFront distribution, including visibility into your application’s top security trends, allowed and blocked traffic, and bot activity. Investigative tools like a visual log analyzer and built-in blocking controls make it easy to isolate traffic patterns and block traffic without querying logs or writing security rules.

The CloudFront security dashboard is designed to make it simple and convenient to enable common security protections, monitor and investigate traffic, and mitigate traffic anomalies and threats. The unified experience centers around high-level workflows so you can focus on making decisions and taking actions inline without writing security rules. For example, visually search AWS WAF logs stored in Amazon CloudWatch without writing queries. Dynamic visual cues like aggregation by IP address, country, HTTP method, and URI path simplify the investigative process while visual blocking actions make it easy to apply mitigating actions in one click.

The CloudFront security dashboard is now available in the CloudFront console. Standard pricing for AWS WAF and Amazon CloudWatch apply. You can estimate the price of AWS WAF security protections or Amazon CloudWatch logs using built-in pricing calculators when making selections. Additional insights and configuration are available in the AWS WAF console. To learn more, refer to the CloudFront Security Dashboard Launch Blog or the CloudFront Developer Guide.

Amazon CloudFront announces query string sorting using CloudFront Functions

Date: Oct 3, 2023

Details: Starting today, you can use CloudFront Functions to improve cache hit rates on CloudFront by sorting query string parameters. CloudFront Functions enables you to personalize content with low latency while delivering web traffic on CloudFront. This new feature allows you to alphabetize or change the order or case of query strings to improve caching. When caching content based on query string parameters, you can improve overall content caching by first sorting, or normalizing, query strings in CloudFront Functions to ensure query strings are ordered in a consistent format.

Previously, you could use Lambda@Edge functions to sort query-string parameters. Since CloudFront Functions offers sub-millisecond startup times and scales immediately to handle millions of requests per second, you can now implement this capability using CloudFront Functions with better performance and at a lower cost. For more information, refer to the CloudFront Developer Guide and a sample function example. To get started with CloudFront, please visit the CloudFront Getting Started.

Amazon CloudFront announces security recommendations

Date: Sep 27, 2023

Details: You can now better protect your CloudFront distributions with AWS WAF security recommendations in the CloudFront console. CloudFront conveniently displays additional security rules for your distributions based on elements of your CloudFront configuration including path patterns or your origin type. Simply select the rules you’d like to enable and CloudFront automatically adds those rules to your AWS WAF configuration.

CloudFront recently launched one-click security protections to handle creating and configuring AWS WAF for you with out-of-the-box protections. Now, you will see additional recommendations based on your CloudFront configuration. For example, if you have configured a cache behavior with a WordPress path pattern, you can enable protections that block malicious request patterns associated with the exploitation of vulnerabilities specific to WordPress, PHP, and SQL databases. Additionally to help protect against HTTP floods, we’ve added a guided workflow to rate limit requests when they are coming at too fast a rate. The workflow starts in monitor mode to capture metrics, tells you if your rate was exceeded—including how often and by how much, and allows you to adjust the rate or enable blocking without leaving the CloudFront console.

CloudFront security recommendations are now available in the Web Application Firewall (WAF) section of the CloudFront console and can be used to configure new or existing CloudFront distributions. Standard pricing for AWS WAF applies. You can estimate the price of AWS WAF security protections using the built-in pricing calculator when making your selection in the CloudFront console. To learn more, refer to the CloudFront Developer Guide.

AWS Lambda@Edge adds support for Python 3.11

Date: Jul 27, 2023

Details: Starting today, you can now use the Python 3.11 runtime to develop and run functions in AWS Lambda@Edge. Python 3.11 contains major performance enhancements over previous version of Python including faster start up times  and improvements to reduce overhead during execution. The optimizations can improve improve performance between 10-60% depending on the workload. For more information, see the blog post at Python 3.11 runtime now available in AWS Lambda.

To deploy Lambda@Edge functions using Python 3.11, upload your code through the Lambda console and select the Python 3.11 runtime. You can also use the AWS CLI, AWS Serverless Application Model (AWS SAM) and AWS CloudFormation to deploy and manage serverless applications written in Python 3.11. To migrate existing Lambda@Edge functions running earlier Python versions, review your code for compatibility with Python 3.11 and then update the function runtime.

To learn more about Lambda@Edge, visit the product page. 

Amazon CloudFront announces support for 3072-bit RSA certificates

Date: Jul 14, 2023

Amazon CloudFront announces support for 3072-bit RSA certificates. Customers can now associate their 3072-bit RSA certificates with CloudFront distributions to enhance communication security between clients and CloudFront edge locations.

RSA is a encryption algorithm widely used in digital certificates to secure internet communications through digital signatures and data encryption. Prior to this update, CloudFront customers could only use RSA certificates with 1024-bit or 2048-bit strength, or an ECDSA P256 certificate. ECDSA P256 certificates provide greater security than 1024-bit or 2048-bit RSA certificates, yet they might not be supported by legacy clients and devices. With the introduction of 3072-bit RSA certificates, customers can now achieve the same security level in CloudFront previously exclusive to ECDSA P256 certificates.

Amazon CloudFront's support for 3072-bit RSA certificates is now available for immediate use. To get started, associate a 3072-bit RSA certificate with your CloudFront distribution using console or APIs. There are no additional fees associated with this feature. For more information, please refer to the CloudFront Developer Guide. To learn more about CloudFront, visit the CloudFront Getting Started page.

AWS announces new edge location in Nigeria

Date: June 15, 2023

Details: Amazon Web Services (AWS) announces expansion in Nigeria by launching a new edge location in Lagos. Customers in Nigeria can expect up to 20% improvement in latency, on average, for data delivered through the new edge location. The new AWS edge location brings the full suite of benefits provided by Amazon CloudFront, a 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 WAF.

Traffic delivered from this edge location is included within the Africa region pricing. To learn more about AWS edge locations, see CloudFront edge locations.

Amazon CloudFront now supports stale-while-revalidate and stale-if-error cache control directives

Date: May 17, 2023

Details: Amazon CloudFront announces support for stale-while-revalidate and stale-if-error cache control directives, which can improve performance and availability. The stale-while-revalidate directive instructs CloudFront to immediately deliver stale responses to users while it revalidates caches in the background. The stale-if-error directive defines how long CloudFront should reuse stale responses if there’s an error, which provides a better user experience.

With stale-while-revalidate, CloudFront can deliver faster responses from its 480+ edge locations and maximize cache hit ratios for better performance after cache expiration. With the stale-while-revalidate directive, your users no longer need to wait for responses from origins, because stale content is rapidly served from caches. stale-while-revalidate is ideal for content that refreshes frequently or unpredictably, or where content requires significant time to regenerate, and where having the latest version of the content is not essential. The stale-if-error directive enhances the user experience and improves availability by serving stale content when origins return an error. 

Support for these directives is now available in all CloudFront edge locations, at no additional cost. You define the directives from your origin server, and CloudFront honors the behaviors based on your directives. For more information, see  the Amazon CloudFront Developer Guide.

Amazon CloudFront announces one-click security protections

Date: May 10, 2023

Details: You can now secure your web applications and APIs with AWS WAF with a single click in the Amazon CloudFront console. CloudFront can create and configure out-of-the-box AWS WAF protection for your application as a first line of defense against common web threats. Optionally, you can later configure additional security protections against bots and fraud or other threats specific to your application in the AWS WAF console.

Previously, you could secure your CloudFront distributions with AWS WAF by preconfiguring an AWS WAF web access control list (web ACL) containing the security rules you wanted to enable. While this approach offers flexibility, you had to decide which initial security rules to enable, and you needed to interact with both the CloudFront and AWS WAF management consoles. Now, CloudFront handles creating and configuring AWS WAF for you with out-of-the-box protections recommended by AWS for all applications. This simple and convenient way to protect your web applications and APIs is available in the CloudFront console at the time you create or edit your distribution. Customers who prefer to use an existing web ACL may continue to select a preconfigured web ACL instead.

One click security protection with AWS WAF is now available in the new Web Application Firewall (WAF) section of the CloudFront console and can be used to configure new or existing CloudFront distributions. Standard pricing for AWS WAF applies. You can estimate the price of AWS WAF security protections using the built-in pricing calculator when making your selection in the CloudFront console. To learn more, refer to the CloudFront Developer Guide.

Amazon CloudFront supports S3 Object Lambda Access Point origin

Date: Apr 5, 2023

Details: Starting today, Amazon CloudFront supports the use of S3 Object Lambda Access Points as origins. This means that you can now use S3 Object Lambda Access Point aliases to configure an S3 bucket-style CloudFront origin, and take advantage of CloudFront's 480+ global edge locations to accelerate the delivery of data transformed by your S3 Object Lambda function.

S3 Object Lambda allows you to add your own code to S3 GET, HEAD, and LIST requests to modify and process data as it is returned to an application. Prior to this launch, you were required to use Lambda@Edge as the signing principal with AWS Signature Version 4 (SigV4) for authentication with the origin. You can now use CloudFront as the signing principal for SigV4 authentication with the S3 Object Lambda Access Point origin. This makes it simpler to use CloudFront to accelerate the distribution of data that the S3 Object Lambda function has transformed, such as filtered rows, dynamically resized images, data with confidential information redacted, and much more.

Amazon CloudFront's support for S3 Object Lambda Access Points origin is now available worldwide. To get started, obtain the S3 Object Lambda Access Points alias in your S3 Console or through an API and create your S3 bucket-style domain as your CloudFront origin. There are no additional fees associated with this feature. For more information, please refer to the CloudFront Developer Guide. To learn more about CloudFront, visit the CloudFront Getting Started page.

Amazon CloudFront announces support for HTTP status and response generation using CloudFront Functions

Date: March 29, 2023

Details: Starting today, you can use CloudFront Functions to further customize responses to viewers, including changing the HTTP status code and replacing the HTTP body of the response. CloudFront Functions is a serverless edge computing feature on CloudFront built for lightweight HTTP transformations that runs in the 450+ CloudFront edge locations globally.

Previously, CloudFront Functions allowed transforming the HTTP request and response attributes such as headers and cookies. With this launch, when CloudFront receives an HTTP response from your origin server or the cache, you can modify the HTTP response to override the HTTP status code and HTTP body. For example, if you want to evaluate the headers returned from your origin to determine whether to block a request, you can change the HTTP status code to 403 and drop the HTTP body in the response. You can also use this capability to generate the HTTP body for each request, for example, you can evaluate a request and respond back to viewers with a customized webpage.

For more information, refer to the CloudFront Developer Guide. There is no additional fee to use this feature. To get started with CloudFront, please visit the CloudFront Getting Started.

Amazon CloudFront supports saving test events with CloudFront Functions

Date: March 23, 2023

Details: Amazon CloudFront now supports the ability to save test events for CloudFront Functions in the CloudFront console. This feature allows you to create and save multiple test events to ensure better test coverage when building CloudFront Functions. Saved test events speed up development times and reduce the overhead when testing CloudFront Functions.

Previously, the CloudFront Functions console only allowed configuring a single test event for validating a function. This would introduce additional effort and you could inadvertently miss certain test cases while modifying the test event. Additionally, test events were only saved during the CloudFront console session, after which the test event would need to be recreated for a new session. By saving test events, you can now create multiple test cases for each function and save them for future use. You can now make changes to an existing function and quickly test against all previously saved test events without manually recreating test events.

Saving test events is available for immediate use at no additional charge in the CloudFront Functions console. For more information, refer to the CloudFront Functions Developer Guide.

AWS announces new Amazon CloudFront edge location in Peru

Date: March 22, 2023

Details: Amazon Web Services (AWS) announces Amazon CloudFront expansion in Peru by launching a new edge location in Lima. Customers in Peru can expect up to 50 percent improvement in latency, on average, for data delivered through the new edge location to provide end users faster, more responsive applications. The new AWS edge location brings the full suite of benefits provided by Amazon
CloudFront, a highly distributed and scalable content delivery network (CDN) that delivers static and dynamic content, APIs, and live and on-demand video. Amazon CloudFront uses a global network of 450+ points of presence (POPs) and 13 regional edge caches in 90+ cities across 49 countries to deliver content to end users.

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 WAF.

Traffic delivered from this edge location is included within the South America
region pricing. To learn more about AWS edge locations, see CloudFront edge
locations.

Amazon CloudFront announces support for blocklists in origin request policies

Date: February 22, 2023

Details: Amazon CloudFront now supports blocklists in origin request policies. This feature allows you to forward all viewer headers, cookies, and query strings to your origin while excluding specific values using a blocklist. Blocklists offer more flexibility in how viewer request data is forwarded to your origin.

Prior to today, you could use origin request policies to decide which viewer headers, query strings, and cookies you wanted to forward to your origin. Using the new blocklist capability, you can now forward all viewer values except the values defined in your blocklist. This makes it easier to forward request data to origins such as API Gateway that do not support forwarding the viewer Host header. Additionally, we’ve released the AllViewerExceptHostHeader managed policy that forwards all values (headers, cookies, and query strings) from the viewer request, but does not include the Host header from the viewer request.

Blocklist support in origin request policies is available for immediate use at no additional charge. You can configure this feature via the CloudFront console, SDK, and CLI. For more information, refer to the CloudFront Developer Guide.

AWS Lambda@Edge now supports Node 18.x

Date: Jan 13, 2023

Details: Starting today, you can now use the Node.js 18.x runtime to develop functions in AWS Lambda@Edge. This runtime is in addition to the currently supported Node.js 16.x and Node.js 14.x runtimes.

Node.js 18.x, the current Long Term Support (LTS) version of Node.js, now supports ES module resolution using NODE_PATH to make loading ES module easier. Additionally, Node.js 18.x brings new language features for improved performance for class fields and private class methods, JSON import assertions, and experimental features such as the Fetch API, Test Runner module, and Web Streams API. For more information about the benefits and new features of Node.js 18.x, read the Node.js 18.x announcement post on the AWS Compute Blog.

To get started with Node.js 18.x, upload your code to AWS Lambda through the AWS CLI or Lambda console, and select Node.js 18.x as the runtime. If you already have existing Node.js functions in Lambda, you can switch to the new runtime by making any required code changes to ensure compatibility with the new runtime and then editing the function configuration to set the runtime to Node.js 18.x.

To learn more about Lambda@Edge, visit the product page . For more information about the Node.js programming model in AWS Lambda, read the AWS Lambda Node.js documentation.

Amazon CloudFront now supports the removal of response headers

Date: Jan 3, 2023

Details: Amazon CloudFront now supports the removal of response headers using response header policies, giving customers a native capability to remove specified headers served from CloudFront. This new capability, along with the existing ability to add and override headers, provides comprehensive flexibility for customers to customize response headers.

Until today, response header policies have allowed customers to specify HTTP headers that Amazon CloudFront adds to responses sent to viewers, including CORS headers, security headers, or custom headers. Now, customers can use response header policies to selectively remove headers sent to viewers, hiding from them the headers that are needed for application logic or CDN-specific caching policies but don't need to be shared. For example, a customer may have a blog application that sends a "x-powered-by" header, which, if revealed, could be targeted by attackers for specific known vulnerabilities of the technology. To protect against this, the customer can use a response header policy to prevent it from being sent to viewers. Additionally, an origin may generate a "Vary" header to indicate headers that have influenced the origin response, but this information may not be needed for viewers and can be removed using a response header policy.

Removing headers using response header policies is now available through the CloudFront Console, AWS SDKs, and the AWS CLI. There are no additional fees associated with this feature. Please note that some HTTP headers are read-only or otherwise inaccessible and hence cannot be removed. For more information on which headers cannot be removed, see Restrictions on Edge Functions. To get started with CloudFront, please visit the CloudFront product page.

Amazon CloudFront launches continuous deployment support

Date: Nov 21, 2022

Details: Amazon CloudFront now supports continuous deployment, a new feature to test and validate the configuration changes with a portion of live traffic before deploying changes to all viewers.

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.

Continuous deployment support is available across all the CloudFront edge locations at no additional cost. You can access it through CloudFront Console, SDK, Command Line Interface, or CloudFormation template. Please visit the launch blog or the documentation to learn more about the new feature.

Amazon CloudFront now supports JA3 fingerprint headers

Date: Nov 17, 2022

Details: Amazon CloudFront now supports Cloudfront-viewer-ja3-fingerprint headers, enabling you to access incoming viewer requests’ JA3 fingerprints. You can use the JA3 fingerprints to implement custom logic to block malicious clients or allow requests from expected clients only.

A Cloudfront-viewer-ja3-fingerprint header contains a 32-character hash fingerprint of the TLS Client Hello packet of an incoming viewer request. The fingerprint encapsulates information about how the client communicates and can be used to profile clients that share the same pattern. You can add the Cloudfront-viewer-ja3-fingerprint header to an origin request policy and attach the policy to your CloudFront distributions. You can then inspect the header value in your origin applications or in your Lambda@Edge and CloudFront Functions, and compare the header value against a list of known malware fingerprints to block the malicious clients. You can also compare the header value against a list of expected fingerprints to allow only requests bearing the expected fingerprints.

Cloudfront-viewer-ja3-fingerprint headers are available for immediate use in all CloudFront edge locations. You can enable JA3 fingerprint headers in your CloudFront console or using the AWS SDK. There are no additional fees to use JA3 fingerprint headers. For more information, see the CloudFront Developer Guide.

Amazon CloudFront adds fields for origin latency and ASN in real-time logs for more granular insights

Date: October 20, 2022

Details: Amazon CloudFront now offers three additional data fields in CloudFront real-time logs: Origin first-byte latency, Origin last-byte latency, and autonomous system number (ASN). CloudFront real-time logs contain detailed information about requests delivered by CloudFront such as the HTTP status codes of the response, or whether the response was cached. With the three new data fields, customers can get more granular insights on CloudFront performance while analyzing real-time logs, or in the dashboards created using the logs. The Origin first-byte latency provides the time taken in seconds by the origin server to respond back with the first byte of the response. The Origin last-byte latency indicates the time taken in seconds by the origin server to respond back with the last byte of the response. ASN is a unique number that identifies the network, such as an internet service provider (ISP) network, that provides the viewer IP address. These new fields can be enabled via the CloudFront Console, SDK, and CLI. In addition to the real-time logs, you can also configure your CloudFront origin request policies to forward the CloudFront-Viewer-ASN header to your origin servers. For more information, refer to the CloudFront Developer Guide and API documentation. 

Amazon CloudFront launches in Vietnam

Date: August 29, 2022

Details: Amazon CloudFront announces its first edge locations in Hanoi and Ho Chi Minh City, Vietnam. Viewers served by these new edge locations can expect up to a 30% improvement in first-byte latency. The addition of these two locations brings CloudFront’s global network to 410+ points of presence in 90+ cities, across 48 countries.

In addition to reducing latency, these edge locations also bring the full suite of benefits provided by Amazon CloudFront, such as Lambda@Edge, Field Level Encryption, and Amazon S3 Transfer Acceleration, as well as seamless integration with other AWS services like AWS Certificate Manager (ACM), AWS Shield, AWS WAF, AWS Simple Storage Service (S3), and Amazon Elastic Compute Cloud (EC2). These new edge locations in Hanoi and Ho Chi Minh City are built to the same high standards as our other CloudFront edge locations around the world, including infrastructure and processes that are all compliant with PCI, DSS, HIPAA, and ISO to ensure secure delivery of the most sensitive data.

Traffic delivered from these edge locations is included within the Asia Pacific region pricing. To learn more about AWS edge locations, see CloudFront edge locations.

Amazon CloudFront launches Origin Access Control (OAC)

Date: August 25, 2022

Details: Amazon CloudFront now offers Origin Access Control, a new feature that enables CloudFront customers to easily secure their S3 origins by permitting only designated CloudFront distributions to access their S3 buckets. Customers can now enable AWS Signature Version 4 (SigV4) on CloudFront requests to S3 buckets with the ability to set when and if CloudFront should sign requests. Additionally, customers can now use SSE-KMS when performing uploads and downloads through CloudFront.

Until now, customers were limited to using Origin Access Identity to restrict access to their S3 origins to CloudFront. Origin Access Control improves upon Origin Access Identity by strengthening security and deepening feature integrations. Origin Access Control provides stronger security posture with short term credentials, and more frequent credential rotations as compared to Origin Access Identity. With Origin Access Control, customers can create granular policy configurations through resource-based policies, which provides better protection against confused deputy attacks. Customers can use Origin Access Control to fetch and put data into S3 origins in regions that require SigV4. Also, Origin Access Control allows customer to use SSE-KMS with their S3 origins, which was not possible using Origin Access Identity.

CloudFront supports both the new Origin Access Control and legacy Origin Access Identity. If you have a distribution configured to use Origin Access Identity, you can easily migrate the distribution to Origin Access Control with few simple clicks. Any distributions using Origin Access Identity will continue to work and you can continue to use Origin Access Identity for new distributions. Refer to CloudFront origin access migration documentation for upcoming region restrictions. 

CloudFront Origin Access Control is now available worldwide except for AWS China regions. You can start using Origin Access Control through the CloudFront console, APIs, SDK, or CLI. There is no additional fee to use Origin Access Control. To learn about how to configure Origin Access Control, refer to the CloudFront origin access control documentation. To get started with CloudFront, visit the CloudFront product page.

Amazon CloudFront now supports HTTP/3 powered by QUIC

Date: August 15, 2022

Details: Amazon CloudFront now supports HTTP version 3 (HTTP/3) requests over QUIC  for end user connections. HTTP/3 uses QUIC, a user datagram protocol (UDP) based, stream-multiplexed, secure transport protocol that combines and improves upon the capabilities of existing transmission control protocol (TCP), TLS, and HTTP/2. HTTP/3 offers several benefits over previous HTTP versions, including faster response times and enhanced security.

Customers are constantly looking to deliver faster and more secure applications to their users. As internet penetration increases globally and more users come online via mobile and from remote networks, the need for improved performance and reliability is greater than ever. HTTP/3 is an improvement over previous HTTP versions, and helps customers improve performance and end-viewer experience by reducing connection times and eliminating head of line blocking. CloudFront's HTTP/3 support is built on top of s2n-quic, a  new open-source QUIC protocol implementation in Rust, with a strong emphasis on efficiency and performance. CloudFront’s HTTP/3 implementation supports client-side connection migrations, allowing client applications to recover connections that are experiencing problematic events such as Wifi to cellular migration or persistent packet loss, with minimal or no interruption. Additionally, HTTP/3 provides enhanced security as it uses QUIC which encrypts the TLS handshake packets by default. CloudFront customers that have enabled HTTP/3 on their distributions have seen up to 10% improvement in time to first byte, and up to 15% improvement in page load times. Customers have also observed reliability improvements as handshake failures reduced when they enabled HTTP/3 on their distributions.

To enable HTTP/3 on your distributions, you can edit the distribution configuration through the CloudFront Console, the UpdateDistribution API action, or using a CloudFormation template. Clients that do not support HTTP/3 can still communicate with HTTP/3 enabled Amazon CloudFront distributions using previous HTTP versions.

HTTP/3 is now available on all 410+ CloudFront edge locations worldwide and there is no additional charge for using this feature. To learn more about Amazon CloudFront HTTP/3, refer the CloudFront Developer Guide. To learn more about Amazon CloudFront, visit the Amazon CloudFront product page.

Amazon CloudFront supports header names of up to 1024 characters in CloudFront policies

Date: Jul 11, 2022

Details: Amazon CloudFront now supports a maximum of 1024 characters across all header names in cache, origin request, and origin response policies. With 1024 characters, customers now have 512 extra characters to add header metadata to their policies.

A CloudFront policy allows customers to apply the same specific combination of settings across many distribution behaviors. Previously, customers could add a maximum of 512 characters as the CloudFront or custom header names in a policy. With the increased character limit, customers can now, for example, add additional headers to a cache policy to configure a more granular cache key, or customers can leverage additional headers as inputs to implement user authentication. All the headers are available to use in Lambda@Edge, CloudFront Functions, or application logic at the Origin.

The increased length of all header names is available for immediate use worldwide. There is no additional fee for using this feature, and customers can continue configuring headers in policies using the CloudFront Console, APIs, SDK, and CLI. For more information, refer to the CloudFront Developer Guide and API documentation.

Amazon CloudFront now supports TLS 1.3 session resumption for viewer connections

Date: Jun 7, 2022

Details: Amazon CloudFront now supports Transport Layer Security (TLS) 1.3 session resumption to further improve viewer connection performance. Until now, Amazon CloudFront has supported version 1.3 of the TLS protocol since 2020 to encrypt HTTPS communications between viewers and CloudFront. Customers that adopted the protocol have seen their connection performance improved by up to 30% compared with previous TLS versions. Starting today, customers that use TLS 1.3 will see up to 50% additional performance improvement thanks to TLS 1.3 session resumption. With session resumption, when a client reconnects to a server with which the client had an earlier TLS connection, the server decrypts the session ticket using a pre-shared key sent by the client and resumes the session. TLS 1.3 session resumption speeds up session establishment as it reduces computational overhead for both the server and the client. It also requires fewer packets to be transferred compared to a full TLS handshake.

TLS session resumption is automatically enabled for customers using TLS 1.3, and customers do not need to make any additional changes to their CloudFront deployment to benefit from the performance improvements of TLS 1.3 session resumption. Note that if your application uses an outdated OpenJDK version, we recommend that you update it to use the latest stable OpenJDK version, as an outdated OpenJDK may cause connection issues when clients attempt to perform session resumption. To learn more about JDK patching, see the OpenJDK bug page and our blog for bug mitigation.

To learn more about supported protocols and ciphers between viewers and CloudFront, see the CloudFront Developer Guide. To learn more about Amazon CloudFront, visit the Amazon CloudFront product page.

Amazon CloudFront now provides TLS version and cipher suite in CloudFront-Viewer-TLS-header

Date: May 23, 2022

Details: CloudFront now provides the CloudFront-Viewer-TLS header for use with origin request policies. CloudFront-Viewer-TLS is an HTTP header that includes the TLS version and cipher suite used to negotiate the viewer TLS connection. Previously, TLS information was available in CloudFront access logs to analyze previous requests. Now, customers can access the TLS version and cipher suite in each HTTP request to make real-time decisions such as restricting requests with outdated TLS versions. The CloudFront-Viewer-TLS header value uses the following syntax: :. For example, TLSv1.2:ECDHE-RSA-AES128-SHA256. 

To configure the CloudFront-Viewer-TLS header, include it in a CloudFront origin request policy to be forwarded to your origin. When configured, the Cloudfront-Viewer-TLS header can also be accessed from CloudFront Functions and Lambda@Edge to perform functions such as restricting access at the edge. 

The Cloudfront-Viewer-TLS header is now available in all regions except the Amazon Web Services China (Beijing) Region, operated by Sinnet, and the Amazon Web Services China (Ningxia) Region, operated by NWCD. There is no additional fee for using the header. For more information about how to use the Cloudfront-Viewer-TLS header, see the CloudFront Developer Guide. For more details on the use cases supported by origin policies, visit this blog. To learn more about Amazon CloudFront, visit the CloudFront product page.

Amazon CloudFront now supports Server Timing headers

Date: Mar 31, 2022

Details: Starting today, you can configure your CloudFront distributions to include Server Timing headers to monitor CloudFront behavior and performance. Server Timing headers provide detailed performance information, such as whether content was served from cache when a request was received, how the request was routed to the CloudFront edge location, and how much time elapsed during each stage of the connection and response process. 

Server Timing headers provide additional metadata in the form of HTTP headers in viewer responses and can be inspected or consumed by client-side application code. You can use Server Timing headers to gain more granular insights when troubleshooting CloudFront performance, to inspect CloudFront behavior, and to collect and aggregate metrics across user-requested  transactions, such as cache misses, first byte latency, and last byte latency.  

Server Timing headers are available for immediate use in all CloudFront edge locations. You can enable Server Timing headers through the CloudFront Console or the AWS SDK. There are no additional fees to use Server Timing headers. For more information, see the CloudFront Developer Guide. 

Amazon CloudFront now supports a managed prefix list

Date: February 7, 2022

Details: Starting today, you can use the AWS managed prefix list for Amazon CloudFront to limit the inbound HTTP/HTTPS traffic to your origins from only the IP addresses that belong to CloudFront’s origin-facing servers. CloudFront keeps the managed prefix list up-to-date with the IP addresses of CloudFront’s origin-facing servers, so you no longer have to maintain a prefix list yourself.

You can reference the managed prefix list for CloudFront in your Amazon Virtual Private Cloud (VPC) security group rules, the subnet route table, the common security group rules with AWS Firewall Manager, and any other AWS resource that can use a managed prefix list. For example, you can use the managed prefix list for CloudFront in the inbound rules of your VPC security group to allow only CloudFront IP addresses to access your EC2 instances. When using the managed prefix list with the common security group rules for AWS Firewall Manager, you can limit access to multiple Application Load Balancers (ALB) across all your AWS accounts. Please see the AWS Managed Prefix List for more details.

The managed prefix list is available for immediate use via the AWS Console, and the AWS SDK in all regions except China, Asia Pacific (Jakarta), and Asia Pacific (Osaka). The prefix list can be referenced in your CloudFormation templates in the available regions. There is no additional fee for using the CloudFront managed prefix lists. For further information, please see the CloudFront developer guide.

Amazon CloudFront now supports configurable CORS, security, and custom HTTP response headers

Date: November 2, 2021

Details: Today, Amazon CloudFront is launching support for response headers policies. You can now add cross-origin resource sharing (CORS), security, and custom headers to HTTP responses returned by your CloudFront distributions. You no longer need to configure your origins or use custom Lambda@Edge or CloudFront functions to insert these headers.

You can use CloudFront response headers policies to secure your application’s communications and customize its behavior. With CORS headers, you can specify which origins a web application is allowed to access resources from. You can insert any of the following security headers to exchange security-related information between web applications and servers: HTTP Strict Transport Security (HSTS), X-XSS-Protection, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Content-Security-Policy. For example, HSTS enforces the use of encrypted HTTPS connections instead of plain-text HTTP. You can also add customizable key-value pairs to response headers using response headers policies, to modify a web applications behavior. Response headers you insert are also accessible to Lambda@Edge functions and CloudFront functions, enabling more advanced custom logic at the edge.

With this release, CloudFront is also providing several pre-configured response headers policies. These include policies for default security headers, a CORS policy allowing resource sharing from any origin, a pre-flight CORS policy allowing all HTTP methods, and policies combining default security headers with CORS or pre-flight CORS. You can also create your own custom policies for various content and application profiles and apply them to any CloudFront distribution’s cache behavior that may have similar characteristics.

CloudFront response headers policies are available for immediate use via the CloudFront Console, the AWS SDKs, and the AWS CLI. For more information, refer to the CloudFront Developer Guide. There is no additional fee for using the CloudFront response headers policies.

Amazon CloudFront adds support for client IP address and connection port header

Date: October 25, 2021

Details: Amazon CloudFront now provides a CloudFront-Viewer-Address header that includes IP address and connection port information for requesting clients. The connection port field indicates the TCP source port used by the requesting client. Previously, IP address and client connection port information were available only in CloudFront access logs, making it harder to resolve issues or perform real-time decision-making based on these data. Now you can configure your CloudFront origin request policies to forward the CloudFront-Viewer-Address header to your origin servers. The header can also be used in CloudFront Functions when included in an origin request policy. The CloudFront-Viewer-Address header uses the following syntax: CloudFront-Viewer-Address: 127.0.0.1:4430

The CloudFront-Viewer-Address header is provided at no additional cost. You can use the header, along with other CloudFront headers, for analyzing, auditing, and logging purposes. For more information about how to use the CloudFront-Viewer-Address header, see the CloudFront Developer Guide. Learn more about cache and origin request policies from our blog. To learn more about Amazon CloudFront, visit CloudFront product page.

AWS Lambda@Edge now supports Python 3.9

Date: September 22, 2021

Details: Starting today, you can now use Python 3.9 to develop functions in Lambda@Edge. This runtime comes in addition to the currently supported Python 3.8.

Python 3.9 is the latest release of the Python language and contains performance improvements and features such as new methods to remove prefixes and suffixes in strings and new operators for dictionaries. For more information about Python 3.9’s benefits and new features, read the AWS Python 3.9 blog post.

To get started with this new runtime, upload your Python code as an AWS Lambda function through the AWS CLI or Lambda console, and select Python 3.9 as the runtime. If you already have existing Python functions in Lambda, you can switch to the new runtime by making any required code changes to ensure compatibility with the new runtime and editing the function configuration to set the runtime to Python 3.9.

To learn more about Lambda@Edge, visit the product page. For more information on Lambda’s Python programming model, refer to the AWS Python documentation. 

Amazon CloudFront now supports ECDSA certificates for HTTPS connections to viewers

Date: July 14, 2021

Details: Starting today, you can use Elliptic Curve Digital Signature Algorithm (ECDSA) P256 certificates to negotiate HTTPS connections between your viewers and Amazon CloudFront. As noted by NIST, ECDSA certificates can provide comparable security strength with smaller key sizes than RSA. As a result, conducting TLS handshakes with ECDSA certificates requires less networking and computing resources making them a good option for IoT devices that have limited storage and processing capabilities.

You can configure your CloudFront distribution to use an ECDSA certificate after importing the certificate into either AWS Certificate Manager (ACM) or AWS Identity and Access Management (IAM). To use an ECDSA certificate on CloudFront for viewer connections, the curve must be P256 (prime256v1). To learn more about which ECDSA ciphers are supported, refer to Supported protocols and ciphers between viewers and CloudFront in the CloudFront Developer Guide. There is no additional fee for using ECDSA P256 certificates for your CloudFront distribution. Get started with CloudFront by visiting the CloudFront Getting Started page.

Amazon CloudFront announces new APIs to locate and move alternate domain names (CNAMEs)

Date: July 08, 2021

Details: Amazon CloudFront announces two new APIs, ListConflictingAliases and AssociateAlias, that help locate and move Alternate Domain Names (CNAMEs) if you encounter the CNAMEAlreadyExists error code. These new APIs let you see which distribution has the CNAME and move the CNAME to a target distribution as long as the source distribution is in the same account or if the source distribution in another account is disabled. To move a CNAME between accounts where the source distribution is still enabled, you must contact AWS Support and follow these steps.

The ListConflictingAliases API allows you to identify a given CNAME, either a specific subdomain or a wildcard, and returns a list of CNAMEs that match or overlap that CNAME. The API also returns corresponding (but partially obfuscated) information about the distribution ID and account ID where each CNAME is located to facilitate follow-up investigations. The AssociateAlias API enables you to move a given CNAME to a target distribution as long as the two distributions are in the same account or the source distribution is disabled. To use either of these APIs, domain validation checks must pass for the call to succeed. To learn more, see Moving an alternate domain name to a different distribution in the CloudFront Developer Guide.

In addition, with the launch of these APIs and the introduction of domain validation in April 2019, CloudFront no longer returns the CNAMEAlreadyExists error code in scenarios involving a cross-account wildcard CNAME. For example, now you can have a wildcard CNAME such as *.example.com on a distribution in Account A and a specific subdomain such as test.example.com on a distribution in Account B.

Amazon CloudFront announces new TLSv1.2_2021 security policy for viewer connections

Date: June 23, 2021

Details: Amazon CloudFront now provides a new security policy, TLSv1.2_2021 which removes the following CBC based ciphers:

• ECDHE-RSA-AES128-SHA256
• ECDHE-RSA-AES256-SHA384

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-CHACHA20-POLY1305
  

Amazon CloudFront announces price cuts in India and Asia Pacific regions

Date: May 6, 2021

Details: Amazon CloudFront announces price cuts of up to 36% in India and up to 26% in Asia Pacific region (Hong Kong, Indonesia, Philippines, Singapore, South Korea, Taiwan, & Thailand) for Regional Data Transfer Out to Internet rates. The new CloudFront prices in these regions are effective May 1st, 2021. You can find CloudFront’s updated on-demand pricing on the CloudFront Pricing Page.

Amazon CloudFront announces CloudFront Functions, a lightweight edge compute capability

Date: May 3, 2021

Details: Amazon CloudFront announces the general availability of CloudFront Functions, a new serverless edge compute capability. You can use this new CloudFront feature to run JavaScript functions across 225+ CloudFront edge locations in 90 cities across 47 countries. CloudFront Functions is built for lightweight HTTP(S) transformations and manipulations, allowing you to deliver richer, more personalized content with low latency to your customers.

CloudFront Functions is ideal for lightweight CloudFront CDN customizations that can run on every request to enable high scale and latency sensitive operations like HTTP header manipulations, URL rewrites/redirects, and cache key normalizations. For example, you can use CloudFront Functions to rewrite requests to language specific versions of your site based on the Accept-Language header of the incoming request. You can also use CloudFront Functions to validate custom tokens to authorize incoming requests. Because these functions run at all of CloudFront’s edge locations, they can scale instantly to millions of requests per second with minimal latency overhead.

CloudFront Functions is natively built-in to CloudFront, allowing you to easily build, test, and deploy viewer request and viewer response functions entirely within CloudFront. Our GitHub repo makes it easy for you to get started by offering a code collection that you can use as a starting point for building functions. You can build functions in the CloudFront console using the IDE, or from the CloudFront APIs/CLI. After you write your code, you can test your function against a CloudFront distribution, to ensure it will run properly after it’s deployed. The test functionality in the console offers a visual editor to quickly create test events without needing to edit JSON.

You can use CloudFront Functions in addition to the existing AWS Lambda@Edge capability that also allows you to run custom code in response to CloudFront events. You should continue using Lambda@Edge for computationally intensive origin request and response operations like server side rendering or image optimizations.

CloudFront Functions is priced at $0.1 per million invocations. For more information about pricing, visit the CloudFront pricing page. To learn more about CloudFront Functions, refer to the CloudFront Functions Launch Blog, CloudFront Developer Guide, or feature FAQs.

AWS Lambda@Edge now supports Node 14.x

Date: April 29, 2021

Details: Starting today, you can now use the Node.js 14.x runtime to develop functions in AWS Lambda@Edge. This runtime is in addition to the currently supported Node.js 10.x and Node.js 12.x runtimes.

Node.js 14.x, the current Long Term Support (LTS) version of Node.js, uses the new V8 8.1 engine and provides better performance than the previous LTS version, 12.x. In addition, Node.js 14.x supports new features such as nullish coalescing (?? operator), options chaining (?. operator), and diagnostic reporting. For more information about the benefits and new features of Node.js 14.x, read the Node.js 14.x announcement post on the AWS Compute Blog.

To get started with Node.js 14.x, upload your code to AWS Lambda through the AWS CLI or Lambda console, and select Node.js 14.x as the runtime. If you already have existing Node.js functions in Lambda, you can switch to the new runtime by making any required code changes to ensure compatibility with the new runtime and then editing the function configuration to set the runtime to Node.js 14.x.

To learn more about Lambda@Edge, visit the product page . For more information about the Node.js programming model in AWS Lambda, read the AWS Lambda Node.js documentation.

Amazon CloudFront announces a new Regional Edge Cache in US West (Northern California) Region

Date: April 08, 2021

Details:  Amazon CloudFront announces a new Regional Edge Cache (REC) located in US West (Northern California). As part of this launch, a few CloudFront Edge locations that previously sent their origin requests through the REC in Oregon will now send their requests through the REC in Northern California.  Because of their proximity to Northern California, or more direct connections to Northern California, these Edge locations will see as much as a 60% reduction in latency fetching content from the California REC when compared to the Oregon REC.

CloudFront now operates 13 Regional Edge Caches around the world which act as mid-tier caching layers positioned between CloudFront’s Edge locations and your origins. These mid-tier caches provide incremental cache width to retain your content for longer periods of time, and further protect your origin from traffic spikes. Like all Regional Edge Caches, the location in Northern California is provided free of charge and automatically included by default for your CloudFront distributions. No configuration change is required to take advantage of CloudFront’s Regional Edge Caches.

For more information on CloudFront’s global infrastructure, including the location of each Regional Edge Cache, go to Amazon CloudFront Key Features page.

AWS Lambda@Edge changes duration billing granularity from 50ms down to 1ms

Date: March 31, 2021

Details: Amazon CloudFront announces reduced billing granularity for Lambda@Edge function duration from 50ms down to 1ms. This will lower the price for most Lambda@Edge functions, more so for functions of short duration. Now, compute duration will be billed in 1ms increments per invocation instead of being rounded up to the nearest 50ms increment per invocation as before.

Lightweight functions such as header manipulations or URL rewrites tend to have a short duration. With this change, it will now be even more cost effective to run these functions on Lambda@Edge. For example, a function that runs in 10ms on average used to be billed for 50ms. Now, that function will be billed for 10ms resulting in a 80% reduction in duration spend. This change applies to all four Lambda@Edge event triggers - viewer request, viewer response, origin request and origin response. This change will be effective starting April 1, 2021. For more information, visit the CloudFront Pricing Page.

Amazon CloudFront launches in Indonesia

Date: March 23, 2021

Details: Amazon CloudFront announces its first edge location in Jakarta, Indonesia. Viewers served by this new edge location can expect up to a 30% improvement in first-byte latency. Traffic delivered from this edge location is included within CloudFront's Asia Pacific region pricing. For more information about CloudFront’s global infrastructure, see Amazon CloudFront Infrastructure.

Amazon CloudFront launches in Croatia

Date: February 09, 2021

Details: Amazon CloudFront announces its first edge location in Zagreb, Croatia. This new edge location in Zagreb will provide viewers as much as a 14% reduction in first-byte latency and is included within CloudFront's European region pricing. For more information about CloudFront’s global infrastructure, see Amazon CloudFront Infrastructure.

Introducing Amazon CloudFront Security Savings Bundle

Date: February 5, 2021

Today, we are announcing the Amazon CloudFront Security Savings Bundle, a flexible self-service pricing plan that helps you save up to 30% on your CloudFront bill in exchange for a monthly spend commitment for a 1-year term. The savings bundle also includes free AWS WAF (Web Application Firewall) usage up to 10% of your committed amount. Any additional Standard CloudFront or WAF charges not covered by the CloudFront Security Savings Bundle still apply. 

With CloudFront Security Savings Bundle, you have the flexibility to choose the monthly commitment that best meets your workloads and maximize savings. For example, if you commit $70 per month, you get CloudFront usage worth $100 covered (a 30% discount). This usage benefit is not limited to data delivered by CloudFront, but applies to all CloudFront usage types including Lambda@Edge. Additionally, customers can take advantage of AWS WAF to protect their web application against common web exploits. In this example, the savings bundle also covers $7 worth of AWS WAF charges, covering up to 11.6M WAF requests.

Enabling the CloudFront Security Savings Bundle is easy. From the CloudFront console, you can use the built-in savings estimator and recommendations capability to estimate your savings based on your historical usage or manual inputs. You can also add multiple Savings Bundles to cover future growth in usage.  

To get started with a CloudFront Security Savings Bundle, visit the CloudFront console. For more information on the CloudFront Security Savings Bundle read the  FAQs or the CloudFront Developer Guide. To learn more about AWS WAF, visit the WAF product page. 

Amazon CloudFront launches in Thailand

Date: November 17, 2020

Details: Amazon CloudFront announces its first two edge locations in Thailand. These new edge locations in Bangkok will provide viewers as much as a 30% reduction in p90 latency measures. These new edge locations are priced within CloudFront’s Asia Pacific geographic region. For more information about CloudFront’s global infrastructure, see Amazon CloudFront Infrastructure.

Amazon CloudFront announces support for public key management through IAM user permissions for signed URLs and signed cookies

Date: October 22, 2020

Details: Amazon CloudFront announces that you can now manage public keys used for signed URLs and signed cookies through Amazon Identity and Access Management (IAM) based user permission, without requiring the AWS root account. With the IAM user permissions based public key management, you get more flexibility and API access to manage your public keys.

Many customers that distribute content over the internet want to restrict access to documents, business data, media streams, or content that is intended for selected users, for example, users who have paid a fee. Customers use CloudFront signed URLs and signed cookies to restrict access to content. Up until now, CloudFront required root account access for trusted signers to manage public keys. With today’s enhancement, you can create and manage Key Groups in CloudFront. Key Groups are sets of multiple public keys which can be created by IAM users based on permissions you grant. 

Key Groups can be shared with other users within your same organization. With this launch, you can also rotate public keys via CloudFront’s API for easier maintenance. You may continue to use root account access for trusted signers to manage public keys if you prefer.

To learn more about serving private content with Amazon CloudFront, read CloudFront’s documentation. To get started with Amazon CloudFront, visit our webpage.

Announcing Amazon CloudFront Origin Shield

Date: October 20, 2020

Details: Amazon CloudFront announces Origin Shield, a centralized caching layer that helps increase your cache hit ratio to reduce the load on your origin. Origin Shield also decreases your origin operating costs by collapsing requests across regions so as few as one request goes to your origin per object. You can also use Lambda@Edge with Origin Shield to enable advanced serverless logic like dynamic origin load balancing. Customers using Origin Shield for live streaming, image handling, or multi-CDN workloads have reported up to a 57% reduction in their origin’s load.

Customer origins with processes that require more compute per request, such as just-in-time packaging, can be sensitive to the number of origin fetches. CloudFront already provides Regional Edge Caches at no additional cost to reduce the operational burden on your origins. Now, you can further minimize your origin’s load by enabling Origin Shield in your CloudFront Origin Settings with just two clicks. To configure Origin Shield, choose the Regional Edge Cache closest to your origin to become your Origin Shield Region. All Origin Shield Regions are built using a highly-available architecture that spans several Availability Zones and includes automatic failover to secondary Origin Shield Regions. Once enabled, CloudFront will route all origin fetches through Origin Shield, and only make a request to your origin if the content is not already stored in Origin Shield's cache.

Origin Shield is charged as a request fee for each request that goes to Origin Shield as an incremental layer. For more information about Origin Shield pricing, see CloudFront Pricing. To learn more about Origin Shield, refer to the Amazon CloudFront Developer Guide. Get started with Amazon CloudFront by visiting our webpage.  

Amazon CloudFront launches in two new countries - Mexico and New Zealand

Date: September 29, 2020

Details: Amazon CloudFront announces its first edge locations in two new countries: Mexico and New Zealand. In Mexico, our two new edge locations in Querétaro will provide viewers as much as a 30% reduction in p90 latency measures. These new edge locations are priced within CloudFront’s North America geographic region. In New Zealand, our two new edge locations in Auckland will provide viewers as much as a 50% reduction in p90 latency measures. These new edge locations are priced within CloudFront’s Australia geographic region. For more information about CloudFront’s global infrastructure, see Amazon CloudFront Infrastructure.

Amazon CloudFront announces support for Brotli compression

Date: September 15, 2020

Details: You can now use Amazon CloudFront to serve Brotli compressed content to your end users. Brotli is a widely supported lossless compression algorithm that often provides a better compression ratio than Gzip. The smaller file sizes improve application performance by delivering your content faster to viewers. CloudFront's Brotli edge compression delivers up to 24% smaller file sizes as compared to Gzip.

Prior to today, you could enable Brotli compression at the origin by whitelisting the 'Accept-Encoding' header. Now CloudFront includes 'br' in the normalized 'Accept-Encoding' header before forwarding it to your origin. You no longer need to whitelist the 'Accept-Encoding' header to enable Brotli origin compression, improving your overall cache hit ratio. Additionally, if your origin sends uncompressed content to CloudFront, CloudFront can now automatically compress cacheable responses at the edge using Brotli.

Brotli is available for immediate use at no additional cost. This feature can be enabled via the CloudFront Console, SDK, and CLI. For more information, refer to the CloudFront Developer Guide. To get started with CloudFront, visit the CloudFront Product Page.

Amazon CloudFront announces support for TLSv1.3 for viewer connections

Date: September 3, 2020

Details: Amazon CloudFront now supports TLSv1.3 for improved performance and security. Amazon CloudFront is a global content delivery network (CDN) that enables you to securely distribute content to viewers with low latency and high availability. Amazon CloudFront supports HTTPS using Transport Layer Security (TLS) to encrypt and secure communication between your viewer clients and CloudFront. TLSv1.3 is the latest version of TLS.

Better Performance

TLSv1.3 provides better performance with a simpler handshake process that requires fewer roundtrips. TLSv1.3 requires one round-trip (1-RTT) compared to TLSv1.2 that requires two round trips (2-RTT) to negotiate a new secure connection which translates into real-world performance improvements with lower first byte latency. In our own internal tests in the US region as an example, first byte latency for new negotiated connections saw reductions of up to 33% for TLSv1.3 compared to previous versions of TLS.

Security Improvements

TLSv1.3 removes legacy features and older cipher suites that are present in previous versions of TLS. TLSv1.3 also supports only PFS (perfect forward secrecy) cipher suites that generate a one-time key used only for the current network session.

TLSv1.3 is available today and enabled by default across all Amazon CloudFront security policies options. No additional changes are required to your CloudFront configuration to benefit from the security and performance improvements of TLSv1.3 for your viewer connections. While most modern web browsers already support TLSv1.3, clients that do not will automatically negotiate to the client’s highest supported TLS version (TLS 1.2, 1.1, or 1). You may select a minimum supported security policy when using a custom SSL certificate.

To learn more about supported protocols and ciphers between viewers and CloudFront, see the CloudFront Developer Guide. To learn more about Amazon CloudFront, visit our product page.

Amazon CloudFront announces real-time logs

Date: August 31, 2020

Details: Amazon CloudFront now supports real-time log delivery of CloudFront access logs. Amazon CloudFront is a global content delivery network (CDN) that enables you to distribute content to viewers with low latency and high availability. The real-time logs contain detailed information about viewer requests that CloudFront receives. These logs are delivered to your Kinesis Data Streams in real time making it easy for you to monitor the performance of your content delivery and respond quickly to operational events.

CloudFront has supported delivery of access logs to customer's Amazon S3 buckets and the logs are typically delivered in a matter of minutes. However, some customers have time sensitive use cases and require access log data quickly. With the new real-time logs, data is available to you in a matter of a few seconds with additional configurability. For example, you can choose the fields you need in the logs, enable logs for specific path patterns (cache behaviors), and choose the sampling rate (the percentage of requests that are included in the logs). The CloudFront real-time logs integrate with Kinesis Data Streams, enabling you collect, process, and deliver log data instantly. You can also easily deliver these logs to a generic HTTP endpoint using Amazon Kinesis Data Firehose. Amazon Kinesis Data Firehose can deliver logs to Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, and service providers like Datadog, New Relic, and Splunk. Using these logs, you can create real-time dashboards, set up alerts, and investigate anomalies or respond to operational events quickly. With today's release, CloudFront has optimized the console experience for access logs with a separate Logs page to manage your log configurations from a central page. From the Logs page, you can create real-time log configurations and apply them to any cache behavior within your CloudFront distributions.

This feature is available for immediate use and can be enabled via the CloudFront Console, SDK, and CLI. CloudFormation support will be available shortly after this release. For more information, refer to the CloudFront Developer Guide and API documentation. The real-time logs are charged based on the number of log lines that CloudFront publishes to your log destination. Information about pricing for the real-time logs can be found on the CloudFront pricing page. The Kinesis Data Stream costs will vary based on your usage and the pricing is available on the pricing page.

Amazon CloudFront announces a new Regional Edge Cache in AWS’ Europe (Ireland) Region

Date: August 10, 2020

Details: Amazon CloudFront announces a new Regional Edge Cache located in AWS’ Europe (Ireland) Region. As part of this launch, a small number of CloudFront Edge locations that sent their origin requests through the Regional Edge Cache in the London Region will now go through the Ireland Region. Because of their proximity to Ireland, or more direct connections to Ireland, these Edge locations will see as much as a 62% reduction in latency fetching content from the Ireland Regional Edge Cache than the London Regional Edge Cache.

CloudFront now operates 12 Regional Edge Caches around the world which act as mid-tier caching layers positioned between CloudFront’s Edge locations and your origins. These mid-tier caches provide incremental cache width to retain your content for longer periods of time and further protect your origin from traffic spikes. Like all Regional Edge Caches, the location in Ireland is provided free of charge and automatically included by default for your CloudFront distributions. No configuration is required to take advantage of CloudFront’s mid-tier locations.

To see a list of CloudFront’s global network, including the location of each Regional Edge Cache, refer to the Amazon CloudFront Feature page.  

Amazon CloudFront adds additional geolocation headers for more granular geotargeting

Date: July 24, 2020

Details: Additional geolocation headers are now available in Amazon CloudFront for use in new cache and origin request policies.

You can now configure CloudFront to add additional geolocation headers that provide more granularity in your caching and origin request policies. Previously, you could configure Amazon CloudFront to provide the viewer’s country code in a request header that CloudFront sends to your origin. The new headers give you more granular control of cache behavior and your origin access to the viewer’s country name, region, city, postal code, latitude, and longitude, all based on the viewer’s IP address.

Additional geolocation headers with sample values:

CloudFront-Viewer-Country-Name: United States

CloudFront-Viewer-Country-Region: MI

CloudFront-Viewer-Country-Region-Name: Michigan

CloudFront-Viewer-City: Ann Arbor

CloudFront-Viewer-Postal-Code: 48105

CloudFront-Viewer-Time-Zone: America/Detroit

CloudFront-Viewer-Latitude: 42.30680

CloudFront-Viewer-Longitude: -83.70590

CloudFront-Viewer-Metro-Code: 505

You can use these additional geolocation headers along with the existing supported CloudFront headers to personalize the content that you deliver to your viewers. For example, you can pass the postal-code header to your origin to display hyper-local content or ads. You can also use Lambda@Edge origin request functions to make network calls to pull in local language files and construct and return a language specific HTML page for each country or region.

These additional geolocation headers are now available to use in all Amazon CloudFront distributions at no additional cost.

To use these new headers, see the CloudFront Developer Guide. Learn more about the new cache and origin request policies in our blog. Visit the Lamda@Edge product page to learn more about running code in response to CloudFront events. To learn more about Amazon CloudFront, visit our product page. 

Amazon CloudFront announces Cache Key and Origin Request Policies

Date: July 22, 2020

Details: Amazon CloudFront now provides enhanced granular control to configure headers, query strings, and cookies that can be used to compute the cache key or forwarded to your origin from your CloudFront distributions. Further, you can configure the cache key and origin request settings independently as account-level policies that can be easily applied across multiple distributions.

Previously, when you configured your CloudFront distribution behavior to forward request metadata such as headers, query strings, and cookies, CloudFront would cache separate versions of these objects based on all the unique combinations of these metadata values. With this new functionality, you do not need to choose between forwarding data to the origin and optimizing cache efficiency by only varying the cache key when absolutely needed. For example, you can configure CloudFront to always forward 'Auth' or 'User-Agent' headers to your origin, but not vary content based on these values. Or you can forward everything, but select a specific header or query string parameter to use for varying the cached content, such as using the ‘Accept-Language’ header to serve localized content variants by client languages supported.

In addition, these options are now set using policies. A policy allows for the same specific combination of settings to be easily applied across many different distribution behaviors, saving setup time and complexity and allowing you to manage consistency across configurations. CloudFront also provides several system policies that are preconfigured. These include default policies for maximum caching and retention (max TTLs, compression, etc.), policies appropriate for proxying dynamic transactions (disable caching), and even some policies for common use cases and integrations with other AWS services, like personalized video streaming with AWS Elemental Media Package, and S3 CORS header support (forwarding of certain expected headers). You can create your own policies for different content and application profiles, and then apply them to any distributions and behaviors that have similar characteristics.

This feature is available for immediate use and is supported in the CloudFront Console, APIs, SDK, and CLI. For more information, refer to the CloudFront Developer Guide and API documentation. There is no additional fee for using this feature. Regular CloudFront charges apply.

Amazon CloudFront announces new TLS1.2 security policy for viewer connections

Date: July 17, 2020

Details: Amazon CloudFront now supports a new security policy, TLSv1.2_2019, which includes only the following ciphers:

• TLS_AES_128_GCM_SHA256

• TLS_AES_256_GCM_SHA384

• TLS_CHACHA20_POLY1305_SHA256

• ECDHE-RSA-AES128-GCM-SHA256

• ECDHE-RSA-AES128-SHA256

• ECDHE-RSA-AES256-GCM-SHA384

• ECDHE-RSA-CHACHA20-POLY1305

• ECDHE-RSA-AES256-SHA384
  

A security policy determines the SSL/TLS protocol that CloudFront uses to communicate with viewers, and the cipher that CloudFront uses to encrypt the content that it returns to viewers. The TLSv1.2_2019 policy sets the minimum negotiated Transport Layer Security (TLS) version to 1.2 and supports only the ciphers listed above. When you create a new distribution using a custom SSL certificate, TLSv1.2_2019 will be the default policy option selected. You may use the AWS Management Console, Amazon CloudFront APIs, or AWS CloudFormation to update your existing distribution configuration to use this new security policy.

The TLSv1.2_2019 security policy is available today. To learn more about this new policy and ciphers supported refer to CloudFront's documentation. To get started with CloudFront, visit the CloudFront product page.

Amazon CloudFront enables configurable origin connection attempts and origin connection timeouts

Date: June 11, 2020

Details: Amazon CloudFront now provides you even more control over the connection behaviors between CloudFront and your origin. You can now configure the number of connection attempts CloudFront will make to your origin and the origin connection timeout for each attempt. In addition, the CloudFront origin response timeout range has been expanded and you can now change the value from 1 to 60 seconds, where previously the minimum value was 4 seconds. These two new configurations can be individually set for any type of origin within your CloudFront distribution and can also be used to further enhance the responsiveness and availability of your multi-origin application when coupled with CloudFront Origin Failover.

For example, you can use CloudFront’s Origin Failover to create high-availability applications with a primary and secondary origin. By using these new origin connection configurations, you can more quickly cycle through Origin Group failover conditions and provide a faster response to the viewer request. For some use cases, like streaming video content, if the primary origin is unresponsive, you might want CloudFront to fail over to the secondary origin in as little as 1 connection attempt with a 1 second timeout. Having a tighter threshold on origin connection behaviors can help minimize video buffering by quickly fetching the video segment from the secondary origin or giving the player time to execute its own retry logic.

These new features are available today at no additional charge. You can use the AWS Management Console, Amazon CloudFront APIs, or AWS CloudFormation to configure these values. To learn more about these new configurations, refer to CloudFront's documentation. To get started with CloudFront, visit the CloudFront product page.

Amazon CloudFront announces its first Edge locations in Kolkata and Hamburg

Date: May 13, 2020

Details: Amazon CloudFront announces its first Edge locations in Kolkata, India and Hamburg, Germany. Viewers served by these new Edge locations can expect to see up to a 20% improvement in latency. In India, CloudFront has multiple Edge locations in Bengaluru, Chennai, Delhi, Hyderabad, and Mumbai. Similarly, CloudFront already has Edge locations in several cities in Germany such as Berlin, Dusseldorf, Frankfurt, and Munich. For more information on CloudFront’s global infrastructure, go to CloudFront Features.

Amazon CloudFront in China announces support for Origin Access Identity

Date: Apr 24, 2020

Details: Amazon CloudFront in China announces support for Origin Access Identity (OAI). By using OAI, you can restrict your viewers from accessing content from your Amazon S3 buckets directly by requiring them to retrieve the content through Amazon CloudFront’s distributed edge network in China. To learn more about OAI with Amazon CloudFront in China, read CloudFront’s documentation on Configuring Secure Access and Restricting Access to Content. To get started with Amazon CloudFront in China, visit our webpage.

AWS Lambda@Edge now supports Node 12.x and Python 3.8

Date: Mar 2, 2020

Details: Starting today, you can now use Node.js 12.x and Python 3.8 to develop functions in Lambda@Edge. Both these runtimes come in addition to the currently supported Node.js 10.x and Python 3.7.

Node.js 12.x, the current Long Term Support (LTS) version of Node.js, uses the new V8 7.4 engine and provides better performance than the previous LTS version 10.x. In addition, Node.js 12.x supports new features such as private classes and enhanced stack tracing. For more information about Node.js 12.x’s benefits and new features, read AWS’ Node.js 12.x blog post.

Python 3.8 is the newest major release of the Python language and contains new features such as assignment expressions, positional-only arguments, and typing improvements. For more information about Python 3.8’s benefits and new features, read AWS’ Python 3.8 blog post.

To get started with these new runtimes, upload your Node.js or Python code as an AWS Lambda function through the AWS CLI or Lambda console, and select either Node.js 12.x or Python 3.8. If you already have existing Node.js or Python functions in Lambda, you can switch to the new runtime by making any required code changes to ensure compatibility with the new runtime and editing the function configuration to set the runtime to Node.js 12.x or Python 3.8.

To learn more about Lambda@Edge, visit the product page. For more information on Lambda’s Node.js programming model, read AWS’ Node.js documentation. For more information on Lambda’s Python programming model, refer to AWS’ Python documentation.

Amazon CloudFront in China announces support for Usage and Activity Reports in the Console

Date: Feb 21, 2020

Details: Amazon CloudFront customers in China can now get detailed information about their CloudFront usage and activity by using CloudFront Reports in the AWS Management Console. Customers in China can use the CloudFront Cache Statistics Report to see total requests, the percentage of viewer requests by result type, bytes transferred, HTTP status codes, and the percentage of GET requests that did not finish downloading. The CloudFront Popular Objects Report shows the 50 most popular objects and statistics about those objects. The CloudFront Top Referrers Report shows the top 25 referrers and the number of requests from each referrer. The CloudFront Usage Report shows the number of requests and data transferred by protocol or destination. The CloudFront Viewers Report shows the breakdown of viewers by devices, browsers, operating systems, and locations. These reports are available to all CloudFront customers at no additional cost.

To get started with CloudFront in China, go to Amazon CloudFront. For documentation, see CloudFront Reports in the Console in the Amazon CloudFront Developer Guide.

Amazon CloudFront launches in five new countries - Bulgaria, Greece, Hungary, Kenya, and Romania

Date: Jan 10, 2020

Details: Amazon CloudFront announces its first Edge Locations in five new countries: Nairobi (Kenya), Sofia (Bulgaria), Athens (Greece), Budapest (Hungary), and Bucharest (Romania). Viewers in these countries will now see, on average, up to a 50% reduction in first-byte latency when accessing content through CloudFront. In addition to these new countries, CloudFront also launched its first Edge location in Dusseldorf, Germany. With these new locations, CloudFront now has 216 Points of Presence in 84 cities across 42 countries. For more information about CloudFront’s global infrastructure, see Amazon CloudFront Infrastructure.

Amazon CloudFront adds eight additional real-time metrics in Amazon CloudWatch

Date: Dec 19, 2019

Details: Amazon CloudFront now offers eight additional real-time metrics in Amazon CloudWatch. These new metrics provide you even more visibility into the performance of your CloudFront traffic. You can use CloudFront’s real-time metrics to monitor, alarm, and receive notifications on the operational performance of your CloudFront distributions. CloudFront already provides six operational metrics, and four Lambda@Edge function metrics, to all CloudFront customers at no additional cost.

The eight new metrics include:

Cache Hit Rate: The percentage of all cacheable requests for which CloudFront served the content from its cache. HTTP POST and PUT requests, and errors, are not considered cacheable requests. The Cache Hit Rate allows you to determine the proportion of your viewer requests that are served from CloudFront edge caches instead of going to your origin servers for content.

Origin Latency: The total time spent in milliseconds from when CloudFront receives a request to when it provides a response to the network (not the viewer), for requests that are served from the origin, not the CloudFront cache. Origin Latency allows you to monitor the performance of your origin server.

Error Rate by status code: The percentage of all viewer requests for which the response's HTTP status code is a particular code in the 4xx or 5xx range. This metric is available for the following error codes: 401, 403, 404, 502, 503, and 504. The Error Rate metric allows you to identify the specific type of HTTP status code behind the 4xx or 5xx errors.

These new metrics can now be enabled in the monitoring page of your CloudFront console, standard CloudWatch rates apply. Additional details on how to enable these metrics are available at Viewing Additional CloudFront Distribution Metrics.

Amazon CloudFront now provides seven new data fields in access logs

Date: Dec 12, 2019

Details: Amazon CloudFront access logs provide detailed information about every user request that CloudFront receives. Starting today, seven additional data fields will now appear in your CloudFront access logs to improve visibility into the delivery of your content. For example, with the x-edge-detailed-result-type field you can identify the specific type of error and with the sc-range-start/sc-range-end fields you can determine the requested range details. These new fields are appended to the end of each log entry to maintain backwards-compatibility with the previous log file format. The seven new data points include:

• c-port – The port number of the request from the viewer.
• time-to-first-byte – The number of seconds between receiving the request and writing the first byte of the response, as measured on the server.
• x-edge-detailed-result-type – When the result type is an error, this field contains the specific type of error.
• sc-content-type – The value of the HTTP Content-Type header of the response.
• sc-content-len – The value of the HTTP Content-Length header of the response.
• sc-range-start – When the response contains the HTTP Content-Range header, this field contains the range start value.
• sc-range-end – When the response contains the HTTP Content-Range header, this field contains the range end value.

Enabling access logs is free of charge, but standard S3 charges apply for storing the log files. For more information about access logs and the log file format, see Web Distribution Log File Format in the CloudFront documentation.

Amazon CloudFront announces 10 new Edge locations including its first Edge location in Rome, Italy

Date: Nov 26, 2019

Details: Amazon CloudFront announces its first Edge location in Rome, Italy and two additional Edge locations in in Milan, Italy – more than doubling CloudFront’s total capacity within the Italian Peninsula. Furthermore, CloudFront announces additional Edge locations in Kuala Lumpur, Mumbai, Singapore, Sydney, Philadelphia, Newark, Atlanta, Los Angeles and Hillsboro bringing CloudFront’s global network to 210 Points of Presence in 78 cities across 37 countries. For more information on CloudFront’s global infrastructure, go to CloudFront Features.

Amazon CloudFront in China announces support for AWS CloudFormation and real-time metrics in Amazon CloudWatch

Date: Nov 1, 2019

Details: Amazon CloudFront in China announces support for AWS CloudFormation templates and Amazon CloudWatch real-time metrics. With this launch, customers in China can now use CloudFormation templates to create CloudFront distributions with Amazon S3 origins or custom origins. CloudFormation simplifies provisioning and management on AWS. Customers can create templates for their desired service or application architectures and use those templates for reliable and repeatable provisioning. Customers can find sample templates and template snippets on the AWS CloudFormation Templates page. 

In addition, customers in China can now monitor, alarm and receive notifications on the operational performance of CloudFront using CloudWatch in the AWS China (Ningxia) Region. Both features launching today are now available to AWS customers at no additional cost.

To get started with CloudFront in China, go to Amazon CloudFront. For documentation, see Amazon CloudFront in the AWS services in China guide.

AWS for WordPress plugin now available and with new Amazon CloudFront workflow

Date: Oct 30, 2019

Details: Amazon Web Services announces the general availability of the AWS for WordPress plugin. Previously known as the Amazon Polly and Amazon AI plugin, the new AWS for WordPress plugin now provides a workflow to configure an Amazon CloudFront distribution that is highly optimized for WordPress websites.

Amazon CloudFront, AWS’s content delivery network, accelerates the performance of your website by using a global network of 200 edge locations to cache and deliver content closer to your viewers. The plugin’s new CloudFront workflow creates a distribution with multiple cache behaviors, each one tailored to serving varying types of content for the best viewer and administrator experience.

The AWS for WordPress plugin is free to download from the WordPress Plugin Directory; standard charges apply for using AWS services. Existing users of the plugin who want to use the new CloudFront workflow will need to update the IAM policy for their plugin’s IAM user. Refer to the CloudFront Developer Guide for more information about creating an updated IAM policy using the new managed IAM policy named AWSforWordPressPluginPolicy.

Read our blog post for a detailed guide to self-hosting WordPress with AWS and using the new CloudFront workflow within the plugin. Also read our newly updated whitepaper, “WordPress: Best Practices on AWS”, for more information about creating highly-scalable WordPress websites on AWS.

Amazon CloudFront expands to 200 locations with new Edge locations in Colombia, Chile, and Argentina and reduces prices in South America by 56%

Date: Oct 24, 2019

Details: Amazon CloudFront announces its first Edge locations in Colombia, Chile, and Argentina. With these Edge locations, viewers within these countries will see an average of 60% improvement in latency when accessing content through CloudFront. In addition, effective November 1st 2019, CloudFront will reduce the pricing for on-demand data transfer by up to 56% in South America. You can refer to the new South America pricing on the CloudFront pricing page. CloudFront now has 200 Points of Presence in 77 cities across 37 countries. Here is a blog from Jeff Barr about this launch.

Amazon CloudFront announces its first Edge location in Belgium

Date: Oct 21, 2019

Details: Amazon CloudFront announces its first Edge Location in Brussels, Belgium. With this new Edge location, viewers in Belgium will now see up to a 28% improvement in latency when accessing content through CloudFront. In addition to Belgium, CloudFront also added four additional Edge locations in Tokyo, Japan and one Edge location in Frankfurt, Germany. CloudFront now has 197 Points of Presence in 74 cities across 34 countries.

For more information on CloudFront’s global infrastructure, go to CloudFront Features.

Amazon CloudFront announces new Edge location in Shenzhen, China

Date: Sep 19, 2019

Details: Amazon CloudFront announces the launch of a new CloudFront Edge (POP) location in Shenzhen, China. With this new POP operated by Ningxia Western Cloud Data Co. Ltd. (NWCD), CloudFront has 4 POPs in 4 cities across China. With this launch, viewers in Shenzhen would see an improvement of 62% in average latency when accessing content through CloudFront.

To view pricing for CloudFront China delivery, please refer to here. For developer guide, please refer here. To get started, log in to the AWS Management Console and start accelerating your content.

Amazon CloudFront announces its first Edge location in Portugal

Date: Sep 4, 2019

Details: Amazon CloudFront announces its first Edge Location in Lisbon, Portugal. With this new Edge location, viewers in Portugal will now see up to a 60% improvement in latency when accessing content through CloudFront. CloudFront now has 190 Points of Presence in 72 cities across 33 countries. Learn more by reading our announcement.

For more information on CloudFront’s global infrastructure, go to CloudFront Features.

Amazon CloudFront expands presence in the Middle East with first Edge location in Bahrain

Date: Aug 27, 2019

Details: Amazon CloudFront announces its first Edge Location in Manama, Bahrain. With this new Edge location, viewers in Bahrain will now see up to a 40% improvement in latency when accessing content through CloudFront. CloudFront now has 189 Points of Presence spread across 71 cities in 32 countries.

A full list of CloudFront’s global infrastructure is available at CloudFront Features.

Amazon CloudFront announces new Edge location in Israel

Date: Aug 13, 2019

Details: Amazon CloudFront announces presence in Israel with its first Edge location in Tel Aviv. With this new Edge location, CloudFront will deliver up to a 75% reduction in latency for content delivery to the viewers in Israel. CloudFront now has a total of 188 Points of Presence (PoPs) in 70 cities across 31 countries.

To learn more about CloudFront pricing, including pricing for the new Edge location in Israel, visit our pricing page.

Amazon CloudFront Announces Support for Resource-Level and Tag-Based Permissions

Date: Aug 8, 2019

Details: You can now define Identity and Access Management (IAM) policies to specify granular resource-level and tag-based user permission in CloudFront. These new features give you increased flexibility to manage access to your CloudFront distributions.

Previously, you could apply IAM policies to manage user actions in CloudFront, but you couldn’t restrict actions to specific distributions in your account. Now, with resource-level permissions, you can configure IAM policies that reference individual CloudFront distributions—using Amazon Resource Names (ARNs) or wildcards—and specify the users and actions that have permissions on only those distributions. Similarly, with tag-based access control, you can create IAM user policies that allow or deny actions on specific CloudFront distributions based on the tags associated with them.

To get started with this new functionality, see the CloudFront Developer Guide. To learn more about Amazon CloudFront, visit our product page.

Lambda@Edge Adds Support for Python3.7

Date: Aug 1, 2019

Details: Starting today, you can use the Python programming language to develop your functions in Lambda@Edge, in addition to currently supported Node.js. This gives you the flexibility of opting for the programming language of your choice as you author your functions.

To get started, simply upload your function code by using the AWS CLI or AWS Lambda console, select the Python 3.7 runtime, and associate an Amazon CloudFront event. Lambda@Edge functions, triggered by CloudFront events, extend your custom code across AWS locations worldwide, allowing you to run application logic closer to your end users to improve responsiveness.

To learn more about Lambda@Edge, visit the product page. For more information on Lambda’s Python programming model, see the documentation. You can also use these example functions to quickly deploy and test Lambda@Edge functions that you author in Python.

Announcing Enhanced Lambda@Edge Monitoring within the Amazon CloudFront Console.

Date: June 20, 2019

Details: Starting today, you can monitor the Lambda functions associated with your Amazon CloudFront distributions directly from your Amazon CloudFront console for an easier monitoring and debugging experience.

Previously, you had to access the CloudFront and AWS Lambda consoles separately to monitor your distributions and the associated functions. With today's announcement, you get the following benefits on the CloudFront console: 

• A revamped monitoring dashboard that lists all of your CloudFront distributions and associated Lambda@Edge functions. This allows you to quickly select and view both distribution metrics and associated function execution metrics.
• A streamlined distribution metrics view with aggregated Lambda@Edge 5xx errors that are logically grouped by distribution, which makes it easier to distinguish and troubleshoot whether CloudFront 5xx errors are caused by your origins or a Lambda@Edge function.
• A new detailed Lambda@Edge errors view for each distribution that shows a regional breakdown of function error metrics: function execution errors, invalid function response errors, and throttles. If you see a spike in errors in one or more AWS Regions, you can select the Region and view the logs for that Region that are stored in AWS CloudWatch.

Today's announcement does not change any capabilities on the Lambda console. Read our blog for a step-by-step guide to monitoring and debugging your Lambda functions using the CloudFront console.

Visit the CloudFront console to get started. To learn more about Amazon CloudFront, visit our product page.

Amazon CloudFront announces seven new Edge locations in North America, Europe, and Australia.

Date: June 18, 2019

Details: Amazon CloudFront announces seven new Edge locations. Four of the new Edge locations are in North America including Houston, Texas (2) , Hillsboro, Oregon, and Toronto, Ontario. Two locations were added in Europe in Manchester, England, and Zurich, Switzerland while another Edge location was added in Sydney, Australia. The addition of these new Edge locations has doubled our capacity in each city to serve the growing number of viewer requests. A full list of CloudFront’s global locations is available on the CloudFront Features webpage.

Amazon CloudFront announces 11 new Edge locations in India, Japan, and the United States.

Date: May 7, 2019

Details: Amazon CloudFront announces 11 new Edge locations around the world, including its first Edge location in Salt Lake City, Utah. The additions come in the following cities:

United States

• Salt Lake City, Utah (New city within the CloudFront network)
• Boston, Massachusetts
• Seattle, Washington
• Phoenix, Arizona

Japan

• Tokyo

India

• Hyderabad x2
• Bangalore x2
• Delhi x2

The launch of these six new Edge locations in India effectively doubles CloudFront’s capacity within the region. Every new CloudFront Edge location continues to enhance the overall performance of serving your web applications to your users. A full list of CloudFront’s global locations is available on the CloudFront Features webpage.

Amazon CloudFront enhances the security for adding alternate domain names to a distribution.

Date: Apr 8, 2019

Details: Starting today, Amazon CloudFront has made the process of adding an alternate domain name to a distribution even more secure than before. Now, when you add an alternate domain name, like www.example.com, to a distribution, you must also attach a SSL/TLS certificate to that distribution that covers the alternate domain name. With today's release, only those with authorized access to your domain's certificate can add your domain to a CloudFront distribution as an alternate domain name.

Adding alternate domain names to CloudFront allows you to serve your content using a custom CNAME from your DNS records, such as www.example.com, instead of the default domain that CloudFront assigns such as d111111abcdef8.cloudfront.net. With this change, when you add an alternate domain name using the AWS Management Console or the CloudFront API, you will now need to attach a certificate to the distribution to confirm that you have authorized rights to use the alternate domain name. The certificate must be valid and come from a publicly trusted Certificate Authority like AWS Certificate Manager which provides public SSL/TLS certificates for free. All alternate domain names that are already added to a CloudFront distribution before this change goes into effect will continue to work as they were before. No action is required to maintain your traffic as it is today.

To learn more about how this new process works, please read our blog detailing the change as well as the updated CloudFront Developer Guide. To get started with CloudFront, visit our Getting Started page.

Amazon CloudFront announces six new Edge locations across United States and France.

Date: Feb 6, 2019

Details: Amazon CloudFront announces six new Edge locations which add incremental capacity to our network in their respective regions. Five of the new Edge locations are in North America: Atlanta (2), Chicago, Dallas, and Houston. This new capacity increases CloudFront’s request processing capacity by up to 50%, on average, in these areas. The sixth new Edge location is located in Paris, France. As always, every new CloudFront Edge location enhances the delivery and performance of your web applications to your customers. A full list of CloudFront’s global locations is available on the CloudFront Features webpage.

Amazon CloudFront announces ten new Edge locations in North America, Europe, and Asia.

Date: Dec 11, 2018

Details: Amazon CloudFront announces ten new Edge locations, adding to our global presence. Eight of the new Edge locations are in North America: Houston, Texas (our first location in this city), Chicago, Illinois, Newark, New Jersey, Los Angeles, California, and Ashburn, Virginia. We also added an Edge location in Berlin, Germany, as well as one in Tokyo, Japan.

With this launch, CloudFront will increase its request processing capacity by up to 40%, on average, in the North American cities.

These new Edge locations add to CloudFront's existing global presence and enhance delivery, performance, and scale for our customers. A full list of CloudFront’s global locations is available on the CloudFront Features webpage.

Celebrating the 10 year anniversary of Amazon CloudFront by launching six new Edge locations bringing the total to 150 Points of Presence worldwide.

Date: Nov 20, 2018

Details: Amazon CloudFront announces six new Edge locations, across four continents. In the United States, the new locations are in Chicago, Newark, and Ashburn. Internationally, the new locations are in Munich, Tokyo, and Rio de Janerio. Just over one year ago, we announced our 100th Edge location in Tokyo. The addition of these six new locations today now brings CloudFront's total network to 150 Points of Presence worldwide, across 65 cities and 29 countries.

We also just celebrated CloudFront's ten year anniverary a few days ago. Read our blog which dives into the story of how CloudFront was created in response to an internal challenge from Jeff Bezos and Andy Jassy. Thank you for being a part of our evolutionary journey. Here's to the next ten years!

Amazon CloudFront announces support for Origin Failover

Date: Nov 20, 2018

Details: Starting today, you can enable Origin Failover for your Amazon CloudFront distributions to improve the availability of content delivered to your end users.

With CloudFront’s Origin Failover capability, you can setup two origins for your distributions - primary and secondary, such that your content is served from your secondary origin if CloudFront detects that your primary origin is unavailable. CloudFront already allows you to configure custom error pages or generate redirects with Lambda@Edge if your origin is unavailable. Now with Origin Failover, you can easily setup failover logic between combinations of AWS origins or non-AWS custom HTTP origins such that there is minimal interruption to your viewer’s experience. For example, you can have two Amazon S3 buckets that serve as your origin, that you independently upload your content to. If an object that CloudFront requests from your primary bucket is not present or if connection to your primary bucket times-out, CloudFront will request the object from your secondary bucket. So, you can configure CloudFront to trigger a failover in response to either HTTP 4xx or 5xx status codes.

There is no additional fee for using this feature. To learn more about how Origin Failover works on CloudFront, please read our Developer Guide or visit our web page to get started.

Amazon CloudFront announces support for the WebSocket protocol

Date: Nov 20, 2018

Details: You can now use Amazon CloudFront for applications using the WebSocket protocol to provide improved performance and security to your end users.

WebSocket is a real-time communication protocol that provides bidirectional communication between a client (such as a browser) and a server over a long-held TCP connection. By using a persistent open connection, the client and the server can send real-time data to each other without the client having to frequently reinitiate connections checking for new data to exchange. WebSocket connections are often used in chat applications, collaboration platforms, multiplayer games, and financial trading platforms.

With CloudFront’s support for the WebSocket protocol, you can now consolidate your WebSocket traffic through the same CloudFront resource as your other dynamic and static content. You can also use CloudFront’s global edge network to terminate SSL/TLS handshakes for WebSocket connections closer to your users and leverage AWS’ optimized network to improve your application’s responsiveness and reliability. You also get comprehensive DDOS protection by mitigating attacks closer to the source through AWS Shield and AWS WAF being tightly integrated with CloudFront.

You can use WebSockets globally, and no additional configuration is needed to enable the WebSocket protocol within your CloudFront resource as it is now supported by default. There’s no additional charge for sending data over the WebSocket protocol. Standard CloudFront charges apply.

To learn more about using the WebSocket protocol in CloudFront, read our Developer Guide or visit our web page to get started.

Amazon CloudFront announces six new Edge locations across North America, Europe, and Asia

Date: Nov 6, 2018

Details: Amazon CloudFront announces six new Edge locations, adding to our global presence in major cities around the world. The new edge locations are in Hyderabad (2), New Delhi, London (2), and Hillsboro. Both Hyderabad, India and Hillsboro, Oregon are brand new locations. With this launch, CloudFront increases its average request processing capacity in India and the United Kingdom by up to 55%.
Adding these edge locations enhances delivery, performance, and scale for our customers. A full list of CloudFront’s global locations is available on the CloudFront Features webpage.

Amazon CloudFront announces two new Edge locations, including its second location in United Arab Emirates

Date: Oct 12, 2018

Details: Amazon CloudFront announces two new Edge locations: Fujairah, United Arab Emirates and Paris, France. Fujairah is our second Edge location in the United Arab Emirates; the first, Dubai, was launched last month. Customers delivering content within the United Arab Emirates can expect to see up to 90% latency improvements on average. The addition of a new Edge location in Paris, France increases our capacity by 50% within the area. A full list of CloudFront’s global locations is available on the CloudFront Details webpage.

Amazon CloudFront launches second Edge location in New Delhi, India

Date: Sep 12, 2018

Details: Amazon CloudFront announces the addition of a second Edge location in New Delhi, India. Adding this location doubles CloudFront’s capacity in the area for both processing viewer requests and caching content locally. For a full list of CloudFront’s global network, see the CloudFront Details webpage.

Amazon CloudFront Launches First Edge Location in Dubai, United Arab Emirates

Date: Sep 4, 2018

Details: Amazon CloudFront announces its first entry into the Middle East with the launch of an Edge location in Dubai, United Arab Emirates. For a full list of CloudFront’s global network, see the CloudFront Details webpage.

Amazon CloudFront expands in Nordics with first Edge locations in Norway and Denmark

Date: Aug 15, 2018

Details: Amazon CloudFront announces two new Edge locations in Oslo, Norway, and Copenhagen, Denmark. Both of these Edge locations are the first in their respective countries and increase CloudFront’s capacity in the Nordics by 55%. CloudFront’s expansion across the Nordics further improves the availability and performance of content delivery to users in the region. Compared to CloudFront’s performance before the new locations were added, we expect that CloudFront end users will see a 35% reduction in latency for content delivery within Norway and Denmark.

A full list of CloudFront’s global locations is available on the CloudFront Details webpage.

Lambda@Edge Now Provides You Access to the Request Body for HTTP POST/PUT Processing

Date: Aug 14, 2018

Details: Lambda@Edge provides you access to various HTTP attributes such as URI, headers and query strings to customize the content delivered to your end-users. Starting today, you can also access the HTTP request body in your Lambda functions enabling you to execute custom logic and generate a response directly from the edge.

Developers typically use Web/HTML forms or Web Beacons/Bugs as a mechanism to collect data from end users and then process that data at their origins servers. With access to request body from your Lambda functions, you can now offload this logic to the edge and improve end-user latency. For example, if you have a static website with a ‘contact us’ web form, you can make a network call to an Amazon DynamoDB global table to save the data from your Lambda function. Or, if you are collecting end user behavior data through a web beacon on your website, you can directly log it to an Amazon Kinesis Firehose endpoint from the Lambda function, thereby simplifying your origin infrastructure.

There’s no additional fee for using this feature. To learn more about Lambda@Edge, visit the product page. For more information on how to use this new feature, see the following resources:

To get started, see examples of Lambda functions showing how to access and modify request body

Read the blogpost on how to build global data ingestion passthrough with Amazon CloudFront, Lambda@Edge and Amazon Kinesis Firehose

For more information, see the documentation here.

Amazon CloudFront announces nine new Edge locations globally across major cities in North America, Europe, and Asia

Date: Jul 24, 2018

Details: Amazon CloudFront announces nine new Edge locations, adding to our presence in major cities globally. Five new Edge locations are being added in North America: Los Angeles, California; San Jose, California; Newark, New Jersey; Dallas/Fort Worth, Texas; and Miami, Florida. Three new Edge locations are being added in Europe, with two in London, England and one in Frankfurt, Germany. And in Asia, one Edge location is being added in Tokyo, Japan, our ninth in the city.

With this release, CloudFront will increase its request processing capacity by 40%, on average, in the five North American cities and the two cities in Europe.

These additional Edge locations will add to CloudFront's existing global presence and will enhance delivery, performance, and scale for our customers. A full list of CloudFront’s global locations is available on the CloudFront Details webpage.

Amazon CloudFront announces four new Edge locations, including its first location in Cape Town, South Africa

Date: Jul 12, 2018

Details: Amazon CloudFront announces four new Edge locations: Cape Town, South Africa; Denver, Colorado; Frankfurt, Germany; and Taipei, Taiwan. Cape Town is our second Edge location in South Africa, the first being Johannesburg, launched in June 2018. Customers delivering content in South Africa are already seeing up to 75% latency improvements on average. The addition of a new Edge location in Denver, Colorado doubles our capacity in Denver. The new Edge location in Frankfurt is the seventh in the city, while the new Edge location in Taipei is the third in the city. The addition of these locations continues to expand CloudFront's global footprint and capacity, allowing us to deliver better performance and scale for our customers.

A full list of CloudFront’s global infrastructure can be seen on the CloudFront Details webpage.

Amazon CloudFront Expands into Africa with new Edge Location in Johannesburg and first Edge Location in Bangalore

Date: June 14, 2018

Details: Since launching Amazon CloudFront in November 2008, we’ve been continuously expanding our infrastructure footprint around the world to improve availability and performance for content delivery. Today, we’re excited to announce the launch of two new Edge locations: one in Johannesburg, South Africa, and one in Bangalore, India. The Edge location in Johannesburg is Amazon CloudFront’s first PoP on the African continent. The addition of these two locations brings CloudFront’s global network to 119 points of presence in 58 cities, across 26 countries.

Amazon CloudFront’s expansion into South Africa further improves availability and performance of content delivery to viewers in the region. We expect that customers who use Amazon CloudFront to reach viewers in South Africa will see performance improvements of as much as 75% from reductions in latency for their content. The new Bangalore PoP is expected to increase CloudFront capacity in India by up to 25%.

In addition to reducing latency, these Edge locations also bring the full suite of benefits provided by Amazon CloudFront, such as Lambda@Edge, Field Level Encryption, and Amazon S3 Transfer Acceleration, as well as seamless integration with other AWS services like AWS Certificate Manager (ACM), AWS Shield, AWS WAF, AWS Simple Storage Service (S3), and Amazon Elastic Compute Cloud (EC2). These new Edge locations in Johannesburg and Bangalore are built to the same high standards as our other CloudFront Edge locations around the world, including infrastructure and processes that are all compliant with PCI, DSS, HIPAA, and ISO to ensure secure delivery of the most sensitive data.

Information about pricing for CloudFront, including pricing for the new South Africa Edge locations, can be found on the pricing page.

Amazon CloudFront launches eighth Edge location in Tokyo, Japan

Date: May 30, 2018

Details: Amazon CloudFront announces the addition of an eighth Edge location in Tokyo, Japan. The addition of another Edge location continues to expand CloudFront's capacity in the region, allowing us to serve increased volumes of web traffic.

For a full list of CloudFront’s global network, see the CloudFront Details webpage.

Lambda@Edge Adds Support for Node.js v8.10

Date: May 14, 2018

Details:  Starting today, you can use Node.js v8.10 to develop your functions in Lambda@Edge, in addition to the currently supported Node.js v6.10 runtime.

Node.js v8.10, the current Long Term Support (LTS) version of Node, uses the new V8 6.0 engine, that provides better performance when compared to the previous LTS version 6.x. In addition, Node.js v8.10 supports new features such as async/await, which is a new way of handling asynchronous operations in Node.js. This enables you to write simpler, easier, and cleaner code for non-blocking calls. You can read this blog post for more details on the benefits of async/await feature introduced in Node.js v8.10.

To get started, you can simply upload your Node.js code as an AWS Lambda function through the AWS CLI or Lambda console, and select the Node.js 8.10 runtime. If you have existing Node.js functions, you can switch to the new runtime by making any required code changes to ensure compatibility with the new runtime and editing their function configuration to set the runtime to Node.js 8.10.

To learn more about Lambda@Edge, visit the product page. For more information on Lambda’s Node.js programming model, you can refer to the documentation.

Amazon CloudFront launches a third Edge location in Singapore and second Edge location in Taipei, Taiwan

Date: April 25, 2018

Details:  Amazon CloudFront announces the addition of a third Edge Location in Singapore and second Edge location in Taipei, Taiwan. Every Edge Location that we add to the AWS infrastructure increases CloudFront's capacity to serve secure content with low latency and high availability, around the world.

A full list of CloudFront’s global infrastructure can be seen on CloudFront Details webpage.

Lambda@Edge Adds S3 Origin Support for Customizing Content Delivery based on Request Headers.

Date: March 20, 2018

Details: Starting today, Lambda@Edge enables you to further customize the delivery of content stored in an Amazon S3 bucket, by allowing you to access additional whitelisted headers, including custom headers, within origin-facing events. For example, you can configure Amazon CloudFront to cache and forward a country header to your S3 origin, and then use Lambda@Edge to dynamically redirect viewers to country-specific versions of your website, based on the viewer’s location. CloudFront also caches the responses to further improve the performance on subsequent requests to your website.

Until now, you could configure Amazon CloudFront with an S3 origin to forward and to cache objects based on only three headers: Access-Control-Request-Headers, Access-Control-Request-Method, and Origin. This limited the ability to leverage the full potential of Lambda@Edge, as you could only use cookies and query strings when you wanted to customize the delivery of content stored in S3 buckets. However, with this launch, you can now configure CloudFront with an S3 origin to cache and forward several additional headers, such as CloudFront-Viewer-Country or CloudFront-Is-*-Viewer, and then use Lambda@Edge to customize content based on these headers and deliver at low latencies to your viewers. To see all the supported headers, click here.

There is no additional fee for the new capability. To learn more about Lambda@Edge, visit the product page. For more information on how to use this new feature, see the following resources:

• Examples showing personalization of content based on viewer location and viewer device type.
• Example showing content-based dynamic origin selection using headers.  

CloudFront now Supports ECDSA Certificates for HTTPS Connections to Origins

Date: March 15, 2018

Details:  Starting today, you can now use Amazon CloudFront to negotiate HTTPS connections to origins using Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA uses smaller keys that are faster, yet, just as secure, as the older RSA algorithm. The smaller keys will also increase the number of TLS handshakes that your origins can process per second, thereby saving compute cycles and reducing your cost of cryptography. To enable ECDSA, simply configure your origin server to use and prefer an ECDSA certificate. There is no additional fee for using this feature.

To learn more about how ECDSA works on CloudFront, see the blog post and the CloudFront Developer Guide.

Amazon CloudFront launches fourth Edge Location in Seoul, South Korea

Date: February 19, 2018

Details:  Amazon CloudFront announces the addition of a new Edge Location in Seoul, South Korea bringing the total number of Edge Locations in Seoul to four. The addition of this newest Edge Location continues to expand CloudFront's capacity within the region allowing us to serve greater volumes of web traffic.

A full list of CloudFront’s global infrastructure can be seen on the CloudFront Details webpage.

Amazon CloudFront announces six new Edge Locations, adding two more in Tokyo, JP, and its first location in Perth, AU

Date: January 5, 2018

Details:  Amazon CloudFront announces six new Edge Locations that are now part of its global network. These six new Edge Locations are located in the following cities:

Perth, Australia; Chennai, India; Rio De Janeiro, Brazil; Los Angeles, California; and two additional Edge Locations in Tokyo, Japan.

A full list of CloudFront’s global infrastructure can be seen on the CloudFront Details webpage.

Lambda@Edge now Allows you to Customize Error Responses From Your Origin

Date: December 21, 2017

Details: Starting today, Lambda@Edge enables you to customize error responses from your origin, by allowing you to execute Lambda functions in response to HTTP errors that Amazon CloudFront receives from your origin. This means Lambda@Edge functions associated with Amazon CloudFront origin response event will now be invoked for 4XX and 5XX error status codes, in addition to the currently supported 2XX (success) and 3XX (redirection) status codes.

Learn more by reading our announcement.

Introducing Field-Level Encryption on Amazon CloudFront

Date: December 14, 2017

Details:  Starting today, you can use a new Amazon CloudFront capability called Field-Level Encryption to further enhance the security of sensitive data, like credit card numbers or personally identifiable information (PII) like social security numbers. CloudFront’s field-level encryption further encrypts sensitive data in an HTTPS form using field-specific encryption keys (which you supply) before a POST request is forwarded to your origin. This ensures that sensitive data can only be decrypted and viewed by certain components or services in your application stack.

Learn more by reading our announcement.

Amazon CloudFront adds six Edge Locations and expands into four new cities

Date: November 22, 2017

Details:  Today, Amazon CloudFront announces the addition of six new Edge Locations to its global content delivery network. The new Edge Locations are located in: Helsinki, Finland; Madrid, Spain; Manchester, England; Denver, Colorado; Newark, New Jersey; and Phoenix, Arizona.

Four of these Edge Locations (Helsinki, Manchester, Denver, and Phoenix) introduce new cities to CloudFront’s network and each of the six Edge Locations provide additional capacity within their region. A full list of CloudFront’s global infrastructure can be seen on the CloudFront Details webpage.

To learn more about Amazon CloudFront, please visit our Getting Started webpage to see our upcoming webinars and to find helpful resources.

Lambda@Edge Now Supports Content-Based Dynamic Origin Selection, Network Calls from Viewer Events, and Advanced Response Generation

Date: November 21, 2017

Details: Starting today, you can use three new capabilities with Lambda@Edge that can further help you build personalized content for your viewers while improving latency and simplifying your origin infrastructure. First, with content-based dynamic origin selection, you can route requests to different backend origin servers based on request attributes such as viewer location, viewer device type, HTTP headers, URL path, query string or cookies. Second, you can make remote network calls from Amazon CloudFront viewer-facing events. Third, you can generate binary data from your Lambda@Edge functions which lets you deliver richer, more customized content using Amazon CloudFront. We have also increased the limits for Lambda@Edge functions. You can choose up to 1536MB of memory, deploy larger packages up to 50MB, and implement Lambda@Edge functions with longer timeouts – up to 30 seconds.

Learn more by reading our announcement.

Amazon CloudFront opens its 101st Point of Presence by launching its first Edge Location in Palermo, Italy.

Date: November 6, 2017

Details: Just last week we announced our 100th Point of Presence. Today, Amazon CloudFront introduces a brand new city into its network with the launch of our first Edge Location in Palermo, Italy. We now have two Edge Locations in Italy, with the other being in Milan. Our network now has 101 Points of Presence comprised of 90 Edge Locations and 11 Regional Edge Caches. The addition of Palermo, Italy as a new city is the first of many new network expansions to be announced over the coming months.

To learn more about Amazon CloudFront and how to get started, please visit our webpage to see our upcoming webinars.

Amazon CloudFront now has 100 Points of Presence with the Launch of its Fifth Edge Location in Tokyo, Japan.

Date: October 31, 2017

Details: Nearly nine years ago, Amazon Web Services (AWS) announced the launch of Amazon CloudFront, its global Content Delivery Network (CDN). What started as a novel, high-performing edge network with 14 Points of Presence has now grown to support millions of viewers around the world. Today, we are excited to announce our 100th Point of Presence (89 Edge Locations and 11 Regional Edge Caches) in one of Amazon CloudFront’s fastest growing geographies, Japan. Our 100th Point of Presence (POP) is also the fifth Edge Location in Tokyo, and our sixth in Japan.

Amazon CloudFront’s 100 Points of Presence reach around the globe, with sites in 50 cities and 23 countries. In the past year, we have increased the size of our network by more than 50 percent, adding 37 locations. Included among these additions are nine new cities and four new countries*: Berlin, Germany; Minneapolis, Minnesota; Prague, Czech Republic*; Boston, Massachusetts; Munich, Germany; Vienna, Austria*; Kuala Lumpur, Malaysia*; Philadelphia, Pennsylvania; and Zurich, Switzerland*.

During 2016’s re:Invent conference, we announced a new type of caching layer called Regional Edge Caches, which added 11 Points of Presence to our network. These locations have a larger cache-width than our classic Edge Locations and sit between our Edge Locations and the customer’s origin server. This allows us to cache the customer’s content longer and closer to their viewers thus reducing the load on the customer’s origin and making origin fetches faster.

We are honored to work with customers of all sizes around the world. From the individual blogger or small business owner, to the world’s largest corporations, we value each of you and thank you for being a part of our global network!

Thank you,

- The Amazon CloudFront Team

To learn more about Amazon CloudFront and how to get started, please visit our webpage to see our upcoming webinars.

Amazon CloudFront Announces its 99th Point of Presence with its Second Edge Location in Miami, FL.

Date: October 30, 2017

Details: The Amazon CloudFront team is happy to announce its 99th Point of Presence with the addition of a second Edge Location in Miami, Florida. Amazon CloudFront’s 99 Points of Presence includes 88 Edge Locations and 11 Regional Edge Caches. Our network spans across 50 cities in 23 countries around the world. To learn more about Amazon CloudFront, and how to get started, please visit our webpage to see our upcoming webinars.

Amazon CloudFront continues to add capacity to the Nordics, Western Europe, and Western United States with new locations in Stockholm, London, and Dallas!

Date: October 11, 2017

Details: The Amazon CloudFront team is excited to announce three additional Points of Presence located in Stockholm, London, and Dallas. Stockholm now has three Points of Presence, London now has five, and Dallas has four! These three network additions continue to expand Amazon CloudFront’s capacity in reach region, ensuring that each end user’s experience is reliable, secure, and fast.

Amazon CloudFront now has 98 Points of Presence (87 Edge Locations and 11 Regional Edge Caches) in 50 cities across 23 countries. To see a full list of CloudFront locations, please visit our website here. Meet with the CloudFront team in one of our upcoming webinars.

Lambda@Edge Now Provides Access to Query String Parameters, Country and Device Type Headers.

Date: October 10, 2017

Details: Lambda@Edge enables you to personalize content with low latency, without having to manage origin servers. Starting today, Lambda@Edge makes it even easier to further personalize your content by giving you access to additional attributes of the request. You can now access query string parameters, country and device type headers in your AWS Lambda functions. With this capability, for instance, you can redirect your end users to country or language specific versions of your website based on your end user’s location from where the request was made.

There is no additional fee for this feature. To learn more about Lambda@Edge, visit the product page. For more information on how to use this new feature, please see the resources below:

• Example showing personalization of content based on end user location and end user device type
• Learn how to access query string parameters

Amazon CloudFront now lets you select a security policy with minimum TLS v1.1, v1.2, and security ciphers for viewer connections.

Date: September 27, 2017

Details: Starting today, you can further improve security for your web applications on Amazon CloudFront by selecting a pre-defined security policy that enforces TLS version 1.1 or 1.2 as the minimum protocol version. Amazon CloudFront will automatically select the cipher suite for your selected security policy which it will use to encrypt your content before returning it to viewers over HTTPS. For instance, with this feature, you can select the security policy that enforces TLS version 1.1 and weak ciphers such as RC4 and 3DES will automatically be excluded. This feature is available when you use custom SSL certificates to serve HTTPS requests using SNI.

All existing CloudFront distributions that are configured to use custom SSL certificates and to serve HTTPS requests using SNI will default to use TLS version 1.0 and all supported ciphers except RC4. You can choose to change the security policy for these distributions via the CloudFront console or API. Note that this feature applies to the SSL handshake for viewer connections to CloudFront. Customers already had the ability to specify minimum TLS version 1.1 or 1.2 for the handshake between CloudFront and their custom origins.

There is no additional fee for this feature. For more information about the security policies, that enforce the minimum TLS versions and their associated cipher suite, please see the CloudFront documentation.

Coast to coast, Amazon CloudFront launches its first Edge location in Boston, MA and a third in Seattle, WA!

Date: September 22, 2017

Details: The Amazon CloudFront team is excited to announce the expansion of their Edge locations into a new city, Boston, MA! In addition to this new city, a third Edge location is now live in Seattle, Washington. Both of these new Edge locations continue to improve CloudFront’s performance, making your end-user’s experience faster and more reliable.

Amazon CloudFront now has 95 Points of Presence (84 Edge Locations and 11 Regional Edge Caches) in 50 cities across 23 countries. Learn more by reading our announcement.

Announcing Additional Edge Locations in Chicago and Frankfurt for Amazon CloudFront

Date: August 11, 2017

Details:   We are pleased to announce the launch of two additional edge locations for Amazon CloudFront, Chicago, Illinois and Frankfurt, Germany. Chicago now has two edge locations while Frankfurt now has six. Each new edge location improves CloudFront’s performance and availability experienced by your application’s end-users.

With the addition of these two locations, the total number of Amazon CloudFront locations is now 93 (including 82 Edge Locations and 11 Regional Edge Cache locations). Learn more by reading our announcement.

Announcing Third Edge Location in Paris, France for Amazon CloudFront

Date: August 4, 2017

Details:  We are happy to announce the launch of our third edge location in Paris, France! This brings Amazon CloudFront's total edge locations to 91 (including 80 Edge Locations and 11 Regional Edge Cache locations). Learn more by reading our announcement.

Announcing Second Edge Location in Stockholm, Sweden for Amazon CloudFront

Date: July 21, 2017

Details:  We are excited to announce a new edge location for Amazon CloudFront in Stockholm, Sweden. This is our second edge location in the Stockholm area, bringing the total number of CloudFront locations to 90 (including 79 points of presence and 11 regional edge cache locations). Learn more by reading our announcement.

Announcing New Edge Location for Amazon CloudFront and Amazon Route 53 in Kuala Lumpur, Our First in Malaysia

Date: July 20, 2017

Details: We are pleased to announce the launch of our newest edge location for Amazon CloudFront and Amazon Route 53 in Kuala Lumpur, our first edge location in Malaysia. With the addition of this location in Malaysia, we are bringing the total number of Amazon CloudFront locations to 89 (including 78 points of presence and 11 regional edge cache locations). Learn more by reading our announcement.

Lambda@Edge is now generally available

Date: July 17, 2017

Lambda@Edge is now generally available for all customers. You can use this new AWS Lambda feature to run Node.js functions across AWS locations globally without provisioning or managing servers, allowing you to deliver richer, more personalized content with low latency to your customers.

You just upload your code to AWS Lambda and configure it to be triggered by Amazon CloudFront events (i.e., viewer request, viewer response, origin request, and origin response). When a related request is received by CloudFront, it is routed to the optimal AWS location close to the viewer for execution. Lambda@Edge then executes your code, and scales with the volume of requests across CloudFront’s global network. With Lambda@Edge, you can run code to customize web pages based on each individual request, create custom authentication logic that executes globally and simplify the delivery of secure custom headers. In addition, you can now make remote network calls to access resources on the internet on origin facing events, and generate dynamic web content from scratch realtime and inline with your requests. Together, this functionality allows customers to deliver richer, more personalized content at low latencies for their end users.

Lambda@Edge functions can now be authored in US East (N. Virginia), and will be replicated globally for invocation in response to CloudFront events.

To learn more about how Lambda@Edge helps developers, visit our documentation.

Amazon CloudFront is now a HIPAA eligible service

Date: June 1, 2017

AWS has expanded its HIPAA Compliance Program to include Amazon CloudFront as a HIPAA eligible service. If you have an executed Business Associate Agreement (BAA) with AWS, you can now use Amazon CloudFront to accelerate the delivery of protected health information (PHI). Information on HIPAA eligible services on AWS can be found at our HIPAA Compliance page.

If you already have an executed BAA with AWS, you can start using Amazon CloudFront immediately with the accounts that your BAA covers. If you don’t have an executed BAA with AWS or have any other questions about HIPAA eligible services on AWS, contact us and we will put you in touch with a representative from our AWS sales team.

To learn more about Amazon CloudFront and building healthcare applications on AWS, visit the Amazon CloudFront documentation and the AWS Cloud Computing in Healthcare page.

Announcing Second Edge Location in Seattle, Washington for Amazon CloudFront 

Date: May 23, 2017

Details:  We are excited to announce a new edge location for Amazon CloudFront in Seattle, Washington. Each new edge location helps improve performance and availability for end users of your application. This is our second edge location in the Seattle area, bringing the total number of CloudFront locations to 88 (including 77 points of presence and 11 regional edge cache locations). Learn more by reading our announcement.

Amazon CloudFront adds new Edge Locations in Tokyo, Japan and Dallas/Fort Worth, Texas 

Date: May 9, 2017

Details:  We are excited to announce new edge locations for Amazon CloudFront in Tokyo, Japan and Dallas/Fort Worth, Texas. Each new edge location helps improve performance and availability for end users of your application. Learn more by reading our announcement.

Announcing Third Edge Location in Atlanta, Georgia for Amazon CloudFront  

Date: April 21, 2017

Details:  We are excited to announce a new edge location for Amazon CloudFront in Atlanta, Georgia. Each new edge location helps improve performance and availability for end users of your application. This is our third edge location in the Atlanta area, bringing the total number of CloudFront locations to 85 (including 74 points of presence and 11 regional edge cache locations). Learn more by reading our announcement.

Configure Read Timeout and Keep-Alive Timeout values for your Amazon CloudFront Custom Origins

Date: March 30, 2017

Details:  We are pleased to announce that starting today you can configure the read and keep-alive idle timeout values used by Amazon CloudFront when communicating with custom origins. You can increase or lower either of these values based on the needs of your applications. Learn more by reading our announcement.

Announcing New Edge Location in Zurich, Our First in Switzerland

Date: March 15, 2017

Details:  We are pleased to announce the launch of our newest edge location in Zurich, our first edge location in Switzerland. With the addition of a new edge location in Zurich, Amazon CloudFront now has a total of 73 edge locations worldwide. Learn more by reading our announcement.

Announcing New Edge Location in Prague, Our First in Czech Republic

Date: March 8, 2017

Details:  We are pleased to announce the launch of our newest edge location in Prague, our first edge location in Czech Republic. With the addition of a new edge location in Prague, Amazon CloudFront now has a total of 72 edge locations worldwide. Learn more by reading our announcement.

New Edge Location in Philadelphia, Pennsylvania for Amazon CloudFront

Date: February 24, 2017

Details: We are pleased to announce that we’ve added a new edge location in Philadelphia, Pennsylvania for Amazon CloudFront. With the addition of the Philadelphia edge location, there are now a total of 24 edge locations in the US and 71 worldwide. Learn more by reading our announcement.

Lambda@Edge adds support for Response Generation and Custom Logging

Date: February 8, 2017

Details: Today, we are excited to announce two new features, Response Generation and Custom Logging that Lambda@Edge functions now support. Using Response Generation, Lambda@Edge now allows you to write Lambda functions that can generate an HTTP response to end user requests arriving at AWS edge locations. In addition, your Lambda@Edge functions can now contain custom logging statements, giving you the ability to write these logs to Amazon CloudWatch to help debug and monitor your Lambda@Edge functions as they execute at edge locations. Learn more by reading our announcement. To sign up for the preview, please visit Lambda@Edge Preview page.

Announcing New Edge Location in Vienna, Our First in Austria

Date: February 7, 2017

Details:  We are pleased to announce the launch of our newest edge location in Vienna, our first edge location in Austria. With the addition of a new edge location in Vienna, Amazon CloudFront now has a total of 70 edge locations worldwide. Learn more by reading our announcement.

Announcing New Munich Edge Location for Amazon CloudFront, our 7th Edge Location in Germany

Date: January 25, 2017

Details: We are pleased to announce that we’ve added a new edge location in Munich, Germany for Amazon CloudFront. The Munich location is our third location in Germany (joining Frankfurt and Berlin), and our 7th edge location in Germany bringing the total number of worldwide edge locations to 69. Learn more by reading our announcement.

Introducing Lambda@Edge in Preview – Run Lambda functions at AWS’s edge locations closest to your users

Date: December 1, 2016

Details: Lambda@Edge, now in Preview, allows you to write functions deployed to the AWS network of Edge locations in response to CloudFront. This new feature allows you to customize or personalize content for your end users close to where they’re located, minimizing network latency. For instance, you can modify HTTP headers to personalize your application for each user, implement custom authentication or encryption logic right at the edge, detect and group users by device, support legacy devices by reformatting content on the viewer response, and much more.

Lambda@Edge is integrated with Amazon CloudFront and uses CloudFront events as triggers to execute functions automatically at AWS’s edge locations, without the need for you to run or manage servers. Just write and upload your Node.js function using the Lambda console and select your CloudFront trigger event. Lambda@Edge will take care of distributing your function to the edge locations closest to your end users. Just as with Lambda today, you pay a fee each time your function executes and for the compute time you consume - there is no charge when your function is not running.

For more information on Lambda@Edge click here. For additional details and service limits, see the CloudFront Developer Guide. To sign-up for the public preview click here. 

Announcing Regional Edge Caches for Amazon CloudFront

Date: November 29, 2016

Details: Today, we are pleased to announce that Amazon CloudFront has added a new type of edge location called Regional Edge Cache that further improves performance for your viewers. Regional Edge Caches, in addition to improving performance, also help reduce the load on your origin resources, minimizing operational burden associated with scaling your origin and reducing your origin costs. The nine new Regional Edge Cache locations are in Northern Virginia, Oregon, São Paulo, Frankfurt, Singapore, Seoul, Tokyo, Mumbai, and Sydney.

Regional Edge Caches are turned on by default for your CloudFront distributions; you do not need to make any changes to your distributions to take advantage of this feature. There are also no additional charges to use this feature. Learn more by reading our announcement.

Amazon CloudFront adds new Edge Locations in Minneapolis, MN, Berlin, Germany and our Fourth in London, England

Date: November 23, 2016

Details: We are excited to announce new edge locations in the cities of Minneapolis, Minnesota and Berlin, Germany. We have also added a fourth edge location in London, England. This brings the total number of worldwide edge locations to 68. Learn more by reading our announcement.

Announcing Our Third Edge Location in Hong Kong for Amazon CloudFront

Date: November 18, 2016

Details: We are excited to announce a new edge location in Hong Kong for Amazon CloudFront. This is the third edge location in Hong Kong which brings the total number of worldwide edge locations to 65. Learn more by reading our announcement.

Announcing Our Fourth Edge Location in Japan for Amazon CloudFront

Date: November 11, 2016

Details: We are excited to announce a new edge location in Tokyo, Japan (Asia-Pacific) for Amazon CloudFront. This is the third edge location in Tokyo and fourth in Japan which brings the total number of worldwide edge locations to 64. Learn more by reading our announcement.

Bring Your Own SSL/TLS Certificates with AWS Certificate Manager

Date: October 21, 2016

Details: You can now use AWS Certificate Manager (ACM) to import an SSL/TLS certificate issued by a third-party Certificate Authority (CA), and associate that certificate with your CloudFront distributions within minutes. You can use the AWS Management Console to monitor the expiration date of your imported certificate, and import a new third-party certificate to replace the expiring one. Importing certificates doesn't cost anything. You pay only for the AWS resources you utilize to run your application. Note that CloudFront still supports using certificates that you uploaded to the Identity and Access Management (IAM) certificate store. Please check out the ACM announcement and the documentation for more details on prerequisites for importing certificates.

Announcing Internet Protocol Version 6 (IPv6) support for Amazon CloudFront

Date: October 6, 2016

Details: We are pleased to announce that starting today you can use Amazon CloudFront to deliver your content both via IPv6 and IPv4 using HTTP/HTTPS.

IPv6 will be enabled by default for all newly created Amazon CloudFront web distributions starting today. For existing web distributions, you can enable IPv6 through the Amazon CloudFront console or API. Viewers and networks that connect to Amazon CloudFront edge locations over IPv6 will automatically be served content over IPv6. Those that connect over IPv4 will continue to work. Connections to your origin servers will remain on IPv4.

We are enabling IPv6 across every Autonomous Systems (AS) in a phased rollout starting today and expect to complete rollout across all networks over the next few weeks. To learn more about IPv6 support in Amazon CloudFront, see the Amazon CloudFront Developer Guide and FAQ.

Announcing Two New Edge Locations in Frankfurt, Germany for Amazon CloudFront

Date: September 23, 2016

Details: We are excited to announce two new edge locations in Frankfurt, Germany for Amazon CloudFront. Frankfurt city now has five edge locations which brings the total number of worldwide edge locations to 63. Learn more by reading our announcement.

Announcing Second Edge Location in Mumbai, India (Asia-Pacific) for Amazon CloudFront

Date: September 19, 2016

Details: We are excited to announce a new edge location in Mumbai, India (Asia-Pacific) for Amazon CloudFront. This is the second edge location in Mumbai and brings the total number of worldwide edge locations to 61. Learn more by reading our announcement.

Announcing Second Edge Location in Atlanta, Georgia for Amazon CloudFront

Date: September 12, 2016

Details: We are excited to announce a new edge location in Atlanta, Georgia for Amazon CloudFront. This is the second edge location in Atlanta and brings the total number of worldwide edge locations to 60. Learn more by reading our announcement.

Amazon CloudFront now supports HTTP/2

Date: September 7, 2016

Details: We are pleased to announce that you can now enable HTTP/2 for your Amazon CloudFront distributions to improve the performance of your web content delivered to clients that support the new HTTP/2 protocol.

HTTP/2, an upgraded version of HTTP, supports multiplexing, header compression and stream priority that make the page loading and rendering faster. HTTP/2 is enabled by default for all new Amazon CloudFront distributions, and for existing distributions HTTP/2 can be enabled by editing their distribution configuration. There is no additional charge for using this feature, and clients that do not support HTTP/2 will still be able to communicate with HTTP/2-enabled Amazon CloudFront distributions using HTTP/1.1.

To learn more about HTTP/2, see Supported HTTP Versions in the Amazon CloudFront Developer Guide.

 Announcing Query String Whitelisting for Amazon CloudFront

Date: August 30, 2016

Details: Amazon CloudFront now lets you specify a whitelist of the query string parameters that you want Amazon CloudFront to use for caching, while still forwarding all the parameters to the Origin. Caching based on selected query string parameters can significantly improve performance to your end users by improving the cache-hit ratio and reducing the load on your origin.

To learn more about query string whitelisting, see Configuring CloudFront to Cache Based on Query String Parameters in the Amazon CloudFront Developer Guide. To learn more about Amazon CloudFront, see the Amazon CloudFront product page.

 Announcing Cost Allocation Tagging for Amazon CloudFront

Date: August 9, 2016

Details: We are pleased to announce that you can now add cost allocation tags to your Amazon CloudFront distributions. Tags make it easier for you to allocate costs and optimize spending by categorizing and grouping AWS resources. For example, you can use tags to group resources by administrator, application name, cost center, or a specific project.

To learn more about cost allocation tagging, see Using Cost Allocation Tags. If you are ready to add tags to you CloudFront distributions, see Amazon CloudFront Add Tags page.

New Edge Locations in Montreal and Toronto, Our First in Canada

Date: August 8, 2016

Details: We are pleased to announce the launch of our newest edge locations in Toronto and Montreal, our first edge locations in Canada. We have also added a second edge location in Sao Paolo, Brazil, our third edge location in Brazil.

With the addition of the new locations in Canada and the second edge location in Sao Paolo, Amazon CloudFront now has a total of 59 edge locations worldwide. To see a list of all Amazon CloudFront global edge locations, please see our edge location list. To learn more about the service, register and attend a monthly office hour session that includes Q&A with Amazon CloudFront Engineers and Product Managers.  

Announcing New Delhi, India Edge Location for Amazon CloudFront

Date: June 14, 2016

Details: We are pleased to announce that we’ve added a new edge location in New Delhi, India for Amazon CloudFront and Amazon Route 53. The New Delhi location is our third edge location in India (joining Mumbai and Chennai), and brings the total number of worldwide edge locations to 56. To see a list of Amazon CloudFront global edge locations, please see our edge location list here.

Announcing Third Edge Location in Seoul, Korea for Amazon CloudFront

Date: May 13, 2016

Details: We are excited to announce a new edge location in Seoul, Korea for Amazon CloudFront. This is the third edge location in Seoul, Korea and brings the total number of worldwide edge locations to 55. Learn more by reading our announcement.

Amazon CloudFront Integrates with AWS Certificate Manager

Date: January 21, 2016

Details: You can now provision SSL/TLS certificates and associate them with CloudFront distributions within minutes. Simply provision a certificate using the new AWS Certificate Manager (ACM) and deploy it to your CloudFront distribution with a couple of clicks, and let ACM manage certificate renewals for you. ACM allows you to provision, deploy, and manage the certificate with no additional charges.

Note that CloudFront still supports using certificates that you obtained from a third-party certificate authority and uploaded to the IAM certificate store. Please check out Jeff Barr’s blog for more details.

Now enforce HTTPS Connections and Support for TLSv1.1 & TLSv1.2 Between Amazon CloudFront & Origin

Date: January 13, 2016

Details: Now you can configure CloudFront to connect to your origin server using HTTPS regardless of whether the viewer made the request by using HTTP or HTTPS.  

You can also enable TLSv1.1 and TLSv1.2 between CloudFront and your origin server. As part of this feature, you can also choose the protocols that CloudFront uses when communicating with your origin: SSLv3, TLSv1.0, TLSv1.1, and/or TLSv1.2.

For more details on these new CloudFront origin security features, you can read more here.

Now Add or Modify Request Headers Forwarded From Amazon CloudFront to Origin

Date: December 28, 2015

Details: You can now configure Amazon CloudFront to add custom headers, or override the value of existing headers, to requests forwarded to your origin. You can use these headers to help validate that requests made to your origin were sent from CloudFront; you can even configure your origin to only allow requests that contain the custom header values you specify. Additionally, if you use multiple CloudFront distributions with the same origin, you can use custom headers to distinguish origin request made by each different distribution. Finally, custom headers can be used to help determine the right CORS headers returned for your requests. You can configure custom headers via the CloudFront API and the AWS Management Console. There are no additional charges for this feature.

For more details on how to set your custom headers, you can read more here.

Amazon CloudFront Now Supports Automatic Gzip Compression at the Edge

Date: December 17, 2015

Details: You can now configure Amazon CloudFront to automatically apply GZIP compression when browsers and other clients request a compressed object with text and other compressible file formats. This means that if you are already using Amazon S3, CloudFront can transparently compress this type of content. For origins outside S3, doing compression at the edge means you don’t need to use resources at your origin to do compression. The resulting smaller size of compressed objects makes downloads faster and reduces your CloudFront data transfer charges.

To learn more about this feature please visit the gzip section of the CloudFront developer guide

New Edge Location in Chicago, Illinois for Amazon CloudFront and Amazon Route 53

Date: December 1, 2015

Details: We are pleased to announce that we’ve added a new edge location in Chicago, Illinois for Amazon CloudFront and Amazon Route 53. The new edge location helps improve performance and availability for end users of your application and supports all Amazon CloudFront and Amazon Route 53 features at no additional cost. With the addition of the Chicago edge location, there are now a total of 21 edge locations in the US and 54 worldwide.

To see a list of Amazon CloudFront global edge locations, please see our edge location list here.

Control Access to your CloudFront Content with AWS WAF

Date: October 6, 2015

Details: You can now integrate your CloudFront web distribution with AWS WAF, a web application firewall that helps protect web applications from attacks by allowing you to configure rules based on IP addresses, HTTP headers, and custom URI strings. Using these rules, AWS WAF can block, allow, or monitor (count) web requests for your web application.

With AWS WAF you pay only for what you use. AWS WAF pricing is based upon how many rules you deploy and how many web requests your web application receives. There are no minimum fees and no upfront commitments. Learn more by reading Jeff Barr's blog post.

Amazon CloudFront is Now Included in the Set of Services That Are PCI DSS Compliant.

Date: August 4, 2015

Details: Amazon CloudFront is now included in the set of services that are compliant with the Payment Card Industry Data Security Standard (PCI DSS) Merchant Level 1, the highest level of compliance for service providers.

PCI DSS compliance is a requirement for any business that stores, processes, or transmits credit card data. Amazon CloudFront's PCI compliance now makes it easier for retail e-commerce, travel booking, ticket sale, or in-app purchase applications to integrate Amazon CloudFront as a part of their architecture and adhere to PCI DSS. Because Amazon CloudFront supports dynamic and static content delivery, customers such as e-commerce businesses can use the same secure service for whole site delivery to accelerate both the browsing and shopping cart experience for their site visitors.

To learn more about Amazon CloudFront's PCI DSS compliance, please read our blog announcement.

Amazon CloudFront Now Support Configrable Default TTL and Max TTL

Date: June 17, 2015

Details: Amazon CloudFront now lets you configure a maximum time-to-live (TTL) and a default TTL to specify how long CloudFront caches your objects in edge locations. Previously, Amazon CloudFront allowed you to configure the minimum TTL. With these new features, you can get even more granular control over the duration of CloudFront caching. Learn more by reading the announcement.

Amazon CloudFront Makes it Easier to Invalidate Multiple Objects

Date: May 21, 2015

Details: Amazon CloudFront’s invalidation feature, which allows you to remove an object from the CloudFront cache before it expires, now supports the * wildcard character. You can add a * wildcard character at the end of an invalidation path to remove all objects that match this path. In the past, when you wanted to invalidate multiple objects, you had to list every object path separately. Now, you can easily invalidate multiple objects using the * wildcard character. Learn more by reading our announcement.

New Amazon CloudFront Devices Report, CSV Export Functionality, & More

Date: March 25, 2015

Details: You can now learn more about the devices your end users use to access content Amazon CloudFront is delivering. The new Devices Report shows you how many requests come from mobile, tablets, desktops, and smart TVs during a specified time period. We’ve also made several other improvements to the Reports & Analytics section of the AWS Management Console easier to use including CSV export functionality. Learn more by reading our announcement.

Announcement: Announcing Support for Smart TV Device Detection

Date: March 13, 2015

Details: You can now use Amazon CloudFront to cache and deliver customized content to your viewers on a Smart TV based on the value of the User Agent header. Learn more by reading about this topic in the Amazon CloudFront Developer Guide.

Amazon CloudFront Adds Signed Cookies for Private Content

Date: March 12, 2015

Details: Amazon CloudFront now gives you a new way to secure your private content: CloudFront signed HTTP cookies. In the past, you could control who is able to access your CloudFront content by adding a custom signature to each object URL. Now you can get that same degree of control by including the signature in an HTTP cookie instead. Learn more by reading our announcement.

Announcing Second Edge Location in Seoul, Korea for Amazon CloudFront and Route 53

Date: January 26, 2015

Details: We are excited to announce a new edge location in Seoul, Korea for Amazon CloudFront and Route 53. This is the second edge location in Seoul, Korea and brings the total number of worldwide edge locations to 53. Learn more by reading our announcement.