Use various origins with CloudFront distributions - Amazon CloudFront
Use an Amazon S3 bucketUse a MediaStore container or a MediaPackage channelUse an Application Load BalancerUse a Lambda function URLUse Amazon EC2 (or another custom origin)Use CloudFront origin groups

Use various origins with CloudFront distributions

When you create a distribution, you specify the origin where CloudFront sends requests for the files. You can use several different kinds of origins with CloudFront. For example, you can use an Amazon S3 bucket, a MediaStore container, a MediaPackage channel, an Application Load Balancer, or an AWS Lambda function URL.

Use an Amazon S3 bucket

The following topics describe the different ways that you can use an Amazon S3 bucket as the origin for a CloudFront distribution.

Use a standard Amazon S3 bucket

When you use Amazon S3 as an origin for your distribution, you place the objects that you want CloudFront to deliver in an Amazon S3 bucket. You can use any method that is supported by Amazon S3 to get your objects into Amazon S3. For example, you can use the Amazon S3 console or API, or a third-party tool. You can create a hierarchy in your bucket to store the objects, just as you would with any other standard Amazon S3 bucket.

Using an existing Amazon S3 bucket as your CloudFront origin server doesn't change the bucket in any way; you can still use it as you normally would to store and access Amazon S3 objects at the standard Amazon S3 price. You incur regular Amazon S3 charges for storing the objects in the bucket. For more information about the charges to use CloudFront, see Amazon CloudFront Pricing. For more information about using CloudFront with an existing S3 bucket, see Add CloudFront to an existing Amazon S3 bucket.

Important

For your bucket to work with CloudFront, the name must conform to DNS naming requirements. For more information, go to Bucket naming rules in the Amazon Simple Storage Service User Guide.

When you specify an Amazon S3 bucket as an origin for CloudFront, we recommend that you use the following format:

bucket-name.s3.region.amazonaws.com

When you specify the bucket name in this format, you can use the following CloudFront features:

Don't specify the bucket using the following formats:

  • The Amazon S3 path style: s3.amazonaws.com/bucket-name

  • The Amazon S3 CNAME

Use Amazon S3 Object Lambda

When you create an Object Lambda Access Point, Amazon S3 automatically generates a unique alias for your Object Lambda Access Point. You can use this alias instead of an Amazon S3 bucket name as an origin for your CloudFront distribution.

When you use an Object Lambda Access Point alias as an origin for CloudFront, we recommend that you use the following format:

alias.s3.region.amazonaws.com

For more information about finding the alias, see How to use a bucket-style alias for your S3 bucket Object Lambda Access Point in the Amazon S3 User Guide.

Important

When you use an Object Lambda Access Point as an origin for CloudFront, you must use origin access control.

For an example use case, see Use Amazon S3 Object Lambda with Amazon CloudFront to Tailor Content for End Users.

CloudFront treats an Object Lambda Access Point origin the same as a standard Amazon S3 bucket origin.

If you're using Amazon S3 Object Lambda as an origin for your distribution, you must configure the following four permissions.

Object Lambda Access Point
To add permissions for the Object Lambda Access Point

  1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.

  2. In the navigation pane, choose Object Lambda Access Points.

  3. Choose the Object Lambda Access Point that you want to use.

  4. Choose the Permissions tab.

  5. Choose Edit in the Object Lambda Access Point policy section.

  6. Paste the following policy into the Policy field.

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3-object-lambda:Get*",
            "Resource": "arn:aws:s3-object-lambda:region:AWS-account-ID:accesspoint/Object-Lambda-Access-Point-name",
            "Condition": {
                "StringEquals": {
                    "aws:SourceArn": "arn:aws:cloudfront::AWS-account-ID:distribution/CloudFront-distribution-ID"
                }
            }
        }
    ]
}

  7. Choose Save changes.

Amazon S3 Access Point
To add permissions for the Amazon S3 Access Point

  1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.

  2. In the navigation pane, choose Access Points.

  3. Choose the Amazon S3 Access Point that you want to use.

  4. Choose the Permissions tab.

  5. Choose Edit in the Access Point policy section.

  6. Paste the following policy into the Policy field.

    {
    "Version": "2012-10-17",
    "Id": "default",
    "Statement": [
        {
            "Sid": "s3objlambda",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:region:AWS-account-ID:accesspoint/Access-Point-name",
                "arn:aws:s3:region:AWS-account-ID:accesspoint/Access-Point-name/object/*"
            ],
            "Condition": {
                "ForAnyValue:StringEquals": {
                    "aws:CalledVia": "s3-object-lambda.amazonaws.com"
                }
            }
        }
    ]
}

  7. Choose Save.

Amazon S3 bucket
To add permissions to the Amazon S3 bucket

  1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.

  2. In the navigation pane, choose Buckets.

  3. Choose the Amazon S3 bucket that you want to use.

  4. Choose the Permissions tab.

  5. Choose Edit in the Bucket policy section.

  6. Paste the following policy into the Policy field.

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "*",
            "Resource": [
                "arn:aws:s3:::bucket-name",
                "arn:aws:s3:::bucket-name/*"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:DataAccessPointAccount": "AWS-account-ID"
                }
            }
        }
    ]
}

  7. Choose Save changes.

AWS Lambda function
To add permissions to the Lambda function

  1. Sign in to the AWS Management Console and open the AWS Lambda console at https://console.aws.amazon.com/lambda/.

  2. In the navigation pane, choose Functions.

  3. Choose the AWS Lambda function that you want to use.

  4. Choose the Configuration tab, then choose Permissions.

  5. Choose Add permissions in the Resource-based policy statements section.

  6. Choose AWS account.

  7. Enter a name for Statement ID.

  8. Enter cloudfront.amazonaws.com for Principal.

  9. Choose lambda:InvokeFunction from the Action dropdown menu.

  10. Choose Save.

Use Amazon S3 Access Point

When you use an S3 Access Point, Amazon S3 automatically generates a unique alias for you. You can use this alias instead of an Amazon S3 bucket name as an origin for your CloudFront distribution.

When you use an Amazon S3 Access Point alias as an origin for CloudFront, we recommend that you use the following format:

alias.s3.region.amazonaws.com

For more information about finding the alias, see Using a bucket-style alias for your S3 bucket access point in the Amazon S3 User Guide.

Important

When you use an Amazon S3 Access Point as an origin for CloudFront, you must use origin access control.

CloudFront treats an Amazon S3 Access Point origin the same as a standard Amazon S3 bucket origin.

If you're using Amazon S3 Object Lambda as an origin for your distribution, you must configure the following two permissions.

Amazon S3 Access Point
To add permissions for the Amazon S3 Access Point

  1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.

  2. In the navigation pane, choose Access Points.

  3. Choose the Amazon S3 Access Point that you want to use.

  4. Choose the Permissions tab.

  5. Choose Edit in the Access Point policy section.

  6. Paste the following policy into the Policy field.

    {
    "Version": "2012-10-17",
    "Id": "default",
    "Statement": [
        {
            "Sid": "s3objlambda",
            "Effect": "Allow",
            "Principal": {"Service": "cloudfront.amazonaws.com"},
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:region:AWS-account-ID:accesspoint/Access-Point-name",
                "arn:aws:s3:region:AWS-account-ID:accesspoint/Access-Point-name/object/*"
            ],
            "Condition": {
                "StringEquals": {"aws:SourceArn": "arn:aws:cloudfront::AWS-account-ID:distribution/CloudFront-distribution-ID"}
            }
        }
    ]
}

  7. Choose Save.

Amazon S3 bucket
To add permissions to the Amazon S3 bucket

  1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.

  2. In the navigation pane, choose Buckets.

  3. Choose the Amazon S3 bucket that you want to use.

  4. Choose the Permissions tab.

  5. Choose Edit in the Bucket policy section.

  6. Paste the following policy into the Policy field.

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "*",
            "Resource": [
                "arn:aws:s3:::bucket-name",
                "arn:aws:s3:::bucket-name/*"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:DataAccessPointAccount": "AWS-account-ID"
                }
            }
        }
    ]
}

  7. Choose Save changes.

Use an Amazon S3 bucket that's configured as a website endpoint

You can use an Amazon S3 bucket that's configured as a website endpoint as a custom origin with CloudFront. When you configure your CloudFront distribution, for the origin, enter the Amazon S3 static website hosting endpoint for your bucket. This value appears in the Amazon S3 console, on the Properties tab, in the Static website hosting pane. For example:

http://bucket-name.s3-website-region.amazonaws.com

For more information about specifying Amazon S3 static website endpoints, see Website endpoints in the Amazon Simple Storage Service User Guide.

When you specify the bucket name in this format as your origin, you can use Amazon S3 redirects and Amazon S3 custom error documents. For more information, see Configuring a custom error document and Configuring a redirect in the Amazon Simple Storage Service User Guide. (CloudFront also provides custom error pages. For more information, see Create a custom error page for specific HTTP status codes.)

Using an Amazon S3 bucket as your CloudFront origin server doesn't change the bucket in any way. You can still use it as you normally would and you incur regular Amazon S3 charges. For more information about the charges to use CloudFront, see Amazon CloudFront Pricing.

Note

If you use the CloudFront API to create your distribution with an Amazon S3 bucket that is configured as a website endpoint, you must configure it by using CustomOriginConfig, even though the website is hosted in an Amazon S3 bucket. For more information about creating distributions by using the CloudFront API, see CreateDistribution in the Amazon CloudFront API Reference.

Add CloudFront to an existing Amazon S3 bucket

If you store your objects in an Amazon S3 bucket, you can either have users get your objects directly from S3, or you can configure CloudFront to get your objects from S3 and then distribute them to your users. Using CloudFront can be more cost effective if your users access your objects frequently because, at higher usage, the price for CloudFront data transfer is lower than the price for Amazon S3 data transfer. In addition, downloads are faster with CloudFront than with Amazon S3 alone because your objects are stored closer to your users.

Note

If you want CloudFront to respect Amazon S3 cross-origin resource sharing settings, configure CloudFront to forward the Origin header to Amazon S3. For more information, see Cache content based on request headers.

If you currently distribute content directly from your Amazon S3 bucket using your own domain name (such as example.com) instead of the domain name of your Amazon S3 bucket (such as amzn-s3-demo-bucket.s3.us-west-2.amazonaws.com), you can add CloudFront with no disruption by using the following procedure.

To add CloudFront when you're already distributing your content from Amazon S3

  1. Create a CloudFront distribution. For more information, see Create a distribution.

    When you create the distribution, specify the name of your Amazon S3 bucket as the origin server.

    Important

    For your bucket to work with CloudFront, the name must conform to DNS naming requirements. For more information, go to Bucket naming rules in the Amazon Simple Storage Service User Guide.

    If you're using a CNAME with Amazon S3, specify the CNAME for your distribution, too.

  2. Create a test webpage that contains links to publicly readable objects in your Amazon S3 bucket, and test the links. For this initial test, use the CloudFront domain name of your distribution in the object URLs, for example, https://d111111abcdef8.cloudfront.net/images/image.jpg.

    For more information about the format of CloudFront URLs, see Customize the URL format for files in CloudFront.

  3. If you're using Amazon S3 CNAMEs, your application uses your domain name (for example, example.com) to reference the objects in your Amazon S3 bucket instead of using the name of your bucket (for example, amzn-s3-demo-bucket.s3.amazonaws.com). To continue using your domain name to reference objects instead of using the CloudFront domain name for your distribution (for example, d111111abcdef8.cloudfront.net), you need to update your settings with your DNS service provider.

    For Amazon S3 CNAMEs to work, your DNS service provider must have a CNAME resource record set for your domain that currently routes queries for the domain to your Amazon S3 bucket. For example, if a user requests this object:

    https://example.com/images/image.jpg

    The request is automatically rerouted, and the user sees this object:

    https://amzn-s3-demo-bucket.s3.amazonaws.com/images/image.jpg

    To route queries to your CloudFront distribution instead of your Amazon S3 bucket, you need to use the method provided by your DNS service provider to update the CNAME resource record set for your domain. This updated CNAME record redirects DNS queries from your domain to the CloudFront domain name for your distribution. For more information, see the documentation provided by your DNS service provider.

    Note

    If you're using Route 53 as your DNS service, you can use either a CNAME resource record set or an alias resource record set. For information about editing resource record sets, see Editing records. For information about alias resource record sets, see Choosing between alias and non-alias records. Both topics are in the Amazon Route 53 Developer Guide.

    For more information about using CNAMEs with CloudFront, see Use custom URLs by adding alternate domain names (CNAMEs).

    After you update the CNAME resource record set, it can take up to 72 hours for the change to propagate throughout the DNS system, although it usually happens faster. During this time, some requests for your content will continue to be routed to your Amazon S3 bucket, and others will be routed to CloudFront.

Move an Amazon S3 bucket to a different AWS Region

If you're using Amazon S3 as the origin for a CloudFront distribution and you move the bucket to a different AWS Region, CloudFront can take up to an hour to update its records to use the new Region when both of the following are true:

  • You're using a CloudFront origin access identity (OAI) to restrict access to the bucket.

  • You move the bucket to an Amazon S3 Region that requires Signature Version 4 for authentication.

When you're using OAIs, CloudFront uses the Region (among other values) to calculate the signature that it uses to request objects from your bucket. For more information about OAIs, see Use an origin access identity (legacy, not recommended). For a list of AWS Regions that support Signature Version 2, see Signature Version 2 signing process in the Amazon Web Services General Reference.

To force a faster update to CloudFront's records, you can update your CloudFront distribution, for example, by updating the Description field on the General tab in the CloudFront console. When you update a distribution, CloudFront immediately checks the Region that your bucket is in. Propagation of the change to all edge locations should take only a few minutes.

Use a MediaStore container or a MediaPackage channel

To stream video using CloudFront, you can set up an Amazon S3 bucket that is configured as a MediaStore container, or create a channel and endpoints with MediaPackage. Then you create and configure a distribution in CloudFront to stream the video.

For more information and step-by-step instructions, see the following topics:

Use an Application Load Balancer

If your origin is one or more HTTP(S) servers (web servers) hosted on one or more Amazon EC2 instances, you can use an internet-facing Application Load Balancer to distribute traffic to the instances. An internet-facing load balancer has a publicly resolvable DNS name and routes requests from clients to targets over the internet.

For more information about using an Application Load Balancer as your origin for CloudFront, including how to make sure that viewers can only access your web servers through CloudFront and not by accessing the load balancer directly, see Restrict access to Application Load Balancers.

To prevent your application from being accessible on the public internet, you can use your Application Load Balancer with a VPC origin. For more information, see Restrict access with VPC origins.

Use a Lambda function URL

A Lambda function URL is a dedicated HTTPS endpoint for a Lambda function. You can use a Lambda function URL to build a serverless web application entirely within Lambda. You can invoke the Lambda web application directly through the function URL, with no need to integrate with API Gateway or an Application Load Balancer.

If you build a serverless web application by using Lambda functions with function URLs, you can add CloudFront to get the following benefits:

  • Speed up your application by caching content closer to viewers

  • Use a custom domain name for your web application

  • Route different URL paths to different Lambda functions using CloudFront cache behaviors

  • Block specific requests using CloudFront geographic restrictions or AWS WAF (or both)

  • Use AWS WAF with CloudFront to help protect your application from malicious bots, help prevent common application exploits, and enhance protection from DDoS attacks

To use a Lambda function URL as the origin for a CloudFront distribution, specify the full domain name of the Lambda function URL as the origin domain. A Lambda function URL domain name uses the following format:

function-URL-ID.lambda-url.AWS-Region.on.aws

When you use a Lambda function URL as the origin for a CloudFront distribution, the function URL must be publicly accessible. To do so, use one of the following options:

  • If you use origin access control (OAC), the AuthType parameter of the Lambda function URL must use the AWS_IAM value and allow the lambda:InvokeFunctionUrl permission in a resource-based policy. For more information about using Lambda function URLs for OAC, see Restrict access to an AWS Lambda function URL origin.

  • If you don't use OAC, you can set the AuthType parameter of the function URL to NONE and allow the lambda:InvokeFunctionUrl permission in a resource-based policy.

You can also add a custom origin header to the requests that CloudFront sends to the origin, and write function code to return an error response if the header isn't present in the request. This helps to make sure that users can only access your web application through CloudFront, not directly using the Lambda function URL.

For more information about Lambda function URLs, see the following topics in the AWS Lambda Developer Guide:

Use Amazon EC2 (or another custom origin)

A custom origin is an HTTP(S) web server with a publicly resolvable DNS name that routes requests from clients to targets over the internet. The HTTP(S) server can be hosted on AWS–for example, an Amazon EC2 instance–or hosted somewhere else. An Amazon S3 origin configured as a website endpoint is also considered a custom origin. For more information, see Use an Amazon S3 bucket that's configured as a website endpoint.

When you use your own HTTP server as a custom origin, you specify the DNS name of the server, along with the HTTP and HTTPS ports and the protocol that you want CloudFront to use when fetching objects from your origin.

Most CloudFront features are supported when you use a custom origin with the exception of private content. Although you can use a signed URL to distribute content from a custom origin, for CloudFront to access the custom origin, the origin must remain publicly accessible. For more information, see Serve private content with signed URLs and signed cookies.

To prevent your application from being accessible on the public internet, you can use your EC2 instance with a VPC origin. For more information, see Restrict access with VPC origins.

Follow these guidelines for using Amazon EC2 instances and other custom origins with CloudFront.

  • Host and serve the same content on all servers that are serving content for the same CloudFront origin. For more information, see Origin settings in the Distribution settings reference topic.

  • Log the X-Amz-Cf-Id header entries on all servers in case you need AWS Support or CloudFront to use this value for debugging.

  • Restrict requests to the HTTP and HTTPS ports that your custom origin listens on.

  • Synchronize the clocks of all servers in your implementation. Note that CloudFront uses Coordinated Universal Time (UTC) for signed URLs and signed cookies, for logs, and reports. In addition, if you monitor CloudFront activity using CloudWatch metrics, note that CloudWatch also uses UTC.

  • Use redundant servers to handle failures.

  • For information about using a custom origin to serve private content, see Restrict access to files on custom origins.

  • For information about request and response behavior and about supported HTTP status codes, see Request and response behavior.

If you use Amazon EC2 for a custom origin, we recommend that you do the following:

  • Use an Amazon Machine Image that automatically installs the software for a web server. For more information, see the Amazon EC2 documentation.

  • Use an Elastic Load Balancing load balancer to handle traffic across multiple Amazon EC2 instances and to isolate your application from changes to Amazon EC2 instances. For example, if you use a load balancer, you can add and delete Amazon EC2 instances without changing your application. For more information, see the Elastic Load Balancing documentation.

  • When you create your CloudFront distribution, specify the URL of the load balancer for the domain name of your origin server. For more information, see Create a distribution.

Use CloudFront origin groups

You can specify an origin group for your CloudFront origin if, for example, you want to configure origin failover for scenarios when you need high availability. Use origin failover to designate a primary origin for CloudFront plus a second origin that CloudFront automatically switches to when the primary origin returns specific HTTP status code failure responses.

For more information, including the steps for setting up an origin group, see Optimize high availability with CloudFront origin failover.