Published on · Updated on
Reworked the five use cases and clarified replication timing, routing, recovery limits, permissions, and cost tradeoffs.
Amazon S3 Cross-Region Replication (CRR) automatically copies eligible objects from a source bucket to one or more buckets in other AWS Regions. It is useful when an application needs another regional copy of its data, but replication alone does not route requests, create an application failover plan, or guarantee that every copy is current.
Here are five situations where CRR can help, along with the design decisions that make each one work.
CRR is asynchronous live replication. A rule on the source bucket selects objects by prefix, tags, or both, and S3 copies eligible new object versions to the configured destination. Both buckets must have versioning enabled, and an IAM role must give S3 permission to replicate. Objects already in the source bucket are not copied retroactively; use S3 Batch Replication when you need to backfill them. See AWS's live replication setup overview and the guide to replicating existing objects.
Replication can take time. A destination copy may lag behind a recent source write, so an application must decide which Region to read from and whether that delay is acceptable. For a primer on buckets and Regions, see Amazon S3 for beginners.
A team may need an object copy in a particular AWS Region to serve a local workload or support an approved data-location policy. CRR can copy selected objects to that Region, and its rules let you control which data moves.
Check what the policy actually requires before configuring replication. CRR adds a destination copy; it does not remove the source object. If data must be stored only in one geography, copying it elsewhere may conflict with that requirement. Region choice also does not, by itself, settle questions about access, retention, backups, or international data transfers. AWS describes Regions as distinct geographic areas and publishes their locations in its Regions and Availability Zones guide.
Replicating objects closer to a group of users can reduce the distance their reads travel. CRR supplies the copy, but it does not decide which bucket receives an application request. The client or application must use the intended regional endpoint, or use a routing feature designed for multi-Region access.
An S3 Multi-Region Access Point provides one global endpoint and routes requests over the AWS global network to a nearby bucket with active routing. It routes by proximity, not by checking whether that bucket contains the requested object. Configure replication separately to keep the buckets' datasets aligned, and make sure the application can tolerate replication delay. AWS explains both features in its guides to Multi-Region Access Points and S3 Replication.
A second regional copy can help restore access to object data after a regional disruption. It does not automatically fail over the application or recover its compute, network, identity, database, and external-service dependencies. Set a recovery time objective (RTO), the maximum acceptable outage, and a recovery point objective (RPO), the maximum acceptable age of recovered data. Then plan how operators or automation will restore the full workload.
S3 Replication Time Control (RTC) is an option when a rule needs a more predictable replication time. AWS says RTC is designed to replicate 99.99% of new objects within 15 minutes; its SLA commits to at least 99.9% within 15 minutes for each Region pair and account in a monthly billing cycle, subject to the SLA's exclusions. It is not a promise that every object is immediately available. Review the current S3 replication FAQ, RTC SLA, and S3 pricing; RTC adds charges, and replication metrics help reveal pending or failed work.
Versioning lets you retain and retrieve object versions, but replication should not be treated as an isolated, immutable backup. In current filtered replication rules, delete markers are not copied by default; deleting a specific version is also not replicated. Check AWS's replication and deletion behavior, and use a separate backup or retention design when recovery must survive destructive changes. Then test the recovery path, including application startup and traffic redirection. The guide to testing AWS disaster recovery explains how to validate more than a successful copy.
CRR can publish a controlled copy to a destination bucket owned by a separate account. This is useful when a security, analytics, audit, or partner account should manage its own copy without using the source account's bucket as the shared access boundary.
The source account configures an IAM role for S3 replication, and the destination account grants that role access with a bucket policy. If the destination should own the replicas, configure S3 Object Ownership with Bucket owner enforced or use the replica ownership setting. For SSE-KMS objects, explicitly enable replication of KMS-encrypted objects in the rule, allow the replication role to use the source key, and grant it encryption access to a customer-managed KMS key in the destination account and Region. See AWS's instructions for cross-account replication and replicating KMS-encrypted objects. For the broader access-policy model, read Amazon S3 access management.
An application can run in multiple Regions and use replicated S3 buckets for static assets, user uploads, or other objects that each regional stack needs. A one-way rule works when one Region owns writes and others mainly read. If users can write in several Regions, configure replication in each direction and design the application around the time before each copy arrives.
Bidirectional rules do not provide a transaction across Regions or merge conflicting writes to the same object key. Define which Region owns each key or implement conflict handling in the application. Multi-Region routing and replicated objects are separate parts of the design: a Multi-Region Access Point can route a request, while CRR copies object versions asynchronously. For the wider architecture choices, see the AWS multi-Region active-active design guide.
Each replica consumes storage in its destination bucket. Replication can also add request, inter-Region transfer, encryption-key, and RTC charges. The total depends on the Regions, volume and size of objects, destination storage class, and replication options. Estimate the workload before enabling broad rules, monitor replication status, and apply lifecycle policies only when their effect on current and noncurrent versions fits the recovery plan. The guide to S3 Lifecycle rules and storage costs covers those tradeoffs.
CRR is a good fit when an application or team needs selected object versions copied to another Region or account. Start with the data that must move, the delay readers can tolerate, the behavior expected after deletes, and the recovery objective. Then configure the matching IAM, bucket, and KMS permissions, monitor replication, and test the application path that consumes the destination copy.
No. Live replication applies to eligible objects created or updated after the rule is configured. Use S3 Batch Replication to copy existing objects.
No. CRR copies objects. Your application or a routing service must direct requests to a destination bucket, and you must recover the rest of the workload separately.
No. Replication is asynchronous, some object operations have special replication behavior, and a replica can lag. Check object replication status and configure deletion behavior for your rule rather than assuming the destination is an exact, instantaneous mirror.