Introducing change-based throttling for Amazon Route 53 APIs

Amazon Route 53 now uses change-based throttling (CBT) and has doubled its default API request rate from 5 to 10 requests per second. This gives you more room to automate DNS management at scale. CBT is a new per-account model that measures DNS change throughput. Together, these updates benefit Route 53 accounts immediately.

Note: These limits apply to Route 53 DNS APIs (hosted zones, records, and health checks). They don’t apply to Route 53 Resolver, Route 53 Profiles, or domain registration APIs, which have their own separate limits.

DNS automation has grown, driven by infrastructure as code (IaC) tools such as Terraform and AWS Cloud Development Kit (AWS CDK), multi-account architectures, and continuous integration and continuous delivery (CI/CD) pipelines. The previous five requests-per-second default no longer matched how customers use Route 53, so we increased the API limits to reflect current usage patterns.

This post explains what changed, how the new throttling model works, and best practices for using your Route 53 API capacity. It’s intended for DevOps engineers, cloud architects, and site reliability engineers (SREs) who manage DNS records programmatically with Route 53. It assumes intermediate (200-level) familiarity with Route 53 APIs.

What changed

Since July 30, 2026, two updates have applied to all Route 53 accounts:

The default API request rate is 10 requests per second (up from 5).
A new change throughput limit of 100 DNS record changes per second (sustained) keeps the service stable for customers. See the Route 53 API throttling documentation for details.

Overview of the new throttling model

Route 53 now applies two independent throttling limits to every account. Both use a token bucket algorithm: a bucket fills at a steady rate (the sustained limit) and holds a maximum number of tokens (the burst capacity). Either limit can throttle a request.

Think of each bucket like a water tank: it fills at a steady drip (the sustained rate), and you can pour out a full tank at once (the burst). When empty, you can only use water as fast as it drips in. Two values describe each bucket: the maximum capacity (how much you can burst) and the refill rate (how much you can sustain).

Request rate limit

The request rate limit controls how many API calls your account can make per second. The default bucket holds 50 tokens (burst) and refills at 10 tokens per second (sustained). This applies at the account level across all Route 53 API operations combined. Some operations have lower limits: for example, CreateHostedZone refills at 2 per second and CreateHealthCheck at 0.5 per second. For the complete per-operation table, see the Route 53 API throttling documentation.

Change throughput limit

The change throughput limit is new. It measures the number of DNS record modifications your account submits per second, regardless of how you batch them across API calls. The bucket holds 1,500 tokens (burst) and refills at 100 tokens per second (sustained).

Changes are counted as follows:

Operation	Tokens consumed
ChangeResourceRecordSets (CREATE)	1 per change
ChangeResourceRecordSets (DELETE)	1 per change
ChangeResourceRecordSets (UPSERT)	2 per change
AssociateVPCWithHostedZone	2
DisassociateVPCFromHostedZone	2
CreateHostedZone	2
DeleteHostedZone	2

All other Route 53 API operations consume zero change-throughput tokens.

How the two limits interact

A single ChangeResourceRecordSets request can contain up to 1,000 changes. Each request consumes tokens from both buckets independently. Two examples:

Example 1 (within limits): You make 10 requests per second, each containing 5 changes. That consumes 10 request-rate tokens (the bucket refills at 10 per second) and 50 change-throughput tokens (the bucket refills at 100 per second). Both limits are satisfied and no throttling occurs.

Example 2 (exceeds change throughput): You make 10 requests per second, each containing 100 changes. That consumes 10 request-rate tokens, within the limit, but 1,000 change-throughput tokens per second, far above the 100-per-second sustained refill rate. The change throughput bucket depletes rapidly and subsequent requests are throttled until it refills.

The request rate controls how frequently you call the API. The change throughput controls how much work those calls collectively represent.

What this means for your workloads

How these limits affect you depends on how you use the Route 53 API. The following scenarios cover the two most common patterns.

Infrastructure as code workflows

If you use Terraform, AWS CDK, or similar tools, you typically make many API calls with few changes per call. The doubled request rate (10 requests per second) is the primary benefit: your plans apply faster and you encounter fewer throttling errors. If your automation submits fewer than 100 total changes per second, which is typical for most Terraform and AWS CDK deployments, the change throughput limit requires no adjustment to your workflow.

Batch DNS migrations

If you migrate thousands of records between hosted zones, the change throughput limit becomes the relevant constraint. You can sustain 100 changes per second indefinitely. For a one-time batch of up to 1,500 changes, the burst capacity absorbs it entirely.

Example: Suppose you are migrating 10,000 A records to a new hosted zone. At 100 changes per second sustained, the migration completes in 100 seconds. To stay within the sustained rate, batch 100 changes into each API call and submit one request per second. This consumes exactly 100 change-throughput tokens per second (matching the refill rate) and 1 request-rate token per second (well under the 10-per-second limit). Batching more changes per call doesn’t raise throughput. It only spends the burst sooner, so 10,000 changes finish in about 86 seconds instead of 100. After the burst is spent, throughput stays at 100 changes per second and further calls are throttled.

Requesting a limit increase

Some workloads need more than 10 API requests per second or more than 100 changes per second. If yours does, you can request a limit increase through AWS Support. Explain why you need higher limits so we can review the request.

Best practices

These practices help you stay within both limits and recover gracefully when you hit them.

Balance request rate against batch size. If throttled by request rate, put more changes into fewer calls (up to 1,000 per request). If throttled by change throughput, reduce total changes per second.
Spread changes over time. Distribute changes evenly across seconds rather than submitting large batches simultaneously. For 6,000 changes, spread over 60 seconds (100 per second) rather than all at once.
Rely on burst for occasional spikes, not sustained throughput. Burst capacity accommodates legitimate traffic spikes. It isn’t a sustained operating ceiling.
Retry throttled requests with exponential backoff and random jitter. Retry only HTTP 400 responses with the Throttling error code. Other 400 errors mean the request itself is invalid, and they fail again on retry. Wait a progressively longer time between retries, and add a small random delay (jitter) so clients don’t all retry at the same moment. AWS SDKs retry with backoff by default. Adaptive retry mode is opt-in, and it limits how often you send requests, not how many changes they contain. Retries only absorb short spikes. If your workload averages more than 100 changes per second, pace your changes or request a limit increase. For more information, see Timeouts, retries, and backoff with jitter.
Monitor throttling. Watch your application logs for HTTP 400 responses with the Throttling error code to detect when you approach either limit.

Conclusion

With change-based throttling, you get more API capacity without sacrificing stability. Route 53 now measures change throughput in addition to request count, and both limits apply to every request. This lets us double the default API request rate while keeping the service stable for customers.

To get started, review the Route 53 API throttling documentation and visit Amazon Route 53 to learn more. If your workload requires higher limits, you can request an increase through AWS Support.