Skip to content

AWS Updated 2026-10-07

S3 replication not replicating: the checklist

When S3 replication is on but objects never reach the destination bucket, you can find the cause by checking one object's replication status. Then work through the usual reasons, from objects older than the rule to missing encryption-key or role permissions.

When you turn on Amazon S3 replication and objects never show up in the destination bucket, or show a FAILED status, this checklist helps you find out why. In most cases replication is doing exactly what the rule tells it to, and the rule covers less than you expected. Four causes explain nearly every case. Replication only copies objects written after the rule existed, so older objects need a separate backfill job called S3 Batch Replication. Objects encrypted with SSE-KMS (server-side encryption using keys held in AWS Key Management Service) are skipped unless the rule opts in and the replication role can use both keys. The rule’s filter, which limits it to object names with a given prefix or tag, may not match the objects you are checking. And the IAM role that S3 uses to copy objects (an AWS identity with its own set of permissions) may lack a permission on the source or destination side. Start with one missing object, because its ReplicationStatus field tells you which of these to look at.

What’s happening

Replication is asynchronous and rule-driven: versioning must be enabled on both source and destination buckets, a replication configuration on the source names a destination and an IAM role, and S3 assumes that role to read versions from the source and write them to the destination. Most objects replicate within minutes; there is no hard SLA unless you enable Replication Time Control (RTC), which targets 15 minutes and adds per-GB and monitoring cost.

The skip list is where the surprises live. Replication does not touch: objects that existed before the rule (by design), objects encrypted with SSE-C (never replicable), SSE-KMS objects unless the rule opts in and the role has kms:Decrypt on the source key and kms:Encrypt/kms:GenerateDataKey on the destination key, objects the source bucket owner does not own (cross-account uploads under legacy ACL ownership), objects that are themselves replicas from another rule (no chaining), and — depending on rule settings — delete markers. Deletes of specific versions are never replicated at all, deliberately, so a compromised source cannot purge your replica.

Each source object carries a ReplicationStatus: PENDING, COMPLETED, FAILED, or absent entirely. Absent is the most diagnostic value — it means no rule matched this object in the first place.

What to check first

  • Is versioning Enabled on both buckets — not suspended, on either side?
  • Were the missing objects written before the rule existed? Compare object LastModified to the rule’s creation time.
  • Does the rule’s filter (prefix or tags) actually match the keys you expect to replicate?
  • Are the objects SSE-KMS encrypted, and does the rule show KMS replication enabled?
  • Cross-account destination: does the destination bucket policy allow the replication role, and is ownership translation configured?

How to verify

Start with one concrete missing object — its status names the failure class:

aws s3api head-object --bucket source-bucket --key data/file.parquet \
  --query '[ReplicationStatus, ServerSideEncryption, SSEKMSKeyId, LastModified]'

FAILED means permissions or KMS on the destination path; PENDING for hours means backlog or throttling; no status field means the rule never matched. Then read the configuration critically:

aws s3api get-bucket-replication --bucket source-bucket
aws s3api get-bucket-versioning --bucket source-bucket
aws s3api get-bucket-versioning --bucket dest-bucket

Check what the role can actually do — the trust policy must allow s3.amazonaws.com, and the permission policy needs s3:GetObjectVersionForReplication, s3:GetObjectVersionAcl, s3:GetObjectVersionTagging on the source, and s3:ReplicateObject, s3:ReplicateDelete, s3:ReplicateTags on the destination:

aws iam get-role --role-name s3-replication-role --query 'Role.AssumeRolePolicyDocument'
aws iam list-attached-role-policies --role-name s3-replication-role

CloudWatch replication metrics exist per rule when RTC or replication metrics are enabled: ReplicationLatency, BytesPendingReplication, OperationsPendingReplication under the AWS/S3 namespace. Console: S3 > Buckets > source-bucket > Management > Replication rules and Metrics.

The checklist

  1. Versioning enabled on both sides. Suspended counts as broken for replication. Fix it and note that only objects written after re-enabling will replicate.
  2. Rule scope matches the keys. A prefix filter of data/ does not match Data/ or prod-data/. Widen the filter or add rules — and remember multiple rules need distinct priorities.
  3. Pre-existing objects need Batch Replication. From the replication rule screen (or aws s3control create-job), run an S3 Batch Replication job to backfill everything written before the rule. This is the answer to “I enabled replication and my 10 TB is not copying.”
  4. KMS handled explicitly. In the rule, enable replication of KMS-encrypted objects and specify the destination KMS key; grant the role kms:Decrypt on the source key policy and kms:GenerateDataKey/kms:Encrypt on the destination key policy. Cross-account, both key policies must name the role explicitly.
  5. Cross-account destination policy and ownership. The destination bucket policy must allow the role s3:ReplicateObject/s3:ReplicateDelete on dest-bucket/*, and set Owner override to destination so replicas belong to the destination account — otherwise the destination owner may not be able to read its own replicas.
  6. Delete-marker replication set intentionally. It is a per-rule toggle. If your DR story expects deletes to propagate, turn it on; if your ransomware story expects them not to, leave it off — but decide, do not discover.
  7. FAILED statuses after fixes: re-drive with Batch Replication. Fixing the role does not retroactively replicate objects marked FAILED; a Batch Replication job scoped to the affected prefix re-processes them.

When this is the wrong move

Replication is not a backup. It faithfully copies overwrites, and (if enabled) propagates delete markers — corruption replicates as efficiently as data. If the requirement is point-in-time recovery or ransomware resilience, you want versioning plus AWS Backup or vault-style copies with separate credentials, not just a live replica. And for one-time bucket copies, aws s3 sync or S3 Batch Operations Copy is simpler than standing up replication.

Common mistakes

  • Enabling replication, checking five minutes later that old objects have not copied, and concluding it is broken — pre-existing data was never in scope.
  • Testing with the console uploader under default bucket encryption (SSE-KMS) while the rule has KMS replication off — test objects skip silently.
  • Trusting aws s3 ls counts to compare buckets; use inventory reports or at least list-objects-v2 with counts per prefix, because replicas of delete markers and versioned stacks make eyeball comparison lie.
  • Deleting a version on the source and expecting the replica version to disappear — version deletes intentionally do not replicate.

Prevention

  • Enable replication metrics (or RTC where the 15-minute target justifies the cost) and alarm on OperationsPendingReplication growing without draining.
  • Schedule a weekly S3 Inventory report on both buckets and diff object counts and checksums per prefix — the only comparison that scales.
  • Keep the replication role’s policy in IaC beside the bucket definitions, so a key rotation or bucket rename updates both sides together.
  • Re-run a scoped Batch Replication job after any incident that produced FAILED statuses, and record it in the incident notes. The replication requirements list at https://docs.aws.amazon.com/AmazonS3/ is worth re-reading whenever a rule changes.

Replication debugging is a closed checklist, not an investigation — one object’s ReplicationStatus plus the seven items above locates the break every time. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.