# AWS and Azure KMS / HSM Key Management Patterns

> **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

```mermaid
flowchart TD
  A[Cloud KMS / Managed HSM root] --> B[Wrapping key / KEK]
  B --> C[Data keys / DEKs]
  C --> D[Encrypted data in DB / object storage / backups]
  A --> E[Signing key]
  A --> F[Separate admin policy boundary]
```

## What KMS/HSM should own

| Function                              | Why it belongs in KMS/HSM                                      |
| ------------------------------------- | -------------------------------------------------------------- |
| key generation                        | stronger controls, audit, reduced app-side entropy mistakes    |
| wrapping / unwrapping high-value keys | keeps KEKs inside managed boundary                             |
| rotation policy                       | central, auditable, easier to standardize                      |
| access control                        | separate who can **use** keys from who can **administer** them |
| usage logging                         | supports forensics, evidence, and misuse detection             |

## Usage separation model

| Responsibility                                       | Example owner                                   |
| ---------------------------------------------------- | ----------------------------------------------- |
| create / disable / delete KMS keys                   | cloud security or platform security             |
| grant app/service use rights                         | platform + service owner through change control |
| call encrypt/decrypt / sign APIs                     | application or service runtime identity         |
| approve exceptional export / import / HSM operations | security leadership or designated approver      |
| investigate unusual key use                          | security operations + cloud/platform team       |

## 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

| Pattern                                            | Good fit                                                            |
| -------------------------------------------------- | ------------------------------------------------------------------- |
| AWS service-side encryption with AWS KMS           | S3, EBS, RDS, backups, logs                                         |
| application-side envelope encryption via data keys | sensitive fields, files, export packages, cache blobs               |
| asymmetric or signing keys in KMS                  | artifact signing, external verification flows, special trust models |
| CloudHSM / custom key store                        | stronger boundary or niche compliance / legacy needs                |

### AWS CLI examples

#### Create a symmetric key and alias it

```bash
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

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

#### Generate a data key for envelope encryption

```bash
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

| Pattern                                          | Good fit                                                              |
| ------------------------------------------------ | --------------------------------------------------------------------- |
| Key Vault keys for CMK-backed service encryption | storage, search, backup, data services that support CMK               |
| Key Vault secrets                                | app secrets, DB credentials, connection strings                       |
| Key Vault certificates                           | TLS / X.509 lifecycle where Key Vault integration helps               |
| Managed HSM                                      | stricter key boundary, HSM-centric operations, compliance-heavy cases |

### Azure CLI examples

#### Create a key in Key Vault

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

#### Configure rotation policy

```bash
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

```bash
# 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

| Topic                            | AWS                                     | Azure                                                     |
| -------------------------------- | --------------------------------------- | --------------------------------------------------------- |
| broad managed key service        | AWS KMS                                 | Azure Key Vault                                           |
| stronger HSM-centric mode        | CloudHSM / custom key store patterns    | Managed HSM                                               |
| common application-side pattern  | `GenerateDataKey` + envelope encryption | app-generated DEK + wrap/unwrap via Key Vault / HSM       |
| service-side at-rest integration | very broad AWS service integration      | broad Azure CMK support, service-specific behavior varies |
| key admin vs key use separation  | key policies, IAM, grants               | RBAC / access policies depending service mode             |
| rotation                         | automatic or on-demand where supported  | per-key rotation policy and versioning                    |

## 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](/architecture-api-crypto-and-identity/index-3/crypto-design-key-hierarchy-envelope-encryption-signing-rotation-and-common-mistakes.md)
* [Application-Level Encryption, Tokenization, Masking, and Key Management](/architecture-api-crypto-and-identity/index-3/application-level-encryption-tokenization-masking-and-key-management.md)
* [AWS IAM and Role Design](/cloud-kubernetes-and-infrastructure-security/index/aws-iam-and-role-design.md)
* [Cloud Environment Security](/cloud-kubernetes-and-infrastructure-security/index/cloud-environment-security-iam-network-storage-service-config-visibility-posture-and-blast-radius.md)

***

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/cloud-kubernetes-and-infrastructure-security/index/aws-and-azure-kms-hsm-key-management-patterns.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.