CloudFront OAC for S3 Multi-Region Access Points: three AWS guides give three different answers in 2026

Summary. Amazon CloudFront supports origin access control in front of an Amazon S3 Multi-Region Access Point, and the configuration is documented in three places that do not agree. The CloudFront Developer Guide tells you to create the OAC with "SigningProtocol": "sigv4a". The CloudFront API Reference for OriginAccessControlConfig states, in the same breath: "The signing protocol of the origin access control ... The only valid value is sigv4", and lists exactly one valid value. The Amazon S3 User Guide adds a third answer, saying you must configure the Multi-Region Access Point as a Custom Origin distribution type, while the CloudFront guide files MRAP under S3 origins and uses OriginAccessControlOriginType: s3. On top of that, the OAC page carries a hard restriction the MRAP feature page does not repeat: OAC with MRAP fails for any bucket in an AWS opt-in Region, and S3 lists 12 opt-in Regions as supported for MRAP, Asia Pacific (Hyderabad) among them. Meanwhile the general S3 OAC page sells opt-in Region support as a headline reason to adopt OAC, naming Regions launched after December 2022 and January 2023. An MRAP can span 17 Regions against 17 default-enabled commercial Regions on the S3 list, an account can hold 100 access points, failover control plane requests are accepted in only 5 Regions, control plane requests in exactly 1, and the AWS Config rule that checks for OAC runs in 1 Region as well. As of 21 August 2026 all 4 documents are current, and none of them cross-references the others.

The three statements, side by side

The practical resolution is to follow the CloudFront Developer Guide, because it is the only page that describes the MRAP case specifically and it gives a complete worked configuration. But if you generate infrastructure code from the API model, or your linting runs against the published enum, expect sigv4a to be flagged. Test the create call before you wire it into a pipeline, and do not assume a template that validates locally will apply.

The origin-type conflict has the same shape. OriginAccessControlOriginType accepts s3 | mediastore | mediapackagev2 | lambda, with no MRAP-specific value, and the CloudFront guide tells you to pick s3. The S3 guide's Custom Origin instruction predates OAC support for MRAP and no longer matches the CloudFront procedure. Follow the CloudFront guide, and note the mismatch when someone on the team quotes the S3 page at you in review.

The opt-in Region trap

This is the failure that will look like a routing bug.

The CloudFront OAC page states it plainly: "OAC with S3 Multi-Region Access Points is not supported for MRAP endpoints backed by buckets in opt-in Regions. Requests routed to a bucket in an opt-in Region will fail. All buckets associated with the Multi-Region Access Point must be in Regions that are enabled by default."

The S3 User Guide, on a different page, lists 12 opt-in Regions that MRAP does support: Africa (Cape Town), Asia Pacific (Hong Kong), Asia Pacific (Jakarta), Asia Pacific (Melbourne), Asia Pacific (Hyderabad), Canada West (Calgary), Europe (Zurich), Europe (Milan), Europe (Spain), Israel (Tel Aviv), Middle East (Bahrain) and Middle East (UAE).

The standard S3 OAC page makes it worse. Its opening list of reasons to prefer OAC over the legacy origin access identity begins: OAC supports "All Amazon S3 buckets in all AWS Regions, including opt-in Regions launched after December 2022". Read the general page and opt-in Regions are the headline reason to adopt OAC. Read the MRAP page and they are the thing that breaks it.

Both are true, in their own scopes. OAC handles opt-in Regions on a plain bucket origin. MRAP supports those Regions. MRAP behind CloudFront OAC does not. Because MRAP routes on network latency, the failure is intermittent and geographic: viewers near the opt-in Region get errors, everyone else is fine, and your synthetic monitoring from a default Region never sees it.

MRAP buckets are also immutable. The S3 restrictions page is explicit that after you create a Multi-Region Access Point "you can't add, modify, or remove buckets from the Multi-Region Access Point configuration. To change the buckets, you must delete the entire Multi-Region Access Point and create a new one." Aliases are never reused, so the replacement gets a new hostname, which means a distribution change and a cache invalidation. Discovering the opt-in restriction after go-live is not a config tweak.

Opt-in Region handling has its own error vocabulary worth putting in a runbook: 403 InvalidRegion when you create an MRAP with a disabled opt-in Region, 403 AllAccessDisabled when you disable a Region that is still part of an active MRAP, and 400 InvalidToken when a requester account has not enabled the same opt-in Regions. AWS also notes that MRAP opt-in Regions "are currently only supported through AWS SDKs and AWS CLI", so the console will not help you here.

Every bucket, every KMS key

Two "Important" callouts on the CloudFront page carry the operational weight.

The first: "You must add this bucket policy to every S3 bucket that is associated with the Multi-Region Access Point. If any bucket is missing the policy, CloudFront requests routed to that bucket will be denied." Same intermittent, latency-dependent failure mode as the opt-in problem.

The second: "You must add this key policy statement to the KMS key in every Region where an underlying S3 bucket uses SSE-KMS encryption." A CloudFront distribution reaching an SSE-KMS bucket needs kms:Decrypt, kms:Encrypt and kms:GenerateDataKey* on that Region's key, conditioned on aws:SourceArn matching the distribution ARN.

AWS offers two shapes for the bucket policy. Option 1 grants the CloudFront service principal s3:GetObject directly on each bucket, conditioned on the distribution ARN, and suits estates that still need direct bucket access from other systems. Option 2 delegates full bucket access to the MRAP with a condition on s3:DataAccessPointArn, which AWS recommends when direct access is not required. Option 2 is the one to reach for: it collapses N bucket policies into one MRAP policy as the source of truth, and it removes the class of bug where somebody edits four bucket policies and misses the fifth.

Lambda@Edge stops working

A note buried in the "Create the origin access control" section: "Lambda@Edge origin request triggers are incompatible with origins that use a SigV4a OAC, whether the origin is accessed directly or through an origin group."

If your distribution rewrites origin requests at the edge, adds headers, does A/B origin selection or normalises paths in an origin-request trigger, adopting a SigV4a OAC breaks it. Origin groups do not save you. CloudFront Functions run at viewer request and viewer response, so viewer-side logic survives, but anything that mutates the request on its way to the origin has to move.

That is the single most likely reason a team will decide against this configuration, and it appears in neither the S3 guide nor the origins overview.

The rest of the MRAP envelope

Before you commit to MRAP as a CloudFront origin at all, the restrictions page sets the boundaries:

• 100 Multi-Region Access Points per account, and 17 Regions per Multi-Region Access Point, counting both commercial and opt-in Regions.

• Gateway VPC endpoints cannot reach an MRAP. Interface endpoints can, and must be of type com.amazonaws.s3-global.accesspoint. IPv6 is not supported.

• Anonymous requests are not supported, TLS 1.2 is the floor, and requests are signed with SigV4A.

• S3 Batch Operations is not supported. CopyObject works as a destination only, using the MRAP ARN.

• Control plane requests to create or maintain an MRAP must go to US West (Oregon). Failover control plane requests must go to one of five Regions: US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Tokyo) or Europe (Ireland).

• S3 on Outposts buckets are not supported.

Detection is also thinner than you would hope. The AWS Config managed rule cloudfront-s3-origin-access-control-enabled checks whether a CloudFront distribution with an S3 origin type has OAC enabled, and it is available only in the US East (N. Virginia) Region. Given the origin-type ambiguity above, confirm what the rule actually evaluates in your account rather than assuming an MRAP distribution is covered.

What to do

Write the OAC with sigv4a and SigningBehavior: always, following the CloudFront Developer Guide, and test the create call before you commit the template. Audit every underlying bucket for the policy and every Region's KMS key for the statement, and prefer the MRAP-delegation policy so there is one place to get it right. Confirm no bucket in the MRAP sits in an opt-in Region, and if one does, decide now whether you are dropping the Region or dropping OAC, because you cannot change the bucket list later. Grep your distribution config for Lambda@Edge origin-request triggers before you switch anything on.

This is the kind of configuration where the cost of getting it wrong is a partial outage that only some users see. If you are designing an active-active footprint rather than debugging one, our multi-region resilience and disaster recovery work covers the routing and failover decisions that sit above this layer, and the same care applies to AWS signing and access models generally.

India-specific considerations

The Region split matters directly here. Asia Pacific (Mumbai) is on the list of Regions enabled by default, so a Mumbai bucket works behind a CloudFront OAC on an MRAP. Asia Pacific (Hyderabad) is an opt-in Region, so a Hyderabad bucket in the same MRAP will fail every request CloudFront routes to it. Any Indian team that added Hyderabad for in-country redundancy, or for data-residency comfort under the Digital Personal Data Protection Act 2023, needs to check this before assuming the second Region is doing anything. Because MRAP bucket lists cannot be edited, the fix is a new MRAP and a new alias, not a policy change.

FAQ

How eCorpIT can help

Multi-Region content delivery fails quietly, which is why it needs someone to check the boring policy surfaces before launch rather than after. Our senior engineering teams audit CloudFront and S3 access configurations, reconcile the conflicting guidance into one tested template, and build the synthetic checks that hit each Region rather than the nearest one. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified, and this work sits alongside our broader cloud migration services. Contact us if you want a second pair of eyes on an active-active footprint.

References

1. Restrict access to an Amazon S3 Multi-Region Access Point origin, Amazon CloudFront Developer Guide.

1. OriginAccessControlConfig, Amazon CloudFront API Reference.

1. Use various origins with CloudFront distributions, Amazon CloudFront Developer Guide.

1. AWS::CloudFront::OriginAccessControl, AWS CloudFormation Template Reference.

1. Multi-Region Access Point restrictions and limitations, Amazon S3 User Guide.

1. Configuring Multi-Region Access Point opt-in Regions, Amazon S3 User Guide.

1. Rules for naming Amazon S3 Multi-Region Access Points, Amazon S3 User Guide.

1. Configuring a Multi-Region Access Point for use with AWS PrivateLink, Amazon S3 User Guide.

1. cloudfront-s3-origin-access-control-enabled, AWS Config Developer Guide.

1. Restrict access to an Amazon S3 origin, Amazon CloudFront Developer Guide.

Last updated: 21 August 2026.