On this page · 9 sections
Summary. On 17 August 2026 AWS raised the Amazon ECR cross-region replication limit from 10 rules to 25 rules per registry. The announcement says the change is available "in all AWS Regions where Amazon ECR is supported". The ECR service quota table says otherwise: ap-east-2 is still capped at 10 rules, and the quota is marked non-adjustable. The more consequential detail is the one the announcement does not mention at all. Unique destinations across all rules in a replication configuration remain capped at 25, unchanged. So 25 rules buy you finer-grained filtering, not wider fan-out. Replication itself is billed as cross-region data transfer plus $0.10 per GB-month of storage in each destination region, so the quota raise is free and the architecture it invites is not.
What actually changed on 17 August 2026
AWS published "Amazon ECR now supports 25 replication rules per registry" to the What's New feed on 17 August 2026 at 19:01 UTC. The registry-level replication configuration that previously accepted 10 rules now accepts 25. Each rule may carry up to 100 filters, which is where the real gain sits: you can now express 25 distinct repository-prefix policies instead of cramming them into 10.
The announcement text states availability "in all AWS Regions where Amazon ECR is supported."
The Amazon ECR service quotas page records a different picture. Under "Rules per replication configuration" the table lists ap-east-2 at 10 and each of the other supported Regions at 25. The same split is mirrored in the AWS general reference entry for Amazon ECR endpoints and quotas. Both mark the quota Adjustable: No, which means a support ticket will not raise it.
If your registry lives in ap-east-2, nothing changed for you on 17 August. That is a small blast radius, but it is exactly the kind of gap that turns an infrastructure-as-code rollout into a failed apply at 2am.
The limit that did not move
The ECR private registry replication documentation states the constraint plainly: a replication configuration supports "up to 25 unique destinations across all rules, with a maximum of 25 rules total. Each rule may contain up to 100 filters."
Read those two numbers together. Before 17 August you had 10 rules and 25 unique destinations. After 17 August you have 25 rules and 25 unique destinations. The number of Regions or accounts an image can land in is identical. What you gained is the ability to route different repository prefixes to different destination sets without collapsing them into a shared rule.
That is a genuine improvement for teams running one registry across several product lines. It is not, as several roundups have framed it, a fan-out increase.
| Constraint | Before 17 Aug 2026 | After 17 Aug 2026 | Adjustable |
|---|---|---|---|
| Rules per replication configuration | 10 | 25 (ap-east-2: 10) | No |
| Unique destinations across all rules | 25 | 25 | No |
| Filters per rule | 100 | 100 | No |
| Replication hops | 1 | 1 | Not a quota |
| Cross-partition replication | Not supported | Not supported | Not a quota |
The four behaviours that break real pipelines
Rule count is rarely what bites teams. These four are, and all four are documented in the ECR replication guide rather than in the announcement.
Pre-existing images are never replicated. Replication applies only to content pushed after the configuration is in place. Standing up a new destination Region does not backfill the registry. If your disaster-recovery plan assumes the destination holds the same tags as the source, it does not, until every one of those tags has been pushed again.
Replication is one hop, not transitive. A rule replicating us-west-2 to us-east-1, plus a rule replicating us-east-1 to us-east-2, does not move images from us-west-2 to us-east-2. Each destination needs its own rule from the source. This is the single most common misreading of the feature, and the new 25-rule ceiling makes hub-and-spoke designs look more attractive than they actually are.
Tag immutability produces untagged images. With tag immutability enabled on the destination repository, a replicated image whose tag already exists lands untagged rather than overwriting. Your latest in the destination Region then silently points at an older digest while the new layer sits in the repository with no tag on it.
Repository settings do not replicate. Lifecycle policies, scanning configuration, encryption settings and repository policies are not carried across. Repository creation templates are the mechanism for applying settings to auto-created destination repositories; without them the destination repository is created with defaults.
Cross-account replication adds one more: the registry policy goes on the destination account, not the source, and it needs both ecr:ReplicateImage and ecr:CreateRepository. Granting only the first produces a replication that fails on any repository that does not already exist in the destination.
What 25 rules actually costs
The quota raise is free. The replication it enables is not.
Amazon ECR charges $0.10 per GB-month for stored images in each Region, per the AWS Price List API offer for Amazon EC2 Container Registry. Archive storage is $0.07 per GB-month and archive retrieval is $0.03 per GB. Replicating an image into a destination Region creates a second billable copy in that Region, and standard cross-region data transfer applies to the copy operation.
Work the arithmetic on a mid-sized registry. A team holding 500 GB of images pays $50 per month in the source Region. Replicating the full set into three destination Regions adds three more copies: $150 per month in storage before any transfer charge. Push the same policy to the full 25 unique destinations and the storage line is $1,250 per month for the same 500 GB of content.
| Scenario | Destinations | Stored GB (total) | Storage cost/month |
|---|---|---|---|
| Single Region | 0 | 500 | $50 |
| Standard DR pair | 1 | 1,000 | $100 |
| Three-Region active | 3 | 2,000 | $200 |
| Full fan-out at the ceiling | 25 | 13,000 | $1,300 |
Prefix filters are the lever that keeps this sane, and 25 rules with 100 filters each is a lot of lever. Replicate the images a Region actually runs, not the registry.
Who should act on this
You should re-read your replication configuration this week if any of the following is true. You hit the 10-rule ceiling and worked around it by merging prefixes into a catch-all rule; that workaround can now be unwound into explicit rules. You run a registry in ap-east-2 and have Terraform or CloudFormation that assumes 25 rules everywhere. You have a destination Region added in the last quarter and have not confirmed that every tag your runbook depends on was pushed after the configuration date.
If none of those apply, this is a quota note, not a project.
Teams sizing a genuine multi-region container footprint usually find the registry is the cheap part. Our multi-region resilience and disaster recovery work almost always spends more effort on data-plane failover than on image distribution. The registry copy is the easy $100 a month; the RDS switchover plan is the hard part.
What is still unknown
AWS has not published whether the ap-east-2 cap is a temporary rollout gap or a standing regional limit. The quota table marks it non-adjustable, which suggests the latter, but the announcement's "all Regions" wording suggests the former. There is no dated statement resolving the two. Until there is, treat ap-east-2 as 10 in any code that reads the quota.
FAQ
How eCorpIT can help
eCorpIT is an ISO 27001:2022 certified, CMMI Level 5 engineering organisation working with AWS on container platform design for teams in India and abroad. Our senior engineering teams audit registry replication configurations against the documented quota table rather than the announcement text, and cost the resulting storage footprint before it lands on the bill. If your multi-region container strategy has grown past what one registry policy can express cleanly, contact us and we will review the configuration with you.
References
Last updated: 22 August 2026.
