Why use KMS?

1. Security: Keys never leave AWS hardware.
2. Compliance: Meets manycompliance requirements (FIPS 140-2, HIPAA, GDPR).
3. Simplicity: Integrates with AWS services out of the box.

Key Features

1. Key Creation: Create symmetric or asymmetric keys, either customer managed or AWS managed.
2. Encryption: Encrypt data directly or use envelope encryption (encrypting data keys).
3. Integration: Works seamlessly with AWS services like S3, EBS, RDS, Lambda, and Redshift.
4. Access Control: Control access using IAM policies and KMS key policies.
5. Audit Logging: Monitor key usage through detailed logs in AWS CloudTrail.
6. Automatic Rotation: Supports automatic key rotation every year for customer-managed keys (CMKs).

List of Encryptions

Symmetric vs. Asymmetric Encryption

1. Symmetric Keys (default): Same key for encryption & decryption. This type of encryption is faster and better suited for bulk encryption.
2. Asymmetric Keys: Key pair — public for encryption, private for decryption or signing. This type is slower, typically used for identity verification or key exchange.

KMS Key Deletion

1. Destructive Action: Once deleted, a KMS key cannot be recovered.
2. Waiting Period: Must be scheduled for deletion with a 7 to 30 days wait time (default: 30 days).
3. During Waiting: Key status is **PendingDeletion**.
4. Cancel Option: You can cancel deletion during the waiting period.
5. After Waiting Period: Key is permanently deleted and unusable.

Server-Side Encryption (SSE) in AWS

Server-Side Encryption (SSE) is the process where AWS encrypts data at rest — after receiving it and before storing it — and decrypts it for authorized access, all handled on the server side by AWS.

AWS supports multiple types of server-side encryption, depending on the service and key management model.

1. SSE with AWS-Owned Keys
2. SSE with AWS KMS
3. SSE-S3 (S3-Managed Keys)
4. SSE-C (Customer-Provided Keys)

1. SSE with AWS-Owned Keys

1. Fully managed AWS — customers don’t see, manage, or control the encryption keys.
2. No key rotation, no access policies, and no audit logs for encryption key usage.
3. Used by default in many AWS services like DynamoDB, RDS, EBS,Redshift.
4. Encryption is automatic with zero configuration required.
5. When to Use It?
   • Require encryption at rest enabled with zero overhead
   • Not require key management, auditing, and compliance controls.
   • Ideal for internal apps or low-risk data

2. SSE-KMS (SSE with KMS)

1. Encryption keys managed through AWS KMS.
2. All key usage is logged in AWS CloudTrail for audit logs.
3. Supports key rotation for CMKs (automatically if enabled).
4. Additional charges for KMS API usage (e.g., Encrypt, Decrypt, GenerateDataKey).
5. Supported by AWS services like S3, EBS, RDS, DynamoDB, Redshift.
6. Supports both subtypes:
   1. AWS-managed KMS keys - Created and fully managed by AWS for customer.
   2. Customer-managed CMKs - Created and controlled by customer in AWS KMS.
7. When to Use It?
   1. Need compliance with regulations (e.g., HIPAA, PCI-DSS, FedRAMP).
   2. Require Auditing access to encryption keys.
   3. Need to centralize the control over key usage.
   4. Require automated or manual key rotation.
   5. Ideal for production systems, sensitive data, and enterprise security requirements.

3. SSE-S3 (SSE with S3-Managed Keys)

1. Specific to Amazon S3.
2. Amazon S3 encrypts each object using a unique key.
3. These keys are encrypted with a master key that is regularly rotated.
4. Key management is handled entirely by Amazon S3.
5. Encryption algorithm: AES-256
6. No extra cost beyond standard S3 storage.
7. No key rotation or CloudTrail logging available.
8. When to Use It?
   • When require basic encryption at rest without managing keys or audit trails.

4. SSE-C (SSE with Customer-Provided Keys)

1. Only available in S3.
2. Customer provides the encryption key with each request (upload/download).
3. AWS does not store or log the key.
4. No CloudTrail integration, and you handle all key rotation/loss issues.
5. When to Use It?
   • When you want to fully control the encryption keys and not rely on AWS key storage.

Note:

1. SSE-S3, SSE-KMS, and SSE-C are valid only within Amazon S3.
2. For other AWS services, AWS-owned keys, or SSE with KMS (either AWS- or customer-managed keys) are used.

Allowing users in other accounts to use a KMS key

To let users or roles in another AWS account use your KMS key, you need:

1. Key Policy (in the key owner's account)
   • Grants the external account ID or its IAM roles/users permission to use the KMS key (e.g., kms:Decrypt, kms:GenerateDataKey).
   • This is the primary control point for granting access.
2. IAM Policy (in the external account)
   • Grants the actual IAM users or roles in that external account the ability to use the key.
   • These permissions must match those allowed by the key policy.

Question: Key Policy Modifying External Accounts

A company recently signed a contract with an AWS Managed Service Provider (MSP) Partner for help with an application migration initiative. A solutions architect needs ta share an Amazon Machine Image (AMI) from an existing AWS account with the MSP Partner's AWS account. The AMI is backed by Amazon Elastic Block Store (Amazon EBS) and uses an AWS Key Management Service (AWS KMS) customer managed key to encrypt EBS volume snapshots. What is the MOST secure way for the solutions architect to share the AMI with the MSP Partner's AWS account?

1. Modify the launchPermission property of the AMI. Share the AMI with the MSP Partner's AWS account only. Modify the key policy to allow the MSP Partner's AWS account to use the key. (Correct Ans)
2. Modify the launchPermission property of the AMI. Share the AMI with the MSP Partner's AWS account only. Modify the key policy to trust a new KMS key that is owned by the MSP Partner for encryption.

Explanation

To securely share an EBS-backed AMI encrypted with a customer-managed KMS key, required two steps -

1. To Share the AMI, you must set the launchPermission of the AMI to allow the specific AWS account ID of the MSP partner.
2. Allow KMS key access: Since the EBS snapshot is encrypted with your customer-managed KMS key, you must update the key policy to allow KMS key access to the MSP partner’s AWS account to use the key.

This enables them to launch instances from the AMI using the encrypted snapshot.

Why Option 2 is incorrect?

"Modify the launchPermission property... Modify the key policy to trust a new KMS key that is owned by the MSP Partner for encryption."

This suggests switching to a KMS key that the MSP owns, which is not how AMI sharing works. You can’t re-encrypt an existing EBS snapshot using a third-party KMS key within the original account.

Question: Customer managed key by using AWS KMS

A company stores sensitive data in Amazon S3 A solutions architect needs to create an encryption solution. The company needs to fully control the ability of users to create, rotate, and disable encryption keys with minimal effort for any data that must be encrypted.

Which solution will meet these requirements?

1. Use default server-side encryption with Amazon S3 managed encryption keys (SSE-S3) to store the sensitive data
2. Create a customer managed key by using AWS Key Management Service (AWS KMS). Use the new key to encrypt the S3 objects by using server-side encryption with AWS KMS keys (SSE-KMS). (Correct Ans)
3. Create an AWS managed key by using AWS Key Management Service {AWS KMS) Use the new key to encrypt the S3 objects by using server-side encryption with AWS KMS keys (SSE-KMS).
4. Download S3 objects to an Amazon EC2 instance. Encrypt the objects by using customer managed keys. Upload the encrypted objects back into Amazon S3.

Explanation:

The key requirement is: “Fully control the ability of users to create, rotate, and disable encryption keys.” Based on this level of control is only possible with customer managed KMS keys — not AWS managed keys or default S3-managed keys.

If key control (create, rotate, disable) is a requirement, customer managed keys with SSE-KMS is the best and most secure solution.