Encryption at Rest and in Transit

Two Phrases, Two Completely Different Threats

The pair is quoted together so often that the difference gets lost. They defend against separate things, and knowing which is which stops a lot of wasted effort.

Encryption at rest protects stored bytes from someone who obtains the storage. A decommissioned drive, a copied snapshot, a backup archive that ends up somewhere it should not, a disk image shared by mistake. The attacker in this model has the media but not your running system.

Encryption in transit protects bytes moving between two points from anyone positioned along the path. A shared network segment, an intermediate provider, a misconfigured proxy, anything sitting between your application and its database.

Notice that neither addresses an attacker who has valid credentials to your running application. That case is an authorisation problem, and no amount of encryption touches it.

At Rest: the Only Real Question Is Who Holds the Key

All major providers now encrypt persistent storage by default, and the cipher is not the interesting part. Every serious implementation uses a strong symmetric algorithm, hardware accelerated on modern processors, so the performance objection that made people hesitate a decade ago has largely disappeared.

What differs is key custody, and platforms offer three arrangements.

Provider managed keys require no configuration. The platform creates, stores, rotates and uses the key on your behalf. It protects against media level exposure and satisfies most baseline requirements, and you have no independent way to make the data unreadable.

Customer managed keys live in the provider's key service under your control: AWS KMS, Azure Key Vault, Google Cloud KMS, Oracle Cloud Vault. You set the access policy, you can rotate on your own schedule, the key service logs every use, and disabling the key renders the data unreadable across every service that depends on it. This is the option most compliance programmes expect.

Customer supplied or externally held keys go further, with material you provide per request or hold outside the provider entirely. It gives the strongest separation and the strongest failure mode: lose the key and the data is gone, with no recovery path anywhere.

On a plain virtual machine you can also encrypt inside the guest with LUKS, which protects against exposure of the underlying volume by the platform itself. The price is that the passphrase or key file must reach the machine at boot, which is a genuine operational puzzle rather than a checkbox.

Why Your Key Never Touches the Data

Key services do not encrypt terabytes. They encrypt other keys, in a pattern called envelope encryption, and understanding it explains most of the behaviour you will observe.

A data encryption key is generated for the object or volume and does the bulk work locally. That key is then encrypted by a key encryption key held inside the key service, and only the wrapped version is stored beside the data. To read, the service is asked to unwrap the data key, which it does only if the caller's permissions allow it.

Two consequences follow. Bulk encryption runs at local speed regardless of the key service, because the master key never leaves it. And revoking access is instant across everything using that key, since unwrapping simply stops being permitted.

It also explains why an access policy on the key is as important as the policy on the storage. Permission to read a bucket without permission to use its key yields ciphertext, and permission to use a key without access to the data yields nothing. Both conditions have to be met, which is a useful separation to design with. AWS covers the mechanics in its KMS concepts documentation.

In Transit: Every Hop, Not Only the Public One

Most teams encrypt the browser to server connection and stop there. The interesting exposure is usually further in.

Start with the public edge, which is the certificate work described in TLS certificates for cloud servers. Then look at the hop from a load balancer or CDN to the origin, which is frequently left unencrypted because it is assumed to be internal. Whether that assumption holds depends entirely on whether the path stays inside a network you control.

Next, the connections your application makes. Database drivers often default to opportunistic encryption that falls back silently, or that encrypts without verifying the server certificate. For PostgreSQL, a connection string with sslmode=verify-full requires both encryption and a verified server identity, which is the setting that actually resists interception.

Then internal service to service traffic. Mutual TLS, where both ends present certificates, gives encryption and authentication together and is what service meshes automate. For machine to machine links across sites, an encrypted tunnel such as WireGuard or IPsec covers everything above it without touching application code.

Private networking reduces exposure but does not remove the need for encryption, since a private network is still shared infrastructure with other tenants and other workloads of your own. The boundaries are described in private networking between cloud servers.

The Decisions That Outlive the Configuration

Once customer managed keys are in play, a handful of choices matter more than the encryption itself.

Scope. One key per environment and data class is a reasonable default. A single key for everything makes revocation an outage, and a key per object makes policy unmanageable.

Rotation. Most services can rotate the master key automatically while keeping earlier versions available to decrypt existing data. Enable it, and understand that rotation alone does not re-encrypt what already exists unless you rewrite the objects.

Deletion. Key services impose a mandatory waiting period before destroying key material, precisely because deletion is irreversible and destroys the data with it. Treat a scheduled deletion as a change requiring the same scrutiny as dropping a database.

Hardware backing. Where a regulator or a contract requires it, dedicated hardware security modules are available on the major platforms. Validation of those modules is tracked publicly through the NIST cryptographic module validation program, which is the reference auditors actually cite.

Logging. Every key use should land in the audit trail, so that unusual decryption activity is visible. That feed belongs with the rest of your records, as described in audit logging in the cloud.

What It Will Not Save You From

Encryption has a narrow job, and overstating it leads to real gaps.

It does not protect data an authorised process reads. An application with valid credentials sees plaintext, so an application vulnerability yields plaintext. Nor does a stolen access key care, since the platform decrypts transparently for anyone permitted to read.

It does not fix an open permission. A public bucket serves decrypted objects to the world exactly as designed, and this is the single most common cloud data exposure.

It does not help with data in use, which is memory. Confidential computing offerings on the major clouds use processor features to encrypt memory and attest the environment, which narrows that gap for specific workloads and is not something you enable casually.

So treat encryption as one layer among several: identity and least privilege first, then the credential hygiene described in managing API keys and secrets, with encryption underneath both.

A Working Checklist

• Confirm default at rest encryption is on for volumes, snapshots, object storage and managed databases.
• Move anything sensitive to customer managed keys so revocation is yours to exercise.
• Write key access policies deliberately, since they are a second lock on the same data.
• Enable automatic key rotation and know that old data keeps its previous key version.
• Treat scheduled key deletion with the same care as deleting the data itself.
• Encrypt the hop to the origin, the database connection and the backup path, not only the browser facing edge.
• Require certificate verification rather than accepting opportunistic encryption.
• Send key usage events to the same place as the rest of your audit records.

Key management depth varies noticeably between platforms. The Google Cloud account listings describe an account where Cloud KMS and customer managed keys are available, and the Google Cloud versus Oracle Cloud comparison looks at how the two organise their key and vault services.