A healthcare SaaS encrypts PHI client-side with the AWS Encryption SDK using a KMS key in us-east-1 and stores the ciphertext in S3. It is expanding to eu-west-1 for disaster recovery, and replicated ciphertext must be decryptable in either Region without re-encrypting data or managing separate keys per Region. Which key strategy meets cross-Region decryptability with centralized control?

The multi-Region KMS design is correct because a primary key in us-east-1 and a replica in eu-west-1 share the same key material and key ID, so ciphertext produced in one Region, such as client-side encrypted records via the AWS Encryption SDK, can be decrypted in the other Region by calling the local replica without re-encrypting, while rotation of the primary keeps the set aligned. Using a single-Region customer managed key with cross-Region IAM grants avoids re-encryption but fails Regional independence because eu-west-1 must call us-east-1 for every decrypt, breaking disaster recovery if the primary Region is impaired. Replicating S3 objects with a separate destination key fails because S3 replication decrypts and re-encrypts the object data keys under the destination key, even when related multi-Region keys are used, so it violates the no re-encryption requirement. Sharing an application data key via Parameter Store supports portable envelope encryption but loses KMS key policy, rotation, and audit controls needed for PHI and is not centrally governed. Exam caveat: AWS services that integrate with KMS for encryption at rest mostly treat multi-Region keys as single-Region keys, so the shared-material advantage applies to client-side encryption and ciphertext moved as-is. Practical check: verify the replica key in both Regions and test decrypt in eu-west-1 with us-east-1 isolated.