Data Protection
Keys and envelopes
A KMS customer managed key is governed by its key policy, which is the root of trust: an IAM policy alone cannot grant access unless the key policy delegates to IAM (the default policy does, for the account). KMS uses envelope encryption - a data key encrypts the object, the CMK encrypts the data key. Automatic rotation is yearly for symmetric customer managed keys and cannot be enabled for asymmetric or imported key material. Deleting a key has a 7–30 day waiting window and is effectively irreversible; disabling is the reversible move during an incident. Grants give temporary, scoped access; multi-region keys replicate key material for cross-region DR.
S3 and storage
S3 supports SSE-S3, SSE-KMS, DSSE-KMS and SSE-C (the client supplies the key, AWS stores no copy, HTTPS is mandatory). Bucket keys cut KMS request costs. Block Public Access has four independent settings - enable all and audit with Access Analyzer for S3. Object Lock provides WORM and requires versioning; versioning plus MFA delete resists ransomware deletion. Presigned URLs delegate time-limited access without changing policy.
Secrets belong in Secrets Manager when you need built-in rotation (RDS, Redshift, DocumentDB) and cross-account sharing, or in SSM Parameter Store SecureString for cheap KMS-backed storage without rotation. CloudHSM gives single-tenant FIPS 140-2 Level 3 hardware; KMS is multi-tenant.
Traps
Turning on default bucket encryption does not retroactively encrypt existing objects. Sharing an encrypted EBS or RDS snapshot cross-account requires sharing the CMK too. Macie classifies only S3 data - it is not general DLP.
Rule of thumb
AWS must not hold the key → SSE-C or client-side. Need audit, rotation and fine-grained policy → SSE-KMS. Need dedicated hardware → CloudHSM.