A company stores millions of confidential objects in an Amazon S3 bucket and requires that all of them be encrypted at rest with a customer managed AWS KMS key for auditability. After enabling SSE-KMS as the default, the team finds that high request volumes generate a large number of KMS GenerateDataKey calls, raising both cost and the chance of hitting KMS request limits. They want to keep the same KMS key and encryption while sharply reducing KMS API calls. Which configuration meets this requirement?
- ASwitch the bucket default encryption to SSE-S3 with Amazon S3 managed keys, removing the dependency on KMS for object encryption and eliminating the KMS request charges.
- BRequest a quota increase for KMS cryptographic operations and add client-side caching of data keys in the application so fewer calls reach the KMS service.
- CEnable an S3 Bucket Key for the bucket, so S3 uses a short-lived bucket-level data key and reduces the number of GenerateDataKey calls made to KMS. Correct
- DReplace the customer managed key with an AWS managed key for S3, because AWS managed keys are not billed for GenerateDataKey calls on encrypted objects.
Why A is wrong: SSE-S3 removes the KMS calls but also abandons the customer managed key and the audit trail the company requires, so it fails the encryption control.
Why B is wrong: Raising quotas and writing client-side caching addresses the symptom but requires application changes and does not reduce the underlying per-object KMS billing the way a bucket key does.
Why C is correct: An S3 Bucket Key generates a bucket-level key that S3 reuses for many objects, cutting per-object KMS calls while keeping SSE-KMS and the customer managed key.
Why D is wrong: AWS managed keys still incur request charges and remove the customer-controlled key policy and rotation control the audit requirement depends on.