

# What is Amazon CloudFront?
<a name="Introduction"></a>

Amazon CloudFront is a web service that speeds up distribution of your static and dynamic web content, such as .html, .css, .js, and image files, to your users. CloudFront delivers your content through a worldwide network of data centers called edge locations. When a user requests content that you're serving with CloudFront, the request is routed to the edge location that provides the lowest latency (time delay), so that content is delivered with the best possible performance.
+ If the content is already in the edge location with the lowest latency, CloudFront delivers it immediately.
+ If the content is not in that edge location, CloudFront retrieves it from an origin that you've defined—such as an Amazon S3 bucket, a MediaPackage channel, or an HTTP server (for example, a web server) that you have identified as the source for the definitive version of your content.

As an example, suppose that you're serving an image from a traditional web server, not from CloudFront. For example, you might serve an image, sunsetphoto.png, using the URL `https://example.com/sunsetphoto.png`.

Your users can easily navigate to this URL and see the image. But they probably don't know that their request is routed from one network to another—through the complex collection of interconnected networks that comprise the internet—until the image is found.

CloudFront speeds up the distribution of your content by routing each user request through the AWS backbone network to the edge location that can best serve your content. Typically, this is a CloudFront edge server that provides the fastest delivery to the viewer. Using the AWS network dramatically reduces the number of networks that your users' requests must pass through, which improves performance. Users get lower latency—the time it takes to load the first byte of the file—and higher data transfer rates.

You also get increased reliability and availability because copies of your files (also known as *objects)* are now held (or cached) in multiple edge locations around the world. 

**Topics**
+ [

## How you set up CloudFront to deliver content
](#HowCloudFrontWorksOverview)
+ [

## Choose between standard distribution or multi-tenant distribution
](#choose-standard-or-multi-tenant)
+ [

## Pricing
](#pricing)
+ [

# Ways to use CloudFront
](IntroductionUseCases.md)
+ [

# How CloudFront delivers content
](HowCloudFrontWorks.md)
+ [

# Locations and IP address ranges of CloudFront edge servers
](LocationsOfEdgeServers.md)
+ [

# Using CloudFront with an AWS SDK
](sdk-general-information-section.md)
+ [

## CloudFront technical resources
](#resources-cloudfront)

## How you set up CloudFront to deliver content
<a name="HowCloudFrontWorksOverview"></a>

You create a CloudFront distribution to tell CloudFront where you want content to be delivered from, and the details about how to track and manage content delivery. Then CloudFront uses computers—edge servers—that are close to your viewers to deliver that content quickly when someone wants to see it or use it.

![\[How CloudFront works\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/images/how-you-configure-cf.png)
<a name="HowCloudFrontWorksConfiguration"></a>

**How you configure CloudFront to deliver your content**

1. You specify *origin servers*, like an Amazon S3 bucket or your own HTTP server, from which CloudFront gets your files which will then be distributed from CloudFront edge locations all over the world. 

   An origin server stores the original, definitive version of your objects. If you're serving content over HTTP, your origin server is either an Amazon S3 bucket or an HTTP server, such as a web server. Your HTTP server can run on an Amazon Elastic Compute Cloud (Amazon EC2) instance or on a server that you manage; these servers are also known as *custom origins.*

1. You upload your files to your origin servers. Your files, also known as *objects*, typically include web pages, images, and media files, but can be anything that can be served over HTTP.

   If you're using an Amazon S3 bucket as an origin server, you can make the objects in your bucket publicly readable, so that anyone who knows the CloudFront URLs for your objects can access them. You also have the option of keeping objects private and controlling who accesses them. See [Serve private content with signed URLs and signed cookies](PrivateContent.md). 

1. You create a CloudFront *distribution*, which tells CloudFront which origin servers to get your files from when users request the files through your web site or application. At the same time, you specify details such as whether you want CloudFront to log all requests and whether you want the distribution to be enabled as soon as it's created.

1. CloudFront assigns a domain name to your new distribution that you can see in the CloudFront console, or that is returned in the response to a programmatic request, for example, an API request. If you like, you can add an alternate domain name to use instead.

1. CloudFront sends your distribution's configuration (but not your content) to all of its *edge locations* or *points of presence* (POPs)— collections of servers in geographically-dispersed data centers where CloudFront caches copies of your files.

As you develop your website or application, you use the domain name that CloudFront provides for your URLs. For example, if CloudFront returns `d111111abcdef8.cloudfront.net` as the domain name for your distribution, the URL for logo.jpg in your Amazon S3 bucket (or in the root directory on an HTTP server) is `https://d111111abcdef8.cloudfront.net/logo.jpg`.

Or you can set up CloudFront to use your own domain name with your distribution. In that case, the URL might be `https://www.example.com/logo.jpg`.

Optionally, you can configure your origin server to add headers to the files, to indicate how long you want the files to stay in the cache in CloudFront edge locations. By default, each file stays in an edge location for 24 hours before it expires. The minimum expiration time is 0 seconds; there isn't a maximum expiration time. For more information, see [Manage how long content stays in the cache (expiration)](Expiration.md).

## Choose between standard distribution or multi-tenant distribution
<a name="choose-standard-or-multi-tenant"></a>

CloudFront offers distribution options for single websites or apps, and for multi-tenant scenarios.

**Standard distribution**  
Designed for unique configurations per website or application. Choose this in the following use cases:  
+ You need a standalone CloudFront distribution
+ Each site or application requires its own custom settings
Most people start with a standard distribution.

**Multi-tenant distribution and distribution tenants (CloudFront SaaS Manager)**  
Designed specifically for SaaS providers and multi-tenant scenarios. Choose this in the following use cases:  
+ You're building a SaaS platform to serve multiple customer websites or applications
+ You need to manage multiple similar distributions efficiently
+ You want centralized control over shared configurations
For more information, see [Understand how multi-tenant distributions work](distribution-config-options.md).

## Pricing
<a name="pricing"></a>

CloudFront charges for data transfers out from its edge locations, along with HTTP or HTTPS requests. Pricing varies by usage type, geographical region, and feature selection.

The data transfer from your origin to CloudFront is always free when using AWS origins like Amazon Simple Storage Service (Amazon S3), Elastic Load Balancing, or Amazon API Gateway. You are only billed for the outbound data transfer from CloudFront to the viewer when using AWS origins.

For more information, see [CloudFront pricing](https://aws.amazon.com/cloudfront/pricing/) and the Billing and Savings Bundle [FAQs](https://aws.amazon.com/cloudfront/faqs/).

# Ways to use CloudFront
<a name="IntroductionUseCases"></a>

Using CloudFront can help you accomplish a variety of goals. This section lists just a few, together with links to more information, to give you an idea of the possibilities.

**Topics**
+ [

## Accelerate static website content delivery
](#IntroductionUseCasesStaticWebsite)
+ [

## Serve video on demand or live streaming video
](#IntroductionUseCasesStreaming)
+ [

## Encrypt specific fields throughout system processing
](#IntroductionUseCasesFieldLevelEncryption)
+ [

## Customize at the edge
](#IntroductionUseCasesProgrammableCDN)
+ [

## Serve private content by using Lambda@Edge customizations
](#IntroductionUseCasesPrivateContentAtTheEdge)

## Accelerate static website content delivery
<a name="IntroductionUseCasesStaticWebsite"></a>

CloudFront can speed up the delivery of your static content (for example, images, style sheets, JavaScript, and so on) to viewers across the globe. By using CloudFront, you can take advantage of the AWS backbone network and CloudFront edge servers to give your viewers a fast, safe, and reliable experience when they visit your website.

A simple approach for storing and delivering static content is to use an Amazon S3 bucket. Using S3 together with CloudFront has a number of advantages, including the option to use [origin access control](private-content-restricting-access-to-s3.md) to easily restrict access to your Amazon S3 content.

For more information about using Amazon S3 together with CloudFront, including an CloudFormation template to help you get started quickly, see [Get started with a secure static website](getting-started-secure-static-website-cloudformation-template.md).

## Serve video on demand or live streaming video
<a name="IntroductionUseCasesStreaming"></a>

CloudFront offers several options for streaming your media to global viewers—both pre-recorded files and live events.
+ For video on demand (VOD) streaming, you can use CloudFront to stream in common formats such as MPEG DASH, Apple HLS, Microsoft Smooth Streaming, and CMAF, to any device.
+ For broadcasting a live stream, you can cache media fragments at the edge, so that multiple requests for the manifest file that delivers the fragments in the right order can be combined, to reduce the load on your origin server.

For more information about how to deliver streaming content with CloudFront, see [Video on demand and live streaming video with CloudFront](on-demand-streaming-video.md).

## Encrypt specific fields throughout system processing
<a name="IntroductionUseCasesFieldLevelEncryption"></a>

When you configure HTTPS with CloudFront, you already have secure end-to-end connections to origin servers. When you add field-level encryption, you can protect specific data throughout system processing in addition to HTTPS security, so that only certain applications at your origin can see the data.

To set up field-level encryption, you add a public key to CloudFront, and then specify the set of fields that you want to be encrypted with the key. For more information, see [Use field-level encryption to help protect sensitive data](field-level-encryption.md).

## Customize at the edge
<a name="IntroductionUseCasesProgrammableCDN"></a>

Running serverless code at the edge opens up a number of possibilities for customizing the content and experience for viewers, at reduced latency. For example, you can return a custom error message when your origin server is down for maintenance, so viewers don't get a generic HTTP error message. Or you can use a function to help authorize users and control access to your content, before CloudFront forwards a request to your origin.

Using Lambda@Edge with CloudFront enables a variety of ways to customize the content that CloudFront delivers. To learn more about Lambda@Edge and how to create and deploy functions with CloudFront, see [Customize at the edge with Lambda@Edge](lambda-at-the-edge.md). To see a number of code samples that you can customize for your own solutions, see [Lambda@Edge example functions](lambda-examples.md).

## Serve private content by using Lambda@Edge customizations
<a name="IntroductionUseCasesPrivateContentAtTheEdge"></a>

Using Lambda@Edge can help you configure your CloudFront distribution to serve private content from your own custom origin, in addition to using signed URLs or signed cookies.

To serve private content using CloudFront, you do the following:
+ Require that your users (viewers) access content using [signed URLs or signed cookies](PrivateContent.md).
+ Restrict access to your origin so that it's only available from CloudFront's origin-facing servers. To do this, you can do one of the following:
  + For an Amazon S3 origin, you can [use an origin access control (OAC)](private-content-restricting-access-to-s3.md).
  + For a custom origin, you can do the following:
    + If the custom origin is protected by an Amazon VPC security group or AWS Firewall Manager, you can [use the CloudFront managed prefix list](LocationsOfEdgeServers.md#managed-prefix-list) to allow inbound traffic to your origin from only CloudFront's origin-facing IP addresses.
    + Use a custom HTTP header to restrict access to only requests from CloudFront. For more information, see [Restrict access to files on custom origins](private-content-overview.md#forward-custom-headers-restrict-access) and [Add custom headers to origin requests](add-origin-custom-headers.md). For an example that uses a custom header to restrict access to an Application Load Balancer origin, see [Restrict access to Application Load Balancers](restrict-access-to-load-balancer.md).
    + If the custom origin requires custom access control logic, you can use Lambda@Edge to implement that logic, as described in this blog post: [Serving Private Content Using Amazon CloudFront & Lambda@Edge](https://aws.amazon.com/blogs/networking-and-content-delivery/serving-private-content-using-amazon-cloudfront-aws-lambdaedge/).

# How CloudFront delivers content
<a name="HowCloudFrontWorks"></a>

After some initial setup, CloudFront works together with your website or application and speeds up delivery of your content. This section explains how CloudFront serves your content when viewers request it. 

**Topics**
+ [

## How CloudFront delivers content to your users
](#HowCloudFrontWorksContentDelivery)
+ [

## How CloudFront works with regional edge caches
](#CloudFrontRegionaledgecaches)

## How CloudFront delivers content to your users
<a name="HowCloudFrontWorksContentDelivery"></a>

After you configure CloudFront to deliver your content, here’s what happens when users request your objects:

1. A user accesses your website or application and sends a request for an object, such as an image file or an HTML file.

1. DNS routes the request to the CloudFront POP (edge location) that can best serve the request, typically the nearest CloudFront POP in terms of latency.

1. CloudFront checks its cache for the requested object. If the object is in the cache, CloudFront returns it to the user. If the object is *not* in the cache, CloudFront does the following:

   1. CloudFront compares the request with the specifications in your distribution and forwards the request to your origin server for the corresponding object—for example, to your Amazon S3 bucket or your HTTP server.

   1. The origin server sends the object back to the edge location.

   1. As soon as the first byte arrives from the origin, CloudFront begins to forward the object to the user. CloudFront also adds the object to the cache for the next time someone requests it.

![\[Request and response from user to origin through CloudFront\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/images/how-cloudfront-delivers-content.png)


## How CloudFront works with regional edge caches
<a name="CloudFrontRegionaledgecaches"></a>

CloudFront points of presence (also known as *POPs* or *edge locations*) make sure that popular content can be served quickly to your viewers. CloudFront also has *regional edge caches* that bring more of your content closer to your viewers, even when the content is not popular enough to stay at a POP, to help improve performance for that content.

Regional edge caches help with all types of content, particularly content that tends to become less popular over time. Examples include user-generated content, such as video, photos, or artwork; e-commerce assets such as product photos and videos; and news and event-related content that might suddenly find new popularity.

**How regional caches work**  
Regional edge caches are CloudFront locations that are deployed globally, close to your viewers. They’re located between your origin server and the POPs—global edge locations that serve content directly to viewers. As objects become less popular, individual POPs might remove those objects to make room for more popular content. Regional edge caches have a larger cache than an individual POP, so objects remain in the cache longer at the nearest regional edge cache location. This helps keep more of your content closer to your viewers, reducing the need for CloudFront to go back to your origin server, and improving overall performance for viewers.

When a viewer makes a request on your website or through your application, DNS routes the request to the POP that can best serve the user’s request. This location is typically the nearest CloudFront edge location in terms of latency. In the POP, CloudFront checks its cache for the requested object. If the object is in the cache, CloudFront returns it to the user. If the object is not in the cache, the POP typically goes to the nearest regional edge cache to fetch it. For more information about when the POP skips the regional edge cache and goes directly to the origin, see the following note.

In the regional edge cache location, CloudFront again checks its cache for the requested object. If the object is in the cache, CloudFront forwards it to the POP that requested it. As soon as the first byte arrives from regional edge cache location, CloudFront begins to forward the object to the user. CloudFront also adds the object to the cache in the POP for the next time someone requests it.

For objects not cached at either the POP or the regional edge cache location, CloudFront compares the request with the specifications in your distributions and forwards the request to the origin server. After your origin server sends the object back to the regional edge cache location, it is forwarded to the POP, and then CloudFront forwards it to the user. In this case, CloudFront also adds the object to the cache in the regional edge cache location in addition to the POP for the next time a viewer requests it. This makes sure that all of the POPs in a region share a local cache, eliminating multiple requests to origin servers. CloudFront also keeps persistent connections with origin servers so objects are fetched from the origins as quickly as possible.

**Note**  
Regional edge caches have feature parity with POPs. For example, a cache invalidation request removes an object from both POP caches and regional edge caches before it expires. The next time a viewer requests the object, CloudFront returns to the origin to fetch the latest version of the object.
Proxy HTTP methods (`PUT`, `POST`, `PATCH`, `OPTIONS`, and `DELETE`) go directly to the origin from the POPs and do not proxy through the regional edge caches.
Dynamic requests, as determined at request time, do not flow through regional edge caches, but go directly to the origin.
When the origin is an Amazon S3 bucket and the request’s optimal regional edge cache is in the same AWS Region as the S3 bucket, the POP skips the regional edge cache and goes directly to the S3 bucket.

The following diagram illustrates how requests and responses flow through CloudFront edge locations and regional edge caches.

![\[Diagram showing request/response paths from viewers to origin via edge locations and regional edge caches.\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/images/regional-edge-caches.png)


# Locations and IP address ranges of CloudFront edge servers
<a name="LocationsOfEdgeServers"></a>

For a list of the locations of CloudFront edge servers, see the [Amazon CloudFront Global Edge Network](https://aws.amazon.com/cloudfront/features/#Global_Edge_Network) page.

Amazon Web Services (AWS) publishes its current IP address ranges in JSON format. To view the current ranges, download [ip-ranges.json](https://ip-ranges.amazonaws.com/ip-ranges.json). For more information, see [AWS IP address ranges](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) in the *Amazon Web Services General Reference*.

To find the IP address ranges that are associated with CloudFront edge servers, search ip-ranges.json for the following string:

```
"region": "GLOBAL",
"service": "CLOUDFRONT"
```

Alternatively, you can view only the CloudFront IP ranges at [https://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips](https://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips).

## Use the CloudFront managed prefix list
<a name="managed-prefix-list"></a>

The CloudFront managed prefix list contains the IP address ranges of all of CloudFront's globally distributed origin-facing servers. If your origin is hosted on AWS and protected by an Amazon VPC [security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html), you can use the CloudFront managed prefix list to allow inbound traffic to your origin only from CloudFront's origin-facing servers, preventing any non-CloudFront traffic from reaching your origin. CloudFront maintains the managed prefix list so it's always up to date with the IP addresses of all of CloudFront's global origin-facing servers. With the CloudFront managed prefix list, you don't need to read or maintain a list of IP address ranges yourself.

For example, imagine that your origin is an Amazon EC2 instance in the Europe (London) Region (`eu-west-2`). If the instance is in a VPC, you can create a security group rule that allows inbound HTTPS access from the CloudFront managed prefix list. This allows all of CloudFront's global origin-facing servers to reach the instance. If you remove all other inbound rules from the security group, you prevent any non-CloudFront traffic from reaching the instance.

The CloudFront managed prefix lists are as follows:
+ `com.amazonaws.global.cloudfront.origin-facing` (IPv4)
+ `com.amazonaws.global.ipv6.cloudfront.origin-facing` (IPv6)



For more information, see [Use an AWS-managed prefix list](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html#use-aws-managed-prefix-list) in the *Amazon VPC User Guide*.

**Important**  
The CloudFront managed prefix list is unique in how it applies to Amazon VPC quotas. For more information, see [AWS-managed prefix list weight](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html#aws-managed-prefix-list-weights) in the *Amazon VPC User Guide*.

# Using CloudFront with an AWS SDK
<a name="sdk-general-information-section"></a>

AWS software development kits (SDKs) are available for many popular programming languages. Each SDK provides an API, code examples, and documentation that make it easier for developers to build applications in their preferred language.


| SDK documentation | Code examples | 
| --- | --- | 
| [AWS SDK for C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp) | [AWS SDK for C\$1\$1 code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp) | 
| [AWS CLI](https://docs.aws.amazon.com/cli) | [AWS CLI code examples](https://docs.aws.amazon.com/code-library/latest/ug/cli_2_code_examples.html) | 
| [AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go) | [AWS SDK for Go code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/gov2) | 
| [AWS SDK for Java](https://docs.aws.amazon.com/sdk-for-java) | [AWS SDK for Java code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2) | 
| [AWS SDK for JavaScript](https://docs.aws.amazon.com/sdk-for-javascript) | [AWS SDK for JavaScript code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3) | 
| [AWS SDK for Kotlin](https://docs.aws.amazon.com/sdk-for-kotlin) | [AWS SDK for Kotlin code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/kotlin) | 
| [AWS SDK for .NET](https://docs.aws.amazon.com/sdk-for-net) | [AWS SDK for .NET code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3) | 
| [AWS SDK for PHP](https://docs.aws.amazon.com/sdk-for-php) | [AWS SDK for PHP code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php) | 
| [AWS Tools for PowerShell](https://docs.aws.amazon.com/powershell) | [AWS Tools for PowerShell code examples](https://docs.aws.amazon.com/code-library/latest/ug/powershell_5_code_examples.html) | 
| [AWS SDK for Python (Boto3)](https://docs.aws.amazon.com/pythonsdk) | [AWS SDK for Python (Boto3) code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python) | 
| [AWS SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby) | [AWS SDK for Ruby code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby) | 
| [AWS SDK for Rust](https://docs.aws.amazon.com/sdk-for-rust) | [AWS SDK for Rust code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1) | 
| [AWS SDK for SAP ABAP](https://docs.aws.amazon.com/sdk-for-sapabap) | [AWS SDK for SAP ABAP code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/sap-abap) | 
| [AWS SDK for Swift](https://docs.aws.amazon.com/sdk-for-swift) | [AWS SDK for Swift code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift) | 

**Example availability**  
Can't find what you need? Request a code example by using the **Provide feedback** link at the bottom of this page.

## CloudFront technical resources
<a name="resources-cloudfront"></a>

Use the following resources to get answers to technical questions about CloudFront:
+ [AWS re:Post](https://repost.aws/tags/TA8pHF0m5aQdawzT2gwPcVYQ/amazon-cloudfront) – A community-based question and answer site for developers to discuss technical questions related to CloudFront.
+ [Support Center](https://console.aws.amazon.com/support/home) – This site includes information about your recent support cases and results from AWS Trusted Advisor and health checks. It also provides links to discussion forums, technical FAQs, the service health dashboard, and information about Support plans.
+ [AWS Premium Support](https://aws.amazon.com/premiumsupport/) – Learn about AWS Premium Support, a one-on-one, fast-response support channel that helps you build and run applications on AWS.
+ [AWS IQ](https://iq.aws.amazon.com/?utm=docs) – Get help from AWS certified professionals and experts.