What One S3 Replication Status Says About Multiple Destinations

One source status combines the destinations for one object

AWS documents x-amz-replication-status in object and metadata responses. For a source object replicated to multiple destinations, COMPLETED requires successful replication to every applicable destination. The aggregate stays PENDING while completion is outstanding, unless a destination failure makes it FAILED.

That aggregation removes destination detail. PENDING does not name the unfinished destination; FAILED does not name the failed one. Read the word alongside the requested bucket, key and version, the bucket's role in that replication relationship, and the destinations applicable to that object. This discussion concerns ordinary object versions in general purpose S3 buckets.

For the separate question of whether several objects form a complete release at a location, see Strong S3 Reads Do Not Make a Multi-Object AI Dataset Release Atomic, cited here and linked first in related reading. Its question about a coherent release remains separate from interpreting one object's status.

References: [S3R1][S3R3][L1]

Four intended copies, three present

Consider the wholly fictional REP-4 example. Source bucket A holds artifacts/X.bin at version label x1 and artifacts/Y.bin at version label y1. Call these exact versions X and Y. The labels are illustrative, not actual S3 identifiers. Both versions are stipulated eligible for replication to exactly two configured destinations, B and C. No object or metadata changes occur during the observation.

There are four intended destination copies: X at B, X at C, Y at B and Y at C. The example stipulates that the copies identified as present have been matched to the intended source versions; a familiar key name alone is not the matching evidence.

Replication of X has succeeded to B and C, and both intended copies are present. Replication of Y has succeeded to B, where its intended copy is present. Y's replication to C remains pending, and that intended copy is not yet present there. Thus three of the four intended destination copies exist.

Under the documented aggregation rule, source X is COMPLETED and source Y is PENDING. Yet B already holds both intended copies. If a supplier uses source Y's PENDING status to say that B is missing Y, the conclusion contradicts the example's destination observation. C is the destination still missing that copy.

The same observation answers two buyer questions differently. B holds the two stipulated versions according to the example's evidence, while the requirement for all four destination copies remains unmet. The aggregate tells the reader that Y's replication is unfinished somewhere; the observations at B and C locate the gap.

References: [S3R3]

FAILED at the source can coexist with a successful B copy

Change one premise of REP-4: Y's replication to C is now stipulated to have failed. The successful copies at B and both copies of X remain as described. AWS's multi-destination rule makes source Y's status FAILED.

That word cannot establish that B lacks Y. It summarizes a failure somewhere among Y's applicable destinations, while the example still has Y at B. Nor does it show that an existing copy has been corrupted. Those claims need evidence about the particular copy.

This variant substitutes a known failure for the earlier pending attempt. It supplies no rule that waiting for an unspecified duration turns PENDING into FAILED, and neither status supplies an arrival deadline.

References: [S3R3]

An existing replica can be PENDING for metadata

The bucket's role changes the interpretation. An S3-created replica ordinarily reports REPLICA. With replica modification sync enabled, metadata propagation can instead make that replica report PENDING or FAILED; successful metadata replication returns it to REPLICA.

In a separate fictional case, the intended Y payload already exists as a replica in B. A tag change made to that replica is being replicated back to its source under an applicable replica modification sync arrangement. B's requested replica can now report PENDING while its payload remains present. Here the outstanding work concerns metadata.

This observation differs from source Y's aggregate PENDING in REP-4, where the stipulated gap was Y's copy at C. The word alone does not distinguish these cases. Identify whether the response describes the source object's replication results or an existing replica's metadata propagation before treating PENDING as evidence of missing payload.

References: [S3R1][S3R4]

An absent header calls for an eligibility question

AWS ties the source replication-status header to the requested object's eligibility. Suppose a different fictional rule covers only keys beginning artifacts/, while the requested source object is notes/readme.txt and no other rule covers it. The absence of a replication-status header for that object outside the rule is not a FAILED result. There is no basis in this premise to describe its missing destination copy as an eligible replication attempt that failed.

Coverage also has a time boundary. AWS distinguishes asynchronous live replication of new and updated objects from on-demand Batch Replication for existing objects. Setting up live replication does not automatically copy objects already present beforehand. The existence of a rule today therefore does not, by itself, put every historical version into the example of a pending copy.

For a version-specific question, establish which version the request selected. AWS's HeadObject reference supports a versionId parameter identifying a specific version. A response about another version cannot settle the intended version's replication status. The related Object Lock guide develops the distinction between a version and the current object selected by a key.

References: [S3R2][S3R3]

Choose the observation that answers the destination question

If the question is whether Y reached B, ask for evidence tied to the intended Y version at B. A source-only aggregate leaves B unidentified. A REPLICA response at B establishes replica origin for the object actually requested; connecting that selected object to the intended Y remains necessary. REP-4 supplied that connection explicitly rather than assuming it from a filename.

If the question is why Y's overall status remains unfinished, evidence from B alone leaves C unresolved. A source aggregate and a destination observation are useful together because they answer different parts of the same question. Neither observation establishes application processing or a successful restore.

If the surrounding deployment also requires physical storage-network cabling, Leviathan's Structured Cabling & Fiber Installation service and the related project inquiry provide a route to discuss separately agreed routes, endpoint labels and connection records. Share a nonconfidential equipment outline, approved endpoints and requested physical work. Cloud replication administration and application validation remain with the appointed storage and application providers.

References: [S3R3][L2]