Object-store replication copies eligible objects to another destination after source writes. A configured replication rule does not mean every new object has already arrived; an item can be pending or fail. A recovery procedure that switches readers to the secondary bucket before required objects complete may serve missing data even when the primary reported a successful write.
Make this comfortable
Object replication: verify the exact recovery object arrived
Operational decision
A claims archive copies signed payout statements to another region. When a statement is written, retain its object key, version identifier, digest, and business operation ID in a durable index. The shell sample inspects one source object's replication status using a provider CLI; it is read-only and assumes an approved account and bucket. Before a regional cutover, compare a manifest of required versions against destination inventory and verify several objects by digest and application parse. Put failed or pending objects on an explicit recovery list; a bucket-level replication configuration is not evidence for a particular statement. During a drill, stop writes or establish a precise cutover position, then check every operation acknowledged before that position has its required object version in the recovery region. Preserve delete-marker semantics and retention controls so a mistaken source deletion cannot silently remove the only usable copy.
aws s3api head-object --bucket claims-primary-archive --key statements/2026/10/payout-47.json --query '{version:VersionId,replication:ReplicationStatus,bytes:ContentLength}'
aws s3api head-object --bucket claims-recovery-archive --key statements/2026/10/payout-47.json --query '{version:VersionId,bytes:ContentLength}'Cost and verification
Cross-region copies consume storage and transfer budget and can lag under failure or high write volume. Checking each object at write time adds API cost; use a manifest and sampled continuous checks, then exhaustive reconciliation at a defined recovery boundary. A destination HEAD response proves existence and metadata, not that the application can parse the object or that it matches the required version. Measure age and count of pending or failed copies against the recovery-point objective.
Common Mistakes
- Do not equate an enabled replication rule with completed copy of every object.
- Do not compare only object keys when versions matter.
- Do not promote a recovery region without reconciling acknowledged writes.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Backups and disaster recovery: prove the restore path
- Immutable backup retention: protect recovery copies from deletion
- Multi-region failover: define write ownership before moving traffic
- Replica lag: define when a read is allowed to be stale
Practice and check
Object storage follow-up
devops
operations