In Amazon S3, what does Replication Time Control (RTC) add to a replication rule, and how would you measure replication lag on a rule that does not use it?

## The default: best-effort S3 replication is asynchronous. A `PutObject` on the source returns as soon as the source write is durable, and replication happens afterwards. In practice the great majority of objects appear at the destination within minutes, but that is an observed behaviour rather than a guarantee. Large objects take longer. A sudden burst of writes queues. Nothing in the default configuration tells you how far behind you are, and nothing entitles you to anything if the tail stretches. That is fine for "we would like a second copy" and not fine for "our recovery point objective is fifteen minutes and the auditor has it in writing". ## What RTC adds **S3 Replication Time Control** is a per-rule option in the destination configuration. It provides: - **A service level agreement**: AWS commits to replicating 99.99% of objects within 15 minutes of upload, with service credits if the commitment is missed. Verify the current SLA text before quoting numbers in a design document — SLA terms are versioned documents that change. - **S3 Replication metrics** in CloudWatch, which give you the operational picture: `ReplicationLatency` (how far behind the rule is running), `BytesPendingReplication` and `OperationsPendingReplication` (the size and count of the backlog). - **Replication event notifications**, including an event raised when an object misses the 15-minute threshold and another when it replicates after having missed it. Those are the hooks you alarm on. It costs a per-GB **Replication Time Control data transfer** charge on top of the ordinary replication request charges, cross-Region transfer and destination storage. On a high-volume bucket that is not a rounding error, which is why RTC is a decision rather than a default. ## Measuring without RTC You do not have to buy the SLA to get visibility. **S3 Replication metrics can be enabled on a replication rule independently**; RTC simply includes them. Once on, the CloudWatch metrics above let you build the alarm that actually matters operationally: not "did one object miss", but "is the pending backlog growing", which is the shape of every real replication incident — a permissions change, a KMS key policy edit, a destination bucket policy tightened by another team. A good alarm pair: - `OperationsPendingReplication` above a threshold **and rising** over several periods — the rule has stalled rather than momentarily queued. - `ReplicationLatency` above your RPO — the tail has stretched past what the design assumes. For a single object under investigation, the replication status is exposed directly: ```bash aws s3api head-object --bucket example-source --key data/latest.json \ --query ReplicationStatus ``` `PENDING` means in flight, `COMPLETED` means replicated, `FAILED` means S3 tried and could not — almost always a permissions or key-policy problem rather than a transient one. On the destination object the same field reads `REPLICA`. ## When to turn RTC on Ask what changes if replication runs an hour late. If the answer is "nothing, the copy is for a compliance checkbox and a Regional disaster is the only scenario we care about", default replication with metrics and an alarm is proportionate. If the answer is "we fail over to the second Region and serve reads from it, so an hour of lag is an hour of missing data for customers", then the RPO is real, and RTC is how you make it a commitment with an alarm attached rather than an assumption. There is a third case worth naming: a **regulated workload** where you must be able to demonstrate the replication objective to an auditor. RTC's SLA and its metrics are evidence; "it usually takes about five minutes" is not. ## The trap in the question Candidates often answer that RTC "makes replication faster". It is better to say it makes replication **bounded and observable**. Throughput is broadly the same; what you are buying is the tail guarantee, the metrics, and the events that tell you when the tail was missed.