[Deep Dive] AWS KMS: From the Basics of Cryptographic Key Management to a Practical Comparison with Google Cloud KMS (CMEK) and Azure Key Vault

Key points first (for busy readers)

• AWS Key Management Service (AWS KMS) is a managed service that securely creates and manages encryption keys (KMS keys) and provides cryptographic operations such as encryption/decryption. It integrates with many AWS services, and in many “at-rest encryption” scenarios you can specify a customer managed key (CMK).
• The core of access control is the key policy (the KMS key’s resource policy). Even if you use IAM policies and the like, the key policy must allow it—an AWS KMS “gotcha” that frequently causes design mistakes.
• Auditing is strong: AWS KMS API calls are logged to CloudTrail, making it easier to build a traceable posture (“who used which key, when”).
• For rotation (replacing key material), AWS-managed keys are rotated yearly, while customer managed keys can optionally enable automatic rotation (yearly by default). On-demand rotation is also possible.
• Pricing is mainly based on key storage (monthly per key) and cryptographic request volume. With a clear unit like $1/month per key (prorated), it’s easier to estimate how costs scale as design expands.
• GCP offers Cloud KMS with CMEK (Customer-managed encryption keys), allowing customers to own/control keys protecting data at rest. Rotation schedules can be configured (with limitations on automatic rotation for asymmetric keys).
• Azure provides Key Vault for keys/secrets/certificates, and supports key rotation policies (auto-rotation and notifications). Understanding the difference between Vault vs Managed HSM resource types makes selection smoother.

Who this article is for (concrete)

AWS KMS is not only for cryptography specialists. More often, it becomes the “responsibility sink” that cloud builders must eventually face. This article is especially useful for:

1. Backend/infra engineers in product development who increasingly need to explain data protection
   It’s no longer enough to say “we encrypt data.” You’ll be asked: “With which key?” “Who can use it?” “How does rotation work?” “Are logs preserved?” KMS is a practical way to satisfy these responsibilities as architecture.

2. SRE/security teams dealing with audit or compliance requirements
   KMS makes it easier to audit key operations via CloudTrail and design permissions around key policy. From an audit viewpoint, it’s powerful for explaining “who could use the key.”

3. Architects planning multi-cloud or migrations who want to understand equivalents in GCP and Azure
   AWS KMS, GCP Cloud KMS, and Azure Key Vault all solve “key management,” but differ in operational norms (policy model, versions, rotation assumptions). If you align the comparison axes, migration design and shared governance become easier.

1. What AWS KMS is: the core for treating cryptographic keys “as a service”

AWS KMS creates and manages cryptographic keys (KMS keys) and provides operations such as encryption/decryption. With a customer managed key, you can create/own/manage keys in your account and control key policy, IAM/grants, enable/disable state, rotation, deletion scheduling, and more.

The important point: KMS is not merely a “key locker.” It often becomes the operational center of cloud data encryption. If applications implement crypto directly, key storage/distribution/rotation/auditing become hard. By pushing these concerns into KMS, you can formalize lifecycle management and auditability at the service level.

2. Fundamentals you must get right: key types and the “management boundary”

2-1. Decide by “who manages the key”: AWS-managed keys vs customer managed keys

In practice, this split speeds decisions:

• Data where you must hold the key (customer requirements, regulation, strong internal control) → customer managed key first
• Data where you want maximum operational simplicity (standard encryption is enough) → consider using the service’s default AWS-managed key

If you tie this decision to a data classification document (confidentiality, retention, who can handle it), team alignment becomes much easier.

2-2. Rotation is less “replacing the key” and more “adding key versions”

A common misunderstanding to avoid: rotation does not necessarily mean existing data is automatically re-encrypted. In many designs, encryption is done via envelope encryption: a data encryption key (DEK) encrypts the data, and a key encryption key (KEK = KMS key) protects the DEK. After rotation, new encryptions use new key material, while decryption can still succeed using older material as needed. Designing with that mental model yields more stable operations.

3. Where most incidents happen: access control (key policy) design

3-1. In KMS, the “key policy is the star”

KMS uses a key policy (a resource policy attached to the KMS key) as the primary access-control mechanism, and every KMS key has exactly one key policy. Even if you use IAM policies or grants, the key policy must allow those paths to work.

This is what causes common real-world stumbles:

• IAM says “Allow,” but KMS still returns AccessDenied
• Even “admin-like” roles can’t use a key
• Cross-account sharing doesn’t behave as expected

The cause is usually that the key policy does not permit IAM-based access or cross-account use in the way you assumed. KMS tends to enforce “control from the key side,” which makes sense because keys are the root of trust.

3-2. A practical “roles and responsibilities” split that reduces conflict

A division that works well in teams:

• Key administrators (Security/Platform)
  • Create keys, deletion schedules, rotation settings
  • Maintain key policies
• Key users (Application)
  • Minimal permissions to run encrypt/decrypt as needed
  • No key policy modifications

KMS is especially good at separating “use” permissions from “manage” permissions—and splitting them reduces incidents.

4. Auditing and observability: tracking key usage with CloudTrail

AWS KMS integrates with CloudTrail so calls to KMS by users/roles/other AWS services are recorded as events, including via console, API, CLI, and CloudFormation.

For audit design, decide up front:

• Do you need audit on key administration, key usage, or both?
• How long should logs be retained (requirements vs storage cost)?
• What granularity do you need for “who used it” (by app, environment, tenant, etc.)?

Also note that CloudTrail log encryption has constraints (e.g., symmetric KMS keys), so it’s safer to confirm audit requirements before deciding key types (symmetric vs asymmetric).

5. Cost design: KMS cost “shows up” as key count + request volume

KMS pricing is largely:

• Per-key monthly storage cost (prorated)
• Cryptographic API request cost (and related usage)

A practical order for cost planning:

1. Reduce key count first: consolidate to “necessary and sufficient” boundaries (environment × purpose)
2. Reduce request volume next: frequent services can accumulate KMS calls quickly
3. Accept justified exceptions: e.g., tenant-per-key isolation if required

Also consider optimization mechanisms on integrated services (e.g., features like bucket keys that can dramatically reduce KMS request costs), and estimate costs with those in mind.

6. Common use cases: where KMS delivers the most value

6-1. Using customer managed keys for at-rest encryption (AWS’s “CMEK-like” usage)

Customer managed keys shine when you specify “your key” for at-rest encryption in managed services. The key design question is the responsibility boundary:

• Disabling or scheduling deletion incorrectly can cause business-impacting decryption failures
• Allowing overly broad key use weakens access control even if data is encrypted

KMS is both an encryption feature and the final gate for access control.

6-2. Using KMS as the core for application encryption (envelope encryption)

When requirements say “encrypt only specific fields” or “encrypt before the DB,” envelope encryption is common:

• Ask KMS to generate a data key
• Use the plaintext data key to encrypt data in the app
• Store the encrypted data key alongside the encrypted data
• For decryption, send the encrypted data key to KMS to recover the plaintext data key, then decrypt data

This keeps data keys short-lived, reduces exposure risk, and leaves KMS usage in audit logs.

7. Comparison with GCP and Azure: same “key management,” different operational habits

Below is a comparison using AWS KMS as the baseline.

7-1. GCP: Cloud KMS and CMEK

GCP’s Cloud KMS CMEK emphasizes that customers can own and control the keys protecting data at rest. Cloud KMS supports rotation schedules (new key versions generated automatically at set intervals) with an operating model where encryption uses the primary version and decryption may use multiple versions.

A key caution: GCP explicitly states that automatic rotation is not supported for asymmetric keys, because distributing a new public key requires extra steps. This can directly affect your key-type choice.

7-2. Azure: Key Vault (Vault / Managed HSM) and key rotation

Azure Key Vault is presented as a secure store for keys, secrets, and certificates, with monitoring/log export options (storage, event hub, Azure Monitor Logs). Azure also distinguishes between Vault and Managed HSM: Vault can handle software-protected and HSM-protected keys, while Managed HSM is for HSM-protected keys only (a common way to meet stricter compliance requirements).

Rotation can be configured through key rotation policies, including automatic rotation and pre-expiry notifications.

7-3. Practical conclusion: selection depends on “integrations” and “operational culture”

• AWS: KMS is deeply embedded as the hub of service integrations, with key-policy-centered control
• GCP: CMEK strongly emphasizes ownership/control, and key versioning/rotation schedules are easy to reason about
• Azure: Key Vault is a unified store for keys + secrets + certs, and Vault vs Managed HSM helps absorb compliance needs

So it’s not “which is best,” but “which fits your service integrations and your operational culture (policy/audit/rotation workflow).”

8. Common pitfalls—and proactive countermeasures

8-1. Assuming “admins can obviously use the key” and getting stuck on key policy

Because key policy is primary, IAM allowances alone may not work. If you don’t know this, you can end up unable to decrypt during an incident.
Countermeasure: design a break-glass (emergency) key-admin role and periodically test that decryption works.

8-2. Treating deletion scheduling too lightly

Key deletion can mean “permanent loss of decryption.” Treat disable/delete as operations akin to data deletion, with strong change management (request/approval/audit).

8-3. Feeling “done” just because rotation is enabled

Auto-rotation is optional for customer managed keys, with yearly default and (depending on tooling) adjustable periods. But rotation is not merely a “setting”—it’s an operational process:

• How do you decide frequency and exceptions (freeze windows)?
• How do you test impact and scope?
  Without a process, it becomes ritualized and loses meaning.

9. Minimal ready-to-use template (sample)

Here’s a small template you can adopt as-is and evolve over time.

9-1. Key-splitting policy (example)

• prod-app-data-key: for production app data at rest (customer managed key)
• prod-audit-log-key: for audit logs (customer managed key, tightly scoped access)
• dev-shared-key: shared development key (minimal necessary control)

This avoids excessive key sprawl while keeping boundaries (prod / audit / dev) clear. With per-key monthly pricing, it’s also easier to justify “why we added keys.”

9-2. Responsibilities (example)

• Security/Platform: key policy changes, rotation settings, disable/delete
• Application: minimal encrypt/decrypt usage permissions
  This aligns with KMS’s key-policy-centered philosophy and reduces accidents.

9-3. Auditing (example)

• Always record KMS API calls via CloudTrail
• Set a retention period and lock down access to logs
  Because CloudTrail integration is built-in, KMS is an easy starting point for audit design.

Summary: AWS KMS makes “operations and accountability” easier than “crypto itself”

AWS KMS helps you systematize key operations around customer managed keys, including key policies, rotation, and audit logging. In particular, the fact that key policy is the center of access control and that CloudTrail can trace key usage can raise the baseline quality of security and operations.

GCP Cloud KMS (CMEK) and Azure Key Vault are also strong options for the same underlying goals—ownership, rotation, audit—but each has its own character in how it treats key versions, rotation, and resource types.

As a first step, even just “create one customer managed key for production data and define responsibilities + audit log policy” delivers real value. From there, you can grow into key partitioning, rotation optimization, and cost optimization in the most failure-resistant way.

Reference links (official documentation 중심)

• AWS KMS Keys (Concepts and Customer-Managed Keys)
• AWS KMS Key Policies
• Using IAM Policies with AWS KMS
• Rotating AWS KMS Keys
• CloudTrail Logging for AWS KMS
• AWS KMS Pricing
• GCP Cloud KMS: CMEK Overview
• GCP Cloud KMS: Key Rotation
• Azure Key Vault Overview
• Azure Key Vault: Key Overview (Vault/Managed HSM)
• Azure Key Vault: Configuring Automatic Key Rotation (Japanese)