Skip to content

Encryption at Rest vs In Transit

1. Decision

Implement Encryption in Transit (TLS 1.3, mTLS) across all external client-to-server and internal microservice-to-microservice network paths to prevent eavesdropping and man-in-the-middle attacks; implement Encryption at Rest (AES-256, KMS envelope encryption) across all databases, disk volumes, object storage, and backups to protect data against physical media theft or unauthorized storage access.

2. 30-Second Answer

Comprehensive system security requires encrypting data in motion and data on disk. Encryption in Transit secures network traffic between clients, proxies, microservices, and databases. It uses TLS 1.2 / TLS 1.3 protocol suites (combining asymmetric RSA/ECC key exchanges with fast symmetric AES-GCM bulk data encryption) and Mutual TLS (mTLS) via Service Meshes (Envoy/Istio) for zero-trust internal microservice communication. Encryption at Rest secures stored data on non-volatile media (EBS disk volumes, S3 buckets, PostgreSQL databases, backup snapshots). It utilizes symmetric AES-256 block ciphers combined with Envelope Encryption managed by a Key Management Service (AWS KMS, HashiCorp Vault), protecting plaintext keys under a Master Key hierarchy.

3. Decision Matrix

Option Best For Avoid When Latency Scalability Consistency Operational Complexity
Encryption in Transit (TLS 1.3 / mTLS) All network communication (Client \(\rightarrow\) API Gateway \(\rightarrow\) Microservice \(\rightarrow\) DB), preventing packet sniffing and MITM attacks Legacy internal networks where sub-millisecond overhead is forbidden (use hardware TLS offload) Low (0-1 RTT handshake; sub-millisecond symmetric AES-NI hardware encryption) High (Offloaded via API Gateway & Envoy sidecars) Real-time secure stream Low to Medium
Encryption at Rest (AES-256 / KMS) Database storage volumes, AWS S3 object buckets, automated database snapshots, regulatory compliance (PCI-DSS, HIPAA) Micro-controller embedded devices lacking hardware AES instructions Sub-millisecond (AES-NI CPU hardware acceleration) High (Seamless cloud KMS key management) Persistent encrypted storage Low (Cloud managed); Medium (Self-managed keys)
Application-Level Field Encryption Ultra-sensitive PII data (SSNs, credit card numbers) requiring protection against database admin access Standard non-sensitive fields (prevents database indexing and SQL range scans) Medium (Application CPU encryption & decryption penalty) Bounded by field-level key management App-managed plaintext High

4. Selection Rules

Requirement Best Choice Rationale / Example
Zero-Trust Microservice Network Security Mutual TLS (mTLS) via Service Mesh Envoy sidecar authenticates and encrypts all East-West microservice HTTP/gRPC traffic
Cloud Storage Volume Security (EBS / S3) AWS KMS Envelope Encryption KMS manages Customer Master Key (CMK); encrypts S3 objects with unique Data Keys
Protect Credit Card Data (PCI-DSS Compliance) Application-Level Encryption Encrypt PAN credit card numbers in application memory before saving to PostgreSQL
Fast TLS 1.3 Handshake Connection Resumption TLS 1.3 (0-RTT) TLS 1.3 reduces handshake latency from 2-RTT to 1-RTT (0-RTT on resumption)
Regulatory Data Sovereignty / Compliance Dedicated Cloud HSM Use AWS CloudHSM / Vault HSM to store master encryption keys in FIPS 140-2 Level 3 hardware

5. Tradeoffs

  1. Zero-Trust Security vs Inter-Service Latency Overhead
  2. Gain (mTLS): Every microservice verifies identity via X.509 certificates; prevents network eavesdropping.
  3. Lose (mTLS): Microsecond CPU serialization and TLS handshake overhead per internal hop.
  4. Transparent Disk Encryption vs Application Field Encryption
  5. Gain (Disk): Zero impact on database queries, indexes, or application developer code.
  6. Lose (Disk): A compromised database admin account or SQL injection attack still exposes unencrypted data.
  7. Application Field-Level Encryption vs Database Indexing
  8. Gain (Field): Data remains encrypted even if raw database disk files or snapshots are stolen.
  9. Lose (Field): Destroys SQL range queries (<, >), B-Tree index lookups, and full-text search.
  10. Cloud Managed KMS vs Self-Managed HSM Hardware
  11. Gain (AWS KMS): Seamless integration with S3, EBS, and RDS with zero key management toil.
  12. Lose (AWS KMS): Dependency on cloud vendor KMS API availability and request costs.
  13. Key Rotation Security vs Re-Encryption Performance Penalty
  14. Gain: Regular key rotation limits exposure window if a key is compromised.
  15. Lose: Re-encrypting multi-terabyte datasets under a new key consumes massive background I/O.

6. Interview Counter Questions

  1. How does TLS 1.3 improve upon TLS 1.2 in terms of latency and cipher suite security?
  2. What is Envelope Encryption and why is it used in AWS KMS and HashiCorp Vault?
  3. How does Mutual TLS (mTLS) work for internal microservices using X.509 certificates?
  4. What is the difference between AES-CBC and AES-GCM cipher modes?
  5. Why does Application-Level Field Encryption break database B-Tree index range scans?
  6. How does AES-NI (Advanced Encryption Standard New Instructions) accelerate encryption on modern CPUs?
  7. What is Perfect Forward Secrecy (PFS) and why is Ephemeral Diffie-Hellman (ECDHE) critical?
  8. How do you rotate database encryption keys automatically without downtime?
  9. What is a Hardware Security Module (HSM) and when is FIPS 140-2 Level 3 compliance required?
  10. How do you handle searchable encryption for encrypted sensitive attributes (Deterministic Encryption / Blind Index)?

7. Gold Standard Answers

  1. TLS 1.3 reduces handshake from 2-RTT to 1-RTT (and 0-RTT for resumption), removes vulnerable legacy ciphers (RSA key exchange, SHA-1, CBC), and mandates Perfect Forward Secrecy (ECDHE).
  2. Envelope Encryption encrypts data with a local Data Encryption Key (DEK), and encrypts the DEK with a master Key Encryption Key (KEK) managed by KMS. Avoids sending heavy data payloads over network to KMS.
  3. In mTLS, both client and server present X.509 digital certificates. The server authenticates the client, and the client authenticates the server, establishing an encrypted, mutually authenticated TLS tunnel.
  4. AES-CBC is an unauthenticated cipher mode vulnerable to padding oracle attacks. AES-GCM (Galois/Counter Mode) provides Authenticated Encryption with Associated Data (AEAD), guaranteeing both confidentiality and tamper detection.
  5. Encrypting a value produces a pseudo-random ciphertext byte array. Random ciphertexts ruin B-Tree sort ordering (WHERE age > 30 fails) and destroy prefix matching.
  6. AES-NI is a dedicated hardware instruction set embedded in Intel/AMD/ARM CPUs. It executes AES encryption/decryption directly in CPU silicon, reducing encryption overhead to sub-nanosecond levels.
  7. PFS ensures that compromising a server's long-term private key today cannot decrypt historical recorded network traffic. Achieved using Ephemeral Diffie-Hellman (ECDHE) key exchange per session.
  8. Re-keying: KMS automatically rotates the master KEK annually. Old data remains encrypted with DEKs; DEKs are re-wrapped under the new KEK without re-encrypting underlying raw disk blocks.
  9. An HSM is a tamper-resistant physical hardware device that generates and stores cryptographic keys. FIPS 140-2 Level 3 requires physical tamper-detection mechanisms (wiping keys if physical casing is opened).
  10. Use a Blind Index: Store a salted SHA-256 hash of the sensitive attribute in a separate column (email_bindex). Query using the hash (WHERE email_bindex = hash(input)) while keeping the main column AES-GCM encrypted.

8. Common Mistakes

  • Using TLS only on public edge endpoints while transmitting plain HTTP traffic unencrypted over internal microservice networks.
  • Implementing custom cryptographic algorithms instead of battle-tested standard libraries (OpenSSL, sodium, Tink).
  • Using AES in ECB (Electronic Codebook) mode, which leaks visual patterns in encrypted data payloads.
  • Encrypting every single database field at the application level, destroying database index performance and search capabilities.
  • Storing master encryption keys in plain text inside source code repositories or environment variables.

9. Keywords

Encryption in Transit, Encryption at Rest, TLS 1.3, mTLS, Service Mesh, Envoy, AES-256, AES-GCM, Envelope Encryption, KMS, DEK, KEK, AES-NI, Perfect Forward Secrecy (PFS), ECDHE, HSM, FIPS 140-2, Blind Index, AEAD.

10. Cheat Sheet

  • In Transit: Use TLS 1.3 for public edge; use mTLS (Envoy sidecars) for East-West internal microservices.
  • At Rest: Use AES-256-GCM with Envelope Encryption managed by AWS KMS or HashiCorp Vault.
  • Envelope Architecture: Plaintext Data \(\xrightarrow{\text{encrypted with DEK}}\) Encrypted Data; DEK \(\xrightarrow{\text{encrypted with KMS KEK}}\) Encrypted DEK.
  • Hardware Acceleration: CPU AES-NI hardware instructions reduce AES encryption overhead to near zero.
  • Cipher Mode: Always use AES-GCM (AEAD authenticated encryption). NEVER use AES-ECB!
  • Searchable Encrypted Data: Use a Blind Index (salted SHA-256 hash column) to enable exact SQL lookups on encrypted fields.

11. Related Decisions