S3 Cross-Region and Same-Region Replication

S3 Replication is an automatic, asynchronous feature that copies objects from a source bucket to a destination bucket. The destination can be in the same AWS Region (Same-Region Replication, SRR) or a different AWS Region (Cross-Region Replication, CRR). Replication is configured at the bucket level using replication rules, which specify the source bucket, destination bucket, IAM role, and optional filters (e.g., prefix, tags). Once enabled, any object upload, delete, or metadata change that meets the rule criteria is replicated to the destination bucket.

Replication addresses several key requirements: - Disaster Recovery (DR): CRR provides geographic redundancy, ensuring data survives a region-wide outage. - Compliance: SRR can maintain copies in the same region for regulatory requirements like data sovereignty. - Latency Reduction: CRR places data closer to users in different geographies. - Data Aggregation: SRR consolidates data from multiple buckets into a single bucket for analytics. - Security: Replicating to a different account can isolate data for access control.

When an object is uploaded to the source bucket, S3 triggers the replication process:

Replication is configured via the AWS Management Console, AWS CLI, or SDKs. Here is an example CLI command to set up replication:

aws s3api put-bucket-replication \
    --bucket source-bucket \
    --replication-configuration file://replication.json

Example replication.json:

{
  "Role": "arn:aws:iam::123456789012:role/s3-replication-role",
  "Rules": [
    {
      "Status": "Enabled",
      "Priority": 1,
      "Filter": {
        "Prefix": ""
      },
      "Destination": {
        "Bucket": "arn:aws:s3:::destination-bucket",
        "StorageClass": "STANDARD_IA"
      },
      "DeleteMarkerReplication": {
        "Status": "Disabled"
      }
    }
  ]
}

To verify replication status:

aws s3api head-object --bucket source-bucket --key myobject.txt

Look for the ReplicationStatus field in the output.

A media company produces video content in the US (us-east-1) and needs to distribute it to users in Europe and Asia. They use CRR to replicate content to buckets in eu-west-1 and ap-southeast-1. This reduces latency for end users and provides disaster recovery. The source bucket stores original high-resolution files (S3 Standard), while destination buckets use S3 Standard-IA to save costs since content is accessed less frequently after initial distribution. They enable Replication Time Control (RTC) for critical content to ensure a 15-minute RPO. A common mistake is forgetting to enable RTC, leading to hours of replication delay during peak upload times. They also set up S3 Event Notifications on the destination buckets to trigger Lambda functions that transcode videos for local formats. Monitoring is done via CloudWatch dashboards showing replication latency and pending bytes. When misconfigured (e.g., missing IAM permissions), replication silently fails, and the company may serve stale content to users.

A financial institution must maintain copies of all transaction records within the same region for regulatory compliance. They use SRR to replicate from multiple application buckets (e.g., 'transactions-prod', 'transactions-archive') to a central 'compliance-audit' bucket. The central bucket has Object Lock enabled to prevent modification or deletion for a retention period of 7 years. SRR ensures that all records are automatically copied without application changes. They configure replication rules with filters based on prefixes (e.g., 'year=2024/') to replicate only relevant data. A challenge is that delete markers are not replicated by default; if an application deletes an object, the compliance bucket still retains the original, which is desired. However, they must ensure that the IAM role has permissions to write to the destination bucket, which is in a different AWS account. They use a bucket policy on the destination to allow cross-account writes. A common issue is that the destination bucket's Object Lock retention period conflicts with the source's lifecycle policy, causing replication failures. They resolve this by ensuring the destination bucket's default retention mode is 'COMPLIANCE' and that the source bucket does not have a lifecycle rule that expires objects before the retention period.

A SaaS company runs its primary infrastructure in us-west-2 and wants DR in us-east-2. They use CRR to replicate all bucket data, including user uploads and configuration files. They enable delete marker replication to ensure that deletions are also mirrored. They use S3 Batch Replication to backfill existing data. They monitor replication using S3 replication metrics and set up alarms for high latency. A critical consideration is that replication is asynchronous; during a disaster, some data may not yet be replicated. They mitigate this by also using S3 Versioning to recover from accidental deletions. They test DR by periodically failing over to the secondary region using Route53 and bucket policies. A common exam trap is assuming replication provides synchronous data protection; it does not. The company also uses S3 Object Lock on the destination bucket to prevent ransomware from encrypting replicated data.