28 CloudFront Quotas Now Self-Service in Service Quotas: I Tried Out Whether They Take Effect Immediately
This page has been translated by machine translation. View original
Introduction
On November 2, 2026, it became possible to view and request increases for 28 Amazon CloudFront quotas from Service Quotas.
Previously, you could also request increases from Service Quotas, but a support case was opened, you had to wait for AWS Support to respond, and the change was not applied immediately.
In this article, using a single verification account in us-east-1, I requested the default value +1 for three quotas and observed how the Status and the applied values changed.
List of supported quotas
You can get the target quotas with the following commands. list-service-quotas returns the applied values, and list-aws-default-service-quotas returns the default values. The region is specified with an environment variable.
export AWS_REGION=us-east-1
aws service-quotas list-service-quotas --service-code cloudfront
aws service-quotas list-aws-default-service-quotas --service-code cloudfront
list-service-quotas returned 28 quotas, and all of them had Adjustable set to true. Value is the applied value after any increase, and the three quotas that I raised by +1 in the request described later, Cache policies per AWS account, Origin request policies per AWS account, and Headers per cache policy, differ from the default values in the table below.
| Quota | Default value |
|---|---|
| Web distributions per AWS account | 500 |
| Alternate domain names (CNAMEs) per distribution | 100 |
| Origins per distribution | 100 |
| Staging distributions per AWS account | 20 |
| VPC origins per AWS account | 25 |
| Response timeout per origin | 120 seconds |
| Keep-alive timeout for a custom origin associated with distribution | 300 seconds |
| Cache policies per AWS account | 20 |
| Headers per cache policy | 10 |
| Cookies per cache policy | 10 |
| Query strings per cache policy | 10 |
| Origin request policies per AWS account | 20 |
| Headers per origin request policy | 10 |
| Cookies per origin request policy | 10 |
| Query strings per origin request policy | 10 |
| Response headers policies | 20 |
| Custom headers per response headers policy | 10 |
| Distributions associated with the same response headers policy | 100 |
| Length of the content security policy value in a response headers policy | 1,783 |
| Continuous deployment policies per AWS account | 20 |
| Key groups per AWS account | 10 |
| Distributions associated with the same origin access control | 100 |
| CloudFront Functions: Maximum number of distributions associated with a single function | 100 |
| Maximum number of connection functions per AWS account | 100 |
| Maximum number of trust stores per AWS account | 20 |
| Maximum number of multi-tenant distributions per AWS account | 500 |
| Maximum number of distribution tenants per AWS account | 1,000,000 |
| Maximum number of connection groups per AWS account | 100 |
Measuring the increase requests
Test conditions
For the verification, I used a billing proxy account with Enterprise Support. In this account, directly opening support cases is restricted, but Service Quotas is available.
The targets were three quotas: Cache policies per AWS account (20), Origin request policies per AWS account (20), and Headers per cache policy (10), and I requested the default value +1 for each.
Request and approval
I ran the request for Cache policies per AWS account with the following command.
$ aws service-quotas request-service-quota-increase --service-code cloudfront --quota-code L-7D134442 --desired-value 21 --output json
"ServiceCode": "cloudfront",
"QuotaCode": "L-7D134442",
"QuotaName": "Cache policies per AWS account",
"DesiredValue": 21.0,
"Status": "PENDING",
"Created": "2026-11-03T12:01:32.973000+09:00",
For the other two, I ran the same command with the quota-code changed to L-C3659C43 (desired-value 21) and L-4C99C1B4 (desired-value 11).
About 10 seconds after the requests, I retrieved the status of the three requests by specifying the request IDs.
aws service-quotas get-requested-service-quota-change --request-id <申請ID> --query "RequestedQuota.{QuotaName:QuotaName,DesiredValue:DesiredValue,Status:Status,CaseId:CaseId,LastUpdated:LastUpdated}" --output json
The result for Cache policies per AWS account is as follows.
2026-11-03T12:01:43+0900
{
"QuotaName": "Cache policies per AWS account",
"DesiredValue": 21.0,
"Status": "APPROVED",
"CaseId": null,
"LastUpdated": "2026-11-03T12:01:33.781000+09:00"
}
No support case was created, and CaseId remained null. When I checked about 10 seconds after the request, all three were APPROVED, and LastUpdated was within 1 second of the request.
Reflection of the applied values
I checked the applied values with Value from get-service-quota. The first check was about 20 seconds after the request, and at that point all three had already been reflected.
| Quota | Before request | About 20 seconds later | About 11 minutes later |
|---|---|---|---|
| Cache policies per AWS account | 20 | 21 | 21 |
| Origin request policies per AWS account | 20 | 21 | 21 |
| Headers per cache policy | 10 | 11 | 11 |
Summary
In this verification, I confirmed that CloudFront quota increases were applied immediately through Service Quotas.
An increase for Response headers policies that I requested in a different account a few weeks ago opened a support case and took about four and a half hours to be approved.
In environments that manage many cache policies and the like with IaC, you may hit a quota when expanding, but you can expect to raise it on the spot and keep working.
However, the upper limit of values that are approved immediately is not stated in the official documentation. If you request an extremely large value, it may not be auto-approved and may wait for support review. Also, quotas not listed in Service Quotas still require requests through support cases as before.
If you need an increase of a scale with no past track record, I recommend requesting it with a generous schedule, assuming that support involvement will occur.
