11.1 AWS KMS Architecture, Key Policies & Key Types

11.1 AWS KMS Architecture, Key Policies & Key Types

Data protection in the cloud requires cryptographic security, strict authorization controls, and auditable governance. AWS Key Management Service (AWS KMS) provides a fully managed, centralized service for creating, controlling, and auditing cryptographic keys. The foundation of AWS KMS is built upon dedicated Hardware Security Modules (HSMs) validated under the FIPS 140-2 (and FIPS 140-3) Cryptographic Module Validation Program at Security Level 3 for cryptographic operations and physical tamper resistance.

Securing workloads on AWS demands a granular understanding of the KMS key hierarchy, symmetric versus asymmetric cryptographic algorithms, key policy grammar, administrative segregation of duties, and lifecycle deletion safeguards.

---

AWS KMS Key Hierarchy & Ownership Models

AWS KMS provides three distinct tiers of cryptographic keys. Understanding the operational, financial, and access boundaries of each tier is essential for enterprise security architecture.

AWS Owned Keys

AWS owned keys are a collection of KMS keys that an AWS service owns and manages for use in multiple AWS accounts. These keys are not in your AWS account, do not appear in your KMS console, and do not emit events to your AWS CloudTrail log streams. You do not pay for the storage or use of AWS owned keys. For example, Amazon DynamoDB encrypts tables with an AWS owned key by default, and Amazon SQS SSE-SQS uses keys owned by the SQS service.

AWS Managed Keys

AWS managed keys are created automatically in your account when you first select encryption using an AWS managed key in an integrated service. These keys feature the reserved alias prefix aws/, such as aws/s3, aws/ebs, or aws/rds.

• Cost Efficiency: You incur no monthly storage fee for AWS managed keys, paying only for API requests exceeding the AWS Free Tier.
• Governance Limitations: You cannot modify the key policy, create grants on the key directly, attach custom tags, or delete the key. Furthermore, AWS managed keys cannot be shared across AWS accounts. If Account B needs to decrypt S3 objects or EBS snapshots originating from Account A, using aws/s3 or aws/ebs will fail immediately because cross-account trust cannot be added to an AWS managed key policy.

Customer Managed Keys (CMKs)

Customer managed keys are KMS keys that you create, own, and manage within your AWS account.

• Granular Access Control: You maintain total control over key policies, IAM policies, and cryptographic grants.
• Lifecycle & Rotation: You decide whether to enable automatic key rotation, when to disable keys, and when to schedule key deletion.
• Enterprise Compliance: CMKs are required for cross-account resource access, specialized encryption context enforcement, and compliance frameworks that mandate customer-controlled cryptographic ownership and separation of duties.

Exam Tip: Whenever an exam question describes cross-account access to encrypted data (such as copying encrypted AMI snapshots or sharing an encrypted S3 bucket between AWS Organizations accounts), the correct solution always requires a Customer Managed Key (CMK). AWS managed keys can never be shared across account boundaries.

---

Cryptographic Key Types: Symmetric vs Asymmetric vs HMAC

AWS KMS supports three primary cryptographic architectures: symmetric encryption keys, asymmetric key pairs, and Hash-Based Message Authentication Code (HMAC) keys.

Loading diagram...

Symmetric Encryption Keys

Symmetric keys represent the standard workhorse of AWS KMS. A symmetric key contains a single 256-bit secret key encrypted and protected inside the HSM. In AWS KMS, symmetric encryption utilizes the Advanced Encryption Standard (AES) algorithm in Galois/Counter Mode (GCM) with 256-bit keys (AES_256_GCM).

• Zero Plaintext Key Exposure: The unencrypted key material never leaves the FIPS-validated HSM boundary under any circumstance.
• Direct Payload Constraint: Direct cryptographic calls (kms:Encrypt, kms:Decrypt, kms:ReEncrypt) support a maximum payload size of 4,096 bytes (4 KB). To encrypt larger payloads (such as databases, media files, or disk volumes), systems must utilize envelope encryption.
• Automatic Key Rotation: Symmetric CMKs with KMS key material natively support automatic key rotation. When enabled, KMS automatically creates a new cryptographic key backing material every 365 days (or on a customer-configured schedule between 90 and 2,560 days) while preserving the key ID, ARN, aliases, and permissions. KMS retains all historical backing keys indefinitely to allow seamless decryption of older ciphertexts without manual intervention.

Asymmetric Key Pairs

Asymmetric KMS keys represent an mathematically linked public and private key pair generated inside a KMS HSM.

• Supported Algorithms: RSA key pairs (2048, 3072, and 4096-bit key sizes) and Elliptic Curve (ECC) key pairs (NIST curves P-256, P-384, P-521, and SECG secp256k1).
• Key Usage Modes: When creating an asymmetric key, you must explicitly declare its usage mode: either ENCRYPT_DECRYPT or SIGN_VERIFY. A single asymmetric key cannot perform both functions.
• Public Key Exportability: While the private key never leaves the KMS HSM, the public key can be downloaded and exported using the kms:GetPublicKey API call. External clients, mobile applications, and on-premises partners can use the public key locally outside AWS to encrypt data or verify digital signatures without making API calls to AWS KMS.
• No Automatic Rotation: Asymmetric keys do not support automatic key rotation. Because the public key is distributed externally, rotating the underlying key material would break verification and encryption for all distributed public keys. To rotate an asymmetric key, you must create a new KMS key, update application configurations, and update any associated KMS aliases.

HMAC Keys

HMAC keys are symmetric keys of varying lengths (224, 256, 384, or 512 bits; key specs HMAC_224 through HMAC_512) used to generate and verify hash-based message authentication codes (kms:GenerateMac and kms:VerifyMac) using the SHA-2 family of hash functions (HMAC-SHA224, SHA256, SHA384, SHA512). HMAC keys do not encrypt data; they verify data integrity and authenticate callers in REST APIs, webhooks, and JSON Web Tokens (JWTs).

---

Key Policies as the Primary Access Control Mechanism

In AWS IAM, identity-based policies (attached to users, groups, or roles) control access to most AWS resources. However, AWS KMS enforces a fundamentally different authorization model: Key Policies are the primary access control mechanism. Every KMS key must have exactly one key policy attached directly to it.

Critical Core Principle: Identity-based IAM policies cannot grant access to an AWS KMS key unless the key policy explicitly authorizes the IAM identity OR explicitly delegates authorization to the AWS account root principal.

Loading diagram...

The Account Root Delegation Statement

The most misunderstood statement in AWS KMS key governance is the default account root delegation statement:

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:root"
  },
  "Action": "kms:*",
  "Resource": "*"
}

Deciphering arn:aws:iam::ACCOUNT_ID:root

In an IAM or KMS policy, the principal arn:aws:iam::ACCOUNT_ID:root does not refer exclusively to the literal AWS root user account credentials. Instead, it represents the AWS Account Entity itself.

• When this statement is present in the key policy, KMS delegates authority over the key to the account's IAM administrator. This enables identity-based IAM policies, IAM permission boundaries, and Organizations Service Control Policies (SCPs) to grant or restrict access to the key.
• If this statement is omitted or removed from a custom key policy, IAM policies have zero effect on the key. Only the specific IAM principals explicitly enumerated in the key policy can perform KMS actions on that key. Even an IAM administrator with full AdministratorAccess (*:*) will receive an AccessDeniedException if they are not explicitly named in the key policy.

Segregation of Duties: Key Administrators vs Key Users

Enterprise governance frameworks mandate strict separation between the administrative personnel who manage cryptographic keys and the application workloads or users who use those keys to encrypt and decrypt sensitive data.

{
  "Version": "2012-10-17",
  "Id": "Production-CMK-Policy",
  "Statement": [
    {
      "Sid": "EnableAccountRootDelegation",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowKeyAdministration",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/SecurityKeyAdminRole"
      },
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:TagResource",
        "kms:UntagResource",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowCryptographicOperations",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/PaymentProcessingAppRole"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }
  ]
}

In this policy architecture:

1. Key Administrators can alter key state, manage tags, view metadata, and schedule deletion, but they cannot invoke kms:Encrypt or kms:Decrypt. They have zero capability to decrypt business data.
2. Key Users (Application Roles) can encrypt and decrypt data, but they cannot modify the key policy, grant permissions to other entities, or schedule the key for deletion.

The Risk of Permanent Key Lockout

If you author a custom key policy that omits the account root delegation statement and accidentally delete or misconfigure the IAM principals named in the policy, the key becomes unmanageable. If no IAM principal has kms:PutKeyPolicy permissions, no user in the account can modify the key. The account root user gets no special access to a KMS key unless the key policy allows it, so in this scenario you must contact AWS Support to regain control. Keep the default root delegation statement, or name at least one reliable key administrator, to avoid this.

---

Key Deletion Safeguards & Lifecycle States

Cryptographic key destruction is irreversible. If a KMS key is deleted, any data encrypted under that key—including Amazon EBS volumes, Amazon RDS databases, Amazon S3 objects, and cold Glacier archives—becomes permanently undecryptable.

To prevent catastrophic data loss from accidental commands, malicious insiders, or compromised automated scripts, AWS KMS strictly prohibits immediate key deletion for KMS-generated key material.

Loading diagram...

kms:ScheduleKeyDeletion and the Mandatory Waiting Period

When a key administrator requests key deletion using the kms:ScheduleKeyDeletion API, AWS KMS enforces a mandatory waiting period:

• Configurable Window: You must specify a waiting period between 7 and 30 days (the default value is 30 days).
• Immediate State Transition: The key immediately transitions from Enabled or Disabled into the PendingDeletion state.
• Cryptographic Freeze: While in PendingDeletion, the key is immediately unusable for all cryptographic operations. Any attempt to invoke kms:Encrypt, kms:Decrypt, or kms:GenerateDataKey fails with a KMSInvalidStateException.

Emergency Recovery: kms:CancelKeyDeletion

During the configured waiting period, if the deletion was initiated in error or if operational dependencies are discovered during testing:

1. An authorized key administrator invokes the kms:CancelKeyDeletion API call.
2. The key transitions from PendingDeletion to the Disabled state.
3. The administrator verifies the key configuration and invokes kms:EnableKey to return the key to production service.

Proactive Alerting on Deletion Requests

Enterprise security operations centers (SOCs) must configure automated alerts whenever ScheduleKeyDeletion is invoked. An Amazon EventBridge rule matching the following pattern captures the event in real time and routes alerts to Amazon SNS and automated ticketing workflows:

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["kms.amazonaws.com"],
    "eventName": ["ScheduleKeyDeletion"]
  }
}

---

Specialty Exam Pitfalls & Architectural Traps

1. The AdministratorAccess Fallacy: An IAM role possessing the AWS-managed AdministratorAccess policy ("Action": "*", "Resource": "*") cannot manage or use a KMS key if the key policy omits the account root delegation statement and does not list the role. In KMS, resource policies override identity policies unless root delegation is explicitly configured.
2. Automatic Rotation on Asymmetric Keys: Exam scenarios frequently suggest enabling automatic rotation on an asymmetric RSA or ECC signing key to fulfill a compliance mandate. This is technically impossible in KMS. Automatic rotation is exclusively supported for symmetric keys. Asymmetric key rotation requires manual key creation and alias repointing.
3. Attempting Cross-Account Access with AWS Managed Keys: An architectural scenario may ask how to share an encrypted S3 bucket in Account A with an analytics worker in Account B using aws/s3. This will never work. The aws/s3 key policy cannot be modified to trust Account B. The customer must migrate the S3 bucket encryption to a Customer Managed Key (CMK).
4. Immediate Key Deletion Requests: Questions testing incident response often feature an auditor or manager demanding the immediate deletion of an compromised KMS key. KMS cannot delete standard keys immediately; the absolute minimum deletion waiting period is 7 days.