Cloud Encryption — Explain encryption at rest and in transit in cloud services (conceptual)

Historical Context & Motivation

The challenge of protecting sensitive information during storage and transmission predates cloud computing by decades. When organizations began migrating workloads from on-premises data centers to third-party cloud service providers (CSPs) in the late 2000s, a fundamental trust problem emerged: how can an enterprise ensure the confidentiality and integrity of its data when the underlying hardware, network fabric, and administrative access belong to another entity? Encryption — the mathematical transformation of plaintext into ciphertext using a secret key — became the primary control for addressing this concern, evolving from a military and diplomatic tool into a ubiquitous infrastructure layer embedded in every major cloud platform.

This historical trajectory reveals a recurring pattern: every expansion of the attack surface — from local disks to network links to shared multi-tenant infrastructure — has been met with a corresponding expansion of cryptographic controls. The central question that this lesson addresses is: what are the distinct threat models, mechanisms, and trade-offs of encrypting data at rest versus data in transit within cloud environments?

Core Principles & Definitions

Before examining encryption at rest and in transit individually, it is essential to establish the foundational concepts that underlie both. Cloud encryption is not a single monolithic feature but rather a layered architecture involving multiple actors — the data owner, the cloud service provider, and potentially third-party key management services — each playing a distinct role in key generation, storage, rotation, and access control. The following principles form the conceptual bedrock of the entire domain.

Visual Explanation — Data Lifecycle in the Cloud

The following diagram illustrates the two primary encryption domains within a typical cloud architecture. On the left, a client application communicates with the cloud over a public network secured by TLS (encryption in transit). On the right, the cloud storage subsystem protects persisted data with AES-256 encryption at rest. The key management service sits centrally, issuing and managing keys for both domains. Observe how data transitions from plaintext inside the client, to ciphertext on the wire, back to plaintext in the application tier, and finally to ciphertext on disk — each transition represents a potential vulnerability that encryption addresses.

Notice the critical gap between the in-transit and at-rest encryption zones: the application tier processes data in plaintext in memory. This is by design — the application must be able to read and manipulate the data to perform its function. However, this gap is precisely why encryption in use (sometimes called confidential computing) is an active research area. Technologies like Intel SGX and AMD SEV attempt to protect data even while it is being processed, but they remain outside the mainstream scope of most cloud encryption discussions today.

How Cloud Encryption Works — Mechanisms in Depth

Encryption at Rest

When a cloud service encrypts data at rest, the goal is to render stored data unintelligible to anyone who gains physical or logical access to the storage medium without possessing the corresponding decryption key. This includes scenarios such as a stolen hard drive, an unauthorized database administrator, or a government subpoena served to the cloud provider. The dominant algorithm is AES-256 operating in Galois/Counter Mode (GCM), which provides both confidentiality and integrity through authenticated encryption. The CSP typically implements encryption at one or more layers: the storage controller (full-disk encryption), the object/block storage service (server-side encryption), or the client SDK (client-side encryption before data leaves the tenant's application).

Envelope Encryption in Detail

Rather than encrypting every stored object directly with a master key, cloud providers employ envelope encryption. A unique data encryption key (DEK) is generated per object (or per chunk), and the DEK itself is then encrypted ("wrapped") by a key encryption key (KEK) stored in the KMS. The wrapped DEK is stored alongside the ciphertext. To decrypt, the application first sends the wrapped DEK to the KMS for unwrapping, receives the plaintext DEK, and then uses it locally to decrypt the data. This architecture means the master key (KEK) never leaves the HSM, limiting its exposure surface dramatically.

Encryption in Transit

Encryption in transit protects data as it moves between the client and the cloud service, between microservices within the cloud, or between data centers in a multi-region deployment. The foundational protocol is Transport Layer Security (TLS), currently at version 1.3 (RFC 8446). A TLS connection is established via a handshake that combines asymmetric and symmetric cryptography: the client and server use asymmetric algorithms (e.g., ECDHE for key agreement, RSA or ECDSA for authentication) to securely negotiate a shared symmetric session key, which is then used to encrypt the application-layer payload using AES-GCM or ChaCha20-Poly1305. This hybrid approach leverages the strengths of both families — asymmetric for key exchange, symmetric for bulk throughput.

Encryption Models — Who Holds the Keys?

A crucial dimension of cloud encryption is not just which algorithm is used, but who controls the encryption keys. The key custodian determines the trust boundary: if the CSP holds all the keys, the CSP can technically access your plaintext data. Conversely, if the customer holds all the keys, the CSP cannot offer value-added services that require reading the data (e.g., indexing, compression, deduplication). Cloud providers typically offer multiple models along this spectrum, each with distinct security, usability, and cost trade-offs.

Worked Example — Designing an Encryption Architecture

Consider a healthcare startup building a patient records application on AWS. The application stores protected health information (PHI) in Amazon S3 and communicates with a React front-end via an API Gateway. Federal regulations (HIPAA) require encryption of PHI both at rest and in transit. The security team must choose appropriate encryption models and document the architecture.

Strengths, Limitations & Trade-offs

Cloud encryption is a powerful control, but it is not a panacea. Understanding its limitations is as important as understanding its strengths, because overestimating what encryption provides can lead to dangerous false confidence. The following table contrasts the two primary encryption domains across several dimensions.

Connection to Advanced Topics — Beyond At-Rest and In-Transit

The at-rest/in-transit dichotomy, while foundational, leaves an important gap: data that is being actively processed in memory is typically unencrypted. This has driven the emergence of confidential computing, a paradigm that uses hardware-based Trusted Execution Environments (TEEs) such as Intel SGX, AMD SEV-SNP, and ARM TrustZone to protect data even during computation. Additionally, advances in homomorphic encryption (FHE) promise the ability to perform computations on ciphertext directly, though current schemes remain orders of magnitude slower than plaintext operations and are not yet practical for general workloads. The table below positions the concepts covered in this lesson relative to these advanced approaches.

As you advance in cloud security, consider how encryption in use completes the triad and how the shift toward zero-trust architectures — where every network segment is treated as hostile — further blurs the traditional at-rest/in-transit boundary. Service meshes, for example, apply mTLS between every microservice, effectively making all internal communication encrypted in transit by default, while confidential computing extends the at-rest guarantee into the CPU cache and registers.

Practice Problems

Lesson Summary