A rule is not the second copy itself
A museum can configure Amazon S3 replication for preservation masters and still have missing replica versions because of filter mismatch, role errors, encryption choices, or delayed processing. GetBucketReplication returns a bucket’s configured replication rules. It does not inspect every destination object, test recoverability, or certify compliance with an archival preservation plan. An operations reviewer should therefore distinguish the configuration inventory from the physical and logical inventory of copies. Start with the authorized source bucket and a representative set of recordings or photographs, then compare the configured rule scope with the copies that should exist.
Check bucket type, region, ownership, and permissions
The API documentation states that GetBucketReplication is not supported for directory buckets and requires s3:GetReplicationConfiguration permission. Before interpreting a missing response, verify that the operator targeted the right bucket and has appropriate access. The request can include an expected bucket owner guard, which protects against a mismatched account context but does not prove that all destination permissions are correct. Treat an access denial differently from “no configuration.” Capture the bucket identifier, region, request time, and permission scope in a restricted audit note. Do not publish account IDs, key names, or role ARNs unnecessarily.
Read every rule, not only the first destination
A replication configuration can have multiple rules, with statuses, priorities, filters, and destination buckets. Parse the entire response rather than stopping at the first visible target. For each rule, record its ID, whether it is enabled, what objects the filter selects, the destination ARN, and the IAM role used for replication. A prefix or tag requirement can exclude older masters whose naming conventions changed. Priority matters where rules interact. A reviewer should map each collection class to applicable rules and highlight any ambiguous gaps for a domain expert to resolve. This mapping is a plan for verification, not a substitute for the destination listing.
Distinguish current objects, versions, and delete markers
S3 Versioning and replication rules have important interactions. A rule that appears to cover an object key may not create an identical history for every previous version automatically. Delete-marker replication is a separate configuration element; its status matters when administrators remove the current visible object. Confirm whether the archive requires preservation of historical versions and whether the chosen rules address that requirement. Do not mistake a replica object with the same name for evidence that each source version is copied. Sample version IDs and destination state where authorized, and note that object metadata and time of creation can differ between source and replica.
Inspect encryption and destination ownership assumptions
Replication of objects encrypted using AWS KMS has additional configuration and authorization requirements. Examine source-selection criteria and any destination ReplicaKmsKeyID in applicable rules, and ask the security team to verify key policies and cross-account permissions. An IAM role ARN in a replication document is only a configured identity: it does not prove that role still has permission to read the source or write to the target. If the destination belongs to another account, also review ownership controls and contractual boundaries. Protect sensitive paths in the audit worksheet while retaining enough structure to identify exactly which rule applies.
Separate live replication from historical backfills
A new live replication rule should not be described as automatically filling every gap in a preexisting archive. Earlier objects or versions may require an explicit backfill mechanism such as S3 Batch Replication, depending on the source state and requirements. The GetBucketReplication response cannot tell a curator that an oral-history master uploaded last year has been copied. Build a time-aware review using a small sample of old and new objects, then check actual replication status and destination presence. Clearly distinguish what the configuration says should happen for eligible future changes from what historical preservation evidence shows.
Read rule propagation and operational lag correctly
AWS notes that replication configuration changes can take time to propagate across S3 systems, so a read immediately after a put or delete can give an unexpected result. Record the timing of changes and do not treat a single immediate read as indisputable evidence of the current intended configuration. Reconcile the configuration after the appropriate observation window and compare it with the approved change record. Replication itself is asynchronous. Performance mechanisms such as S3 Replication Time Control have separate metrics and conditions, and a configuration read is not a measured delivery latency report.
Sample destination copies using objective checks
For a controlled set of eligible source objects, record source key, version ID, relevant retention metadata, replication state if available, expected destination, and observed destination object version. Verify content integrity using documented checksums where applicable rather than assuming identical ETags always prove byte identity, especially for multipart or encrypted objects. Distinguish verification of a returned object from authorization to restore, distribute, or reuse its contents. An illustrative diagram can show “pending” and “checked” states, but these labels must not be presented as an actual test of any customer bucket.
Do not equate replication with a recovery strategy
Replication is one preservation control, not a complete backup or disaster recovery plan. Authorized deletion behavior, ransomware, human configuration error, retention settings, and destination compromise can affect source and target. A recovery strategy needs its own restore exercises, access controls, object-lock decisions, and documented independent copies. If an auditor reports “replication enabled,” also list whether version histories, required collections, KMS access, destination permissions, and tested restoration were verified. Teams should avoid rewriting replication rules during a read-only investigation; changes require separate authority and an assessed blast radius.
Publish an evidence matrix, not a blanket assurance
A useful report pairs each intended collection group with rule ID, filter, status, destination, role, encryption requirement, delete-marker behavior, sampled object evidence, and remaining uncertainty. Clearly mark unknowns rather than quietly promoting them to compliant. Have another reviewer compare the report against the current AWS documentation and preservation policy. If a rule is absent, disabled, or mismatched, the next step is a change proposal rather than an improvised production edit. This workflow offers a defensible answer to which copies have been checked without inventing a live replication result.
How We Research
We used these named official references (checked November 11, 2026): AWS, GetBucketReplication API; AWS, Replication configuration elements; AWS, S3 replication overview. We examined the S3 GetBucketReplication response schema and replication configuration guidance; the diagram separates configured rules from verified copies. This is documentation-based instructional analysis, not a product benchmark, a hands-on integration, or a test of a real museum environment. Scenarios and all illustrations are hypothetical; we did not measure accuracy, throughput, file availability, granted permissions, or actual delivery. Before deployment, an authorized operator should recheck API versions, limits, identity scope, prices where relevant, and institution-specific retention and approval rules. We make no claim that any depicted response, screenshot, dataset, or user consent occurred in production.
Frequently Asked Questions
No. It returns configuration; check source and destination object state separately. A rule can be disabled or target the wrong key prefix.
No. Scope and backfill of existing objects require separate analysis. Previously stored versions may need separate batch replication.
It affects how delete markers are handled and can change what readers see at the destination. Inspect destination behavior, not only the source setting.
No. Verify the actual permissions and key policies for encrypted objects. Destination IAM and KMS configuration can block copies.
No. Restoration and independent retention requirements need their own evidence. Practice recovery separately and retain evidence for the actual versions.