#38627·aws-cdk

feat(cloudfront): add support for S3 Multi-Region Access Point origins with OAC

Author: piotrekwitkowskiCreated Aug 21, 2026Updated Sep 18, 2026
Labelsp2feature-request@aws-cdk/aws-cloudfronteffort/medium

Describe the feature

Support Amazon S3 Multi-Region Access Points (MRAP) as a CloudFront origin protected by Origin Access Control.

Use Case

CloudFront natively signs requests to S3 MRAP origins as of 2026-08-20. Per the developer guide, the required OAC config is the existing s3 origin type with the sigv4a signing protocol:

OriginAccessControlOriginType: s3
SigningBehavior: always
SigningProtocol: sigv4a

CDK cannot express this. SigningProtocol (packages/aws-cdk-lib/aws-cloudfront/lib/origin-access-control.ts:135) has one member:

typescript
export enum SigningProtocol {
  SIGV4 = 'sigv4',
}

and all three Signing statics (:149, :155, :160) are built on it. No new OriginAccessControlOriginType is needed.

Proposed Solution

  1. Add SIGV4A to SigningProtocol and a matching Signing static, usable with the existing S3OriginAccessControl.
  2. Add S3MrapOrigin to aws-cloudfront-origins, taking the MRAP alias and deriving the origin domain. Leaving a withOriginAccessControl() grant helper out for now, since there is no MRAP L2 to write the policies on.

Origin configuration

An MRAP origin is a custom origin with originAccessControlId set — not S3OriginConfig. Per the S3 user guide: "To use Multi-Region Access Points with Amazon CloudFront, you must configure the Multi-Region Access Point as a Custom Origin distribution type." Note that OriginAccessControlOriginType: s3 does not imply S3OriginConfig — CDK's FunctionUrlOrigin already pairs a lambda-type OAC with a CustomOriginConfig.

S3MrapOrigin should therefore extend HttpOrigin, following S3StaticWebsiteOrigin, which is likewise an S3-branded custom origin deriving its domain from its input. HttpOrigin already defaults protocolPolicy to HTTPS_ONLY, so no override is needed.

Dependency

The AWS::CloudFront::OriginAccessControl schema currently constrains SigningProtocol to ^(sigv4)$, so a sigv4a OAC would synthesize but fail at deploy. Once it lands in CloudFormation, step 1 is additive and small.

Workaround

originAccessControlId is on OriginOptions, which HttpOriginProps extends:

typescript
const oac = new cloudfront.S3OriginAccessControl(this, 'Oac');
const origin = new origins.HttpOrigin('<alias>.accesspoint.s3-global.amazonaws.com', {
  originAccessControlId: oac.originAccessControlId,
});

Subject to the same CloudFormation constraint, with policies written by hand.

Acknowledgements

  • I may be able to implement this feature request
  • This feature might incur a breaking change

AWS CDK Library version

main (2e6b561e28)

AWS CDK CLI version

N/A

Environment details

macOS 26.5.1