What Is Cloud Encryption? States, Keys, and KMS

Pull the storage logs after a cloud incident and you will usually find the bucket was encrypted the whole time. AES-256, server-side, enabled by default, exactly as the compliance report claimed. The attacker did not break the cipher. They assumed a role that was allowed to call Decrypt, and the platform handed back plaintext because that is what a valid kms:Decrypt request is supposed to do. The encryption worked. It just was not protecting against the thing that happened.

Cloud encryption is the use of cryptography to render data in a cloud environment unreadable without the right key, applied across the three states data lives in: at rest, in transit, and in use. This guide covers what that means in practice: the three states and the algorithm behind each, symmetric versus asymmetric and where AES-256 and TLS actually sit, why key management is the real problem and not the math, how customer-managed and provider-managed keys differ, what encryption does and does not protect against, and what a defender checks to confirm it is working. It is written for the people who answer for the data after the fact: SOC analysts, threat hunters, and DFIR responders reading cloud forensics artifacts to reconstruct who could decrypt what.

What is cloud encryption?

Cloud encryption transforms readable data (plaintext) into an unreadable form (ciphertext) using an algorithm and a key, so that anyone who obtains the data without the key gets nothing usable. Decryption reverses it with the right key. In the cloud the data sits on infrastructure you do not own and share with other tenants, so encryption is the control that keeps your data yours even when the storage layer, the network path, or the physical disk is outside your hands.

The point that gets lost in vendor copy: encryption does not protect data. Keys protect data. The ciphertext is only as private as the key that unlocks it, which means the entire security of a cloud encryption scheme collapses down to one question, who can use the key. A perfectly encrypted database with a key that 400 IAM principals can call is a database 400 principals can read. That is why the rest of this article spends more time on key management than on ciphers.

Encryption in the cloud is not one feature you switch on. It is three separate problems, one for each state the data passes through, each with its own mechanism and its own failure modes.

The three states: at rest, in transit, in use

Data is exposed differently depending on what it is doing, so it is encrypted differently in each state. Getting all three is what "encrypted everywhere" actually means.

At rest is data sitting in storage: an S3 object, an EBS volume, a database file, a snapshot, a backup. The standard mechanism is symmetric encryption with AES-256, applied server-side by the storage service so the bytes on disk are ciphertext. This is the state most compliance checks look at, and the one most cloud providers now enable by default. It protects against a stolen disk, a leaked snapshot, or a misconfigured bucket whose objects are exfiltrated, none of which yields readable data without the key.

In transit is data moving over a network: client to API, service to service, region to region. The mechanism is Transport Layer Security (TLS), TLS 1.3 or 1.2 in current deployments, which encrypts the channel so traffic cannot be read or tampered with in flight. Every call to a cloud API and every byte returned from a key service rides inside TLS. AWS KMS, for example, returns decrypted material to you only over your TLS connection, never in the clear.

In use is data being processed: decrypted in memory so a CPU can compute on it. This is the hardest state and the one most encryption programs skip. Traditionally data has to be in plaintext to be worked on, which leaves it exposed to the hypervisor, the host OS, and anyone with access to that memory. Confidential computing closes the gap by running the computation inside a hardware-based trusted execution environment (TEE), a region of the CPU that isolates the data and code from the operating system, the hypervisor, and the cloud operator itself. The data stays encrypted in memory and is decrypted only inside the protected enclave.

Most real programs cover at rest and in transit well and treat in-use as aspirational. That is a defensible order of operations, but know which state you have actually covered, because "our data is encrypted" almost always means the first two.

Symmetric vs asymmetric, and where AES-256 and TLS fit

Two families of cryptography do the work, and they solve different problems.

Symmetric encryption uses one key for both encryption and decryption. It is fast, which is why it does the bulk-data work: encrypting the actual objects, volumes, and database pages. The dominant standard is the Advanced Encryption Standard (AES), almost always at a 256-bit key length, AES-256. AES is a NIST standard that has stood up to decades of public cryptanalysis with no break of its core design, and AES-256 is approved for protecting classified information. AWS KMS does its symmetric work with 256-bit AES-GCM keys. The catch with symmetric crypto is distribution: both sides need the same key, so you have to get that key to them without exposing it.

Asymmetric encryption uses a key pair, a public key that encrypts and a private key that decrypts (RSA and elliptic-curve are the common algorithms). Anyone can encrypt with the public key; only the holder of the private key can decrypt. That solves the distribution problem but is far slower, so it is not used to encrypt large data directly. Its job in the cloud is establishing trust and exchanging keys, which is exactly what happens in the TLS handshake that protects data in transit, and in signing and certificate operations.

In practice the two are combined rather than chosen between. TLS uses asymmetric crypto to authenticate the server and agree on a shared secret, then switches to fast symmetric encryption for the actual session traffic. Cloud storage does the parallel move with envelope encryption, below: a fast symmetric key encrypts the data, and a second key protects the data key. Symmetric does the heavy lifting; asymmetric and key-wrapping handle the key problem.

Key management is the real problem

Ciphers are not where cloud encryption fails. AES-256 is not getting brute-forced. Encryption fails at key management: where keys live, who can use them, whether their use is logged, and what happens when one is exposed. This is the part the platform makes easy to get wrong, because the defaults optimize for "it just works," not "the smallest set of principals can decrypt."

The mechanism underneath nearly every cloud storage encryption scheme is envelope encryption. Instead of handing your master key to the storage service, the service generates a unique symmetric data key, encrypts the object with it, then encrypts (wraps) that data key under a master key held in the key management service. The encrypted data key is stored next to the ciphertext; the plaintext data key is used and discarded. To read the object, the service sends the wrapped data key to the KMS, the KMS unwraps it using the master key (which never leaves the service), and returns the plaintext data key over TLS. The master key does the small job of protecting data keys; the data keys do the bulk encryption. This is why large objects never travel to the key service and why the master key never travels to storage.

A key management service (KMS) is the cloud-native system that holds those master keys, controls who may use them through policy, and logs every use. AWS KMS, Azure Key Vault, and Google Cloud KMS are the platform versions. The master keys themselves are generated and stored inside a hardware security module (HSM), a tamper-resistant device whose backing key material is designed never to leave the HSM in plaintext. For workloads that need a dedicated, single-tenant HSM under their own control, providers offer it directly, AWS CloudHSM is the example.

Two operational facts matter for defenders. Master keys can be rotated, and provider-managed keys often rotate automatically (AWS managed keys, for instance, rotate annually). And every decrypt is a logged API call, which is the single most useful artifact for answering "who read this data," covered below.

Who holds the key: provider-managed vs customer-managed

The most consequential encryption decision in the cloud is not which algorithm, it is who controls the key. The models trade control for convenience, and the right one depends on how much you need to prove about key access.

Provider-managed keys are the default. The platform creates, stores, and rotates the master key for you, and encryption "just happens." It is the right choice when you want data encrypted at rest with zero key overhead. The trade-off is control and, often, visibility: some provider-owned key types are not auditable by the customer at all.

Customer-managed keys (CMK) are keys you create and own inside the provider's KMS. You set the key policy that decides which principals can encrypt and decrypt, you control rotation and deletion, and every use is logged to you. CMKs are the practitioner default when key access has to be controlled and audited, because they give you the policy surface and the logs that provider-managed keys do not.

Bring your own key (BYOK) means you generate the key material yourself and import it into the provider's KMS, so the key's origin is under your control even though it then lives in the provider's HSM. Hold your own key (HYOK) goes further: the key stays in your own external key store or HSM outside the provider, and the provider must call out to you to decrypt, meaning it can never read your data on its own. HYOK is the highest-assurance and the most operationally heavy option, and it only makes sense when the threat model genuinely requires that the provider never hold a usable key.

Shared responsibility for encryption

Encryption is split across the shared responsibility line, and the split is where most gaps open. The provider is responsible for security *of* the cloud: the HSMs, the KMS service, the cryptographic implementation, the physical disks. You are responsible for security *in* the cloud: turning encryption on, choosing the key model, writing the key policy, and deciding who can decrypt.

The provider gives you sound primitives and then steps back. It will not stop you from granting kms:Decrypt to an over-broad role, leaving a key policy open to the whole account, or shipping data to a region with no encryption configured. "The cloud encrypts everything" is true at the infrastructure layer and irrelevant to the failures that cause incidents, which live entirely on your side of the line. This is the same dynamic behind most AWS misconfigurations: the secure option exists, the default does not enforce it, and the gap is the customer's to close.

What encryption protects against, and what it does not

Encryption is precise about its job. It protects confidentiality of data against anyone who obtains the data without authorized use of the key. That covers a real and common set of threats: a stolen or improperly decommissioned disk, a leaked snapshot or backup, an exfiltrated storage bucket, traffic intercepted on the wire, and a cloud operator or co-tenant who can touch the storage but not your keys. In all of these the attacker ends up with ciphertext and no key, which is to say nothing.

What encryption does not do is stop an attacker who can make the platform decrypt for them. If an adversary obtains valid credentials for a principal that is allowed to call kms:Decrypt, the platform decrypts on request, exactly as designed. The data being "encrypted at rest" is irrelevant at that point, because the attack is not against the storage, it is against the identity that holds decrypt rights. This is the core failure pattern in incidents like cloud jacking, where a compromised credential or assumed role inherits all the key access the legitimate identity had. Encryption also does nothing against data that is already decrypted in use (outside a confidential-computing enclave), against a malicious insider whose access is legitimate, or against a key that is deleted or lost, which renders the data permanently unreadable to everyone including you.

The defensive takeaway is to stop treating "is it encrypted" as the security question. The security question is who can decrypt, and encryption only narrows the attack surface to exactly that set of principals. Tighten that set, and encryption is strong; leave it broad, and the cipher is doing honest work that the access policy quietly undoes.

Compliance drivers

A large share of cloud encryption exists because a framework requires it, and the requirements are specific enough to shape the architecture. PCI DSS mandates encryption of cardholder data at rest and in transit. HIPAA drives encryption of protected health information. GDPR treats encryption as a recognized safeguard, and in several breach-notification regimes encrypted data exposed without the key may not trigger the same disclosure duty, a direct incentive to encrypt at rest. FIPS 140 governs validation of the cryptographic modules themselves, which is why regulated workloads often require FIPS-validated HSMs.

For a defender, compliance is useful less as a goal than as a forcing function: it is what gets CMKs, key rotation, and decrypt logging turned on. The trap is treating the audit checkbox as the finish line. "Encryption at rest: enabled" passes the audit and tells you nothing about how many principals can call decrypt, which is what determines whether the encryption matters.

The defender's view: verifying encryption actually protects

Encryption is a control you have to verify, not assume, and the verification is concrete. Three questions, in order of how often they catch real problems.

Is encryption actually enabled, everywhere it should be? Inventory the storage and confirm encryption at rest is on for buckets, volumes, databases, and snapshots, and that TLS is enforced for data in transit (reject plaintext connections, do not just offer encryption). The common gaps are new resources created without it, one region or account missed in a rollout, and backups or snapshots encrypted weaker than the primary. Cloud security posture tooling exists largely to answer this question continuously.

Who can decrypt? This is the question that matters most and the one least often asked. Read the key policies and IAM policies and enumerate every principal that can call decrypt on each key. Over-broad grants, a wildcard principal, a role far more roles can assume than intended, a key shared across accounts, are the actual exposure. Apply least privilege to key usage exactly as you would to any other sensitive permission, and separate the duty of managing a key from the permission to use it.

Is key usage logged, and is anyone watching? Every decrypt should be an audited API event (CloudTrail for AWS KMS, the equivalent on other platforms). That log is the artifact that turns "was this data accessed" from a guess into an answer, so confirm it is enabled, retained, and feeding detection. A spike in decrypt calls, a decrypt from an unexpected principal or region, or a key policy change are all signals worth an alert. Without the log, a credential-theft attacker using valid decrypt rights leaves no trace you can find after the fact, which returns you to the bucket from the opening: encrypted the whole time, and no way to tell who read it.

The bottom line

Cloud encryption protects data across three states: at rest with symmetric AES-256, in transit with TLS, and in use with confidential computing, and most programs cover the first two and treat the third as advanced. The cryptography is not where it fails. AES-256 holds, TLS holds, and envelope encryption lets a master key in a KMS protect the data keys that do the bulk work without the master key ever leaving the service.

It fails at key management. The security of every encrypted object reduces to who can use the key, which is why the choice between provider-managed and customer-managed keys, and the discipline of least privilege on decrypt rights, matters more than any algorithm. Encryption stops an attacker who gets your data without the key. It does nothing against one who can make the platform decrypt for them. For a defender that turns the question from "is it encrypted" into three you can actually answer: is it on everywhere, who can decrypt, and is every decrypt logged and watched.