☁️ AWS and Azure KMS / HSM Key Management Patterns — Hierarchy, Rotation, and Usage Separation

Intro: Managed KMS/HSM platforms are most useful when they simplify separation of duties, key hierarchy, auditability, and crypto agility. Treat them as control planes for keys, not as magic boxes that automatically fix every encryption design mistake.

What this page includes

• AWS and Azure mental models for KMS / HSM use
• key hierarchy and usage-separation patterns
• rotation and ownership guidance
• CLI examples and common design mistakes

High-level design pattern

What KMS/HSM should own

Usage separation model

AWS KMS patterns

Recommended mental model

• use customer managed KMS keys for workloads that need explicit ownership, policy control, rotation policy, or cross-account design;
• use data keys for application-side or service-side envelope encryption;
• separate keys by environment, data class, and purpose;
• keep signing keys separate from encryption keys.

Common AWS usage patterns

AWS CLI examples

Create a symmetric key and alias it

aws kms create-key \
  --description "prod/customer-data-kek" \
  --key-usage ENCRYPT_DECRYPT \
  --customer-master-key-spec SYMMETRIC_DEFAULT

aws kms create-alias \
  --alias-name alias/prod-customer-data-kek \
  --target-key-id 1234abcd-12ab-34cd-56ef-1234567890ab

Enable automatic rotation

aws kms enable-key-rotation \
  --key-id alias/prod-customer-data-kek \
  --rotation-period-in-days 180

Generate a data key for envelope encryption

aws kms generate-data-key \
  --key-id alias/prod-customer-data-kek \
  --key-spec AES_256

Typical application flow:

• KMS returns a plaintext DEK and an encrypted DEK;
• app encrypts the payload with the plaintext DEK;
• app stores ciphertext + encrypted DEK;
• app discards plaintext DEK from memory.

AWS review questions

• Are we using one key for too many unrelated data classes?
• Who can call kms:Decrypt in production?
• Can the same role both deploy the workload and administer the key?
• Are we relying on AWS managed keys when we actually need customer-managed control and audit detail?

Azure Key Vault / Managed HSM patterns

Recommended mental model

• use Azure Key Vault for broad key/secret/certificate management needs;
• use Managed HSM when you need HSM-backed dedicated control and stronger isolation properties;
• use customer-managed keys (CMKs) for services where you need stronger control over encryption at rest;
• separate keys, secrets, and certificates operationally even if they sit under one service family.

Common Azure usage patterns

Azure CLI examples

Create a key in Key Vault

az keyvault key create \
  --vault-name prod-kv \
  --name customer-data-kek \
  --kty RSA-HSM

Configure rotation policy

az keyvault key rotation-policy update \
  --vault-name prod-kv \
  --name customer-data-kek \
  --value '{
    "lifetimeActions": [
      {
        "trigger": {"timeAfterCreate": "P180D"},
        "action": {"type": "Rotate"}
      },
      {
        "trigger": {"timeBeforeExpiry": "P30D"},
        "action": {"type": "Notify"}
      }
    ],
    "attributes": {"expiryTime": "P2Y"}
  }'

Wrap and unwrap a DEK

# wrap a locally generated data key
az keyvault key encrypt \
  --vault-name prod-kv \
  --name customer-data-kek \
  --algorithm RSA-OAEP-256 \
  --value "$BASE64_DEK"

# later, unwrap / decrypt the DEK
az keyvault key decrypt \
  --vault-name prod-kv \
  --name customer-data-kek \
  --algorithm RSA-OAEP-256 \
  --value "$BASE64_WRAPPED_DEK"

Azure review questions

• Are secrets and keys mixed operationally with weak RBAC boundaries?
• Does the workload identity have only the minimal get, wrap, unwrap, encrypt, or decrypt operations it truly needs?
• If a service uses CMK, how long does it take that service to pick up a rotated key version?
• Is the old key version disabled only after dependency services have actually moved over?

AWS vs Azure quick comparison

Common mistakes

1. One key per kingdom — the same key protects logs, backups, exports, and customer data.
2. No usage separation — the same role can administer the key and decrypt data.
3. Rotation without dependency planning — key rotates, dependent service still uses old version or breaks.
4. Assuming KMS replaces app design — data is encrypted but plaintext still leaks into logs, temp files, and exports.
5. Treating HSM as automatically better — HSM makes sense when the boundary and operational model need it, not just because it sounds stronger.

Practical best practices

• separate keys by purpose, environment, and data sensitivity;
• prefer envelope encryption over storing plaintext master keys in apps;
• log and review decrypt operations, not only key creation events;
• keep signing and encryption keys separate;
• document rotation owners, expected service pickup windows, and rollback paths;
• treat KMS/HSM policy as part of architecture review, not post-build cloud housekeeping.

Example design checklist

• customer data and operational data are not encrypted under the same business key without justification
• non-production cannot use production keys
• CI/CD principals cannot both deploy and broadly decrypt sensitive production data
• key rotation path is tested
• app behavior when KMS is unavailable is understood and documented
• audit logs for key use are centralized and retained

Related pages

• Crypto Design — Algorithm Choice, Key Hierarchy, Envelope Encryption, Signing, Rotation, and Common Coding Mistakes
• Application-Level Encryption, Tokenization, Masking, and Key Management
• AWS IAM and Role Design
• Cloud Environment Security

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.