AWS Encryption Explained: At Rest, In Transit, KMS, S3, EBS & RDS

Simple explanation

Encryption at rest means data stored on disk is scrambled so that it cannot be read without the correct key. Even if someone gains physical access to the storage hardware, encrypted data is useless to them.

Encryption in transit means data moving over a network (between your browser and AWS, between two AWS services, or between an application and a database) is protected using protocols like TLS. Anyone intercepting the traffic sees meaningless data.

AWS offers multiple layers of encryption depending on the service and how you configure it. Some services encrypt everything by default. Others need you to turn encryption on. Some let you bring your own keys for tighter control and audit logging.

Why encryption matters in AWS

Encryption is a foundational control in every major compliance framework. SOC 2, PCI-DSS, HIPAA, GDPR, and FedRAMP all require encryption of sensitive data at rest and in transit. Even without compliance requirements, encryption limits the damage from storage-level breaches. If an attacker accesses raw EBS volume data or S3 storage, encrypted data is useless without the keys.

AWS makes encryption straightforward for most services, but misconfiguration is common. Knowing which services require explicit opt-in, and what the default behavior actually is, helps you build a security posture you can verify and defend.

Under the shared responsibility model, AWS encrypts data in transit between its own infrastructure components (hypervisor to storage, inter-region replication traffic). But you are responsible for enabling encryption on services like EBS and RDS, enforcing HTTPS where needed, and choosing appropriate key management strategies.

How AWS encryption works

Most AWS encryption uses AWS Key Management Service (KMS) and a technique called envelope encryption. A data encryption key (DEK) encrypts your actual data. A KMS key encrypts the DEK. Only the encrypted DEK is stored alongside your data. To decrypt, AWS calls KMS to unwrap the DEK, then uses it to decrypt the data.

The critical difference between encryption options comes down to who owns and controls the key. AWS offers three key types, each with different levels of customer control.

Key ownership models

AWS-owned keys are created, managed, and rotated entirely by AWS. You cannot view, manage, or audit them. Multiple AWS customers may share the same underlying key. This is what S3 uses for default SSE-S3 encryption and what DynamoDB uses by default.

AWS-managed KMS keys are KMS keys that AWS creates in your account on your behalf (e.g., aws/s3, aws/ebs). You can view them in the KMS console and see usage in CloudTrail, but you cannot change their key policy, disable them, or control rotation beyond the automatic yearly rotation AWS performs.

Customer managed KMS keys (CMKs) are keys you create and fully control. You set the key policy, decide who can use the key, configure rotation schedules, and can disable or delete the key. CloudTrail logs every use. This is the option that gives you the most control and auditability.

Key type comparison

Encryption at rest

Encryption at rest protects data stored on physical media. Most AWS services that support at-rest encryption use KMS and envelope encryption under the hood.

S3 encryption options

S3 supports multiple server-side encryption (SSE) modes:

• SSE-S3 uses an AWS-owned key that AWS manages entirely. You have no visibility or control over the key. This is the default for all S3 objects since January 2023.
• SSE-KMS uses a KMS key (the AWS-managed aws/s3 key or your own CMK). You get CloudTrail logging of every encrypt and decrypt call and can control key access via key policies.
• SSE-C lets you provide your own encryption key with every request. AWS never stores the key. You manage key storage and rotation entirely outside AWS.
• DSSE-KMS applies two independent layers of server-side encryption using KMS keys. Each layer uses a separate data encryption key derived from the KMS key. Required by specific compliance frameworks such as CNSSP-15 and recommended for certain FedRAMP High workloads.

For most workloads handling sensitive data, SSE-KMS with a customer managed key is the right choice. It gives you encryption with audit logging and key-level access control.

EBS encryption

EBS volumes are not encrypted by default. You must either encrypt each volume at creation time or enable the account-level default:

# Enable EBS encryption by default for the account in a region
aws ec2 enable-ebs-encryption-by-default --region us-east-1

# Verify the setting
aws ec2 get-ebs-encryption-by-default --region us-east-1

Once enabled, all new EBS volumes created in that region are encrypted automatically. Existing unencrypted volumes are not affected. You must create a snapshot, copy it with encryption enabled, and create a new volume from the encrypted snapshot.

RDS encryption

RDS encryption at rest must be enabled when you create the database instance. It cannot be turned on later.

Encryption in transit

Encryption in transit protects data as it moves between clients and services, between services, and between AWS regions. AWS uses TLS (Transport Layer Security) as the standard protocol.

AWS API endpoints

All AWS service API endpoints require HTTPS with TLS 1.2 or higher. When you make an API call using the CLI, SDK, or console, the traffic is encrypted. AWS does not offer unencrypted HTTP endpoints for service APIs.

S3 HTTPS enforcement

While S3 API calls always use HTTPS, bucket policies can allow or deny based on the transport protocol. To enforce HTTPS for all access to a bucket, apply this bucket policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyHTTP",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Application Load Balancer TLS

For web applications, terminate TLS at the ALB and use AWS Certificate Manager (ACM) for certificate management:

• ACM certificates are free for use with ALB and CloudFront.
• ACM auto-renews certificates, so no manual renewal is needed.
• Configure the ALB listener to redirect HTTP to HTTPS.
• For end-to-end encryption, configure HTTPS between the ALB and your backend instances as well.

RDS encryption in transit

RDS supports TLS for client connections, but enforcement depends on the database engine:

• MySQL / MariaDB: set the require_secure_transport parameter to ON in the parameter group.
• PostgreSQL: set rds.force_ssl to 1 in the parameter group.
• SQL Server: set rds.force_ssl to 1. You can also enforce encryption at the application connection string level.
• Oracle: configure the SSL option in the option group and use the Oracle native network encryption settings.
• Aurora MySQL / Aurora PostgreSQL: follows the same parameter approach as the underlying engine.

By default, most RDS engines support TLS but do not require it. Clients can connect without encryption unless you explicitly enforce it through parameter or option groups.

AWS encryption options compared

This comparison focuses on S3 server-side encryption options, which are the most common encryption decision teams face.

When to use each option

Basic internal bucket with low sensitivity

Use SSE-S3 (the default). No configuration needed. Suitable for application logs, build artifacts, and non-sensitive internal data where you do not need to track who decrypted what.

Sensitive production data needing audit trails

Use SSE-KMS with a customer managed key. This gives you CloudTrail logging of every key usage, the ability to restrict decryption through key policies, and a clear ownership boundary. This is the right default for PII, financial records, and health data.

Strict compliance requirements (CNSSP-15, FedRAMP High)

Use DSSE-KMS if your compliance framework explicitly requires dual-layer encryption. Otherwise, SSE-KMS with a customer managed key is sufficient for most regulated workloads including HIPAA, PCI-DSS, and SOC 2.

EBS volumes for workloads that should never launch unencrypted

Enable EBS encryption by default at the account level. This ensures every new volume in the region is encrypted without relying on individual developers to remember. For sensitive workloads, specify a customer managed key instead of the default aws/ebs key.

RDS databases where encryption must be planned at creation

Always enable encryption when creating an RDS instance. There is no way to encrypt an existing unencrypted database in place. If your organization runs both dev and production databases, enforce encryption even in dev environments to avoid the risk of promoting an unencrypted database to production.

Service-by-service quick reference

How to verify encryption is enabled

Use AWS Config rules

AWS Config provides managed rules that continuously evaluate your resources against encryption requirements:

# Check if all EBS volumes are encrypted
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name encrypted-volumes

# Check if RDS instances have storage encryption
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name rds-storage-encrypted

# Check if S3 buckets enforce HTTPS
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name s3-bucket-ssl-requests-only

Use Security Hub

AWS Security Hub includes the Foundational Security Best Practices standard, which runs automated checks for encryption configuration across services. Enabling Security Hub is the fastest way to get a comprehensive view of encryption gaps across your entire account.

Verification checklist

• S3: confirm bucket default encryption is set to SSE-KMS for sensitive buckets. Verify the aws:SecureTransport deny policy is applied.
• EBS: confirm account-level EBS encryption by default is enabled in every region you use. Check for any existing unencrypted volumes.
• RDS: confirm StorageEncrypted is true for every instance. Check parameter groups for TLS enforcement settings.
• General: review AWS Config compliance dashboard for any non-compliant encryption rules. Check Security Hub findings filtered to encryption-related controls.