Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

To configure Amazon S3 cross-Region replication (CRR) with Terraform, enable versioning on both buckets, give S3 an IAM role it can assume, and define one aws_s3_bucket_replication_configuration resource for the source bucket. The rule handles eligible objects created after it is configured; it does not automatically backfill existing objects. Use S3 Batch Replication for historical objects.

How the Terraform setup fits together

A replication configuration belongs to the source bucket and points to the destination bucket. S3 assumes the IAM role named in the configuration to replicate objects. Both buckets must have versioning enabled before replication is configured.

Manage replication with the standalone Terraform resource aws_s3_bucket_replication_configuration, rather than treating replication as part of the bucket resource. A source bucket supports only one replication configuration, so put all rules for that bucket in a single resource; multiple configuration resources for the same bucket can cause Terraform to show a perpetual difference. See the AWS provider 6.0.0 replication configuration documentation.

Configure versioning before replication

Declare versioning resources for both buckets and ensure Terraform applies them before the replication configuration. The following is a structural example, not a complete deployment: it assumes the source and destination bucket resources and an S3-assumable IAM role already exist. The role’s trust policy and permissions must be configured to allow the required S3 replication actions; this example does not supply a least-privilege policy.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
resource "aws_s3_bucket_versioning" "source" {
  bucket = aws_s3_bucket.source.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_versioning" "destination" {
  bucket = aws_s3_bucket.destination.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_replication_configuration" "source" {
  bucket = aws_s3_bucket.source.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-all"
    status = "Enabled"

    destination {
      bucket = aws_s3_bucket.destination.arn
    }
  }

  depends_on = [
    aws_s3_bucket_versioning.source,
    aws_s3_bucket_versioning.destination,
  ]
}

Terraform references already create dependencies where resources are referenced directly. The explicit depends_on makes the intended ordering clear: replication configuration follows successful versioning setup on both buckets. The provider’s versioned documentation describes this standalone resource pattern; check its schema against the AWS provider version pinned by your configuration. See the AWS provider 5.42.0 replication configuration documentation.

Choose which objects the rule covers

The example uses a rule without a filter, so it is intended to replicate all eligible objects under the source bucket. If you need to replicate only a subset, define a filter in the rule and verify the provider schema for your pinned version. A tag-based filter also affects deletion behavior: S3 does not support delete-marker replication with tag-based rules.

CRR is live replication, not an automatic copy of the bucket’s existing contents. AWS states that, by default, replication covers objects created after the configuration is added. To replicate existing objects, or certain objects that were previously replicated elsewhere, use S3 Batch Replication. See AWS’s replication coverage guide.

Understand what deletion means

  • A simple delete request on a versioned source bucket creates a delete marker. With filter-based rules, S3 does not replicate delete markers by default. You can enable delete-marker replication for rules that are not tag-based.
  • Lifecycle-generated delete markers are not replicated, even when delete-marker replication is enabled.
  • Deleting a specific object version in the source does not delete the corresponding version in the destination.

These behaviors mean replication is not a full mirror of source deletion operations. If you need delete markers copied, configure the rule option deliberately and account for the restriction on tag-based rules. See AWS’s delete-marker replication guide.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Plan for configuration and storage that replication does not copy

Replication covers eligible object data and associated metadata, not bucket-level settings. It does not copy lifecycle rules or notification configuration, so configure destination lifecycle and notifications independently.

Objects in certain archival storage tiers are excluded from replication until restored and copied to another storage class. AWS lists unencrypted, SSE-S3, SSE-C, and SSE-KMS encrypted objects among default replication coverage, but SSE-KMS needs additional permissions and key-policy review. Do not assume an ordinary role policy is sufficient for encrypted replication; consult AWS’s current permissions guidance before implementing it. Cross-account replication likewise requires destination permissions beyond the basic same-account structure shown above.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Apply and verify the configuration

  1. Pin the AWS provider version in your Terraform configuration and confirm the replication resource’s arguments against that version’s provider documentation.
  2. Run terraform plan and check that it enables versioning on both buckets before creating the source replication configuration.
  3. Apply the plan with terraform apply. A successful apply configures the rule; it does not mean existing objects have been copied.
  4. Check replication status and object behavior in S3 for new eligible objects. If historical objects need replication, plan a separate S3 Batch Replication job.

The configuration shown here is a basic same-account pattern. Exact cross-account permissions, least-privilege IAM policies, and SSE-KMS key permissions depend on the deployment and are not specified by the cited resource examples; verify them in AWS’s current guidance before using those variants.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.