Amazon CloudFront introduces Origin Access Control (OAC)

Amazon CloudFront is a global content delivery network that securely delivers applications, websites, videos, and APIs to viewers across the globe in milliseconds. Using CloudFront, customers can access different types of origin services to suit their use cases. One of the performant architectures customers adopt is to use Amazon S3 as the origin to host content like websites and videos, and use CloudFront to deliver them to viewers. Today, when using this architecture, customers can leverage CloudFront’s origin access identity (OAI) to secures S3 origin access to CloudFront only.

Origin Access Control (OAC)

While OAI provides a secure way to access S3 origins to CloudFront, it has limitations such as not supporting granular policy configurations, HTTP and HTTPS requests that use the POST method in AWS regions that require AWS Signature Version 4 (SigV4), or integrating with SSE-KMS. To strengthen security and deepen feature integrations, OAC was introduced as a feature that secures AWS origins by permitting access to the designated distributions only. OAC now supports Amazon S3 bucket origins, S3 Multi-Region Access Points, Lambda function URLs, Lambda Web Functions, AWS Elemental MediaStore, AWS Elemental MediaPackage v2, and VPC Origins. OAC is based on an AWS best practice of using IAM service principals to authenticate with S3 origins. Compared with OAI, some of the notable enhancements OAC provide include:

• Security – OAC is implemented with enhanced security practices like short term credentials, frequent credential rotations, and resource-based policies. They strengthen your distributions’ security posture and provides better protections against attacks like confused deputy.

• Comprehensive HTTP methods support – OAC supports GET, PUT, POST, PATCH, DELETE, OPTIONS, and HEAD.

• SSE-KMS – OAC supports downloading and uploading S3 objects encrypted with SSE-KMS.

• Access S3 in all AWS regions – OAC supports accessing S3 in all AWS regions, including existing regions and all future regions. In contrast, OAI does not support opt-in AWS Regions launched after December 2022. OAI is now labeled a legacy feature; AWS recommends migrating to OAC for all distributions.

When using OAC, a typical request and response workflow will be: 1. A client sends HTTP or HTTPS requests to CloudFront. 2. CloudFront edge locations receive the requests. If the requested object is not already cached, CloudFront signs the requests using OAC signing protocol. OAC supports both SigV4 (for standard S3 bucket origins) and SigV4A (for S3 Multi-Region Access Point origins). 3. S3 origins authenticate, authorize, or deny the requests. When configuring OAC, you can choose among three signing behaviors – “Do not sign requests”, “Sign requests”, and sign requests but “Do not override authorization header” (Figure 1). Next we will talk about OAC’s expected behaviors for each signing option.

Figure 1. OAC signing options

“Sign requests” option

When you configured “Sign requests” option, IAM CloudFront service principal will sign each request with SigV4. The signature will then be included, along with additional data, to form an Authorization header which will be sent to your S3 origin. When your S3 origin receives this request, it will perform the same steps to calculate the signature and compare its calculated signature to the one CloudFront sent with the request. If the signatures match, the request is processed. If the signatures don’t match, the request is denied.

With “Sign requests” option, CloudFront will always sign requests received from the clients, even when an incoming request already has an Authorization header signed by your client applications. In which cases, CloudFront will drop client’s Authorization header, re-sign the request with CloudFront’s credential, and generate a new Authorization header to send to S3 origin.

We recommend most customers use “Sign requests” option as it ensures your applications will always work because CloudFront will always sign the incoming request. Additionally, by having CloudFront to sign your requests, your applications’ performance is improved as less data is transferred between client and CloudFront.

“Do not override authorization header” option

If your client applications can sign requests, and your use cases involve toggling between client-signed and CloudFront-signed Authorization headers based on attributes like different cache behaviors, file directories, HTTP methods, edge computer invocations, you can use “Do not override authorization header” sub-option after selecting “Sign request.” For example, if you want to limit the S3 upload authorization to your client applications but assigning S3 download authorization to CloudFront, you can enable this option. Note that in this example, you must configure your S3 bucket policy accordingly so only your client’s Authorization will be accepted to perform uploading.

In addition, because CloudFront requires headers to be explicitly allow-listed to be forwarded to origin, you must allowlist Authorization header in your cache policy so that client Authorization header can be forwarded to your origin. If “Do not override authorization header” sub-option is enabled but client’s Authorization header isn’t allow listed, CloudFront will drop client’s Authorization header, re-sign the request with CloudFront’s credential, and generate an Authorization header to send to S3 origin.

“Do not sign requests” option

“Do not sign requests” instructs CloudFront to not sign any requests received from S3 origins. You can choose this option if your client applications will always sign the requests, or if your S3 bucket is public (Not a best practice). Note “Do not sign requests” option is equivalent with not using origin access control. This option is useful if you want to change an OAC’s signing options for a large number of CloudFront distributions. For example, if you previously configured an OAC with “Sign requests”, and it’s associated with 100 origins. If you now want clients to sign the requests, instead of changing the OAC associations for 100 origins manually, you can just change this very OAC’s configuration to “Do not sign requests”. CloudFront will then stop signing requests for the 100 origins.

Now we know OAC’s signing behaviors for each option, let’s take a look at how you can configure OAC. We will also look at how you can configure KMS policy to work with OAC.

Configure OAC when creating a new CloudFront distribution

1. Sign in to the AWS Management Console and open the CloudFront console at https://console.aws.amazon.com/cloudfront/v4/home

2. Choose Create Distribution.

3. In the Origin configuration section, select an S3 origin from the Origin domain drop-down list.

4. You can optionally configure an origin path to append to the origin domain name for origin requests.

5. Enter a name to uniquely identify the current origin configuration.

6. Choose Origin access control settings (Figure 2)

   

   Figure 2. Configure origin access when creating a distribution

7. You can choose an existing origin access control or create a new control setting with one of three signing options (Figure 1)

8. Follow the detailed instructions here on how to configure the rest of the settings

9. Select Create distribution at the bottom of the page once all the configuration settings have been chosen

10. Once the distribution is successfully created, you must update the S3 bucket policy, you can reference the policy statement provided on distribution detail page (Figure 3)

11. Note that the policy provided only includes permissions to read objects from S3. If you would like to also upload objects to S3, you must update the policy with additional permissions for “s3:PutObject”

    

    Figure 3. Distribution detail page

    Configure OAC when updating an existing CloudFront distribution

    1. Sign in to the AWS Management Console and open the CloudFront console at https://console.aws.amazon.com/cloudfront/v3/home

    2. Select one of the distributions from the list

    3. Select the Origins tab and choose the S3 origin which you want to associate with an origin access control setting

    4. If the origin is not using any access mechanism, it will show as public. If the origin is already using OAI, it will show as “Legacy access identifies”. To use OAC, select “Origin access control settings” and choose an existing origin access control or create a new control setting with one of three signing options (Figure 1)

       

       Figure 4. Update an existing distribution

    5. You must update the S3 policy to allow CloudFront IAM service principal and your distribution resource to access the S3 bucket. Unlike configuring origin access when creating distribution where you can update the policy only after the distribution is created, when updating a distribution, you can, and we indeed recommend, that you update the policy to allow access to both OAI and OAC, prior to saving the origin configuration, to reduce the service downtime to zero. The following is a sample policy that allows access to both OAI and OAC.

       {
           "Version": "2012-10-17",
           "Statement": [
               {
                   "Sid": "AllowCloudFrontServicePrincipalReadOnly",
                   "Effect": "Allow",
                   "Principal": {
                       "Service": "cloudfront.amazonaws.com"
                   },
                   "Action": "s3:GetObject",
                   "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
                   "Condition": {
                       "StringEquals": {
                           "AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT_ID:distribution/DISTRIBUTION_ID"
                       }
                   }
               },
               {
                   "Sid": "AllowLegacyOAIReadOnly",
                   "Effect": "Allow",
                   "Principal": {
                       "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EH1HDMB1FH2TC"
                   },
                   "Action": "s3:GetObject",
                   "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
               }
           ]
       }

    6. Similar to configure OAC when creating a distribution, the policy CloudFront provided only includes permissions to read objects from S3. If you would like to also upload objects to S3, you must update the policy with additional permissions for “s3:PutObject”

    7. At the bottom of the page, choose Save

    Enable SSE-KMS for CloudFront OAC

    AWS Well-Architected recommends protecting your data in transit and at rest. If you are using OAI, your data is already protected in transit, and you can already protect your data at rest using Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3). On the other hand, if your organizations require that SSE-KMS encryption be used to encrypt content stored in their S3 buckets, you can use OAC to access SSE-KMS encrypted S3 objects. Note that when using OAC with an S3 bucket origin, you must set Amazon S3 Object Ownership to Bucket owner enforced (the default for new S3 buckets). If you require ACLs, use the Bucket owner preferred setting instead. Note you need to configure your KMS policy to allow CloudFront IAM service principal to access your KMS keys. Adding aws:SourceArn condition key allows only a specific CloudFront distribution to access SSE-KMS encrypted objects using this key policy. You can follow the configuration steps below

    1. Open the KMS console at https://us-east-1.console.aws.amazon.com/kms/home?region=us-east-1#/kms/keys

    2. Select the customer managed KMS key that is used to encrypt the content in the S3 origin

    3. Select the Key policy tab

    4. Update the KMS key policy to give access to CloudFront Service Principle

       {
           "Sid": "Allow use of the key",
           "Effect": "Allow",
           "Principal": {
               "Service": [
                   "cloudfront.amazonaws.com"
               ]
            },
             "Action": [
                 "kms:Decrypt",
                 "kms:Encrypt",
                 "kms:GenerateDataKey*
              ],
              "Resource": "*",
              "Condition":{
                  "StringEquals":{
                       “aws:SourceArn”: “arn:aws:cloudfront::ACCOUNT_ID:distribution/DISTRIBUTION_ID”
                  }
              }
       }

    Do I need to migrate to OAC?

    If you already have CloudFront distributions configured with OAI, you may wonder if you need to migrate from OAI to OAC. We strongly recommend migrating all distributions from OAI to OAC. OAI is now a legacy feature and is not recommended for new distributions. OAI does not support S3 buckets in opt-in AWS Regions launched after January 2023, SSE-KMS encryption, or dynamic PUT/DELETE requests. Existing distributions using OAI will continue to work, but migrating to OAC ensures full regional coverage and the latest security practices. For step-by-step migration guidance, see Migrating from origin access identity (OAI) to origin access control (OAC).

    Now available

    CloudFront Origin Access Control is available worldwide except for AWS China regions, and now supports multiple origin types beyond Amazon S3, including Lambda function URLs, Lambda Web Functions, AWS Elemental MediaStore, MediaPackage v2, VPC Origins, and S3 Multi-Region Access Points. You can configure OAC through the CloudFront console, APIs, SDK, or CLI. There is no additional fee to use OAC. To learn about all supported origin types and configuration steps, see Restrict access to an AWS origin in the CloudFront Developer Guide.

Update (October 2026): Revised to reflect that OAC now secures many AWS origin types beyond Amazon S3—including S3 Multi-Region Access Points, Lambda function URLs, Lambda Web Functions, AWS Elemental MediaStore, MediaPackage v2, and VPC Origins—and that OAC supports both SigV4 and SigV4A (required for Multi-Region Access Points). Also corrected the OAI cutoff to opt-in Regions launched after December 2022 and added the S3 Object Ownership (Bucket owner enforced) prerequisite for using OAC with S3 origins. Updated by Jaiganesh Girinathan.

About the Authors