This chapter covers the three key management options for server-side encryption in AWS: AWS managed keys, customer managed keys, and customer provided keys. Understanding the differences is critical for the SAA-C03 exam, as encryption key management appears in about 10-15% of questions related to secure architectures. You will need to know which service uses which option, the level of control each provides, and the compliance and security implications. This chapter provides a deep dive into each option, including how they work under the hood, their IAM and key policy requirements, and common exam scenarios.
Jump to a section
Imagine you want to store a valuable item securely. You have three options: use a safe deposit box at a bank (AWS managed key), use the bank's vault with your own lock (customer managed key), or keep it in your own lockbox at home (customer provided key). With the safe deposit box, the bank owns the box and the key; you just tell them what to store and they handle everything—you trust their security, but you have no control over the key itself. With the bank vault plus your own lock, you bring your own padlock and key; the bank provides the vault room and security, but only you can open the lock. If you lose your key, the bank cannot help you open it. With your own lockbox at home, you have full control over the lock and the key, but you are responsible for the security of the entire box—if your house is burgled, the lockbox is gone. In AWS, these correspond to AWS managed keys (KMS keys created by AWS for services like S3 SSE-S3), customer managed keys (KMS keys you create and control, with policies and rotation), and customer provided keys (you supply the encryption key yourself, as in SSE-C for S3). Each offers a different balance of control, convenience, and responsibility.
What Are AWS Key Management Service Keys?
AWS Key Management Service (KMS) is a managed service that makes it easy to create and control encryption keys used to encrypt your data. KMS keys (formerly called customer master keys or CMKs) are the primary resource in KMS. They are logical representations of cryptographic keys that can be used for encryption, decryption, and signing operations. KMS keys never leave the AWS KMS hardware security modules (HSMs) unencrypted. They are stored and used only within the FIPS 140-2 validated HSMs.
AWS Managed Keys
AWS managed keys are KMS keys that are created, managed, and used on your behalf by an AWS service that is integrated with AWS KMS. These keys are created automatically when you first use a service that encrypts data with KMS, such as Amazon S3 (SSE-S3), Amazon EBS, Amazon RDS, or Amazon Redshift. The key alias is usually in the format aws/service-name, for example aws/s3 for S3 managed keys.
Control: You cannot view, manage, or rotate AWS managed keys. AWS manages the key material and the key policies. You cannot modify the key policy, schedule key deletion, or disable the key. You cannot use AWS managed keys for cryptographic operations directly; they are used only by the AWS service that created them.
Rotation: AWS manages the automatic rotation of AWS managed keys every year (365 days). You cannot change the rotation period.
Pricing: AWS managed keys are free of charge (no monthly fee). However, you pay for API calls to KMS (e.g., for encrypt/decrypt operations) if the service does not handle them transparently.
Use Cases: Best for customers who want encryption without needing to manage keys. Suitable for most compliance requirements where you do not need to control the key lifecycle.
Customer Managed Keys
Customer managed keys are KMS keys that you create, own, and manage. You have full control over these keys, including defining key policies, enabling and disabling the key, enabling automatic rotation (yearly by default but configurable), and scheduling deletion.
Control: You can create key policies that grant permissions to IAM users, roles, or AWS services. You can also use IAM policies in conjunction with key policies. You can tag the key, create aliases, and set a description.
Rotation: You can enable automatic rotation (once per year) or manually rotate the key by creating a new key and updating aliases. Automatic rotation is optional and can be enabled at creation or later.
Pricing: Each customer managed key costs $1/month (pro-rated per hour). Additionally, you pay for API calls to KMS (e.g., $0.03 per 10,000 requests for symmetric keys).
Use Cases: Required when you need to control the key lifecycle, enforce separation of duties (e.g., security team manages keys, developers use them), or meet compliance requirements that mandate customer-controlled keys.
Customer Provided Keys
Customer provided keys (also known as SSE-C for S3) are encryption keys that you supply yourself. AWS does not store the key; you provide it with each API call, and AWS uses it to encrypt or decrypt the data. After the operation, AWS discards the key. This option is available for Amazon S3 (SSE-C) and Amazon SQS (for server-side encryption using customer provided keys).
Control: You have full control over the key material. You must manage the key lifecycle, including generation, storage, rotation, and revocation. AWS never stores the key; you must provide it for every operation.
Rotation: You are responsible for rotating keys. AWS does not manage any aspect of the key.
Pricing: No additional KMS charges because you are not using KMS. However, you incur the cost of managing and storing keys securely (e.g., using AWS Secrets Manager or your own HSM).
Use Cases: When you need to maintain complete control over the encryption key and do not want AWS to have any access to the key material. Often used in regulated industries where the customer must hold the key.
How KMS Keys Work Internally
When you create a KMS key, AWS generates a cryptographic key pair (for asymmetric keys) or a symmetric key (256-bit AES-GCM) inside an HSM. The key material is encrypted under a root key that never leaves the HSM. The encrypted key material is stored in the KMS database, but it can only be decrypted inside the HSM when authorized operations are requested.
Key Policy: Every KMS key has a key policy that defines who can use and manage the key. The key policy is a resource-based policy attached directly to the key. For customer managed keys, you can also use IAM policies to grant access (if the key policy allows it). For AWS managed keys, the key policy is set by AWS and cannot be modified.
Grants: You can use grants to give temporary access to a KMS key without modifying the key policy. Grants are often used by AWS services (e.g., AWS Lambda) to access keys on your behalf.
Cryptographic Operations: When you call Encrypt, Decrypt, or GenerateDataKey, the request is sent to KMS. KMS verifies the caller has the necessary permissions (via key policy and IAM). If authorized, the HSM decrypts the key material and performs the operation. The plaintext key is never exposed to the caller for symmetric keys (except in GenerateDataKey where you get a plaintext data key and an encrypted copy).
Key Policies vs IAM Policies
Understanding the difference is critical for the exam.
- Key Policies: These are resource-based policies attached to the KMS key. They define who can manage the key and who can use it for cryptographic operations. For example, you can specify a principal (user, role, AWS service) and actions like kms:Decrypt, kms:Encrypt, kms:CreateGrant.
- IAM Policies: These are identity-based policies attached to IAM users, groups, or roles. They can grant permissions to KMS actions, but they only take effect if the key policy also allows the same permissions (i.e., the key policy must have a statement that allows IAM policies to grant access). By default, customer managed keys do not allow IAM policies to grant access unless you include a statement like:
{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::111122223333:root"},
"Action": "kms:*",
"Resource": "*"
}This statement gives the AWS account root user full access, and then IAM policies can further restrict permissions.
Envelope Encryption
KMS uses envelope encryption to encrypt data. When you encrypt data larger than 1 KB (the maximum KMS can encrypt directly with a KMS key is 1 MB, but for large data you use data keys), you generate a data key using the KMS key. The data key is used to encrypt your data (symmetric encryption), and then the data key itself is encrypted under the KMS key. This encrypted data key is stored alongside the encrypted data. When decrypting, you first decrypt the data key using KMS, then use the plaintext data key to decrypt the data.
GenerateDataKey: Returns a plaintext data key and an encrypted copy. Use the plaintext to encrypt data, then discard it. Store the encrypted data key.
GenerateDataKeyWithoutPlaintext: Returns only the encrypted data key. Use this when you want to generate a data key for future use but do not need to encrypt now.
Decrypt: Decrypts an encrypted data key (or any ciphertext up to 1 MB) using the KMS key.
Interaction with AWS Services
Different AWS services support different key management options. For the exam, you need to know which services offer which options.
Amazon S3:
SSE-S3: Uses AWS managed keys. No additional cost. Automatic rotation every year.
SSE-KMS: Uses customer managed keys (or AWS managed keys for S3). You can use your own KMS key. Supports envelope encryption. Additional cost for KMS API calls.
SSE-C: Customer provided keys. You supply the key with each request. AWS does not store the key.
Amazon EBS:
EBS encryption uses KMS. You can use either the AWS managed key for EBS (aws/ebs) or a customer managed key. You cannot use customer provided keys.
By default, EBS encryption uses the AWS managed key, but you can specify a customer managed key in the console or API.
Amazon RDS:
RDS encryption uses KMS. You can use the AWS managed key for RDS (aws/rds) or a customer managed key. You cannot use customer provided keys.
Encryption is enabled at database creation; you cannot encrypt an existing unencrypted database.
Amazon Redshift:
Redshift encryption uses KMS. You can use AWS managed key or customer managed key. Customer provided keys are not supported.
AWS Lambda:
Lambda environment variables can be encrypted using a customer managed key (or AWS managed key). You can also use customer provided keys via the AWS Encryption SDK, but not natively.
Amazon SQS:
SQS supports SSE with KMS (customer managed or AWS managed) and SSE with customer provided keys (SSE-C).
Amazon DynamoDB:
DynamoDB encryption at rest uses KMS. You can use AWS managed key or customer managed key. Customer provided keys are not supported.
Key Rotation
AWS Managed Keys: Automatically rotated every 365 days. You cannot disable or change this.
Customer Managed Keys: You can enable automatic rotation (once per year) or manually rotate. When you enable automatic rotation, KMS creates new cryptographic material for the key every year. The key ID, key ARN, and key policy remain the same. Old data encrypted with the previous key material can still be decrypted because KMS keeps the old key material (up to three previous versions).
Customer Provided Keys: No automatic rotation; you must rotate keys manually by generating a new key and re-encrypting data.
Deletion of KMS Keys
AWS Managed Keys: You cannot delete an AWS managed key. It is managed by the service.
Customer Managed Keys: You can schedule deletion of a customer managed key. The minimum waiting period is 7 days (default) and maximum 30 days. During the waiting period, the key is in "pending deletion" state and cannot be used for cryptographic operations. After the waiting period, KMS deletes the key material permanently. You cannot cancel deletion after the key is deleted.
Customer Provided Keys: Not stored by AWS, so no deletion process. If you lose the key, data cannot be decrypted.
Imported Key Material
For customer managed keys, you can import your own key material instead of letting KMS generate it. This is useful for hybrid scenarios where you want to use the same key on-premises and in AWS. You create a KMS key without key material, then download a wrapping key and import token. You encrypt your key material with the wrapping key and upload it to KMS. The key material is then stored in the HSM. You can delete the key material (but not the key) to disable the key temporarily.
Multi-Region Keys
KMS supports multi-region keys, which are KMS keys that can be replicated to other AWS regions. They have the same key ID and key material, so you can encrypt in one region and decrypt in another without cross-region calls. This is useful for disaster recovery and global applications.
Create a Customer Managed Key
Log in to the AWS Management Console, navigate to KMS, and click 'Create key'. Choose symmetric or asymmetric (symmetric is common for encryption). Provide an alias (e.g., 'my-app-key') and description. Under 'Key administrators', select IAM users/roles that can manage the key (e.g., modify key policy, enable/disable). Under 'Key users', select IAM users/roles that can use the key for cryptographic operations (e.g., encrypt/decrypt). You can also define a key policy directly. After creation, the key is active. You can enable automatic rotation by editing the key configuration. Note that you cannot change the key material once created; you would need to create a new key.
Use the Key with an AWS Service
When configuring an AWS service like S3 bucket encryption, select 'SSE-KMS' and choose your customer managed key from the list. The service will call KMS to generate a data key using your KMS key. The data key encrypts the object, and the encrypted data key is stored with the object. When reading the object, the service calls KMS to decrypt the data key, then uses the plaintext data key to decrypt the object. All KMS API calls are logged in CloudTrail. Ensure the service role (e.g., S3's service role) has permission to use the key via the key policy or grants.
Monitor and Audit Key Usage
Enable CloudTrail to log all KMS API calls. You can view events like CreateKey, Encrypt, Decrypt, GenerateDataKey. Use CloudTrail Insights to detect unusual patterns. You can also use AWS Config rules to monitor that keys have automatic rotation enabled or that key policies comply with your security standards. For customer managed keys, you can view the key policy in the KMS console and see which principals have access. Use IAM Access Analyzer to identify keys shared with external accounts.
Rotate the Key
For customer managed keys, you can enable automatic rotation in the key configuration. KMS will automatically generate new cryptographic material every year. The old material is retained for decryption of existing data. If you need to rotate more frequently, you can manually create a new key and update your application to use the new key alias. For AWS managed keys, rotation is automatic and cannot be changed. For customer provided keys, you must generate a new key and re-encrypt all data with the new key.
Schedule Key Deletion
To delete a customer managed key, go to the KMS console, select the key, and choose 'Schedule key deletion'. You must set a waiting period between 7 and 30 days. During this period, the key status is 'Pending deletion'. You cannot use the key for any cryptographic operations. If you change your mind, you can cancel deletion within the waiting period. After the waiting period, KMS deletes the key material permanently. Data encrypted with that key becomes unrecoverable. AWS managed keys cannot be deleted.
Enterprise Scenario 1: PCI DSS Compliance for a Payment Processing Platform
A financial services company processes credit card transactions and must comply with PCI DSS. They need to control the encryption keys used to protect cardholder data. They choose customer managed keys in KMS because they require the ability to rotate keys every 90 days (more frequently than the default 365 days) and to enforce that only specific security administrators can manage the keys. They create a key policy that grants the security team full management permissions and the application team only the ability to use the key for encrypt/decrypt operations. They enable CloudTrail to log all key usage and set up CloudWatch alarms for any unauthorized attempts. They also use automatic rotation, but they manually rotate the key every quarter by creating a new key and updating the application to use the new alias. This ensures that even if a key is compromised, the exposure window is limited. A common misconfiguration is forgetting to update the key policy when adding new application roles, which causes decryption failures in production.
Enterprise Scenario 2: Multi-Tenant SaaS Application with Customer Provided Keys
A SaaS provider offers a document storage service where customers want to retain full control over their encryption keys. The provider uses Amazon S3 with SSE-C. Each customer provides their own AES-256 key when uploading and downloading documents. The provider never stores the keys; they are passed in the HTTP headers (x-amz-server-side-encryption-customer-key) and are immediately discarded after the operation. The provider uses AWS Secrets Manager to securely store the keys on behalf of customers, but the keys are encrypted at rest and only decrypted in memory for the duration of the request. This approach satisfies customers who require that no third party, including the cloud provider, has access to the key. However, if a customer loses their key, the data is unrecoverable. The provider must implement a key escrow or backup mechanism (e.g., storing a copy of the key in a separate region encrypted with a different key). Performance is a consideration because the key must be provided with every request, adding latency. The provider also uses S3 multipart uploads, which require the key to be provided for each part.
Enterprise Scenario 3: Hybrid Cloud with Imported Key Material
A large enterprise runs a hybrid infrastructure with on-premises and AWS workloads. They have an existing key management system (e.g., an HSM) and want to use the same key material in both environments to avoid re-encrypting data. They create a customer managed KMS key with no key material, then import their own key material from their on-premises HSM. They use the wrapping key and import token provided by KMS to securely upload the key material. Now they can encrypt data on-premises with the same key and decrypt it in AWS, or vice versa. This allows seamless data sharing without cross-environment key exchange. However, they must ensure that the imported key material is protected during transit and that the on-premises HSM is FIPS 140-2 validated. A common pitfall is failing to properly protect the wrapping key and import token, which could allow an attacker to replace the key material.
What the SAA-C03 Tests
The exam focuses on your ability to choose the correct key management option for a given scenario. You will see questions that describe a compliance requirement (e.g., 'The company must rotate keys every 90 days and control who can manage the keys') and you must select the appropriate option: customer managed key (since AWS managed keys cannot be rotated more frequently than yearly and you cannot control management). Another common objective is understanding the difference between key policies and IAM policies. The exam objective code is Domain 1: Secure Architectures, Objective 1.2: 'Choose the right encryption key management solution.'
Common Wrong Answers
Choosing AWS managed keys when customer managed keys are required: Candidates often pick AWS managed keys because they are free and easier. However, if the scenario requires control over key rotation, key policy, or key deletion, AWS managed keys are insufficient. AWS managed keys cannot be modified, rotated on demand, or deleted.
Thinking customer provided keys are stored by AWS: Some candidates believe SSE-C means AWS stores the key. In reality, AWS does not store the key; you provide it with each request. This is a common trap. The exam might ask: 'Which option allows the customer to retain full control over the encryption key and not have it stored by AWS?' Answer: SSE-C (customer provided key).
Confusing KMS key policies with IAM policies: A typical question: 'An IAM policy allows a user to perform kms:Decrypt, but the user gets an AccessDenied error. Why?' The answer is that the key policy does not allow IAM policies to grant access (the default for customer managed keys is that the key policy must explicitly allow the root user, and then IAM policies can grant permissions). Many candidates think IAM policies are sufficient, but they are not unless the key policy allows it.
Assuming all services support all key options: For example, EBS does not support customer provided keys (SSE-C). Only S3 and SQS support SSE-C. The exam may ask about encrypting EBS volumes with a customer provided key; the correct answer is that it is not possible.
Specific Numbers and Terms
Rotation period: AWS managed keys rotate every 365 days (1 year). Customer managed keys can rotate automatically every year or manually.
Key deletion waiting period: 7 to 30 days for customer managed keys.
Maximum KMS encrypt size directly: 1 MB (for a single Encrypt call). For larger data, use envelope encryption with GenerateDataKey.
Cost: Customer managed key: $1/month per key. API calls: $0.03 per 10,000 requests (symmetric).
Key alias format: aws/service-name for AWS managed keys; any custom alias for customer managed keys.
Edge Cases
Imported key material: You can import your own key material, but you cannot export it. If you lose the key material, you cannot recover it. The exam may ask: 'Which feature allows you to use your own key material in KMS?' Answer: Import key material.
Multi-Region keys: These are replicated keys with the same key ID and material across regions. Useful for global applications. The exam may test that you can encrypt in one region and decrypt in another without cross-region API calls.
Key policies for cross-account access: To allow a user from another account to use your KMS key, you must specify the external account principal in the key policy. IAM policies in the external account are not sufficient alone.
How to Eliminate Wrong Answers
If the scenario mentions 'control over key rotation' or 'separation of duties', eliminate AWS managed keys.
If the scenario says 'AWS does not store the encryption key', eliminate all KMS options and choose SSE-C.
If the scenario involves EBS or RDS encryption, eliminate SSE-C because it is not supported.
If the question is about cost, remember that AWS managed keys are free (no monthly fee), but you still pay for API calls if applicable. Customer managed keys have a monthly fee.
If the question mentions 'key policy' and 'IAM policy', check whether the key policy allows IAM policies. The default does not.
AWS managed keys are free, automatically rotated yearly, and cannot be controlled by the customer.
Customer managed keys cost $1/month each, offer full control, and support automatic or manual rotation.
Customer provided keys (SSE-C) are not stored by AWS; you must supply the key with each request.
Key policies are resource-based; IAM policies are identity-based. Both must allow access for a user to use a customer managed key.
Only S3 and SQS support customer provided keys (SSE-C); EBS, RDS, and DynamoDB do not.
KMS can encrypt up to 1 MB directly; for larger data, use GenerateDataKey for envelope encryption.
Deletion of a customer managed key requires a waiting period of 7 to 30 days; after deletion, data is unrecoverable.
Imported key material allows you to use your own key in KMS, but it cannot be exported.
Multi-region keys have the same key ID and material across regions, enabling cross-region encryption without KMS calls.
AWS managed keys have aliases like aws/s3; customer managed keys have custom aliases.
These come up on the exam all the time. Here's how to tell them apart.
AWS Managed Keys
Created and managed by AWS services automatically.
Cannot be viewed, modified, or deleted by customer.
Automatic rotation every 365 days, cannot be changed.
No monthly cost; pay only for API calls if applicable.
Key policy is set by AWS and cannot be modified.
Customer Managed Keys
Created and managed by the customer via KMS.
Full control: enable/disable, schedule deletion, modify key policy.
Automatic rotation optional (once per year) or manual rotation.
Monthly cost: $1 per key per month plus API call charges.
Key policy is fully customizable; can allow IAM policies or cross-account access.
Customer Managed Keys (KMS)
Key stored and managed in AWS KMS HSMs.
Can be used with many AWS services (S3, EBS, RDS, etc.).
Supports automatic rotation and key policies.
Cost: $1/month per key + API calls.
Key can be used for envelope encryption with data keys.
Customer Provided Keys (SSE-C)
Key not stored by AWS; provided with each request.
Only supported by S3 and SQS.
No rotation management; customer handles key lifecycle.
No KMS charges; customer bears key management cost.
No envelope encryption; key used directly on data (max 1 MB per request).
Mistake
AWS managed keys can be deleted by the customer.
Correct
AWS managed keys cannot be deleted; they are managed entirely by AWS. Only customer managed keys can be scheduled for deletion (with a waiting period of 7 to 30 days).
Mistake
Customer provided keys (SSE-C) are stored by AWS and can be retrieved later.
Correct
AWS does not store customer provided keys. You must provide the key with each API call. If you lose the key, the data cannot be decrypted.
Mistake
IAM policies alone can grant access to a customer managed key without any key policy configuration.
Correct
By default, customer managed keys do not allow IAM policies to grant access. The key policy must include a statement that allows the account root user, and then IAM policies can grant permissions to specific users/roles.
Mistake
All AWS services support customer provided keys (SSE-C).
Correct
Only Amazon S3 and Amazon SQS support SSE-C. Services like EBS, RDS, and DynamoDB do not support customer provided keys.
Mistake
Automatic rotation for customer managed keys can be set to any interval.
Correct
Automatic rotation for customer managed keys can only be set to once per year (365 days). If you need more frequent rotation, you must manually rotate the key by creating a new key and updating aliases.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AWS managed keys are created and managed by AWS services on your behalf. You cannot control their lifecycle, rotation, or policies. Customer managed keys are created by you and give you full control over key policies, rotation, deletion, and usage. Customer managed keys cost $1/month per key, while AWS managed keys are free. For compliance requirements that demand control, use customer managed keys.
No. Amazon EBS encryption only supports KMS keys (either AWS managed or customer managed). SSE-C is only supported by Amazon S3 and Amazon SQS. For EBS, you must use a KMS key.
First, modify the key policy to allow the AWS account root user (or a specific principal) to delegate permissions via IAM. For example, add a statement with "Principal": {"AWS": "arn:aws:iam::111122223333:root"} and "Action": "kms:*". Then, attach an IAM policy to the user that grants the necessary KMS actions (e.g., kms:Decrypt, kms:Encrypt). Without the key policy allowing IAM policies, the IAM policy alone is insufficient.
Data encrypted with that key becomes permanently unrecoverable. AWS does not store the key. You must keep a secure copy of the key (e.g., in AWS Secrets Manager or an on-premises HSM). If you lose the key, there is no way to decrypt the data. Always implement a key backup strategy.
When you enable automatic rotation, KMS generates new cryptographic material for the key once per year. The key ID, ARN, and policy remain unchanged. Old key material is retained so that data encrypted with previous material can still be decrypted. KMS keeps up to three previous versions of the key material. You cannot change the rotation interval; it is always 365 days.
No. AWS managed keys are owned and managed by AWS services. You cannot delete, disable, or modify them. If you want control over deletion, you must use a customer managed key.
The maximum size for a single Encrypt or Decrypt call is 1 MB. For larger data, you must use envelope encryption: call GenerateDataKey to get a data key, encrypt your data with that data key, and store the encrypted data key alongside the data.
You've just covered Customer Managed Keys vs AWS Managed Keys vs Customer Provided — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?