Why Is My S3 Replication Not Working?
A Complete Troubleshooting Guide

You've carefully configured Amazon S3 Replication, whether for Cross-Region Replication (CRR) or Same-Region Replication (SRR). You expect your data to be durable and highly available, but you've hit a wall: objects uploaded to your source bucket are not appearing in the destination. When S3 replication is not working, it can be frustrating, but the cause is almost always a misconfiguration in permissions or encryption.

This guide will walk you through the most common reasons for S3 replication failure and provide a step-by-step checklist to troubleshoot and fix them.

First: Are You Replicating NEW or EXISTING Objects?

This is the most common "problem" that isn't actually a problem. By default, S3 replication rules *only* apply to new objects uploaded *after* the rule is created and enabled. Replication does not retroactively copy objects that already exist in the bucket.

The Fix: If you need to replicate your existing data, you must use S3 Batch Replication. This is a separate, one-time operation you can run to sync your source and destination buckets before letting the live replication rule take over for new objects.

Your S3 Replication Troubleshooting Checklist

If your *new* objects are failing to replicate, it's time to check your configuration. Test by uploading a new object after each step to see if the issue is resolved.

1. Check the IAM Role and Trust Policy

S3 replication uses an IAM role for S3 replication to act on your behalf. This role must have the correct permissions to read from the source and write to the destination.

Your IAM role's permissions policy must include (at a minimum):

• s3:ListBucket, s3:GetReplicationConfiguration on the source bucket.
• s3:GetObjectVersion, s3:GetObjectVersionAcl, s3:GetObjectVersionTagging on objects in the source bucket (SourceBucket/*).
• s3:ReplicateObject, s3:ReplicateTags on objects in the destination bucket (DestinationBucket/*).

Crucial Check: The role's Trust Policy is just as important. It *must* allow the S3 service principal (s3.amazonaws.com) to assume the role.

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

2. Fix the Destination Bucket Policy (for Cross-Account Replication)

This is the most common point of failure for S3 cross-account replication. The destination bucket (in Account B) must have a S3 bucket policy for replication that explicitly allows the source account's (Account A) IAM role to replicate objects.

Your *destination* bucket policy should look like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReplicationPermissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::SOURCE-ACCOUNT-ID:role/YOUR-REPLICATION-ROLE-NAME"
      },
      "Action": [
        "s3:ReplicateObject",
        "s3:ReplicateTags",
        "s3:ObjectOwnerOverrideToBucketOwner"
      ],
      "Resource": "arn:aws:s3:::YOUR-DESTINATION-BUCKET/*"
    },
    {
      "Sid": "AllowBucketPermissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::SOURCE-ACCOUNT-ID:role/YOUR-REPLICATION-ROLE-NAME"
      },
      "Action": [
        "s3:GetBucketVersioning",
        "s3:PutBucketVersioning"
      ],
      "Resource": "arn:aws:s3:::YOUR-DESTINATION-BUCKET"
    }
  ]
}

Note: The s3:ObjectOwnerOverrideToBucketOwner action is required if you are changing object ownership. See Step 4.

3. Troubleshoot S3 Replication with KMS Encryption

If your objects are encrypted with SSE-KMS (S3 replication KMS), permissions get more complex. Failure is almost guaranteed if this is misconfigured.

• IAM Role Permissions: The IAM role needs kms:Decrypt permission for the *source* KMS key and kms:Encrypt permission for the *destination* KMS key.
• Cross-Account KMS: This is the hardest part.
  • You cannot use the default AWS-managed key (aws/s3) for cross-account replication. You must use a customer-managed key (CMK).
  • The destination KMS key's policy (in Account B) must give the *source account's IAM role* (from Account A) permission to use it (kms:GenerateDataKey, kms:Encrypt).

4. Check S3 Object Ownership Settings

Another common trap is S3 object ownership. By default, the source account still "owns" the replicated objects, even when they are in the destination bucket. If the destination bucket has its "Object Ownership" set to "Bucket owner enforced," replication will fail unless you override the ownership.

The Fix: In your replication rule, you must enable "Change object ownership to the destination bucket owner." This also requires an additional permission: s3:ObjectOwnerOverrideToBucketOwner, which must be in *both* the IAM role and the destination bucket policy (as shown in the policy in Step 2).

5. Check Other Common Issues

• Bucket Versioning: S3 replication requires versioning to be enabled on *both* the source and destination buckets. This is a non-negotiable prerequisite.
• Replication Rule Filters: Check your rule's filter. If you are filtering by prefix (e.g., images/) or tags, ensure the new objects you are uploading actually match the filter. Remember, filters are case-sensitive.
• Explicit Deny Statements: A single "Effect": "Deny" statement in any policy (IAM role, bucket policy, KMS key policy, or an AWS Organizations SCP) will override all Allow statements. Check for any denies that might be blocking the replication role.
• Delete Marker Replication: If you want delete markers to replicate (so that deleting an object in the source also deletes it in the destination), you must explicitly enable this in the rule *and* add s3:ReplicateDelete to the IAM role's permissions.

Conclusion: How to Find the Exact Failure

When S3 replication is not working, the root cause is almost always a permissions mismatch. The fastest way to get a definitive answer is to enable S3 event notifications for s3:Replication:OperationFailedReplication. These events will send a detailed JSON message (often to SQS or Lambda) that explicitly states *why* the replication failed (e.g., "Access Denied," "KMS.Disabled," etc.), pointing you directly to the policy you need to fix.