Account A wants to replicate SSE-KMS encrypted objects from its bucket to a bucket owned by Account B, encrypting the replicas with a KMS key in Account B. Beyond meeting the general replication requirements, which two additional conditions must be satisfied for this cross-account, KMS-encrypted replication to work?
- The replication rule must opt in to replicating KMS-encrypted objects and specify Account B's key; separately, Account B must grant Account A's replication role permission in that key's key policy — and the key must be a customer managed key, since AWS managed keys cannot be used cross-account
- Nothing extra is required beyond enabling versioning on both buckets, since KMS-encrypted objects replicate identically to unencrypted ones
- Account A must switch the source bucket to SSE-S3 encryption before replication will process any objects
- Account B must make its bucket fully public so Account A's replication role can reach it without a key policy grant
Why A? And why not the others?
Correct answer: A. The replication rule must opt in to replicating KMS-encrypted objects and specify Account B's key; separately, Account B must grant Account A's replication role permission in that key's key policy — and the key must be a customer managed key, since AWS managed keys cannot be used cross-account
By default, Amazon S3 does not replicate objects encrypted with SSE-KMS at all; the replication configuration must explicitly opt in by enabling the SourceSelectionCriteria element for SSE-KMS encrypted objects and must specify the destination KMS key ID that will encrypt the replicas. In a cross-account scenario, AWS documentation is explicit that the KMS key owner (Account B) must grant the source bucket owner's replication role permission to use that key, via the key's own key policy, since a bucket policy alone cannot grant access to a KMS resource owned by another account. AWS documentation further notes that a cross-account replication rule must specify a customer managed key for the destination, because AWS managed keys don't allow cross-account use and therefore cannot serve as the destination key at all. The option claiming nothing extra is required beyond versioning is wrong because KMS-encrypted objects are excluded from replication by default and require this explicit opt-in and key-policy grant on top of the baseline versioning requirement. Switching the source bucket to SSE-S3 is not a requirement and defeats the stated goal of replicating SSE-KMS-encrypted objects with a KMS key in Account B; it describes abandoning KMS entirely rather than enabling its cross-account replication. Making the destination bucket fully public is neither necessary nor sufficient: cross-account replication access is granted through a bucket policy statement authorizing the source account's role, and the KMS key policy grant described above, not through making the bucket world-readable, which would be a serious and unrelated security exposure.
Source: AWS S3 documentation: Replicating encrypted objects (SSE-S3, SSE-KMS, DSSE-KMS, SSE-C) — SourceSelectionCriteria opt-in, cross-account KMS key policy grants, and the customer-managed-key requirement for cross-account replication