Encryption at Rest and in Transit: The Actual Case, and What It Costs You

Why encryption isn't optional, what it does and doesn't protect against, and the real tradeoffs — key management overhead, performance, and the false sense of security it can create.

Every cheat sheet in this pillar has an encryption line item buried in it — SSE-S3 here, a Key Vault reference there. This piece is why that line item exists at all, what it's actually defending against, and where it stops helping.

Two different jobs, often conflated

Data at rest is anything sitting on a disk, in a database, in object storage — data that isn't currently moving. Encrypting it protects against someone getting hold of the storage medium or the backend directly: a stolen drive, a misconfigured backup, a cloud storage bucket left public, a database snapshot that leaks. Without it, physical or backend access to the storage is the same as reading the data in plaintext.

Data in transit is anything moving across a network — a request to an API, a file upload, replication traffic between regions. Encrypting it (TLS, in practice) protects against someone positioned on the network path: a man-in-the-middle attack, a compromised router, unencrypted Wi-Fi, an attacker who's gotten a foothold inside a VPC and is now sniffing internal traffic that everyone assumed was "safe because it's internal."

That last point is where a lot of otherwise-solid setups quietly fail: TLS enforced at the public-facing load balancer, and plaintext HTTP everywhere behind it, on the assumption that internal network traffic doesn't need protecting. It does. "Internal" isn't a security boundary, it's a network topology — and once an attacker has any foothold inside it, unencrypted internal traffic is free reconnaissance.

The stakes, with real numbers

IBM's 2026 Cost of a Data Breach report puts the global average cost of a breach at $4.99 million — a record, up 12% year over year. Buried in that report is the actual encryption story:

• 53% of breached organizations had sensitive data that was not encrypted at rest or in transit at the time of the breach
• Only 37% encrypt sensitive data both at rest and in transit
• Only 34% have visibility into their own cryptographic assets — meaning nearly two-thirds of organizations can't fully account for what's encrypted with what, or which keys are even still in use
• Ponemon's research (cited in the same report) found encrypted breaches cost roughly $200K less than unencrypted ones, on average

Read that together and the picture is blunt: most breached organizations weren't fully encrypting their data, and the ones that were paid less when something went wrong anyway. Encryption doesn't prevent a breach — it changes what an attacker actually gets when one happens.

How it's actually built: envelope encryption

Almost every cloud key-management service — AWS KMS, Azure Key Vault, GCP Cloud KMS — implements the same underlying pattern, and it's worth understanding rather than treating as a black box:

• A Data Encryption Key (DEK) encrypts the actual data, locally, using a fast symmetric algorithm (AES-256)
• The DEK itself is then encrypted by a Key Encryption Key (KEK) — the "master key" that lives in the KMS and never leaves it
• Both the encrypted data and the encrypted DEK get stored together; decrypting requires asking the KMS to unwrap the DEK first

This is envelope encryption, and it's the pattern NIST and the Cloud Security Alliance both recommend. The reason it exists: encrypting large volumes of data directly against a KMS key would mean every single encrypt/decrypt operation is a network round-trip to the KMS. Envelope encryption means the KMS is only ever touched to unwrap a small key, not to process the actual data — the expensive part happens locally and fast, and the sensitive part (the master key) never leaves a hardened, access-controlled service.

The baseline worth actually enforcing

• TLS 1.2 minimum, TLS 1.3 where supported — anything older has known weaknesses
• AES-256 for symmetric encryption at rest — the practical default across every major cloud
• FIPS 140-2/140-3 validated modules where compliance requires it (a real, non-optional requirement in regulated industries — not a nice-to-have)

The tradeoffs — because there are real ones

• Losing the key means losing the data, permanently. This is the tradeoff that gets glossed over most: encryption converts "my data got exposed" risk into "if I mismanage this key, my data is gone forever, and no one — including the cloud provider — can get it back" risk. Customer-managed keys hand you real control, and real responsibility. Key rotation, backup, and access policy on the key itself need to be treated with at least as much rigor as the data it protects.
• It's not free at scale. Envelope encryption keeps the overhead low, but a pattern that calls the KMS on every single object operation (rather than caching a data key for reuse) will hit real API rate limits and add real latency under high-throughput workloads. This is a common mistake, not a theoretical one.
• Encryption is not access control. This is the single most common false sense of security: encrypted data that a compromised, over-permissioned IAM identity can still legitimately decrypt and read is not protected from that identity. Encryption defends against someone bypassing your access controls — it does nothing against someone who already has valid access. (More on exactly this in the companion piece on IAM and key vaults.)
• Client-side / end-to-end encryption is the strongest option and the most expensive one operationally. If data is encrypted before it ever reaches the server, the provider genuinely cannot read it — but that also means server-side search, indexing, and most managed-service features that need to operate on the data stop working. It's the right call for data that must never be visible to the platform itself, and a real functional cost everywhere else.
• Post-quantum migration is coming, and almost nobody's started. The same IBM report found 69% of organizations have no post-quantum cryptography project underway, and 61% lack the controls to even monitor their own cryptographic assets. This isn't an urgent fire for most teams today, but "we don't know what's encrypted with what" is exactly the visibility gap that makes a future migration painful — worth knowing that gap exists now, not discovering it during a forced migration later.

Sources: IBM — Cost of a Data Breach Report 2026 · AWS — About AWS KMS keys / envelope encryption · AWS KMS — Client-side encryption