Lesson 172 · AWS Learning Path

AWS 172: AWS KMS fundamentals

Anil Jalela · Published Dec 14, 2025 · 9 min read

Why this lesson matters

Understand KMS keys, aliases, key material origin, symmetric and asymmetric use, grants, rotation, multi-Region keys, deletion, and service integrations.

What you will be able to do

By the end, you can:

• explain aws kms fundamentals in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+------------------------------+
|  Authorized encrypt request  |
+------------------------------+
               |
               v
+---------------------------------+
|  KMS key and policy evaluation  |
+---------------------------------+
                |
                v
+------------------------------------+
|  Data key or cryptographic result  |
+------------------------------------+
                  |
                  v
+-------------------------------------+
|  Encrypted data and audit evidence  |
+-------------------------------------+

KMS is a regional cryptographic control plane, not a storage service. A KMS key protects small values directly or, more commonly, protects a data-encryption key used by S3, EBS, RDS, an SDK encryption client, or another workload. The plaintext data key exists only where encryption or decryption occurs; the encrypted copy can travel with the ciphertext. CloudTrail records KMS API use, but encryption does not replace IAM authorization, network controls, backups, or data classification.

Build the complete KMS mental model

Key material origin and stores

• AWS_KMS means KMS generates and protects the key material.
• EXTERNAL means you import material and own its availability, expiry and re-import procedure.
• A CloudHSM custom key store keeps material in a customer-controlled CloudHSM cluster; an external key store delegates cryptographic operations to an external key manager. Both add availability, latency, cost and incident dependencies.
• Multi-Region keys contain related key material in independently managed regional primary and replica keys. Their aliases, policies and grants are regional. Use them only when an application must perform compatible cryptographic operations in another Region; ordinary S3 replication can decrypt and re-encrypt with unrelated regional keys.

State and lifecycle are part of data durability

Enabled permits use subject to authorization. Disabled, PendingImport, Unavailable, and PendingDeletion stop some or all cryptographic operations. Scheduling deletion is not cleanup like deleting a test instance: after the 7–30 day waiting period, ciphertext can become permanently unrecoverable. Disable first, monitor CloudTrail for attempted use, verify backups and dependencies, then schedule deletion only under an approved destruction process.

Automatic rotation changes backing key material while retaining the key ID and old material for decrypting existing ciphertext. It does not re-encrypt stored data. Current KMS supports configurable automatic rotation periods and on-demand rotation for eligible symmetric customer-managed keys. A new key plus alias migration is still needed when policy, Region, key usage, origin, or cryptographic specification must change.

Authorization evaluation

A caller needs an effective allow that KMS accepts. For a customer managed key, start with the key policy. The key policy can authorize principals directly or enable the account to delegate through IAM. Identity policy alone is not automatically sufficient. Then evaluate SCPs, permission boundaries, session policies, VPC endpoint policy, grants, explicit denies, key state and conditions such as kms:ViaService, encryption context, source account, or grant constraints. Cross-account use needs permission in both the key-owning account policy and the caller account identity path.

Envelope-encryption request path

1. The workload calls GenerateDataKey against an authorized KMS key.
2. KMS returns a plaintext data key and a copy encrypted under the KMS key.
3. The workload encrypts bulk data locally and immediately removes the plaintext data key from memory.
4. It stores ciphertext, encrypted data key, algorithm metadata and required encryption context together.
5. To read, it sends the encrypted data key and identical context to Decrypt, then decrypts the bulk ciphertext locally.

This keeps large payloads out of KMS and reduces request volume. Never log plaintext keys, decrypted values, or unredacted CLI results.

Architecture decision table

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Use the Console service search and open Key Management Service, Customer managed keys and AWS managed keys; confirm the account and Region before reading the page.
2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws kms list-aliases --query 'Aliases[].{Alias:AliasName,Target:TargetKeyId}' --output table
aws kms list-keys --query 'Keys[].KeyId' --output table
aws kms describe-key --key-id replace-with-key-id --query 'KeyMetadata.{Arn:Arn,State:KeyState,Manager:KeyManager,Origin:Origin,Usage:KeyUsage,MultiRegion:MultiRegion}' --output json

Expected interpretation

Enabled means KMS can consider cryptographic requests; authorization still depends on key policy, IAM, grants, conditions, service context, and key state.

Practical work

Create a key-choice sheet for S3, EBS, RDS, application field encryption, cross-account data, signing, and strict external-key requirements. Choose AWS-owned, AWS-managed, customer-managed, or external options.

Diagnose this topic from its own evidence

Use the error and key metadata to separate failure classes:

Record the failed CloudTrail event name, error code, caller, key ARN and encryption context keys. Context values can contain business data, so redact before sharing.

Cost and cleanup

Customer-managed keys, requests, custom key stores, external key stores, and some integrations can charge. This lesson is read-only.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Understand KMS keys, aliases, key material origin, symmetric and asymmetric use, grants, rotation, multi-Region keys, deletion, and service integrations.

1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AWS KMS.

1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AWS KMS.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid creating a key for every lab, scheduling deletion casually, or confusing encryption with authorization.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Customer-managed keys, requests, custom key stores, external key stores, and some integrations can charge. This lesson is read-only.

Lesson acceptance

• Distinguish AWS owned, AWS managed and customer managed keys without calling an alias a key.
• Choose symmetric, asymmetric or HMAC usage and explain why the alternatives are wrong.
• Draw envelope encryption and identify where plaintext exists.
• Evaluate key policy, IAM, grants, conditions, organizational controls and key state in the correct order.
• Explain rotation versus re-encryption and why deletion can destroy access to retained data.
• Produce a redacted describe-key record and a service-by-service key-choice sheet without creating resources.

Official sources

• AWS KMS concepts
• KMS keys
• Rotate KMS keys
• Multi-Region keys
• Delete KMS keys safely
• AWS security documentation
• Security Pillar