AWS Services
AWS Key Management Service
Understand AWS KMS for key management, envelope encryption, key policies, grants, service integrations, auditability, and SAA-C03 encryption decisions.
After this, you will understand
KMS is the difference between saying data is encrypted and knowing who can use the key that makes decryption possible.
KMS lets AWS services and applications use managed cryptographic keys without exposing raw key material.
Learners think S3 or RDS encryption is only a checkbox and forget that key policy, IAM, grants, and audit logs decide usable access.
Choose the key type, control key usage separately from data access, and verify both IAM and key policy paths for decrypt operations.
Think before readingWhy can someone have S3 permission but still fail to read an encrypted object?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- AWS KMS
- KMS keys
- AWS managed and customer managed keys
- Key policies
- IAM permissions
- Grants
- Envelope encryption
- Rotation
- Cross-account key use
- CloudTrail auditing
1. Plain-English Mental Model
AWS Key Management Service, or KMS, is managed key control for encryption and signing.
Many AWS services can encrypt data. KMS is where you control the keys those services use, who can administer those keys, who can use those keys, and how key usage is audited.
The simple model is:
data access + KMS key use = successful decrypt
If an S3 object is encrypted with a KMS key, permission to read the object is not always enough. The caller also needs permission to use the KMS key. If an EBS volume, RDS database, CloudTrail log, or Secrets Manager secret uses a KMS key, the key policy and IAM permissions become part of the access path.
KMS is not a place where you usually download raw keys and manually encrypt everything. Most AWS architectures use KMS through service integrations and envelope encryption.
2. Why This Service Exists
Encryption creates a second security question beyond data location.
Where is the data stored? Who can read the data? Who can use the key that decrypts the data? Who can rotate the key? Who can disable it? Who can audit its use?
Without a managed key service, teams may store encryption keys in code, configuration files, databases, or human-run secret stores. That creates dangerous key exposure and weak auditability.
KMS exists to centralize key management, integrate with AWS services, enforce key policies, support rotation, and record key usage through CloudTrail.
For SAA-C03, KMS appears whenever a question mentions encryption at rest, customer-managed keys, key rotation, cross-account decryption, CloudTrail log encryption, S3 SSE-KMS, EBS encryption, RDS encryption, or separation between key administrators and key users.
3. The Naive Approach And Where It Breaks
The naive approach is to treat encryption as a checkbox:
enable encryption -> done
That breaks when access fails because the key policy does not allow the principal, when a cross-account reader cannot decrypt, when a disabled key makes data inaccessible, or when administrators and users are not separated.
Another naive approach is to store application encryption keys directly in environment variables. If the application is compromised, the key is compromised. Rotation becomes manual. Audit is weak.
Another mistake is making every principal a key administrator. A key administrator can change key policy or disable keys. That is different from a key user who only needs encrypt and decrypt.
KMS is about controlled key use, not just encrypted storage.
4. Core Primitives
A KMS key is the logical key resource in KMS. It can be symmetric or asymmetric depending on use case. Most service encryption integrations use symmetric KMS keys.
AWS managed keys are created and managed by AWS for a service in your account. Customer managed keys are created and controlled by you. Customer managed keys give more control over policy, rotation, aliases, and lifecycle.
A key policy is the primary resource policy for a KMS key. IAM policies can also allow key use, but the key policy must allow the account or principal path.
Grants are permissions for key use, often used by AWS services for temporary or scoped access.
Envelope encryption means data is encrypted with a data key, and the data key is encrypted under a KMS key. This avoids sending large data payloads to KMS.
Aliases are friendly names for keys, such as alias/app-prod.
5. Architecture Use Cases
Use KMS to encrypt S3 objects with SSE-KMS when you need customer-managed key control or auditability beyond S3-managed keys.
Use KMS with EBS, RDS, EFS, DynamoDB, CloudTrail, Secrets Manager, SQS, SNS, and many other AWS services.
Use customer managed keys when you need control over key policy, rotation, cross-account access, or separation of administrative duties.
Use key policies to allow a central logging service to encrypt CloudTrail logs and allow security analysts to decrypt them.
Use KMS for application-level envelope encryption only when service-level encryption is not enough or the app must encrypt before storing data.
Do not choose KMS as a general secret store. Secrets Manager or Parameter Store usually stores secret values; KMS protects encryption keys.
7. Security Model
KMS security is policy-heavy.
The key policy controls who can administer and use the key. IAM identity policies can grant KMS permissions only when the key policy allows that access path.
Separate key administrators from key users. Administrators manage policy and lifecycle. Users encrypt, decrypt, generate data keys, or sign depending on key type.
Watch explicit deny and cross-account access. A role can have S3 read access and still fail if KMS denies decrypt.
Use CloudTrail to audit KMS API calls. KMS integrates with CloudTrail so key usage can be investigated.
Be careful disabling or scheduling deletion of keys. If data depends on that key, losing key access can mean losing data access.
8. Reliability And Resilience
KMS is a regional service. Keys are regional unless using multi-Region keys for supported scenarios.
If a KMS key is disabled, scheduled for deletion, or inaccessible due to policy changes, services depending on that key can fail to decrypt data.
For cross-Region disaster recovery, consider how encrypted backups and replicas will be decrypted in the target Region. Snapshot copy often involves destination Region keys.
Key rotation can improve security posture, but understand whether rotation changes only backing key material or requires re-encrypting data for the service and key type.
Avoid single-person key administration. Use controlled roles and break-glass paths.
9. Performance And Scaling
Most service integrations handle KMS calls for you, but high-volume direct KMS usage can hit quotas or add latency.
Envelope encryption reduces KMS usage because the service or client encrypts data locally with data keys and uses KMS to protect data keys.
For application encryption, cache data keys carefully only when the security model allows it. Do not cache sensitive material casually.
KMS latency is usually not the dominant factor for normal service encryption, but it can matter in custom high-throughput encryption paths.
Monitor throttling and errors if the application calls KMS directly.
10. Cost Model
KMS cost includes customer managed key monthly charges and API request charges. AWS managed keys have different pricing characteristics.
High-volume services using SSE-KMS can create significant KMS request cost if every object operation requires KMS usage.
Multi-Region keys and custom key stores can add cost and operational complexity.
Cost should not drive you to remove encryption where the requirement needs it. Instead, choose the right key type and usage pattern.
Use S3 bucket keys where appropriate to reduce KMS request costs for S3 SSE-KMS workloads.
12. SAA-C03 Exam Signals
"Customer controls key rotation or policy" points to customer managed KMS keys.
"S3 object encrypted with SSE-KMS cannot be read" often points to missing KMS decrypt permission.
"Encrypt CloudTrail logs" points to KMS key policy allowing CloudTrail delivery and authorized readers.
"Separate key administrators from key users" points to key policy and IAM separation.
"Cross-account access to encrypted data" requires both data resource access and KMS key access.
"Audit key usage" points to CloudTrail logs for KMS actions.
13. Common Exam Traps
Do not assume data access implies key access.
Do not confuse Secrets Manager with KMS. Secrets Manager stores secret values; KMS protects keys used for encryption.
Do not grant key administrator permissions to every application role.
Do not delete or disable a key without understanding dependent data.
Do not forget KMS permissions when copying encrypted snapshots or sharing encrypted resources across accounts.
Do not treat encryption as only a storage checkbox. Key policy is part of architecture.
15. Related Topics
Review Identity Policies vs Resource Policies, Amazon S3, and Secure Cross-Account CloudTrail Logging.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.