Cloud Encryption Fundamentals: Data at Rest vs Data in Transit

Encryption at rest protects data while it is stored on disk, in a database, or in object storage, while encryption in transit protects data as it moves across a network. Cloud security teams need both, plus a disciplined key management strategy, to keep data unreadable to anyone who should not have access to it.

Encryption sits alongside identity and access management as one of the two pillars every cloud security engineer is expected to master. Employers do not just want someone who can turn on a checkbox in a console. They want someone who understands what encryption actually protects against, how key management works, and where cloud providers differ. This guide covers both encryption states in plain language, explains how AWS, Azure, and Google Cloud handle key management, and points out the mistakes that show up most often in cloud security audits.

What encryption at rest actually protects

Encryption at rest applies to data while it sits on a storage medium: a database volume, an object storage bucket, a snapshot, a backup file, or a log archive. The purpose is narrow but important. If a physical disk is stolen, if a storage volume is misconfigured and exposed, or if a backup is copied to the wrong location, encrypted data remains unreadable without the corresponding key.

The industry standard symmetric algorithm for encryption at rest is AES-256, which is approved under NIST guidance and considered computationally infeasible to brute-force with current technology. NIST Special Publication 800-111 covers guidance for storage encryption technologies, and most cloud-native encryption at rest options (S3 server-side encryption, Azure Storage Service Encryption, Google Cloud's default encryption) implement AES-256 under the hood.

What encryption at rest does not protect against:

• A compromised application or user account that already has legitimate decryption access
• Data exposed through an application-layer vulnerability such as SQL injection
• An overly permissive IAM policy that grants access to both the data and the key

This is why encryption at rest is a control layer, not a complete solution. It has to be paired with least-privilege identity controls, which is covered in more depth in AWS IAM Security Best Practices.

What encryption in transit actually protects

Encryption in transit protects data as it moves between systems: from a user's browser to a web application, from an application server to a database, or between microservices inside a cloud environment. The standard here is Transport Layer Security (TLS). NIST Special Publication 800-52 provides guidelines for TLS implementation, and current best practice is TLS 1.2 as a minimum with TLS 1.3 preferred where supported, since TLS 1.3 removes several legacy cipher suites that were considered weak.

Encryption in transit protects against network-level interception: an attacker on the same network segment, a compromised router, or a man-in-the-middle attempt. It does not protect data once it reaches its destination and is decrypted for processing or storage, which is exactly where encryption at rest picks up.

A common architecture mistake is encrypting traffic between the internet and a load balancer but leaving internal traffic between application tiers unencrypted, on the assumption that "internal" traffic is inherently safe. In a cloud environment, that assumption does not hold. Virtual networks can be misconfigured, and a compromised instance inside the network can still observe unencrypted internal traffic. Zero trust architecture treats internal and external traffic with the same suspicion, an approach covered in Zero Trust in the Cloud: A Practical Architecture Guide.

Key management: the part most people get wrong

Encryption is only as strong as the protection around the encryption keys. This is where most real-world cloud security failures happen: not because AES-256 was broken, but because a key was overly accessible, never rotated, or stored next to the data it was supposed to protect.

Cloud providers solve this with managed key management services and a pattern called envelope encryption. Instead of using a single master key to encrypt every piece of data directly, the provider generates a unique data key for each object or dataset, encrypts the data with that data key, and then encrypts the data key itself with a master key stored in a hardware security module (HSM). To decrypt, the application sends the encrypted data key to the key management service, which returns the plaintext data key only if the caller is authorized. This keeps data keys short-lived, reduces the blast radius of a single key compromise, and generates an audit trail every time a key is used.

How the major cloud key management services compare

Feature	AWS KMS	Azure Key Vault	Google Cloud KMS
Envelope encryption	Supported natively	Supported natively	Supported natively
Key rotation	Automatic rotation available (annual for AWS-managed keys)	Rotation policies with event-driven triggers	Rotation schedules for symmetric keys; not supported for asymmetric keys
HSM backing	FIPS 140-2 validated HSMs by default	FIPS 140-2 Level 2 validated HSMs (Premium tier for HSM-backed keys)	Cloud HSM option available for hardware-backed keys
Key types supported	Symmetric and asymmetric	RSA and Elliptic Curve	Symmetric, asymmetric, and MAC keys
Access control model	IAM policies and key policies	Azure RBAC and access policies	Cloud IAM with fine-grained permissions

The exact defaults and tier options change over time, so always confirm current behavior against each provider's own documentation before making a design decision, especially for regulated workloads that require specific FIPS validation levels.

Common encryption mistakes that show up in audits

• Leaving default encryption off on storage services that support it, especially older object storage buckets or database instances created before encryption-by-default became standard.
• Using the same key for everything, which means a single key compromise affects the entire environment instead of a narrow blast radius.
• Granting broad key access through overly permissive IAM roles, effectively giving decryption rights to anyone with data access, which defeats the separation of duties that key management is supposed to provide.
• Never rotating keys, particularly for long-lived customer-managed keys that were set up once and forgotten.
• Encrypting at rest but not in transit (or the reverse), leaving one half of the data lifecycle exposed.
• Storing secrets and keys in application code or configuration files instead of a dedicated secrets manager or key vault.

None of these are exotic attack techniques. They are configuration and process gaps, which is exactly why encryption and key management show up heavily on cloud security certification exams and in real interview loops, not just as theory but as scenario-based questions about what you would actually configure.

Where encryption fits in a cloud security career

Interviewers rarely ask "what is AES-256." They ask how you would design encryption for a specific scenario: a multi-region database, a data pipeline handling regulated data, or a legacy application being migrated to the cloud. That requires hands-on practice with actual KMS configurations, not just familiarity with the vocabulary.

This is the gap that a lab-based training path is built to close. Working through real encryption and key management scenarios across AWS, Azure, and Google Cloud, inside projects that mirror what a security engineer builds on the job, is what turns "I know what encryption at rest means" into "I can implement it correctly and explain the tradeoffs." The PrimeSec Academy curriculum includes hands-on labs across all three major clouds, and the certifications path maps directly to the concepts covered here, including AWS, Azure, and Google Cloud security credentials.

Frequently asked questions

Is encryption at rest enabled by default in the cloud? Many storage services now enable a baseline level of encryption at rest by default, but the specifics vary by provider, service, and account age. Older resources or non-default configurations may not have it enabled, so it should always be verified rather than assumed, and confirmed against current provider documentation.

What is the difference between a customer-managed key and a provider-managed key? A provider-managed key is created, stored, and rotated entirely by the cloud provider with no customer configuration required. A customer-managed key (CMK) is created within the customer's account, giving the customer control over rotation policy, access permissions, and the ability to disable or delete the key, which also means the customer is responsible for managing it correctly.

Does encrypting data in transit protect against all network attacks? No. TLS protects the confidentiality and integrity of data while it moves between two endpoints, but it does not protect against a compromised endpoint, a misconfigured certificate trust chain, or application-layer vulnerabilities. It is one control among several needed for a secure network architecture.

Why would an organization use envelope encryption instead of encrypting data directly with a master key? Envelope encryption limits how often the master key itself is used, reduces the amount of data any single key is exposed to, and allows data keys to be rotated independently and frequently without re-encrypting the master key infrastructure. It also keeps every decryption request auditable through the key management service.

Which certification covers cloud encryption and key management in the most depth? Encryption and key management appear across most cloud security certifications, including the AWS Certified Security - Specialty exam, Microsoft's Azure security credentials, and Google Cloud's Professional Cloud Security Engineer exam. Coverage depth and exact objectives vary, so check each certifying body's current exam guide before studying.

How much hands-on experience with KMS tools do I need before applying for cloud security roles? Enough to describe, and ideally demonstrate, how you would configure key rotation, restrict key access, and choose between provider-managed and customer-managed keys for a given scenario. Reading documentation is a starting point, but employers generally look for evidence of applied lab work, not just conceptual familiarity.

Encryption and key management are foundational skills that show up in nearly every cloud security role, and they are exactly the kind of hands-on skill that is hard to learn from reading alone. If you want structured labs that walk through real KMS, Key Vault, and Cloud KMS configurations across AWS, Azure, and GCP, see the full PrimeSec Academy curriculum or enroll to get started.

Sources: NIST Computer Security Resource Center, AWS Key Management Service documentation