How to design encryption on AWS? How to choose and implement KMS and encryption keys.

Amazon Web Services (AWS) offers data encryption capabilities across many services, including Amazon S3, Amazon EBS, and Amazon RDS. The design process involves identifying the data to be protected and selecting appropriate encryption methods for both storage and transit, as well as a method for managing the encryption keys.

When using AWS KMS, you should consider the differences between AWS-managed keys and customer-managed keys, as well as requirements such as permission management, rotation, and auditing.

This article explains everything from the initial decisions to make when designing encryption in AWS, to how to choose AWS KMS and encryption keys, and how to design and operate it using major services such as Amazon S3, Amazon EBS, and Amazon RDS.

What to decide first when designing your AWS encryption

AWS encryption design begins by clearly defining the data to be protected and the required security standards. Then, data is divided into data at rest and data in transit, and appropriate encryption methods are considered for each. AWS also recommends classifying data and considering encryption methods based on the data's state.

Organize the data to be protected and the security requirements.

First, we identify the data handled on AWS and classify it according to its importance and confidentiality. For customer information, personal information, authentication information, and confidential business data, we set protection levels based on the impact of any potential data breach.

We will also take into account internal security policies, laws and industry standards, and audit requirements. Conditions such as whether to manage encryption keys in-house, how restricting users will be, and whether key usage history will be tracked will influence AWS KMS key selection and permission design.

Different encryption methods are used for data being stored and data being transmitted.

Data to be encrypted can be broadly divided into two categories: "in storage" and "in transit."

The data stored includes objects in Amazon S3, volumes in Amazon EBS, and databases in Amazon RDS. It is protected using encryption features and AWS KMS provided by each AWS service.

Data in transit is data moving between users and AWS services or systems. HTTPS, TLS, and other protocols are used to prevent eavesdropping and tampering during communication.

The applicable method and key management approach will vary depending on the importance of the data, how it will be used, and the company's internal management requirements.

How to choose between AWS KMS and encryption keys

AWS KMS (AWS Key Management Service) allows you to manage KMS keys used for data encryption. The main factors to consider when selecting a KMS are who manages the keys and the scope of control required by the user. AWS KMS offers three types of keys: AWS-owned keys, AWS-managed keys, and customer-managed keys.

Differences between AWS-owned keys, AWS-managed keys, and customer-managed keys

The three keys offer different levels of control over what users can manage.

AWS-owned keys are managed by AWS and cannot be viewed or modified by the user.

AWS managed keys are KMS keys created and managed by AWS services within the user's account. For example, Amazon RDS uses managed keys. aws/rds While this is used, users cannot change or delete key policies.

Customer-managed keys are created and managed by the user. They can handle key policies, IAM policies, grant-based access control, enabling/disabling keys, rotation, and deletion.

Cases where a customer-managed key is required

Customer-managed keys are suitable when you want granular control over how a key is used. For example, you might want to allow only specific IAM roles to use a key, use it across multiple AWS accounts, or apply your own rotation policy.

This is also suitable when audits or internal regulations require specifying which users and roles can use and manage keys.

However, with customer-managed keys, the user is responsible for managing policies and lifecycles. We select between the scope where standard AWS encryption can meet requirements and the scope where custom management is required.

Design key permissions, rotation, and lifecycle.

If you use a customer-managed key, you must also define its operation after creation in advance.

Key policies and IAM policies are used to restrict key management privileges and the ability to use them for encryption and decryption to only those who need them. Depending on the system and the roles of the personnel, there are also methods to separate administrator and user privileges.

Rotation procedures are defined based on the organization's security policies and audit requirements. Key material for AWS managed keys is automatically rotated by AWS KMS. Automated and on-demand rotation are available for corresponding customer-managed keys.

Caution is also needed when disabling or deleting KMS keys. Deleting a KMS key may prevent you from decrypting data encrypted with that key. AWS KMS has a waiting period of 7 to 30 days before deleting customer-managed keys.

Encrypting data at rest in key AWS services

AWS provides a mechanism for encrypting data at rest for each service. The scope of encryption and the available KMS keys differ by default, so you should choose the settings based on the specifications of each service and your company's management and audit requirements.

Amazon S3 | How to choose between SSE-S3 and SSE-KMS

Starting in January 2023, all new objects in Amazon S3 will be encrypted by default using SSE-S3 (Server-Side Encryption with Amazon S3 Managed Keys). Currently, the main decision point is whether SSE-S3 can meet the requirements or whether SSE-KMS, which utilizes AWS KMS, is necessary.

SSE-KMS allows for access control and usage auditing of KMS keys. It's used when you want to use a specific customer-managed key. Additionally, a customer-managed key is required when sharing S3 objects encrypted with SSE-KMS with another AWS account. 

With SSE-KMS, charges may apply for API requests to AWS KMS. If you use customer-managed keys, you should also consider the cost of the keys themselves. For environments handling a large number of objects, S3 Bucket Keys are another option that can reduce the number and cost of requests to AWS KMS. 

Amazon EBS | Encrypting Volumes and Snapshots

Amazon EBS allows you to encrypt EBS volumes using AWS KMS. EBS encryption is enabled by default at the account and region level, and encryption will be applied to newly created EBS volumes.

Snapshots created from encrypted EBS volumes are also encrypted. Existing unencrypted volumes cannot be encrypted directly. You will need to take steps such as creating a new encrypted volume via an encrypted snapshot.

Amazon RDS and Amazon Aurora | Encrypting Databases

Amazon RDS allows you to encrypt your DB instances using AWS KMS. Encrypted DB instances encrypt not only storage, but also logs, backups, read replicas, and snapshots. You can choose to use either an AWS-managed key or a customer-managed key for encryption.

Amazon Aurora database clusters created on or after February 18, 2026, will now be encrypted at rest by default. By default, AWS-owned keys are used, but customer-managed keys and other options are available depending on requirements. Clusters created before this date may have different settings, so for existing environments, it's recommended to understand the current encryption status before considering any changes.

Design encryption for data in transit.

In addition to stored data, data exchanged between users and AWS services, and between AWS services themselves, is also protected. Encryption in transit is based on TLS, and this applies not only to communication over the internet but also to communication within the AWS environment, depending on requirements. The AWS Well-Architected Framework also recommends the use of secure TLS protocols and cipher suites.

Encrypt the communication path using TLS.

Using TLS encrypts data during transmission, reducing the risk of eavesdropping and tampering. Web applications use HTTPS, and communication paths for services like Application Load Balancer, Amazon CloudFront, and Amazon API Gateway are configured with TLS in mind.

We will also select the TLS version and cipher suite. We will choose the security policy for each service in accordance with the organization's encryption policy, and configure the system to avoid using older SSL/TLS or less secure encryption methods.

TLS will also be applied to communications involving the sending and receiving of highly sensitive data within the AWS environment, such as between applications and databases, as required.

The process includes the issuance and renewal of certificates.

AWS Certificate Manager (ACM) manages not only the issuance but also the renewal of certificates used for TLS. Using AWS Certificate Manager (ACM), you can issue and manage SSL/TLS certificates and deploy them to compatible AWS services such as Elastic Load Balancing and Amazon CloudFront.

Certificates issued by ACM are eligible for managed renewal if certain conditions are met. These conditions include the certificate being used with the corresponding AWS service and the necessary settings for DNS verification being maintained.

We will implement an operational flow that monitors expiration dates and renewal status, and can handle certificate revocations and renewal failures.

Points to consider when designing encryption on AWS

After deciding on the encryption method, you will specify who will manage the encryption keys, who will have access rights, and how to audit them. If using customer-managed keys, you will clearly define the scope of management handled by AWS and the scope of management handled by your company.

Customer-managed keys should be used according to management requirements.

Customer-managed keys allow users to manage key policies, enable/disable keys, rotate keys, and delete keys themselves. This is suitable when custom access control is required or when it is necessary to clearly define who uses the keys for auditing purposes.

If your requirements can be met with standard encryption from AWS services, AWS managed keys are also an option. The extent to which you should use customer-managed keys depends on the required level of control, audit requirements, and management burden.

Combining encryption and access control

Encryption alone cannot prevent data access through improper permission settings. IAM policies and KMS key policies must be combined to control who can access the data and who can use the encryption keys.

Permissions are granted in accordance with the principle of least privilege. Access and decryption permissions for data are managed together, and unnecessary permissions are removed in response to personnel changes or system modifications.

For more details, please see the article below.

 >> What is the principle of least privilege? The risks of excessive privileges and specific steps for designing IAM.

Design the operation including logging and auditing.

AWS managed keys and customer-managed keys are recorded in AWS CloudTrail, allowing you to audit who used which key and when. AWS-owned keys cannot be audited by the user. 

In terms of operation, rules will be established regarding the frequency of log checks, actions to be taken when anomalies are detected, disabling and deleting unnecessary keys, and reviewing permissions.

For information on designing logs using AWS CloudTrail, please see the article below.

>> AWS Security Log Design Guide | Focusing on AWS CloudTrail: Separating "Audit Trails" and "Detection"

Summary

AWS encryption design involves selecting encryption methods for both data at rest and in transit based on data importance, usage, and security requirements. When using AWS KMS, you'll also choose between AWS-managed keys and customer-managed keys depending on the required control scope and audit requirements.

In addition to service specifications for Amazon S3, Amazon EBS, and Amazon RDS, we design encryption operations that you can sustain in-house, including key access control, rotation, logging, and auditing.