AWS KMS
Managed service for creating and controlling encryption keys
KMS is like a high-security vault for encryption keys. Imagine you have a diary with a lock, and you need to keep the key safe. You could hide it under your mattress (risky), or you could put it in a bank vault where it's protected by guards, cameras, and alarms. KMS is that vault for your encryption keys. When you encrypt data (EBS volumes, S3 objects, RDS databases), KMS stores and manages the keys. You never see the actual key; you just tell KMS 'encrypt this' or 'decrypt that,' and KMS does it securely. KMS integrates with most AWS services, making encryption easy and automatic.
KMS manages customer master keys used to encrypt data. Operations on KMS keys run inside KMS's FIPS 140-3 Level 3 validated hardware security modules (HSMs); HSMs in China Regions are locally certified instead. Envelope encryption: applications encrypt data with data keys, and KMS protects the data keys. You can use AWS-managed keys (free, automatic rotation), customer-managed keys (you control rotation and policies), or import your own keys.
Key Capabilities
- Manages symmetric (AES-256) and asymmetric (RSA, ECC) encryption keys; all cryptographic operations happen inside HSMs and keys never leave in plaintext
- Three key types: AWS Managed Keys (auto-created per service, rotated annually), Customer Managed Keys (you create and control), and AWS Owned Keys (fully AWS-managed, not visible in your account)
- Key policies are resource-based policies attached directly to the key, separate from and in addition to IAM policies
- Grants allow temporary, scoped delegation of key use to other principals without modifying the key policy
- Multi-region keys replicate a key across AWS regions for globally consistent encryption and decryption
- Every KMS API call is logged in CloudTrail; envelope encryption (KMS generates a data key used locally) handles high-throughput workloads without hitting API quotas
Gotchas & Constraints
Gotcha #1: KMS has request rate limits (5,500-30,000 requests/second depending on region); high-volume encryption can hit limits. Use data key caching or request limit increases. Gotcha #2: Deleting a KMS key is irreversible after the waiting period (7-30 days); all data encrypted with that key becomes unrecoverable. Constraints: KMS keys are regional (replicate for multi-region), direct encryption caps at 4KB (use envelope encryption), and cross-account access needs key and IAM policies.
A healthcare company must encrypt all patient data per HIPAA requirements. They use KMS to create customer-managed keys for different data types: one for EBS volumes, one for S3 buckets, one for RDS databases. When they create an RDS instance, they specify the KMS key; RDS automatically encrypts data at rest. For S3, they enable default encryption with KMS, so all objects are encrypted automatically on upload. They set key policies restricting key usage to specific IAM roles; only the application role can decrypt patient data, not developers. KMS logs all key usage to CloudTrail, so they can audit who decrypted what and when. For disaster recovery, they create multi-region keys that replicate to a secondary region. When they need to share encrypted data with a partner, they use KMS grants to give temporary decrypt permissions that expire after 24 hours.
The Result
comprehensive encryption, centralized key management, and full audit trail for compliance.