Encryption at Rest vs In Transit — The Visual Guide

“We encrypt everything” is something every organization claims. But when you dig in, you often find gaps: data encrypted in S3 but sent unencrypted between services. Database connections using TLS but backups stored in plaintext on a shared drive. Encryption is only effective when it covers both states: at rest (stored) and in transit (moving).

These are fundamentally different problems with different solutions. Understanding what each protects — and what it doesn’t — is the first step to actually encrypting everything.

At Rest vs In Transit

Encryption at rest protects data when it’s sitting still. Someone steals a hard drive, gains access to your S3 bucket, or finds an unprotected database backup — the data is gibberish without the decryption key. Encryption in transit protects data while it’s moving. Someone intercepts network traffic between your browser and server, or between two microservices — they see encrypted packets, not actual data.

Encryption — At Rest vs In Transit

At Rest

Protects stored data: databases, disks, backups, S3 buckets

Data → Encrypt with AES-256 → Store ciphertext

Retrieve ciphertext → Decrypt with key → Data

KMS, LUKS, BitLocker, dm-crypt, Transparent Data Encryption

Protects against: disk theft, unauthorized storage access, backup exposure

In Transit

Protects moving data: API calls, browser traffic, service-to-service

Client → TLS handshake → Encrypted channel

Data flows encrypted → Decrypted at destination

TLS 1.3, mTLS, HTTPS, VPN, WireGuard, SSH tunnels

Protects against: eavesdropping, MITM attacks, packet sniffing

🔐 Both Required

Encryption at rest without in transit = data encrypted on disk but sent in cleartext over the wire. In transit without at rest = data encrypted during transfer but readable by anyone with disk access.

The implementation gap I see most often is internal traffic. Teams configure HTTPS for their public endpoints but leave service-to-service communication unencrypted because “it’s inside our VPC.” That worked when networks were trusted. In a zero-trust world, you encrypt everything — especially internal traffic, because that’s where attackers move laterally after initial access.

For encryption at rest, the critical decision is key management. The encryption itself is straightforward — AES-256 is the standard. The hard part is who holds the keys, how they’re rotated, and what happens when someone leaves the team. Use a managed KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) rather than managing keys yourself. Self-managed key infrastructure is a full-time job and a single point of failure.

For encryption in transit, TLS 1.3 is the standard. Enforce it everywhere — don’t allow fallback to older versions. For service-to-service inside Kubernetes, mTLS through a service mesh or cert-manager handles certificate issuance and rotation automatically. The days of manually managing certificates are over.