Data Encryption & Key Management
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
When you attempt to encrypt terabytes of data over a network using a single central cryptographic key, the architecture immediately collapses under the weight of its own mathematical and physical constraints. Dragging a massive database backup across a network to a hardware security module simply to scramble the bytes introduces devastating latency, consumes astronomical bandwidth, and creates a massive bottleneck at the cryptographic engine. Modern cloud security avoids this impossibility by using a technique called envelope encryption.
Envelope encryption is a cryptographic strategy where a primary master key encrypts a generated, temporary plaintext data key, and that lightweight data key is used locally to encrypt the actual massive payload. Instead of moving the mountain to the lock, we mint a temporary lock, secure the mountain locally, and then securely wrap the key to that lock inside a master vault. This fundamental mechanism dictates how AWS Key Management Service (AWS KMS) and large-scale cloud storage services operate.
AWS Key Management Service is the foundational cryptographic engine of the AWS ecosystem. As a solutions architect, you must internalize that KMS is designed to protect keys, not to process large datasets directly.
Because of the severe performance implications of transmitting large data payloads over the network to KMS, AWS Key Management Service limits the maximum payload size for the direct Encrypt API operation to exactly 4 kilobytes. This direct API is intended exclusively for tiny payloads: a database password, a third-party API token, or an internal configuration secret.
If your applications are encrypting payloads larger than 4 kilobytes, they must use the AWS Key Management Service GenerateDataKey API. This API call asks KMS to generate a new data key and returns two versions of it to your application: a plaintext data key and an encrypted copy of that data key (the "envelope"). Your application uses the plaintext key to perform local encryption operations on the massive payload, permanently deletes the plaintext key from its memory, and stores the encrypted data key alongside the newly encrypted ciphertext payload.
The Cryptographic Primitives
When you create a key in KMS, you must define its mathematical behavior.
- Symmetric AWS Key Management Service keys represent a single 256-bit secret key used simultaneously for both encryption and decryption operations. This is the workhorse of cloud encryption, leveraging the AES-GCM algorithm. It is fast, mathematically efficient, and powers almost all native AWS service integrations (like S3, EBS, and RDS).
- Asymmetric AWS Key Management Service keys represent a mathematically related public key and private key pair used for encryption, decryption, or digital signatures. These are crucial when you have components in your architecture that need to encrypt data (using the public key) without ever possessing the ability to decrypt it, or when validating the authenticity of a payload via digital signatures.
The Three Tiers of Key Ownership
Control over cryptographic material in AWS is segmented into three distinct tiers of ownership. Your choice here fundamentally dictates your operational overhead and auditability.
| Key Type | Visibility & Control | Use Case |
|---|---|---|
| AWS owned keys | These are created and managed automatically by internal AWS services and do not appear in the customer AWS Key Management Service console. | True "hands-off" default encryption where you do not need audit logs of the key usage. |
| AWS managed keys | These are created in the customer AWS account by AWS services but cannot be deleted or directly modified by the customer. | A middle ground. You can view them and track their usage via AWS CloudTrail, but you cannot alter their policies. |
| Customer managed keys | Customer managed keys are created, owned, and fully controlled by the customer within the customer AWS account. [1.1.1] | Strict compliance regimes requiring custom rotation, strict access policies, or granular cross-account sharing. |
In a well-architected cloud environment, developers rarely handle encryption algorithms directly. Instead, they configure infrastructure to handle encryption transparently, shifting the burden from application code to the AWS infrastructure layer.
Block Storage and Databases
When you attach an encrypted Amazon Elastic Block Store (EBS) volume to an EC2 instance, the hypervisor handles the heavy lifting. Amazon Elastic Block Store volumes encrypted with AWS Key Management Service automatically handle transparent decryption when data is read and encryption when data is written. The guest operating system remains completely unaware that the underlying disk is encrypted.
Similarly, Amazon Relational Database Service (RDS) supports transparent data encryption at the storage level using AWS Key Management Service for database instances.
A common architectural hurdle arises when an engineer forgets to enable encryption at the time of creation. Because of how blocks are physically allocated, an unencrypted Amazon Relational Database Service instance cannot be encrypted directly. The same physical limitation applies to EBS. To fix this, you must apply a snapshot strategy: a snapshot of an unencrypted Amazon Elastic Block Store volume or RDS instance can be copied, and during that copy process, you apply KMS encryption to create a new, perfectly encrypted volume or database.
Object Storage at Scale
Consider a data lake in Amazon S3 receiving millions of small sensor readings per second. If every object independently calls KMS to generate a unique data key, the GenerateDataKey API requests will result in throttling and massive, unexpected billing spikes.
To solve this, AWS introduced Amazon Simple Storage Service Bucket Keys. Bucket Keys reduce AWS Key Management Service request costs by generating a single bucket-level data key to encrypt multiple storage objects. S3 holds this bucket-level key in memory for a short time, generating local data keys for the incoming objects. This drastically reduces the network round-trips to KMS, frequently reducing encryption-related KMS costs by up to 99%.
Cryptographic best practices dictate that keys must not live forever. The longer a key is active, the more ciphertext is generated under that key, increasing the theoretical blast radius if the key material were ever compromised.
Automatic key rotation mitigates this risk. When enabled, automatic key rotation changes the underlying cryptographic material of a Key Management Service key while preserving the exact same logical key identifier and Amazon Resource Name (ARN). This preservation is critical: it means you never have to update your application code, database configurations, or IAM policies when a key rotates.
How do we read old data? A common fear of key rotation is data loss. "If the key changes, how do I read the file I encrypted last year?" You do nothing. AWS Key Management Service automatically retains all previously used backing keys to seamlessly decrypt older ciphertext without requiring explicit key version selection. If you pass an old encrypted envelope to KMS, it instantly recognizes which generation of the key was used and decrypts it.
Rotation schedules are strictly governed by the key's ownership tier:
- AWS managed Key Management Service keys have automatic key rotation permanently enabled, and the rotation schedule cannot be disabled by the customer. They rotate their underlying cryptographic material automatically every 365 days.
- Customer managed Key Management Service keys, by contrast, put the responsibility on you. Automatic key rotation for these keys is entirely optional and remains disabled by default. If enabled, customer managed Key Management Service keys support a customizable automatic rotation interval ranging strictly between 90 and 2560 days.
There are structural exceptions. Due to the mathematical complexities of public-key infrastructure and the risks of desynchronizing external systems, asymmetric AWS Key Management Service keys fundamentally do not support automatic key rotation. The same prohibition applies to external cryptographic keys you manually import into KMS.
A cryptographic key is entirely useless if the wrong entities can invoke it. KMS uses a highly specific, dual-layered authorization model that trips up many experienced engineers.
Every AWS Key Management Service key requires exactly one associated resource-based key policy to control access permissions. This is the constitutional law of the key.
You might assume that granting an EC2 instance an IAM policy with kms:Decrypt is sufficient. It is not. Identity and Access Management policies alone cannot grant access to an AWS Key Management Service key unless the associated key policy explicitly authorizes the AWS account to use Identity and Access Management policies. If the key policy does not contain the root delegation statement ("Principal": {"AWS": "arn:aws:iam::111122223333:root"}), every IAM policy in your account attempting to use that key will fail immediately.
For dynamic workloads, modifying the JSON key policy continuously is dangerous. Instead, AWS provides AWS Key Management Service Grants. Grants provide an alternative access control mechanism to temporarily delegate specific cryptographic permissions to AWS principals or integrated AWS services. When you configure an EC2 Auto Scaling Group with an encrypted EBS volume, the Auto Scaling service dynamically creates a grant to decrypt the volume when launching an instance, and retires the grant when the instance terminates.
While KMS secures your data at rest, data flowing over the open internet requires a different cryptographic approach: Transport Layer Security (TLS).
AWS Certificate Manager (ACM) provisions, manages, and deploys public and private SSL and TLS certificates for secure data transit. It eliminates the manual, error-prone lifecycle of purchasing certificates, responding to cryptographic challenges, and manually rotating them before they expire.
The Mechanics of Public Certificates
To ensure a secure internet, public certificates require proof that you control the domain you are claiming. Consequently, AWS Certificate Manager strictly requires domain ownership validation via Domain Name System (DNS) records or email verification before issuing a public certificate. DNS validation is overwhelmingly preferred in modern architectures because it enables automation.
If you use DNS validation and the certificate is actively attached to an AWS resource, AWS Certificate Manager automatically renews public certificates that remain actively associated with supported AWS resources. Furthermore, public SSL certificates provisioned directly by AWS Certificate Manager are provided to AWS customers completely free of charge.
However, this convenience comes with strict, unbreakable security boundaries. To prevent private key compromise, public certificates generated by AWS Certificate Manager cannot be exported or downloaded directly by the customer. You will never see the raw .pem file or the private key.
Because you cannot download them, AWS Certificate Manager public certificates cannot be installed directly onto standard Amazon Elastic Compute Cloud (EC2) operating systems like standard Linux or Windows web servers. The singular, highly specialized exception is that AWS Certificate Manager public certificates can be associated directly with Amazon Elastic Compute Cloud instances strictly through the use of AWS Nitro Enclaves, an isolated compute environment that protects the cryptographic operations.
Architectural Placement of Certificates
Because standard EC2 instances cannot hold public ACM certificates, modern cloud architectures rely on TLS offloading. AWS Certificate Manager public certificates are typically attached to intermediate services like Application Load Balancers (ALBs) or Amazon CloudFront to perform TLS decryption before passing traffic to compute targets. The load balancer securely holds the private key, decrypts the inbound HTTPS traffic, and forwards standard HTTP (or newly re-encrypted traffic) to the EC2 instances behind it.
When placing certificates, you must respect regional boundaries:
- Regional load balancing resources (like an Application Load Balancer or API Gateway) require an attached AWS Certificate Manager certificate to be provisioned in the exact same AWS region as the load balancer.
- Global edge routing has a strict exception: Amazon CloudFront distributions strictly require associated AWS Certificate Manager certificates to be created in the US East (N. Virginia) region, regardless of where your users or origin servers are located.
Bridging the Gap: Private CAs
If you architect a hybrid environment requiring internal encryption—perhaps you have legacy on-premises servers, IoT devices, or strict regulatory requirements mandating mutual TLS (mTLS) within a Kubernetes cluster—ACM's public certificate restrictions are unworkable.
For these scenarios, the AWS Private Certificate Authority enables the generation and direct export of private TLS certificates for manual installation on custom servers or on-premises resources. Unlike public ACM certificates, Private CA acts as your own organizational root of trust, allowing you to generate, export, and manually distribute keys securely across any environment you command.
