Cross-Region Replication (CRR)

CRR operates on an eventually consistent model. When an object is uploaded to the source bucket, the replication process is triggered asynchronously. This ensures that write operations to the source are not blocked by the latency of the cross-region transfer. The system guarantees a 99.9% Service Level Agreement (SLA) for replication within a defined time window, typically under 15 minutes, though it is often much faster. This mechanism is ideal for compliance and backup rather than synchronous, real-time active-active workloads.

This feature is the primary technical control for enforcing data residency. By configuring a replication rule, you can automatically create a durable, read-only copy of your data in a specific sovereign cloud region. This satisfies legal mandates that require a primary or secondary copy of data to be physically stored within a nation's borders. The destination bucket can be owned by a different account, allowing a security team to hold the keys in a separate compliance zone, preventing source-region administrators from deleting jurisdictional copies.

While standard CRR is one-way, advanced configurations enable bi-directional replication between two buckets in different regions. This is crucial for active-active geo-redundancy where users write to the nearest regional endpoint. To prevent infinite replication loops, the system uses object metadata to track replication status. This architecture supports low-latency global access while ensuring both regions maintain a complete, eventually consistent dataset for failover scenarios.

CRR allows you to change the storage class of the replica independently of the source. For example, you can replicate standard-tier data from a production region directly into a cold archive storage class in a backup region to optimize costs. Additionally, you can override object ownership, forcing the destination bucket owner to become the object owner. This is a critical security feature for compliance, ensuring the source account cannot delete or modify the replicated compliance copy.

A critical data protection feature is the ability to disable the replication of delete markers. In a compliance or backup scenario, you do not want a malicious or accidental deletion in the source region to propagate to your disaster recovery or legal hold copy. By configuring CRR to ignore delete markers, the destination bucket retains a permanent, immutable record of all objects, even after they have been removed from the source, providing a strong safeguard against data destruction.

For compliance-sensitive workloads, Replication Time Control (RTC) provides a predictable, enforceable SLA for replication. Unlike standard CRR, RTC guarantees that 99.99% of objects are replicated within 15 minutes, and the vast majority within seconds. If this SLA is breached, it triggers a monitoring alert. RTC is designed for use cases where the window of inconsistency between regions must be tightly bounded to meet strict Recovery Point Objectives (RPO).

The legal and regulatory requirement that digital data must be stored and processed within the physical borders of a specific country or geographic region. Unlike data sovereignty, which concerns legal jurisdiction, residency focuses on the physical location of the bits. CRR is the primary technical mechanism used to satisfy residency mandates by ensuring a copy of the data exists in a compliant zone.

The two fundamental modes of CRR that dictate the consistency guarantees and latency profile of the system.

• Synchronous Replication: Writes to the source bucket are not acknowledged until the object is durably written to the destination region. This guarantees zero Recovery Point Objective (RPO) but introduces higher write latency due to the speed-of-light delay.
• Asynchronous Replication: The source acknowledges the write immediately and replicates the object to the destination in the background. This offers minimal latency impact but risks data loss in a disaster scenario, resulting in a non-zero RPO.