← Back to list

AWS Security Explained — AWS KMS Deep Dive | Key Management and Encryption Keys

In the previous article — AWS KMS, we explored the fundamentals of AWS Key Management Service (AWS KMS), how it works, and the difference…

Satyavarssheni · 2026-07-14 18:17 · 6 claps · 4.3 min read
#aws #aws-kms #encryption #kms-key #keys
Open on Medium ↗
Wiki topics: BIZ · Business Strategy ☁️ · DevOps & Cloud 🔒 · Cybersecurity

AWS Security Explained — AWS KMS Deep Dive | Key Management and Encryption Keys

In the previous article — AWS KMS, we explored the fundamentals of AWS Key Management Service (AWS KMS), how it works, and the difference between symmetric and asymmetric cryptographic keys.

The next question naturally becomes:

Who owns the encryption key, and who is responsible for managing it?

AWS offers multiple KMS key types to accommodate different levels of control, compliance, and operational responsibility. While all of them can be used to encrypt data, they differ significantly in terms of ownership, visibility, customization, auditing, and lifecycle management.

Choosing the appropriate key type is an important architectural decision because it directly affects:

  • Security
  • Compliance
  • Operational overhead
  • Cost
  • Key rotation
  • Cross-account sharing
  • Disaster recovery

Let’s explore each KMS key type in detail.

Types of AWS KMS Keys

AWS provides four primary categories of KMS keys:

  1. AWS Owned Keys
  2. AWS Managed Keys
  3. Customer Managed Keys
  4. Imported Key Material

Although they may appear similar at first glance, they offer very different levels of control and flexibility.

1. AWS Owned Keys

AWS Owned Keys are encryption keys that are fully owned and managed by AWS.

These keys are not visible in your AWS account, and you have no control over them.

Advantages

  • Extremely easy to use
  • Zero operational effort
  • No key management required
  • Ideal for customers who simply want encryption enabled

Limitations

  • No control over key policies
  • No visibility into the key
  • Cannot audit individual key usage
  • Cannot share across accounts

2. AWS Managed Keys

AWS Managed Keys provide a balance between simplicity and visibility.

Unlike AWS Owned Keys, these keys are created inside your AWS account and are visible in the AWS KMS console.

However, AWS still manages them on your behalf.

Each AWS service automatically creates its own managed key.

Limitations

Although AWS Managed Keys are visible, customers cannot fully control them. For example: You cannot,

  • Modify the key policy
  • Disable the key
  • Schedule key deletion
  • Share the key across AWS accounts
  • Configure rotation frequency

AWS manages all of these operations automatically.

3. Customer Managed Keys (CMKs)

Customer Managed Keys provide the highest level of control.

Unlike AWS Managed Keys, these keys are created and owned by the customer inside AWS KMS.

This means the customer controls nearly every aspect of the key’s lifecycle.

Customer Managed Keys are the preferred choice for production workloads that require governance, auditing, and compliance.

What Can You Control?

With Customer Managed Keys, you can manage:

  • Key policies
  • IAM permissions
  • Aliases
  • Tags
  • Rotation settings
  • Cross-account access
  • Enable or disable the key
  • Schedule key deletion
  • Grants

This flexibility makes CMKs suitable for enterprise workloads.

Limitations

More control also means more responsibility.

Administrators must:

  • Design appropriate key policies
  • Enable rotation if required
  • Monitor usage
  • Manage lifecycle
  • Control cross-account permissions

4. Imported Key Material (Bring Your Own Key — BYOK)

Some organizations are required to generate encryption keys outside AWS due to regulatory or organizational policies.

Instead of allowing AWS KMS to create the key, they generate it using their own Hardware Security Module (HSM) or cryptographic system and then import the key material into AWS KMS.

This model is commonly known as Bring Your Own Key (BYOK).

Advantages

  • Meets regulatory requirements
  • Supports existing enterprise HSM infrastructure
  • Greater control over key generation
  • Enables migration of existing cryptographic systems

Limitations

  • Manual key rotation
  • More complex management
  • Customer responsible for lifecycle planning
  • Requires secure import procedures

Automatic vs Manual Key Rotation

Key rotation is the process of replacing old cryptographic key material with new key material while maintaining access to previously encrypted data.

Regular rotation reduces the impact of long-term key exposure and is recommended as part of a strong security posture.

Automatic Rotation

Customer Managed symmetric keys support automatic rotation, but it is not enabled by default.

Once enabled:

  • AWS periodically rotates the cryptographic material.
  • The key ID, ARN, aliases, and permissions remain unchanged.
  • Existing encrypted data continues to work without re-encryption.

This allows applications to continue operating without any code changes.

On-Demand Rotation

AWS also supports on-demand rotation for eligible customer-managed symmetric keys.

This is useful when:

  • A key is suspected to be compromised.
  • Compliance requires immediate rotation.
  • An organization follows its own rotation schedule.

Administrators can rotate the key material without waiting for the automatic schedule.

Imported Keys

Imported key material does not support automatic rotation.

Organizations must generate new key material externally and import it again whenever rotation is required.

Choosing the Right KMS Key Type

The appropriate KMS key depends on your application’s requirements.

Use AWS Owned Keys when:

  • Simplicity is the priority.
  • No customer control is required.
  • Internal AWS-managed encryption is sufficient.

Use AWS Managed Keys when:

  • You want easy integration with AWS services.
  • Automatic rotation is sufficient.
  • Basic auditing through CloudTrail is required.

Use Customer Managed Keys when:

  • Fine-grained access control is needed.
  • Compliance requires customer ownership.
  • Cross-account sharing is necessary.
  • Applications require dedicated encryption keys.
  • Enterprise governance is important.

Use Imported Key Material when:

  • Regulations require customer-generated keys.
  • Existing on-premises HSM infrastructure must be retained.
  • Bring Your Own Key (BYOK) policies are mandated.

Architect’s Corner

A common misconception is that Customer Managed Keys are always the best choice.

In reality, the best key type depends on your requirements:

  • A startup storing public website assets may be perfectly served by AWS Owned Keys.
  • A development environment can often rely on AWS Managed Keys for simplicity.
  • A financial institution handling payment data will likely require Customer Managed Keys to meet compliance and auditing requirements.
  • A government agency with strict key ownership mandates may need Imported Key Material (BYOK).

Choosing the simplest solution that satisfies your security and compliance requirements is often the best architectural decision.


메타데이터
post_id
df5bbc4fdb8e
slug
aws-security-explained-aws-kms-deep-dive-key-management-and-encryption-keys-df5bbc4fdb8e
url
https://medium.com/@satyavarssheni/aws-security-explained-aws-kms-deep-dive-key-management-and-encryption-keys-df5bbc4fdb8e
canonical_url
https://medium.com/@satyavarssheni/aws-security-explained-aws-kms-deep-dive-key-management-and-encryption-keys-df5bbc4fdb8e
author_url
https://medium.com/@satyavarssheni
status
ok
fetched_at
2026-08-23 10:49:09