Skip to main content
This lesson covers AWS Key Management Service (KMS): what it does, why it matters, and how to use it to protect data at scale. KMS centralizes creation, storage, rotation, access control, and auditing for cryptographic keys used by AWS services and your applications. Why encryption matters
  • Plaintext data is readable by anyone who can access the storage — including attackers who gain access to S3 buckets, EBS snapshots, or source code repositories.
  • Encryption transforms data into ciphertext so it is unreadable without the correct cryptographic key.
  • Proper encryption also supports integrity checks and reduces the risk of tampering when data is transmitted across networks.
A slide titled "Why do we need Encryption?" showing a client, a server, and a hooded attacker with arrows indicating unauthorized access attempts. It illustrates that data is encrypted and therefore unreadable to the attacker.
What KMS solves
  • Managing keys across many applications and services becomes complex: creation, rotation, policy management, and auditing are required for each key.
  • KMS provides a managed, centralized service that handles key lifecycle and exposes cryptographic APIs you can call from applications or AWS services.
How KMS works (overview)
  • KMS creates and stores keys (you typically don’t have direct access to key material KMS manages).
  • KMS enforces key policies and IAM controls.
  • KMS exposes APIs for cryptographic operations (Encrypt, Decrypt, GenerateDataKey, Sign, Verify).
  • KMS supports automated rotation (for eligible keys), scheduled deletion, and import of customer key material under controlled workflows.
The image is a simple KMS diagram showing a KMS logo and three stylized icons: a red key/card icon, a key labeled "Create KMS Keys," and locks with a key labeled "Cryptographic Operations." It visually represents key creation and cryptographic operations in a key management service.
Key metadata and lifecycle attributes Each key stored in KMS includes metadata and attributes you use to identify and control it. Common attributes include:
  • Key ID and Amazon Resource Name (ARN)
  • Key material origin (KMS-generated or imported)
  • Key state (Enabled, Disabled, Pending Deletion, Pending Import, etc.)
  • Key usage (Encrypt/Decrypt for symmetric; Sign/Verify for asymmetric)
  • Key spec and algorithm size
  • Creation date
  • Rotation status (automatic rotation enabled/disabled)
  • Key policy (controls permissions at the key level)
  • Tags and aliases
  • Deletion scheduled date (if pending deletion)
KMS does not reveal private key material for keys it generates. You choose whether KMS generates and manages key material or whether to import your own under documented import processes.
A presentation slide titled "Keys Metadata" showing a large key icon in the center surrounded by labeled metadata fields (Key ID and ARN, Creation Date, Key Usage, Key Material, Key Spec, State, Rotation Status, Policy, Tags). The items are arranged in grey rounded boxes inside a dotted border.
KMS integration with AWS services KMS integrates tightly with many AWS services to provide server-side or client-side encryption: These services can use AWS-managed keys automatically or accept customer-managed keys so you can apply your own policies and rotation settings.
A slide titled "KMS With AWS Services" showing a KMS icon on the left with an arrow to a dotted box containing icons and labels for Amazon S3, Amazon EBS, and Amazon RDS, illustrating KMS integration with those AWS storage services.
Monitoring and auditing Because keys are highly sensitive, KMS integrates with AWS monitoring and auditing tools:
  • AWS CloudTrail logs all KMS API calls (CreateKey, Encrypt, Decrypt, GenerateDataKey, policy changes, etc.), enabling a complete audit trail of key usage and administrative actions.
  • Amazon CloudWatch collects KMS metrics and supports alarms/dashboards for request counts, error rates, and operation latencies.
A slide titled "KMS Monitoring" showing an AWS KMS key icon on the left with an arrow pointing to a dotted box containing AWS CloudTrail and Amazon CloudWatch icons. It illustrates KMS activity being sent to CloudTrail and monitored by CloudWatch.
KMS key types and uses KMS supports multiple key types to cover different use cases:
  • Customer master keys (CMKs) / KMS keys — primary KMS resources used to perform cryptographic operations and protect data keys. Can be customer-managed or AWS-managed.
  • Data keys — plaintext keys used to encrypt large data objects; KMS can generate data keys and return both plaintext and encrypted forms.
  • Imported key material — your own key material imported into a customer-managed key under defined import procedures.
  • AWS-managed keys — created and managed by AWS for use with specific services (for example, aws/s3, aws/ebs). You cannot edit their policy or rotation settings.
  • AWS-owned keys — keys owned and used by AWS across accounts; not visible in your account.
A slide titled "KMS Keys" showing five numbered panels with colorful icons. The panels list: 01 Customer Master Keys, 02 Data Key, 03 Imported Key Material, 04 AWS Managed Keys, and 05 AWS Owned Keys.
Customer-managed vs AWS-managed keys
A diagram showing a developer icon connecting to AWS KMS (key) service. Inside KMS are sections for Customer Managed Keys (CMK) and AWS Managed Keys labeled aws/sqs, aws/s3, and aws/ebs.
Symmetric vs Asymmetric keys
  • Symmetric keys: single secret key used for both encryption and decryption. Ideal for encrypting data at rest, widely supported by KMS.
  • Asymmetric keys: a public/private key pair. Use the public key for encryption or signature verification and the private key for decryption or signing. Asymmetric keys are useful where public distribution of the verification/encryption key is required while keeping the private key secret.
A diagram titled "Symmetric and Asymmetric CMKs" that illustrates files being encrypted and decrypted using keys, with colored document icons, key symbols, and padlocks. The top and bottom rows contrast how encryption/decryption flows differ for symmetric versus asymmetric key use.
Envelope encryption and data keys (recommended pattern) KMS is optimized to protect small secrets (keys) rather than directly encrypt very large payloads. The recommended envelope encryption pattern uses CMKs to protect data keys, and data keys to encrypt large objects: Typical flow:
  1. Call KMS GenerateDataKey (or GenerateDataKeyWithoutPlaintext if you only need the encrypted form). GenerateDataKey returns both:
    • The plaintext data key (raw key bytes), and
    • The same data key encrypted (ciphertext) under a CMK.
  2. Use the plaintext data key locally to encrypt the large object (file, stream), then immediately discard the plaintext data key from memory.
  3. Store the encrypted object together with the encrypted data key (the ciphertext blob returned by KMS).
  4. To decrypt: retrieve the encrypted data key and call KMS Decrypt to obtain the plaintext data key. Use that plaintext data key to decrypt the object, then discard it from memory.
  5. For additional protection or distributed architectures, use GenerateDataKeyWithoutPlaintext so services never receive plaintext keys — they can instead rely on KMS to unwrap keys when needed.
This envelope encryption pattern gives centralized control (CMK management, auditing, policies) and efficient encryption for large payloads. Note: KMS CMKs can directly encrypt only small objects (maximum practical size ~4 KB / 4096 bytes), which is why data keys are used for larger data. KMS benefits (summary)
  • Centralized key lifecycle management across AWS resources and applications
  • Fine-grained access control via key policies and IAM
  • Built-in auditability through CloudTrail and monitoring via CloudWatch
  • Native integration with many AWS services (S3, EBS, RDS, etc.)
  • Support for envelope encryption (data keys) to encrypt large data efficiently
  • Automatic rotation for eligible symmetric customer-managed CMKs and ability to import key material when required
Never store plaintext secrets (like credentials or private keys) in source code, configuration files, or unprotected storage. Use KMS (or a Secrets Manager) and follow the envelope encryption pattern to protect large data and maintain centralized control and auditability.
Links and references

Watch Video