S3 Replication Not Working? Existing Objects, Versioning, IAM Role, Delete Markers, Cross-Account, KMS, How Long It Takes, RTC and Cost

S3 replication copies new objects from one bucket to another automatically, in the same Region (SRR) or another Region (CRR), in the same account or a different one. When it seems not to work, the cause is usually one of these: the objects existed before the rule (replication only copies new objects; use S3 Batch Replication for existing ones); versioning is not enabled on both buckets; the IAM role lacks a permission or its trust policy does not allow s3.amazonaws.com; the rule's prefix or tag filter does not match (tags must be set when the object is uploaded); objects are SSE-KMS encrypted and the rule does not opt in or the role cannot use the keys; a cross-account destination bucket policy does not allow the role; or the objects are in Glacier storage classes. Deletes behave differently by design: delete markers are only replicated if you turn that on, and deleting a specific version is never replicated. Most objects replicate within 15 minutes; check an object with aws s3api head-object and read ReplicationStatus (PENDING, COMPLETED, FAILED or REPLICA). Below: setup with the console, CLI and Terraform, every requirement, cross-account and KMS, costs, Replication Time Control, and the full troubleshooting list.

The shop keeps every invoice and signed contract in one S3 bucket. After a scare (a deleted folder that took an afternoon to recover), Ethan set up replication to a second bucket in another Region. A week later Jake asked a sensible question: "Is last year's stuff in the backup too?" It was not. Neither were the files a contractor uploaded from their own account. And when Ethan tested a delete, the file vanished from the source but stayed in the copy, which turned out to be exactly what he wanted, though not what he had expected.

New to S3, versioning or delete markers? The cards below cover each in plain English, plus request costs and lifecycle rules.

What S3 replication is, and the two kinds

Replication is a set of rules you put on a source bucket that tells S3: whenever a new object (or a new version of one) lands here, copy it to this destination bucket. S3 does the copying in the background for you; your applications keep writing to the source as before, and you change nothing in your code. If S3 itself is new to you, our plain-English S3 guide comes first.

• Cross-Region Replication (CRR): the destination is in another Region. You use it for disaster recovery, for compliance rules that ask you to keep copies far apart, and for lower latency when your users are near the other Region.
• Same-Region Replication (SRR): the destination is in the same Region. You use it to collect logs from several of your buckets into one, to keep a copy in another of your accounts as protection against accidental or malicious deletes, or to separate your production and test data.

Either kind works across your accounts, can send to several destinations, and can replicate everything or only the objects you pick by prefix or tags. Replication is asynchronous: the source write succeeds first, the copy follows, usually within minutes.

What replication is not: a backup with history you can roll back to on its own. If something overwrites a file in your source, the overwrite is replicated too. What protects you is versioning on your destination (your old versions stay), the fact that version-specific deletes are never replicated (covered below), and, if you want the strongest protection, a destination in another of your accounts with Object Lock.

Jake: "So it's a photocopier on the filing cabinet, not a time machine?"

Ethan: "Right. It copies every new page. Old pages need a separate job, and the history comes from versioning."

The requirements checklist

Check every one of these; if any is false, your objects quietly stay unreplicated and nothing tells you:

1. Versioning is enabled on the source and every destination bucket. Suspended versioning on either side stops replication.
2. An IAM role that S3 can assume (trust policy for s3.amazonaws.com) with permission to read from the source and replicate into the destination.
3. A replication rule with status Enabled, the correct destination bucket ARN, and a filter (prefix and/or tags) that matches the objects you expect.
4. For a destination in another account: a bucket policy on the destination that allows the role to replicate, and an object ownership setting that gives the destination account ownership of replicas.
5. For SSE-KMS encrypted objects: the rule opts in to KMS-encrypted objects, names a destination KMS key, and the role can decrypt with the source key and encrypt with the destination key.
6. The source bucket owner can read the objects. Objects uploaded by another account without granting the bucket owner access are skipped.
7. No explicit Deny in either bucket policy, the role's permissions boundary, a service control policy or a resource control policy blocks the replication actions.

Items 1 to 3 cover most "nothing replicates at all" cases; items 4 to 7 cover "some objects replicate and others do not".

Setting up replication: console, CLI and Terraform

In the console:

1. Turn on versioning for both buckets: each bucket's Properties tab, Bucket Versioning, Enable.
2. Open the source bucket, choose Management, Replication rules, Create replication rule.
3. Name the rule, keep it Enabled, and choose the scope: all objects, or a prefix and/or tags.
4. Choose the destination: a bucket in this account, or another account's bucket by account ID and name.
5. For the IAM role, choose Create new role (the console writes the right permissions) or an existing role.
6. Optionally choose a destination storage class (for example Standard-IA for a backup copy), encryption options, Replication Time Control, replication metrics and delete marker replication.
7. Save. The console then asks whether to replicate existing objects; choosing yes creates a Batch Replication job for everything already in the bucket.

With the CLI, first the role. Trust policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": ["s3.amazonaws.com", "batchoperations.s3.amazonaws.com"]},
    "Action": "sts:AssumeRole"
  }]
}

Permissions policy (the batchoperations principal above lets the same role run Batch Replication):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetReplicationConfiguration", "s3:ListBucket"],
      "Resource": "arn:aws:s3:::shop-files"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObjectVersionForReplication", "s3:GetObjectVersionAcl", "s3:GetObjectVersionTagging"],
      "Resource": "arn:aws:s3:::shop-files/*"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:ReplicateObject", "s3:ReplicateDelete", "s3:ReplicateTags"],
      "Resource": "arn:aws:s3:::shop-files-dr/*"
    }
  ]
}

Then the replication configuration, saved as replication.json:

{
  "Role": "arn:aws:iam::111122223333:role/s3-replication-role",
  "Rules": [{
    "ID": "everything-to-dr",
    "Status": "Enabled",
    "Priority": 1,
    "Filter": {"Prefix": ""},
    "DeleteMarkerReplication": {"Status": "Enabled"},
    "Destination": {
      "Bucket": "arn:aws:s3:::shop-files-dr",
      "StorageClass": "STANDARD_IA"
    }
  }]
}

aws s3api put-bucket-versioning --bucket shop-files --versioning-configuration Status=Enabled
aws s3api put-bucket-versioning --bucket shop-files-dr --versioning-configuration Status=Enabled
aws s3api put-bucket-replication --bucket shop-files --replication-configuration file://replication.json
aws s3api get-bucket-replication --bucket shop-files

Terraform:

resource "aws_s3_bucket_replication_configuration" "dr" {
  depends_on = [aws_s3_bucket_versioning.source]   # versioning must exist first
  role       = aws_iam_role.replication.arn
  bucket     = aws_s3_bucket.source.id

  rule {
    id     = "everything-to-dr"
    status = "Enabled"
    filter {}
    delete_marker_replication { status = "Enabled" }
    destination {
      bucket        = aws_s3_bucket.dr.arn
      storage_class = "STANDARD_IA"
    }
  }
}

The depends_on matters: applying the replication configuration before versioning is enabled fails, and Terraform does not know about that ordering unless you tell it.

Existing objects: why they are not replicated, and Batch Replication

Your replication rule only applies to objects you create after the rule exists. Everything already in your bucket stays where it is, which is why Jake's "last year's stuff" was missing. The same goes for objects that already replicated to a different destination before you changed the rule, objects that are themselves replicas from another of your rules, and objects that previously failed.

S3 Batch Replication fills those gaps. It is a Batch Operations job that replicates objects matching your replication rules:

1. In the source bucket's Batch Operations (or answer "yes" when the console offers it after saving a rule), create a job with the operation Replicate.
2. Let S3 generate the manifest from the replication configuration, optionally filtered by creation date or by replication status (for example only FAILED or objects never replicated).
3. Choose the IAM role (its trust policy must include batchoperations.s3.amazonaws.com) and a bucket for the completion report, ideally not the source bucket.
4. Run the job and read the completion report: it lists each failed object with a reason.

Batch Replication costs Batch Operations fees (per job and per object), plus manifest generation, plus the normal replication costs. For a bucket with millions of small objects, the per-object fee is the part to estimate first.

Two cases Batch Replication cannot fix: objects in Glacier Flexible Retrieval, Glacier Deep Archive or Intelligent-Tiering's archive tiers must be restored and copied to another storage class first; and objects you deleted from the destination by version ID cannot be re-replicated, so copy them in place in the source (which creates new versions that replicate normally).

How deletes are replicated (and why some are not)

This is the part that surprises most people, so here is exactly what happens:

• When you delete an object normally (no version ID), S3 adds a delete marker in your source bucket. With the current rule format (rules that have a Filter), that marker is not replicated unless you enable delete marker replication on your rule. If you enable it, the object also looks deleted in your destination, but its versions are still there. You cannot use delete marker replication with tag-based rules.
• When you delete a specific version (a permanent delete), that is never replicated: your destination keeps that version. This is deliberate, so someone with access to your source cannot wipe your copy.
• Lifecycle expirations are not replicated either. If the source has a rule that expires objects after 90 days, the destination keeps them until its own lifecycle rule removes them. To keep both in step, add the same lifecycle rule to both buckets; our lifecycle troubleshooting guide covers the rule syntax.
• Cross-account: delete markers are not replicated by default either; enable delete marker replication if you want them.

That is why Ethan's test delete "worked" the way it did: the rule had no delete marker replication, so the file disappeared from the source and stayed visible in the copy. For a disaster-recovery copy, that is usually what you want. If you need the destination to mirror deletes, enable delete marker replication; the data is still recoverable from versions, as our guide to restoring deleted S3 objects explains.

Checking replication status

Every object your rules cover gets a replication status. To check one of your objects:

aws s3api head-object --bucket shop-files --key invoices/2026-10-001.pdf \
  --query "[ReplicationStatus,VersionId]" --output text

For a whole bucket, an S3 Inventory report can include each object's replication status, which you can then query with Athena instead of calling head-object millions of times. For live monitoring, enable replication metrics on the rule to get CloudWatch metrics for bytes pending, operations pending, replication latency and failed operations, and subscribe to replication failure events (s3:Replication:OperationFailedReplication) through S3 Event Notifications to SNS, SQS or Lambda. The failure event includes a reason code, which saves a lot of guessing. If those notifications do not arrive, our guide to S3 events not triggering Lambda covers the usual reasons.

Cross-account replication

The contractor's files that never reached the backup were a cross-account ownership problem; the destination in another account adds its own rules too. For a destination bucket owned by account 444455556666:

1. The destination bucket policy must allow the source account's replication role:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowReplicationFromShopAccount",
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111122223333:role/s3-replication-role"},
    "Action": ["s3:ReplicateObject", "s3:ReplicateDelete", "s3:ReplicateTags", "s3:ObjectOwnerOverrideToBucketOwner"],
    "Resource": "arn:aws:s3:::shop-files-dr/*"
  }, {
    "Sid": "AllowVersioningCheck",
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111122223333:role/s3-replication-role"},
    "Action": ["s3:GetBucketVersioning", "s3:PutBucketVersioning"],
    "Resource": "arn:aws:s3:::shop-files-dr"
  }]
}

2. Replica ownership. Without changes, replicas belong to the source account, and the destination account may not be able to read them. Either set the destination bucket's Object Ownership to Bucket owner enforced (the modern default, which makes the destination account own everything), or enable Change object ownership to the destination bucket owner in the rule, in which case the role also needs s3:ObjectOwnerOverrideToBucketOwner.

3. Objects uploaded by other accounts into the source. Replication only copies objects the source bucket owner can read. If a contractor's account uploads into your bucket with old-style ACLs and does not grant you access, those objects are skipped. Setting the source bucket to Bucket owner enforced fixes this for new uploads; existing ones need the uploader to grant access or re-upload.

A destination bucket in another account cannot be a Requester Pays bucket. Our cross-account Access Denied guide covers the bucket policy patterns in more detail.

Replicating KMS-encrypted objects

If your objects use SSE-S3 or SSE-C, they replicate without extra steps from you. If they use SSE-KMS (or DSSE-KMS), you need three things:

• Opt in on the rule: in the console, Replicate objects encrypted with AWS KMS, which sets SourceSelectionCriteria / SseKmsEncryptedObjects to Enabled in the configuration. Without it, KMS-encrypted objects are silently skipped.
• A destination key (ReplicaKmsKeyID), in the destination Region. For a destination in another account, use a customer managed key owned by the destination account, not the aws/s3 managed key, or the destination account cannot read the replicas.
• Key permissions: the role needs kms:Decrypt on the source key and kms:Encrypt plus kms:GenerateDataKey on the destination key, in its IAM policy and, for a cross-account destination key, in that key's policy too.

Two quieter traps: KMS key policies that only allow certain IP ranges or VPC endpoints make replication fail, because replication does not come from those places; and if a key policy checks the encryption context while S3 Bucket Keys are on, the context is the bucket ARN, not the object ARN. Our KMS.AccessDeniedException guide covers key policies for S3 in general.

How long replication takes, and Replication Time Control

Most of your objects replicate within 15 minutes. The time depends on your Region pair and the object size; very large objects can take several hours. Without extra options, replication is best effort: you get no promise for any single object.

S3 Replication Time Control (RTC) adds a promise: it is designed to replicate 99.99% of new objects within 15 minutes, backed by a service level agreement, and it turns on replication metrics and events for objects that miss the 15-minute threshold (OperationMissedThreshold and OperationReplicatedAfterThreshold). It costs an extra fee per GB replicated on top of normal replication costs, so most teams use it only for data with a recovery-point requirement, such as compliance copies or active-active applications.

Without RTC, you can still watch the ReplicationLatency metric if you enable replication metrics on the rule.

What S3 replication costs

You are not charged for the replication feature itself. You pay for what it does for you:

• Storage in your destination bucket, at your destination storage class's price. Choosing Standard-IA or Glacier Instant Retrieval for a backup copy reduces this (minimum storage durations and retrieval fees apply); our storage class guide helps you choose.
• PUT requests in the destination for each replicated object, at the destination storage class's request rate. For millions of small files, request charges can exceed storage; our guide to S3 request pricing shows when that happens.
• Inter-Region data transfer for CRR, per GB replicated. SRR has no data transfer charge.
• Replication Time Control per GB, if enabled, and CloudWatch charges for replication metrics.
• KMS requests for SSE-KMS objects (decrypt in the source, encrypt in the destination); S3 Bucket Keys reduce these a lot.
• Batch Replication job fees for existing objects.

A quick estimate: take the GB you add to the source per month, and add destination storage for that amount, plus its PUT requests, plus inter-Region transfer for CRR. For backup buckets that rarely change, the first month (when Batch Replication copies everything) is the expensive one.

S3 replication not working: the full troubleshooting list

When the reason is still unclear, a replication failure event or the Batch Replication completion report gives you the failure reason code for each object, which points straight at the permission or setting involved.

Two-way replication and replica modification sync

For active-active setups, where applications write to buckets in two Regions, you add a rule on each bucket pointing at the other. Objects replicated into a bucket are marked REPLICA and are not sent back, so there is no loop. To keep metadata changes (tags, ACLs, Object Lock settings) made on replicas in step too, enable replica modification sync on both rules. Multi-Region Access Points can sit in front of the pair, so applications use one endpoint and S3 routes each request to the nearest bucket.

For the shop, one-way CRR to a backup bucket in another account, with versioning, no delete marker replication and a lifecycle rule moving old versions to cheaper storage after 90 days, gives strong protection at a modest cost.

Frequently asked questions

A Batch Replication job copied last year's files over a quiet weekend; the contractor now uploads into a bucket set to Bucket owner enforced; and Ethan left delete marker replication off on purpose, so the backup keeps anything deleted in the source. Jake asked one last question: "How do we know it's still working next month?" The answer was a CloudWatch alarm on failed replication operations, which has stayed silent since.

Revision note. Written October 19, 2026. Replication does exactly what its rules say; most surprises are rules that say less than you assumed.