S3 replication: configure copies and verify recovery

S3 replication copies eligible objects asynchronously between Amazon S3 buckets. Use Same-Region Replication (SRR) for copies within one AWS Region, Cross-Region Replication (CRR) for another Region, and Batch Replication for existing objects. A saved rule is only the start: you still need to check which objects arrived and whether your application can recover from them.

This guide is for teams configuring replication for S3 general purpose buckets. It covers the choice of replication method, permissions, a small validation workflow, deletion behavior, and monitoring. The command examples inspect configuration and object metadata; they do not create rules or delete data.

Choose the replication method around a specific need

AWS distinguishes live and on-demand replication. Live replication copies eligible new writes after a rule is in place. It can operate within one account or across accounts.

• Same-Region Replication: consider it when a second team or account needs a copy in the same Region. Account separation and geographic separation solve different problems.
• Cross-Region Replication: consider it when the recovery location or a consuming application is in another Region. Decide how the application will select and access that copy.
• Batch Replication: use it to address a defined set of existing objects, including eligible objects whose replication previously failed. Review the job scope before starting it.

Write down the reader or recovery process that needs the destination. “A second bucket” is too vague to test. A more useful requirement is: the recovery team can read a completed daily export from the destination account, using its recovery role, without relying on the original application's credentials. For broader service selection, see our Amazon cloud storage guide.

Check versioning, ownership, and permissions first

Both buckets must have versioning enabled. If the source uses Object Lock, the destination must also support it through an enabled Object Lock configuration. AWS lists these and other replication prerequisites. Review the effects on retained versions and cost before enabling features on an existing bucket.

Use an authorized AWS CLI profile. These read-only checks show each bucket's versioning state. Replace the bucket names, profile, and Regions; a cross-account check may require a different profile for the destination.

aws s3api get-bucket-versioning --bucket amzn-s3-demo-source --profile storage-review --region eu-west-1
aws s3api get-bucket-versioning --bucket amzn-s3-demo-destination --profile storage-review --region eu-central-1

Look for Status: Enabled in each response. A blank status or Suspended is not equivalent. The get-bucket-versioning reference describes the response. An access error means the check is incomplete, not that versioning is disabled.

The replication IAM role lets Amazon S3 read the relevant source versions and write replicas. Your operator permissions and the service role's permissions are separate. Scope access to the intended resources, and check the destination bucket policy and replica ownership when accounts differ. Follow the live replication permissions guide rather than granting broad access to make an error disappear.

Handle KMS encryption explicitly

SSE-KMS and DSSE-KMS objects need an explicit replication opt-in, a suitable destination KMS key, and the required key permissions. The destination key must be in the destination Region. AWS warns that accepting a replication configuration does not validate the key's usability. Check the encrypted-object replication requirements, then test the encryption mode your application actually writes.

Start with a small replication rule

For an initial exercise, use approved test buckets and a dedicated prefix such as replication-test/. Keep unrelated data out of the exercise. Record the source and destination account IDs, Regions, bucket names, rule ID, and intended storage class so another person can review the setup.

1. In the source bucket's Management tab, create a replication rule with a clear name.
2. Limit the rule to the test prefix. Choose the destination bucket and the reviewed replication role.
3. Decide the destination storage class, encryption settings, replica ownership, and delete marker behavior deliberately.
4. Enable replication metrics if you need an ongoing view of this rule. Review the additional charges.
5. Save the rule, then verify its configuration before uploading a new, non-sensitive test object.

The AWS setup overview explains prefix and object-tag filters. If you use tags, test the actual upload path and its tags rather than assuming that every writer attaches them correctly. Keep the first exercise simple enough that you can account for every expected object.

Read back the source bucket's configuration:

aws s3api get-bucket-replication --bucket amzn-s3-demo-source --profile storage-review --region eu-west-1 --output json

Check the enabled rule, filter, role, and destination ARN. The configuration API can briefly return an older view while a change propagates. A successful read confirms configuration visibility; it does not prove that replication has completed.

Plan existing objects as a separate job

Enabling live replication does not automatically backfill old data. S3 Batch Replication uses a Batch Operations job and a manifest to select existing objects. It requires a source replication configuration and appropriate job permissions. Request a completion report and inspect its failures; a finished job is not proof that every selected object succeeded.

Separate the initial backlog from new incoming writes in your acceptance record. For example, record an expected list for yesterday's exports, then use today's test export to check live replication. This makes it easier to identify an incomplete backfill instead of mistaking a few new replicas for complete historical coverage.

Review storage-class eligibility and interactions with lifecycle rules before a large job. Do not pause production retention or expiry rules casually. Agree on the handling of old versions, deleted objects, and any temporary policy change with the owner of the dataset.

Decide what deletions should do

With current replication rules, user-created delete markers are not copied by default. Enabling delete marker replication can make the object appear deleted at the destination too. Tag-based rules do not support this option, and lifecycle-created delete markers are not replicated. See AWS's delete marker behavior before selecting it.

Deleting a specific source version does not replicate that permanent deletion. Bucket configurations, such as lifecycle rules, are also not copied as part of object replication. AWS's replication exclusions explain these boundaries. Destination retention and access therefore need their own review.

For the first test, verify copies before testing deletion behavior. If a later test includes deletion, use disposable objects in the agreed test area and write down the expected result on both sides. Avoid using an object someone still needs to establish whether a checkbox works.

Verify the exact object version

Record the version ID from the test upload or the source object's version list. Replace SOURCE_VERSION_ID below with that value:

aws s3api head-object --bucket amzn-s3-demo-source --key replication-test/sample.txt --version-id SOURCE_VERSION_ID --profile storage-review --region eu-west-1 --query "{VersionId:VersionId,ReplicationStatus:ReplicationStatus,Bytes:ContentLength}" --output json

For ordinary one-way replication, source status is PENDING, COMPLETED, or FAILED; a destination replica reports REPLICA. Check the status reference for multi-destination rules and replica modification sync. A missing status is not a success result. Check whether you selected an eligible version and whether the rule covers it.

Find the expected replica version at the destination and substitute its ID in this check:

aws s3api head-object --bucket amzn-s3-demo-destination --key replication-test/sample.txt --version-id REPLICA_VERSION_ID --profile storage-review --region eu-central-1 --query "{VersionId:VersionId,ReplicationStatus:ReplicationStatus,Bytes:ContentLength}" --output json

HeadObject returns metadata without downloading the body. The byte count is useful for spotting mistakes, but matching sizes do not prove matching content. Read a representative replica through the intended recovery identity, compare it with the retained source sample, and test whether the consuming application accepts it.

Keep the expected object list alongside these results. One successful file does not establish that an entire prefix, all historical versions, or a database export is recoverable. Our recoverability testing guide covers the broader restore exercise.

Monitor delays and failures after the test

Replication metrics expose pending bytes, pending operations, latency, and failed operations. They can be enabled without Replication Time Control. Use failure events and job reports to investigate individual objects; an absence of alerts is only meaningful when monitoring is configured and delivering data.

S3 Replication Time Control adds a 15-minute threshold, related notifications, and SLA terms. It is not a promise that every object or operation completes within that interval. It does not turn asynchronous replication into a zero-data-loss application design. Batch Replication needs its own job tracking.

Assign an owner to a growing backlog. Check recent changes to the role, destination policy, versioning, and encryption keys before repeatedly recreating rules. For objects already marked failed, resolve the cause and plan a controlled retry, such as an appropriately scoped Batch Replication job. Record the result instead of treating a configuration repair as proof that earlier failures recovered.

Budget for the copy and the recovery process

Allow for destination storage, retained versions, replication requests, cross-Region data transfer where applicable, and optional Batch, RTC, monitoring, and KMS charges. Use the actual Regions and storage classes on the S3 pricing page. The data volume alone does not determine the bill.

Before relying on replication, record the maximum acceptable data lag and the steps to switch the application to the destination. Include credentials, encryption-key access, dependencies, and a return plan. A copy that exists but cannot be read by the recovery team does not meet that requirement.

Replication can contribute to a cloud backup plan, but independent retention and a tested restore still need explicit decisions. For Hivenet or another S3-compatible provider, verify the service's own replication capabilities. S3 API compatibility alone does not establish support for AWS replication features.