cloudfront-origins: readTimeout cannot exceed 180s even after an origin response timeout quota increase

[mekza]

Describe the bug

readTimeout on HttpOrigin, VpcOrigin, FunctionUrlOrigin and RestApiOrigin is validated against a hardcoded upper bound of 180 seconds:

validateSecondsInRangeOrUndefined('readTimeout', 1, 180, props.readTimeout);

It maps to the CloudFront origin response timeout, which is an adjustable service quota. Once a limit increase is approved for an account, CloudFront accepts values above 180 seconds — but the L2 construct rejects them at synth time, so there is no way to express a valid configuration.

This is inconsistent with the construct's own documented behaviour for this same property, which already defers enforcement of the quota to the service:

Note that values over 60 seconds are possible only after a limit increase request for the origin response timeout quota has been approved in the target account; otherwise, values over 60 seconds will produce an error at deploy time.

So values between 61 and 180 are already left to the service to validate, while values above 180 are blocked client-side.

Regression?

No

Last known working version

N/A — the bound has been present since the property was introduced.

Expected Behavior

readTimeout above 180 seconds should synth successfully, and CloudFront should reject it at deploy time if the account's quota has not been raised — the same way values above 60 seconds behave today.

Current Behavior

Synth fails with:

«InvalidDurationRange» readTimeout: Must be an int between 1 and 180 seconds (inclusive); received 300.

Reproduction Steps

new cloudfront.Distribution(this, 'Distribution', {
  defaultBehavior: {
    origin: new origins.HttpOrigin('example.origin.internal', {
      readTimeout: Duration.seconds(300),
    }),
  },
});

Fails at synth, before any call to CloudFront.

For contrast, setting the same value directly on the service succeeds on a distribution whose quota has been raised. Note that CloudFront also constrains the product of ConnectionAttempts × (ConnectionTimeout + OriginReadTimeout), so a high readTimeout may additionally require lowering connectionAttempts; with connectionAttempts: 1 a 300 second readTimeout is accepted:

An error occurred (InvalidArgument) when calling the UpdateDistribution operation:
When your OriginReadTimeout value exceeds the maximum permitted value, ConnectionAttempts must not be set too high.

Possible Solution

Drop the hardcoded upper bound for readTimeout and let the service validate it, keeping the 1 second minimum and the whole-number-of-seconds check.

Additional Information/Context

This matters for long-running streaming origins. In our case a Bedrock AgentCore MCP endpoint behind CloudFront can legitimately take several minutes to respond, and with a 180 second cap the client receives a 504 while the origin is still working.

CDK CLI Version

2.248.0

Framework Version

aws-cdk-lib 2.248.0

Node.js Version

20.x

OS

macOS

Language

TypeScript

[pahud]

Hi @mekza,

┌────────────────────────────────────────────────────────────────┐
│ 🔴 Reported State                                              │
│ readTimeout above 180s fails at synth even when the            │
│ account's origin response timeout quota has been raised        │
└───────────────────────────────┬────────────────────────────────┘
                                │
                                ▼
┌────────────────────────────────────────────────────────────────┐
│ 🔍 Root Cause                                                  │
│ An adjustable, account-scoped service quota is modelled as     │
│ a hardcoded synth-time constant (6 call sites)                 │
│ cloudfront-origins/lib/private/utils.ts#L7-L13                 │
└───────────────────────────────┬────────────────────────────────┘
                                │
                                ▼
┌────────────────────────────────────────────────────────────────┐
│ 🟢 Suggested Fix                                               │
│ Drop the upper bound and let the service validate              │
│ (PR #38432); also fix keepaliveTimeout, capped at 180          │
│ though its default quota is 1-300                              │
└────────────────────────────────────────────────────────────────┘

Thanks for the detailed writeup, and for opening #38432 alongside it. I was able to reproduce this locally on aws-cdk-lib@2.262.0 — readTimeout: Duration.seconds(300) throws with your exact message, while 61 passes, so the inconsistency you describe is real and still present on the latest release.

Checking the CloudFront quotas page makes the case even stronger than the issue states. "Response timeout per origin" is listed as 1-120 seconds — Request a higher quota, so the hardcoded 180 isn't just a low ceiling, it doesn't correspond to any current quota value at all. It's a stale snapshot: the bound was 60, #18628 raised it to 180, and the documented default has since moved to 120. From my view that history is the best argument for your approach over bumping the constant again — otherwise this issue simply recurs at the next quota change.

aws-cdk/packages/aws-cdk-lib/aws-cloudfront-origins/lib/private/utils.ts

Lines 7 to 13 in 38241e2

	export function validateSecondsInRangeOrUndefined(name: string, min: number, max: number, duration?: cdk.Duration) {
	if (duration === undefined) { return; }
	const value = duration.toSeconds();
	if (!Number.isInteger(value) || value < min || value > max) {
	throw new cdk.UnscopedValidationError(lit`InvalidDurationRange`, `${name}: Must be an int between ${min} and ${max} seconds (inclusive); received ${value}.`);
	}
	}

One thing worth folding into the PR while you're in there: the same quotas page lists "Keep-alive timeout per origin" as 1-300 seconds, but keepaliveTimeout is capped at 180 on the very next line of each constructor. I confirmed locally that keepaliveTimeout: Duration.seconds(300) throws, and that value needs no quota increase at all — so that bound is plainly wrong today, not just conservative. Since it's the same fix in the same lines, handling both would avoid an immediate follow-up issue:

aws-cdk/packages/aws-cdk-lib/aws-cloudfront-origins/lib/http-origin.ts

Lines 78 to 79 in 38241e2

	validateSecondsInRangeOrUndefined('readTimeout', 1, 180, props.readTimeout);
	validateSecondsInRangeOrUndefined('keepaliveTimeout', 1, 180, props.keepaliveTimeout);

Until the fix ships, you can keep readTimeout at 180 and override the rendered OriginReadTimeout on the L1 using the generated CfnDistributionPropsMixin from @aws-cdk/cfn-property-mixins (I verified it exposes originReadTimeout). It's awkward because you have to restate the nested origin config structure, which is really just more evidence the L2 bound should go.

Making this a p1.

[M9005]

- Martin-Zack reported a bug where AWS CDK incorrectly caps readTimeout at 180 seconds. - Pahud validated the issue, prioritized it, and suggested fixing keepaliveTimeout limits as well.

…

On Wed, Jul 29, 2026, 23:52 Pahud Hsieh ***@***.***> wrote: *pahud* left a comment (aws/aws-cdk#38433) <#38433 (comment)> Hi @mekza <https://github.com/mekza>, ┌────────────────────────────────────────────────────────────────┐ │ 🔴 Reported State │ │ readTimeout above 180s fails at synth even when the │ │ account's origin response timeout quota has been raised │ └───────────────────────────────┬────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────┐ │ 🔍 Root Cause │ │ An adjustable, account-scoped service quota is modelled as │ │ a hardcoded synth-time constant (6 call sites) │ │ cloudfront-origins/lib/private/utils.ts#L7-L13 │ └───────────────────────────────┬────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────┐ │ 🟢 Suggested Fix │ │ Drop the upper bound and let the service validate │ │ (PR #38432); also fix keepaliveTimeout, capped at 180 │ │ though its default quota is 1-300 │ └────────────────────────────────────────────────────────────────┘ Thanks for the detailed writeup, and for opening #38432 <#38432> alongside it. I was able to reproduce this locally on ***@***.*** — readTimeout: Duration.seconds(300) throws with your exact message, while 61 passes, so the inconsistency you describe is real and still present on the latest release. Checking the CloudFront quotas page <https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html> makes the case even stronger than the issue states. "Response timeout per origin" is listed as 1-120 seconds — Request a higher quota, so the hardcoded 180 isn't just a low ceiling, it doesn't correspond to any current quota value at all. It's a stale snapshot: the bound was 60, #18628 <#18628> raised it to 180, and the documented default has since moved to 120. From my view that history is the best argument for your approach over bumping the constant again — otherwise this issue simply recurs at the next quota change. https://github.com/aws/aws-cdk/blob/38241e2ed3be9c50869a5e18576ff5e8c70dc22e/packages/aws-cdk-lib/aws-cloudfront-origins/lib/private/utils.ts#L7-L13 One thing worth folding into the PR while you're in there: the same quotas page lists "Keep-alive timeout per origin" as 1-300 seconds, but keepaliveTimeout is capped at 180 on the very next line of each constructor. I confirmed locally that keepaliveTimeout: Duration.seconds(300) throws, and that value needs no quota increase at all — so that bound is plainly wrong today, not just conservative. Since it's the same fix in the same lines, handling both would avoid an immediate follow-up issue: https://github.com/aws/aws-cdk/blob/38241e2ed3be9c50869a5e18576ff5e8c70dc22e/packages/aws-cdk-lib/aws-cloudfront-origins/lib/http-origin.ts#L78-L79 Until the fix ships, you can keep readTimeout at 180 and override the rendered OriginReadTimeout on the L1 using the generated CfnDistributionPropsMixin from @aws-cdk/cfn-property-mixins (I verified it exposes originReadTimeout). It's awkward because you have to restate the nested origin config structure, which is really just more evidence the L2 bound should go. Making this a p1. — Reply to this email directly, view it on GitHub <#38433?email_source=notifications&email_token=BNTCQF2VR2DYLTFFO4IEUL35HI6F5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJSGE4DMOBVGMY2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5121868531>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BNTCQF4KPZFCTSWLVNCRPUT5HI6F5AVCNFSNUABFKJSXA33TNF2G64TZHMYTANJYGA4DONRXHNEXG43VMU5TIOJZHA4TMMJYGMZKC5QC> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mekza]

Hi @pahud,

keepaliveTimeout is in #38432 now.

I'd actually seen that bound sitting on the very next line and deliberately left it alone: I only had hard evidence for readTimeout (a live distribution happily accepting 300s once the quota was raised) and didn't want to relax a second bound I hadn't tested. Your pointer to the quotas page is what closed that gap. Keep-alive is documented as 1-300 seconds, so anything from 181 to 300 needs no limit increase at all. That one isn't conservative, it's just wrong.

The history you traced is the bit I'd underweighted, and honestly it's the best argument in the thread. The bound went 60 to 180 while the documented default drifted to 120, so bumping the constant again would just tee this up for whoever hits 300 next.

Thanks for the quick turnaround on this one.