S3 Replication – Complete Guide

If you’ve ever needed to keep files in sync between S3 buckets—whether that’s in the same region, across regions, or even across different AWS accounts—S3 Replication is the feature you want. I’ve used it for disaster recovery setups, compliance requirements, and just plain old data redundancy. Let me walk you through how it works and how to set it up.

What is S3 Replication, and why would you use it

S3 Replication automatically copies objects from one bucket to another. The source and destination buckets can be in the same region (Same-Region Replication, or SRR) or different regions (Cross-Region Replication, or CRR). You can even replicate between buckets owned by different AWS accounts.

Here’s where it comes in handy:

• Compliance and data residency: Some regulations require data to live in specific geographic locations. CRR lets you store copies in a region that meets those requirements.
• Disaster recovery: If one region has issues, you can fail over to another without losing data.
• Lower latency: Serving content from a region closer to your users means faster downloads.
• Aggregating logs: SRR makes it easy to collect logs from multiple sources into one bucket.
• Separating environments: Replicate from production to test without manual interventions.

There’s also S3 Replication Time Control (S3 RTC), which gives you a 15-minute SLA for new objects to replicate. That’s useful when you need predictable replication timing backed by a service commitment.

Setting up S3 Replication

You’ll need to enable versioning on both source and destination buckets—S3 Replication won’t work without it.

The basic setup happens in the S3 console:

1. Go to your source bucket
2. Navigate to the Replication rules section
3. Create a new replication rule
4. Choose your destination bucket (it can be in another account)
5. Assign an IAM role that S3 can assume to perform the replication

If you’re managing multiple buckets or want infrastructure-as-code, AWS CLI, Terraform, or the AWS SDKs all support creating and managing replication configurations. I tend to use Terraform for anything beyond a quick test—it keeps the configuration version-controlled and repeatable.

For the IAM role, S3 needs permissions to read objects from the source bucket and write them to the destination. The console can create a role with the right permissions automatically, or you can roll your own if you need finer control.

Replication types

Cross-Region Replication (CRR): Objects copy to a bucket in a different region. Good for disaster recovery and serving users in multiple geographic areas.

Same-Region Replication (SRR): Objects copy to another bucket in the same region. Useful for log aggregation, separating test and production environments, or meeting data sovereignty rules.

Cross-Account Replication: The destination bucket belongs to a different AWS account. You control who pays for storage, and you can even change replica ownership to the destination account.

S3 Batch Replication: This replicates objects that already existed before you enabled replication, or objects that failed to replicate previously. It runs on demand rather than continuously.

Two-Way Replication: With this, metadata changes like ACL updates, tag modifications, and object lock settings sync back to the source. Combined with S3 Multi-Region Access Points, you can set up active-active configurations for failover scenarios.

Encrypted objects

If your objects use server-side encryption (SSE-S3, SSE-KMS, or SSE-C), the replication process handles it:

• SSE-S3: The object replicates as-is, encrypted with the same key.
• SSE-KMS: The destination bucket needs access to the same KMS key, either directly or through cross-account permissions. If the destination can’t use the key, replication fails.
• SSE-C: You provide your own encryption key, and S3 manages encryption during replication.

For client-side encrypted objects, the encrypted blob replicates as-is. The destination needs the decryption key to read the contents.

Troubleshooting common issues

Replication doesn’t always work perfectly. Here are the problems I run into most often:

Replication lag: Objects taking longer than expected to appear in the destination bucket. This usually comes down to network issues, bandwidth constraints, or replication rule misconfiguration. S3 RTC helps monitor and alert on replication time SLAs.

Replication failures: Objects fail to replicate entirely. Check the S3 console replication metrics and CloudWatch logs. Common causes include missing IAM permissions, destination bucket policy conflicts, or KMS key access issues.

Data consistency gaps: The source and destination get out of sync—usually when deletes happen on the source before replication finishes. Versioning helps track which objects need attention. S3 doesn’t prevent deletes from propagating, so if you need to protect against accidental deletes, consider S3 Object Lock or enable versioning with MFA delete.

Insufficient permissions: The IAM role S3 uses can’t read from the source or write to the destination. Double-check the role’s trust policy allows S3 to assume it, and that the access policy grants the right bucket and object permissions.

Costs running higher than expected: Replication egress fees apply for cross-region copies. If you’re replicating a lot of data, watch out for those charges. S3 Intelligent-Tiering can help by moving rarely-accessed replicated data to cheaper storage classes automatically.

Best practices

A few things I’ve learned the hard way:

Plan your data selection: Don’t replicate everything blindly. Use prefixes, tags, or object filters to limit replication to what you actually need. This keeps costs down and replication faster.

Think about ownership: By default, the source account owns the replicas. You can enable the owner override option to give the destination account ownership—useful when replicating across accounts.

Test your recovery procedure: Having replicas sitting in another bucket doesn’t help if you don’t know how to restore from them. Document and practice your failover process.

Monitor replication status: Use S3 Replication metrics in CloudWatch to track pending operations, latency, and failures. Set up alerts so you know when something breaks.

Consider your encryption strategy: Make sure KMS keys are accessible across accounts before you enable replication. Nothing worse than discovering a replication failure months later because of a missing key grant.

Wrapping up

S3 Replication is solid technology for keeping buckets in sync. I’ve used it for disaster recovery, compliance, and operational convenience. The setup isn’t complicated, but you do need to understand versioning, IAM permissions, and how encryption works across accounts.

Once it’s running, keep an eye on replication metrics and costs. The flexibility to replicate across regions, accounts, or just within the same region covers most use cases I encounter.

If you have questions about specific scenarios, the AWS documentation has detailed examples for different replication configurations.