Setting Up S3 Cross-Account Replication

AWS stores S3 data redundantly across at least three availability zones within a region, providing eleven nines of durability. For most use cases that’s more than sufficient — but there are scenarios where replicating data to a different account or region is still worth doing.

Common reasons include cross-region disaster recovery, compliance requirements that mandate copies in specific locations, protecting data from accidental deletion or modification in the source account, and placing data geographically closer to users. AWS handles all of this through S3 replication rules, which continuously copy new objects from a source bucket to one or more destinations.

Before You Start

Replication requires versioning to be enabled on both the source and destination buckets. Versioning preserves a copy of every object version, which replication depends on to track changes. This can be enabled under each bucket’s Properties tab.

One important caveat: replication only applies to objects uploaded after the rule is created. Existing objects aren’t automatically copied. To replicate those, a separate S3 Batch Operation is needed.

Creating the Replication Rule

Inside the source bucket, navigate to the Management tab and select Create replication rule. Give the rule a descriptive name — since multiple rules can exist on a single bucket, a name that conveys what’s being replicated and where is helpful long-term.

Rules can apply to all objects in the bucket or be scoped down using filters:

• Prefix filter — Limits replication to objects whose key starts with a given prefix, such as logs/ or backups/2026/.
• Tag filter — Limits replication to objects with specific key-value tag pairs.
• Both filters can be combined for more precise targeting.

Destination and IAM Configuration

For cross-account replication, the destination requires both the target account ID and the bucket name. There’s also an option to change object ownership to the destination bucket owner — useful when the source account owns the objects and the destination account needs full access to them without relying on ACLs.

For the IAM role, selecting Create new IAM role lets AWS automatically generate a role with the permissions needed for standard replication. Once the rule is saved, note the ARN of the role that was created — it’s needed in the next step.

Granting Access from the Destination Account

The replication role lives in the source account, but it needs permission to write objects into the destination bucket. That permission is granted via a bucket policy on the destination side.

Log into the destination account, navigate to the bucket, and go to Permissions → Bucket policy. Add the following, replacing the role ARN and bucket name with your values:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{Account-ID}:role/service-role/{Role-Name}"
      },
      "Action": [
        "s3:ReplicateObject",
        "s3:ReplicateDelete",
        "s3:ReplicateTags",
        "s3:GetObjectVersionForReplication",
        "s3:GetObjectVersionAcl",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": "arn:aws:s3:::{destination-bucket}/*"
    }
  ]
}

Encryption Options

By default, replicated objects use SSE-S3 encryption (AWS-managed keys). If stricter key control is needed, KMS encryption can be applied instead.

Using a KMS key from the source account — The destination bucket and any roles that access replicated objects will need permission to use the key for decryption.

Using a KMS key from the destination account — The replication role in the source account needs permission to use the destination account’s key for encryption. The full key ARN from the destination account is entered manually.

Additional Options Worth Knowing

A few optional settings are useful depending on the use case:

Destination storage class — By default, replicated objects inherit the storage class of the source. This can be overridden to place replicated copies in a cheaper storage tier.

Replication Time Control (RTC) — For buckets with large or numerous objects, replication can lag. RTC guarantees that objects are replicated within 15 minutes, at additional cost.

Replication metrics — Publishes numeric replication metrics to CloudWatch, useful for monitoring and alerting on replication health.

Delete marker replication — When an object is deleted in a versioned bucket, a delete marker is added rather than removing the object outright. By default, that marker isn’t replicated, so the object still appears active in the destination. Enabling this setting replicates delete markers so both buckets reflect deletions consistently.

Replica modification sync — Allows metadata changes made in the destination bucket to propagate back to the source. This is the only form of bidirectional sync S3 replication supports — it doesn’t replicate new objects or deletes back to the source, only metadata.

Closing Thoughts

Cross-account replication is straightforward once versioning, IAM, and the destination bucket policy are aligned. The most common setup issues come from the destination bucket policy missing the right actions or the replication role lacking permissions to write to the target. Enabling event notifications for failed replication events on the destination bucket makes those issues visible quickly.