This chapter covers Amazon S3 Replication, including Cross-Region Replication (CRR) and Same-Region Replication (SRR), which are critical for data durability, compliance, and low-latency access. For the SOA-C02 exam, questions on S3 Replication appear in the Reliability domain (Objective 2.2) and can constitute roughly 5-8% of the exam. You must understand the differences between CRR and SRR, replication rules, IAM roles, and how to troubleshoot common misconfigurations.
Jump to a section
Imagine a library system with a main branch and a branch in another city. The main branch has a special service that automatically copies any new book added to its shelves to the other branch. This service can be set to copy only books in the 'Fiction' section (prefix filter) or all books. When a book is added, the service creates an exact duplicate for the other branch, including any sticky notes (metadata) and tags (storage class). If the book is later removed from the main branch, the copy at the other branch is also removed (delete marker replication). However, if the main branch's copy is overwritten with a newer edition, the service updates the other branch if configured with 'Replica Modification Sync'. The service uses a special librarian (IAM role) that has permission to read from the main branch and write to the other branch. The replication process is asynchronous; the copy appears at the other branch within 15 minutes typically (15-minute SLA). The library can also replicate to multiple branches (SRR) or across different library systems (CRR). Importantly, the service does not replicate existing books by default; you must enable a batch operation to backfill. Also, if the main branch is in a different city (region), the service uses an encrypted connection (SSL/TLS) and can replicate across AWS accounts using a bucket policy on the destination. The library can also replicate objects encrypted with a specific key (SSE-KMS) by configuring the appropriate KMS key permissions.
What is S3 Replication?
Amazon S3 Replication is a feature that automatically and asynchronously copies objects from a source bucket to one or more destination buckets. The destination buckets can be in the same AWS Region (Same-Region Replication, SRR) or in different AWS Regions (Cross-Region Replication, CRR). Replication is used to meet data residency requirements, improve data durability, reduce latency for geographically distributed users, and provide a backup in case of accidental deletion or regional failure.
How It Works Internally
When you enable replication on a source bucket, you define a replication rule that specifies:
The source bucket (the bucket where the rule is applied).
The destination bucket(s) (one or more).
An IAM role that grants S3 permission to read objects from the source and write to the destination.
Optional filters (prefix or tags) to replicate only a subset of objects.
Replication options: replication of delete markers, replica modification sync, and encryption settings.
Once the rule is active, S3 monitors the source bucket for object uploads and other events that trigger replication. When an object is uploaded (PUT), S3 asynchronously copies it to the destination bucket. The replication is performed internally by the S3 service; you do not need to manage any infrastructure. The time to replicate depends on object size and network conditions, but S3 provides a 15-minute Service Level Agreement (SLA) for most objects. For large objects (multi-part uploads), replication can take longer.
Key Components and Defaults
Replication Rule: Defined on the source bucket. You can have up to 1,000 replication rules per bucket.
IAM Role: Must have permissions for s3:GetReplicationConfiguration and s3:ListBucket on the source, and s3:PutObject, s3:PutObjectAcl, s3:PutObjectTagging, etc., on the destination. The role must be trusted by the S3 service.
Destination Bucket: Can be in the same or different AWS account. If cross-account, you must attach a bucket policy on the destination bucket that grants the source account's IAM role permission to replicate.
Replication Time Control (RTC): An optional feature that provides a predictable 15-minute replication SLA for most objects. Without RTC, replication is best-effort.
Delete Marker Replication: By default, delete markers are not replicated. You can enable it in the rule.
Replica Modification Sync: When enabled, metadata changes (like tags or ACLs) on the source object are replicated to the replica. This is only available for SRR.
Encryption: Replication supports SSE-S3, SSE-KMS, and SSE-C. For SSE-KMS, you must specify the KMS key to use for encrypting objects at the destination. You can also choose to replicate objects encrypted with a different KMS key.
Existing Objects: By default, only objects uploaded after the rule is enabled are replicated. To replicate existing objects, you must use S3 Batch Operations with a replication task.
Configuration and Verification
To configure replication using the AWS CLI, you first create an IAM role with the necessary permissions. Then you apply a replication configuration to the source bucket. Example JSON for a replication rule:
{
"Role": "arn:aws:iam::123456789012:role/s3-replication-role",
"Rules": [
{
"Status": "Enabled",
"Priority": 1,
"Filter": {
"Prefix": "logs/"
},
"Destination": {
"Bucket": "arn:aws:s3:::destination-bucket",
"StorageClass": "STANDARD_IA",
"EncryptionConfiguration": {
"ReplicaKmsKeyID": "arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}
},
"DeleteMarkerReplication": { "Status": "Enabled" },
"SourceSelectionCriteria": {
"ReplicaModifications": {
"Status": "Enabled"
}
}
}
]
}To apply this configuration, use:
aws s3api put-bucket-replication --bucket source-bucket --replication-configuration file://replication.jsonTo verify replication status, you can check the ReplicationStatus metadata on objects using:
aws s3api head-object --bucket source-bucket --key logs/2023/01/01/app.logThe response includes ReplicationStatus which can be COMPLETED, PENDING, FAILED, or REPLICA.
Interaction with Related Technologies
S3 Versioning: Replication requires versioning to be enabled on both source and destination buckets. Without versioning, replication fails.
S3 Lifecycle Policies: Lifecycle rules on the destination bucket can manage the lifecycle of replicated objects independently from the source.
S3 Object Lock: If object lock is enabled on the source, replication will copy the retention settings. The destination must also have object lock enabled.
S3 Batch Operations: Used to replicate existing objects or to perform bulk actions on objects that failed replication.
AWS CloudTrail: Can log replication events, including failures.
Amazon CloudWatch: Metrics such as ReplicationLatency and BytesPendingReplication are available.
CRR vs SRR: When to Use Which
CRR: Use when you need to store data in a different geographic region for disaster recovery, compliance (data must remain in a specific country), or to reduce latency for users in another region. CRR incurs inter-region data transfer costs.
SRR: Use when you need to aggregate logs from multiple buckets into a single bucket within the same region, or to create a live copy of data for processing without affecting the source. SRR does not incur data transfer costs (only request costs).
Replication of Delete Markers
By default, delete markers are not replicated. If you enable delete marker replication, when a delete marker is added to the source (i.e., an object is deleted), the delete marker is replicated to the destination. This means the object appears deleted in both buckets. However, if you delete an object version (permanent deletion), it is not replicated because version deletion is not supported by replication.
Replication of Metadata and Tags
Replication copies the object’s metadata (system-defined and user-defined) and tags by default. With replica modification sync (SRR only), any subsequent changes to metadata or tags on the source are also replicated.
Failure Handling
If replication fails (e.g., due to permissions, network issues, or bucket configuration), S3 will retry for up to 15 days. After that, the object is marked as FAILED in the replication metrics. You can use S3 Batch Operations to retry replication for failed objects. Common reasons for failure include incorrect IAM role permissions, missing bucket policy on the destination (cross-account), or the destination bucket being in a different region without proper VPC endpoints (if using VPC endpoints).
Pricing
CRR: You pay for inter-region data transfer out (from source region) + PUT requests to destination.
SRR: You pay only for PUT requests to destination (no data transfer).
RTC: Additional hourly charge per GB of data replicated.
Exam-Relevant Values
Maximum number of replication rules per bucket: 1,000
Replication SLA (without RTC): best effort; with RTC: 15 minutes for 99.99% of objects
Replication requires versioning on both buckets.
Default replication status on new objects: PENDING (until replicated)
Delete marker replication is disabled by default.
Replica modification sync is only available for SRR.
You cannot replicate objects encrypted with SSE-C unless you provide the encryption key in the replication configuration (not supported directly).
Cross-account replication requires a bucket policy on the destination bucket that grants the source account's IAM role permission to s3:ReplicateObject, s3:ReplicateDelete, etc.
Step-by-Step: Setting Up CRR
Enable versioning on source and destination buckets.
Create an IAM role with trust policy for S3 and permissions to read from source and write to destination.
(If cross-account) Attach a bucket policy on the destination bucket allowing the IAM role to replicate.
Create a replication rule on the source bucket via AWS Console, CLI, or SDK.
Verify replication by uploading an object and checking its ReplicationStatus.
Common Exam Traps
Trap: Replication replicates existing objects. Reality: Only objects uploaded after the rule is enabled are replicated. Use S3 Batch Operations for existing objects.
Trap: Delete marker replication is enabled by default. Reality: It is disabled by default; you must explicitly enable it.
Trap: Replica modification sync works with CRR. Reality: It only works with SRR.
Trap: You can replicate objects to a bucket in a different AWS account without any additional configuration. Reality: You need a bucket policy on the destination bucket granting replication permissions.
Trap: Replication works without versioning. Reality: Versioning must be enabled on both buckets.
Trap: You can replicate objects encrypted with SSE-C. Reality: SSE-C objects cannot be replicated; you must decrypt and re-encrypt using a different method.
Summary
S3 Replication is a powerful feature for data durability, compliance, and performance. Understanding the differences between CRR and SRR, the prerequisites (versioning, IAM roles), and the configuration options (delete markers, replica modification sync) is essential for the SOA-C02 exam. Remember that replication is asynchronous and best-effort unless RTC is enabled. Always verify your setup by checking replication status on objects.
Enable Versioning on Buckets
Replication requires versioning to be enabled on both the source and destination buckets. Without versioning, the replication configuration cannot be applied. Versioning allows S3 to track object versions, which is necessary for replication to handle overwrites and deletions correctly. You can enable versioning via the AWS Console (select bucket, Properties, Versioning) or CLI: `aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled`.
Create IAM Replication Role
Create an IAM role that S3 can assume to read objects from the source bucket and write to the destination bucket. The role's trust policy must allow the S3 service to assume it. The permissions policy must include actions like `s3:GetObject`, `s3:ListBucket` on the source, and `s3:PutObject`, `s3:PutObjectAcl`, `s3:PutObjectTagging` on the destination. For cross-account replication, the destination account must also attach a bucket policy allowing the role to replicate.
Configure Replication Rule on Source
On the source bucket, create a replication rule. Specify the destination bucket ARN, IAM role ARN, and optional filters (prefix or tags). Choose whether to replicate delete markers, enable replica modification sync (SRR only), and set encryption options (e.g., KMS key for destination). You can create up to 1,000 rules per bucket. Each rule has a priority; if filters overlap, the higher priority rule applies.
Attach Bucket Policy to Destination (Cross-Account)
If the destination bucket is in a different AWS account, you must attach a bucket policy that grants the source account's IAM role permission to replicate objects. The policy should allow actions like `s3:ReplicateObject`, `s3:ReplicateDelete`, and `s3:ReplicateTags`. Example: `{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::source-account-id:role/s3-replication-role" }, "Action": [ "s3:ReplicateObject", "s3:ReplicateDelete" ], "Resource": "arn:aws:s3:::destination-bucket/*" }`.
Upload Object and Verify Replication
Upload an object to the source bucket. Check its replication status using `aws s3api head-object --bucket source-bucket --key myobject`. The status should change from `PENDING` to `COMPLETED` after replication succeeds. You can also check the destination bucket to confirm the object exists. If replication fails, check CloudWatch metrics like `ReplicationLatency` and `BytesPendingReplication`, and review CloudTrail logs for errors.
Enterprise Scenario 1: Disaster Recovery with CRR
A financial services company needs to ensure that their transaction logs are available even if the entire us-east-1 region goes down. They configure CRR from their source bucket in us-east-1 to a destination bucket in us-west-2. They enable versioning on both buckets and set up a replication rule with a prefix filter to replicate only objects under the 'transactions/' prefix. They also enable Replication Time Control (RTC) to guarantee a 15-minute SLA for replication. The IAM role is created with least privilege permissions. They test the setup by uploading sample files and monitoring replication status. In production, they handle large volumes of log files (several TB per day) and find that CRR with RTC meets their RPO of 15 minutes. They also set up lifecycle policies on the destination to transition older logs to Glacier for cost savings.
Enterprise Scenario 2: Log Aggregation with SRR
A SaaS company runs microservices across multiple AWS accounts, each generating access logs stored in separate S3 buckets in the same region (us-east-1). They want to aggregate all logs into a central bucket for analysis. They configure SRR from each source bucket to the central destination bucket. Since SRR does not incur data transfer costs, this is cost-effective. They use prefix filters to replicate only log files. They enable delete marker replication so that if a log is deleted from the source, it is also deleted from the central bucket to maintain consistency. They also enable replica modification sync so that any tag changes on the source are reflected in the replica. The central bucket has a lifecycle policy to transition logs to S3 Standard-IA after 30 days.
Common Misconfigurations and Pitfalls
Missing IAM permissions: The most common issue is an IAM role that does not have the correct permissions. For example, forgetting to include s3:PutObjectAcl can cause replication to fail if the destination bucket has ACLs enabled. Always test with a sample object.
Cross-account bucket policy missing: When replicating across accounts, the destination bucket must have a policy that explicitly allows the source account's IAM role to replicate. Without this, replication fails with an access denied error.
Versioning not enabled: Replication cannot be configured if versioning is not enabled on both buckets. The S3 API will return an error.
Delete marker replication misunderstanding: Many assume that deleting an object from the source will delete the replica. By default, it does not; you must enable delete marker replication. Even then, only the delete marker is replicated, not the permanent deletion of versions.
SSE-C objects: Replication does not support objects encrypted with SSE-C. If you need to replicate such objects, you must decrypt and re-encrypt using a different method.
Performance and Scale Considerations
For high-volume replication, consider using S3 Replication Time Control (RTC) to meet strict SLAs. Monitor replication metrics in CloudWatch. If you have many small objects, the number of PUT requests to the destination can become costly. Use S3 Batch Operations to replicate existing objects after initial setup. If you need to replicate to multiple destinations, you can create multiple rules, but each rule adds overhead. For large-scale scenarios, consider using S3 Multi-Region Access Points for a simpler configuration.
What SOA-C02 Tests on S3 Replication
The exam objectives under Reliability (2.2) include implementing and managing S3 replication. Specific areas tested:
Differences between CRR and SRR
Prerequisites: versioning, IAM roles, bucket policies for cross-account
Replication of delete markers and metadata
Replication Time Control (RTC) and its 15-minute SLA
Handling of existing objects (not replicated by default)
Replica modification sync (SRR only)
Encryption considerations (SSE-S3, SSE-KMS, SSE-C)
Troubleshooting replication failures
Common Wrong Answers and Why Candidates Choose Them
"Replication automatically replicates existing objects." Candidates often think that enabling replication will backfill all objects already in the bucket. Reality: Only objects uploaded after the rule is enabled are replicated. Existing objects require S3 Batch Operations.
"Delete marker replication is enabled by default." Many assume that because versioning is enabled, delete markers are replicated. Reality: Delete marker replication is disabled by default; you must explicitly enable it in the rule.
"Replica modification sync works for both CRR and SRR." Candidates may think metadata changes are always synced. Reality: Replica modification sync is only available for SRR.
"You can replicate to a bucket in a different account without any additional configuration." Candidates forget the destination bucket policy. Reality: A bucket policy on the destination must grant replication permissions to the source IAM role.
"Replication works without versioning." Some think versioning is optional. Reality: Versioning must be enabled on both buckets.
Specific Numbers and Terms That Appear on the Exam
Maximum replication rules per bucket: 1,000
RTC SLA: 15 minutes for 99.99% of objects
Default replication status: PENDING
Replication of existing objects: use S3 Batch Operations
Replica modification sync: SRR only
Delete marker replication: disabled by default
Cross-account replication: requires destination bucket policy
SSE-C objects: not supported for replication
Replication failure retry period: up to 15 days
Edge Cases and Exceptions
If you replicate objects encrypted with SSE-KMS, you must specify the KMS key to use at the destination. If the source uses a different KMS key, you can configure the rule to use a different key.
If you enable object lock on the source, the destination must also have object lock enabled, and the retention settings are replicated.
Replication of lifecycle policies is not automatic; you must set up lifecycle rules on the destination independently.
If you replicate to a bucket in a different region that has a VPC endpoint, you may need to configure the endpoint to allow cross-region access.
How to Eliminate Wrong Answers Using the Underlying Mechanism
When you see an answer choice that says "existing objects are replicated," recall that replication is a near-real-time process that only acts on new objects. The mechanism is event-driven (PUT events). Therefore, existing objects do not generate events and are not replicated. Similarly, if an answer says "delete markers are replicated by default," remember that replication rules have a separate toggle for delete markers; it is off by default to avoid accidental deletion of replicas. Understanding the asynchronous, event-driven nature helps eliminate incorrect options.
S3 Replication requires versioning enabled on both source and destination buckets.
Only objects uploaded after the replication rule is enabled are replicated; existing objects require S3 Batch Operations.
Delete marker replication is disabled by default; you must explicitly enable it.
Replica modification sync is only available for Same-Region Replication (SRR).
Cross-account replication requires a bucket policy on the destination bucket granting replication permissions to the source IAM role.
Replication Time Control (RTC) provides a 15-minute SLA for 99.99% of objects.
Objects encrypted with SSE-C cannot be replicated directly.
Replication failures are retried for up to 15 days; use S3 Batch Operations to retry failed objects.
Maximum of 1,000 replication rules per bucket.
Replication status can be PENDING, COMPLETED, FAILED, or REPLICA.
These come up on the exam all the time. Here's how to tell them apart.
Cross-Region Replication (CRR)
Copies objects across different AWS Regions
Used for disaster recovery, compliance, and latency reduction
Incurs inter-region data transfer costs
Replica modification sync not supported
Requires RTC for 15-minute SLA
Same-Region Replication (SRR)
Copies objects within the same AWS Region
Used for log aggregation, data processing, and live copies
No data transfer costs, only request costs
Supports replica modification sync
RTC available but less critical due to low latency
Mistake
Replication replicates all existing objects in the bucket automatically.
Correct
Replication only replicates objects uploaded after the rule is enabled. To replicate existing objects, you must use S3 Batch Operations with a replication task.
Mistake
Delete markers are replicated by default when you enable replication.
Correct
Delete marker replication is disabled by default. You must explicitly enable it in the replication rule.
Mistake
Replica modification sync works for both CRR and SRR.
Correct
Replica modification sync is only available for Same-Region Replication (SRR). For CRR, metadata changes on the source are not automatically replicated.
Mistake
You can replicate objects to a bucket in a different AWS account without any additional configuration.
Correct
Cross-account replication requires a bucket policy on the destination bucket that grants the source account's IAM role permissions to replicate objects.
Mistake
S3 Replication works without versioning enabled on the buckets.
Correct
Versioning must be enabled on both the source and destination buckets for replication to function. Without versioning, replication configuration will fail.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, by default replication only copies objects that are uploaded after the replication rule is enabled. To replicate existing objects, you must use S3 Batch Operations with a replication task. This is a common exam trap.
Yes, but it is disabled by default. You can enable delete marker replication in the replication rule. When enabled, adding a delete marker to the source object (soft delete) will replicate the delete marker to the destination. Permanent deletion (deleting a version) is not replicated.
CRR copies objects across different AWS Regions, while SRR copies objects within the same region. CRR is used for disaster recovery, compliance, and reducing latency for remote users. SRR is used for log aggregation, data processing, and creating live copies. CRR incurs inter-region data transfer costs; SRR does not.
Yes, but you must specify the KMS key to use for encrypting objects at the destination. The IAM role must have permission to use the KMS key. You can also configure the rule to use a different KMS key than the source.
You can check the replication status of an object using the AWS CLI: `aws s3api head-object --bucket source-bucket --key object-key`. The `ReplicationStatus` field will show PENDING, COMPLETED, FAILED, or REPLICA. You can also monitor CloudWatch metrics like `ReplicationLatency` and `BytesPendingReplication`.
S3 will retry replication for up to 15 days. After that, the object is marked as FAILED. You can use S3 Batch Operations to retry replication for failed objects. Common causes include incorrect IAM permissions, missing bucket policy (cross-account), or versioning not enabled.
Yes, you can create multiple replication rules on the same source bucket, each pointing to a different destination bucket. However, you can only have up to 1,000 rules per bucket.
You've just covered S3 Replication: CRR and SRR — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?