Securing Data in Transit: Encryption Practices in Cloud

Securing data in the cloud is critical in today’s interconnected world. Whether data is in motion (in-transit) or at rest (in storage), strong encryption ensures that sensitive information remains confidential and integral. In this newsletter, we dive deep into how leading cloud platforms, AWS and Azure, protect data through encryption. We’ll explore encryption-in-transit vs. at-rest, delve into key management services on each platform, examine the algorithms at play (including emerging post-quantum approaches), and illustrate practical use cases. This guide is aimed at cloud architects, cybersecurity professionals, CTOs, and IT leaders, and is written in a clear, engaging style to help concepts stick.

Encryption In Transit and At Rest

Data encryption comes in two flavors: protecting data as it moves (in-transit) and protecting data where it rests (at-rest). In-transit encryption usually means using protocols like TLS/SSL or IPsec to secure network traffic. At-rest encryption means encrypting stored data, files, disks, databases, so that even if storage media is compromised, the data remains unreadable without keys. Cloud providers handle both, often by default or through integrated services.

• In Transit (Data-In-Flight): Data in transit typically travels over networks or between services. Cloud providers enforce TLS (Transport Layer Security) for API endpoints, web consoles, and service connections. This ensures a “secure tunnel” between clients and services. For example, AWS and Azure services use TLS 1.2 or higher for all their APIs. Modern TLS uses ephemeral Diffie–Hellman key exchange to provide forward secrecy (making each session’s keys independent). Azure explicitly negotiates TLS with 2048-bit RSA keys and forward secrecy, protecting sessions from interception. Both clouds also encrypt their internal networks: AWS automatically encrypts all data sent between regions or availability zones at the physical layer, and Azure’s infrastructure similarly secures inter-data-center links (preventing wiretapping attacks on internal links).
• At Rest (Data-In-Storage): Data at rest lives on disks, volumes, database files, etc. Both AWS and Azure offer built-in encryption for storage. By default, services like AWS S3, EBS, and RDS, or Azure Blob Storage, managed disks, and SQL Database, are protected using encryption. For example, AWS S3 automatically encrypts all new objects with AES-256 (SSE-S3) unless you configure otherwise. AWS EBS volumes can be encrypted on creation using AWS KMS; once encrypted, any snapshots or copies of those volumes remain encrypted. On the Azure side, managed disks are encrypted at rest with 256-bit AES by default, and Blob storage uses AES-256 under the hood. Databases follow suit: Azure SQL TDE encrypts files with AES (or optionally Triple-DES) and AWS RDS supports encryption using AES-256. In summary, all major storage services encrypt data-at-rest, typically with AES-256, so that customers don’t have to build encryption into every application. Customers control the keys in many cases (see key management below), but even service-managed keys ensure a strong baseline of protection.

AWS: In-Transit & At-Rest Encryption

Amazon Web Services (AWS) provides encryption everywhere. All AWS services allow encryption of data-in-transit and data-at-rest. In practice, this means:

• In Transit: Every AWS API endpoint and service endpoint uses HTTPS/TLS. AWS enforces TLS 1.2+ and now widely supports TLS 1.3 across services. For example, connectivity to S3, DynamoDB, Lambda, and all AWS APIs goes over TLS. AWS recommends clients use cipher suites with perfect forward secrecy (e.g. ECDHE, DHE). Internally, AWS encrypts inter-region and inter-AZ traffic at the physical level; even packet data on the AWS backbone is encrypted before leaving datacenter networks. Customers can further secure network traffic by using AWS PrivateLink, VPN (IPsec), or Direct Connect (with MACsec encryption) to keep data private on the network.
• At Rest: For storage, AWS uses strong block ciphers, almost always AES-256. For instance, Amazon S3 server-side encryption (SSE) uses AES-256 to encrypt objects. S3 offers options: SSE-S3 (AES-256 with Amazon-managed keys), SSE-KMS (AES-256 with keys you control in AWS KMS), or even client-side encryption before upload. Amazon EBS volumes (persistent block storage for EC2) can be encrypted with a KMS-managed AES-256 key on creation. EBS encryption is seamless: you choose a KMS key (or use the default), and all data written to the volume is encrypted at the hypervisor level with that key. Snapshots of encrypted volumes remain encrypted under the same key. Similarly, RDS databases can be encrypted with KMS-managed keys, and EFS file systems support encryption at rest. Even ephemeral instance storage is encrypted: for example, NVMe instance store volumes use XTS-AES-256 hardware encryption per volume. In all these cases, AES-256 is the workhorse cipher. AWS KMS-driven services like DynamoDB and Redshift also encrypt data-at-rest with AES-256 under the hood.

In AWS, the common model is envelope encryption: the actual data is encrypted with a data key (AES-256-GCM) and that key is itself encrypted under a master key in KMS. AWS KMS thus serves as a central key manager for all these services, allowing fine-grained control over keys and policies. The result is comprehensive coverage: your data is protected on the wire by TLS and at rest by AES-256 (or similar) without requiring manual cryptography.

Azure: In-Flight & At-Rest Encryption

Microsoft Azure takes a similarly comprehensive approach. Azure secures data in flight with TLS and data at rest with AES-based encryption:

• In Flight: All interactions with Azure services use HTTPS/TLS by default. For example, the Azure Portal, REST APIs, and SDKs require TLS 1.2 or higher. Azure’s front-end infrastructure negotiates TLS with customers; connections use forward secrecy and typically RSA-2048 certificates by default. Azure Front Door and Application Gateway (its global load-balancers) support TLS 1.2 and 1.3, ensuring modern ciphers like AES-GCM are used. The Azure documentation explicitly notes that TLS protects data “when it’s traveling between the cloud services and customers.” Forward secrecy and RSA-2048 are used, making in-flight interception difficult. Customers can also employ VPN Gateway/IPsec or ExpressRoute with MACsec for site-to-site encryption into Azure. Internally, Azure data center networks encrypt traffic as well; network devices often encrypt switch-to-switch traffic to prevent wiretapping, though specific cipher details are managed by Microsoft.
• At Rest: Azure encrypts storage by default. All new Managed Disks (VM OS and data disks) are automatically encrypted with AES-256 using Microsoft-managed keys. Customers can opt to bring their own keys (BYOK) in Azure Key Vault, in which case the disk data key (AES-256) is wrapped (encrypted) by a Key Vault key. Azure Blob and File Storage have Server-Side Encryption (SSE) that also uses AES-256. Databases follow suit: Azure SQL Database uses Transparent Data Encryption (TDE) which encrypts data and log files with AES (or 3DES) at the page level. Azure Cosmos DB, Data Lake, and other services likewise encrypt data at rest. Like AWS, Azure’s model is envelope encryption: data is encrypted with a symmetric key (AES-256), and that key is protected by a root key in Key Vault. By default Microsoft provides and rotates those keys, or customers can manage the keys themselves. The result is that in Azure all persistent data is encrypted by default, isolating data-in-memory from data-on-disk and reducing exposure.

AWS Key Management Service (KMS)

To enable all this encryption, AWS provides the Key Management Service (KMS) as the centralized key vault. AWS KMS is a managed service that creates, stores, and uses cryptographic keys in Hardware Security Modules (HSMs). Its architecture and features deserve a close look:

• Architecture: AWS KMS is built as a tiered, regional service. Client requests (Encrypt, Decrypt, GenerateDataKey, etc.) come in over TLS to KMS web endpoints. These endpoints authenticate and authorize requests with IAM, then forward valid requests to a cluster of multi-tenant Hardware Security Modules (HSMs) behind the scenes. The HSMs are FIPS 140-2 validated and isolate key material: KMS stores only encrypted keys outside the HSM. As the AWS whitepaper notes, “plaintext keys cannot be used outside the HSM by anyone, including AWS employees”. The HSMs do all cryptographic operations (AES encrypt/decrypt, RSA sign, etc.) on behalf of the customer’s key, and return only ciphertext or signatures. This design protects keys even from AWS staff. Each AWS region has its own separate KMS deployment in multiple Availability Zones (3+ AZs per region). AWS KMS provides a 99.999% availability SLA and is designed for zero planned downtime. Multi-Region Keys allow synchronizing key material across regions if desired. In short, AWS KMS gives you a highly available, scalable, multi-AZ key vault.
• Multi-Tenant & Resilience: Internally, AWS KMS uses a multi-tenant HSM design to handle huge request volumes while keeping keys confidential. Key material is encrypted at rest even within KMS. When a new customer key is created, the plaintext key is immediately encrypted under a root key inside an HSM, then stored in secure backing storage. When that key is needed later, it is fetched and decrypted just in time inside an HSM. The effect is layers of envelope encryption within KMS itself. AWS ensures that any key or policy change replicates across all regional hosts, so any KMS server in the region has the info to process requests. Importantly, KMS operators cannot extract plain keys: requests to use keys must be signed by valid AWS credentials and are only decrypted momentarily in a protected HSM. This architecture provides both resilience (multi-AZ copies of keys and keys stored encrypted) and confidentiality (root keys sealed in tamper-responding HSMs).
• Key Types & Algorithms: AWS KMS supports symmetric and asymmetric keys. A symmetric KMS key is a 256-bit AES key used for encryption/decryption and HMAC (e.g. for KMS data keys). Asymmetric KMS keys (customer-managed only) come in various flavors: RSA (2048, 3072, 4096-bit) and ECC (curves P-256, P-384, P-521, secp256k1). AWS also supports special SM2 keys in Chinese regions. For symmetric operations, KMS uses AES-256 Galois/Counter Mode (GCM) for authenticated encryption. For example, when you call GenerateDataKey, KMS produces a plaintext data key and an AES-GCM ciphertext of it under the master key. For asymmetric operations, KMS supports RSA-OAEP (with SHA-1 or SHA-256) for encryption/decryption and RSA-PSS or PKCS#1 v1.5 for signing. It also supports elliptic curve key agreements (ECDH) and ECDSA signatures. Internally, KMS uses NIST-approved algorithms and can switch them if needed. It also employs an HMAC-SHA256-based key derivation (per-call key derivation) to derive unique keys for each encryption use. The cryptographic stack is FIPS 140-2 compliant and regularly audited.
• Key Policies & Best Practices: In KMS, every key has a key policy (an IAM-like policy) that controls who can use or manage it. Best practice is to grant least privilege: only allow specific IAM roles or users to encrypt/decrypt with a key, and separate roles for key management (e.g. rotation). AWS recommends defining data classification first, then enforcing encryption for sensitive data in transit and at rest as a policy. For example, you might enforce that S3 buckets only accept PUT requests over TLS 1.2, and that any object is encrypted with a KMS key. Use AWS Certificate Manager (ACM) for SSL certificates, and KMS for symmetric keys. Isolate your keys by purpose: don’t mix many workloads under one key if security boundaries differ. Enable logging (CloudTrail) for all KMS actions to audit key usage. Use AWS PrivateLink or VPC endpoints for KMS to avoid traffic leaving your VPC.
• Key Lifecycle: KMS keys go through states: enabled, disabled, pending deletion. You create a key (either symmetric or asymmetric) and then can rotate it or schedule deletion. AWS KMS automatically generates the key material for you (unless you import your own). You can also import key material into a KMS key (for BYOK scenarios) or create keys in an AWS CloudHSM cluster (custom key store). Once created, a key’s usage is audited, and you can disable a key to prevent use without deleting it. To rotate keys, AWS KMS offers automatic annual rotation for symmetric keys. You can configure a customer key to rotate at a chosen interval (90–2560 days). By default, rotation is disabled for new customer keys, but if you enable it, AWS KMS will create a new key version every year. When keys are rotated, KMS retains older key versions so that existing ciphertext can still be decrypted without re-encryption. For asymmetric or imported keys, you must manage rotation manually (e.g. by creating a new key and re-encrypting data). When a key is no longer needed, you can schedule its deletion (7–30 day waiting period); during this period you can cancel if needed, but once deleted all data encrypted under it becomes irrecoverable. AWS KMS also supports Multi-Region Keys: you can mark two symmetric keys as replicas (primary and replica) in different AWS Regions. These multi-Region keys share the same key material and ID, so you can encrypt data in one region and decrypt in another without re-encrypting or cross-region calls. This is useful for global DR and active-active architectures.
• Key Operations: Using keys in KMS is straightforward. You call the KMS API (via AWS SDK or CLI) to Encrypt, Decrypt, GenerateDataKey, or Sign/Verify. Applications can use envelope encryption: obtain a data key (plaintext+ciphertext) via KMS, use the plaintext AES key locally to encrypt large data, then store the encrypted data and the encrypted data key together. Decryption reverses the process with KMS. KMS also integrates with services like S3, EBS, RDS so that you can simply specify a KMS key and AWS handles encryption automatically. AWS KMS supports these operations natively; for example, you can “encrypt” data up to 4 KB directly with a symmetric key, or if larger, use a data key. For signing, you can use asymmetric KMS keys to sign payloads (e.g. code signing), and KMS will use RSA-PSS or ECDSA internally. Overall, AWS KMS provides a central, hardened key management plane. You should treat KMS keys as highly sensitive credentials – rotate them regularly, restrict usage, and audit access.

Azure Key Management: Azure Key Vault

Azure’s answer to key management is Azure Key Vault (with an option for Managed HSM). Key Vault is a multi-tenant key management service that stores keys, secrets, and certificates. Its features roughly mirror AWS KMS, but with Azure’s own model:

• Architecture (Vaults vs Managed HSM): Azure Key Vault can operate in two modes. A standard Key Vault is a zone-redundant, managed service that can store “software-protected” keys or HSM-protected keys (in the Premium SKU). In contrast, Azure Managed HSM is a single-tenant, fully hardware-backed key store where keys live in dedicated HSM pools you control. As Microsoft notes, “Keys stored in vaults benefit from robust protection using FIPS 140 validated HSMs”. In practice, a normal (non-HSM) key vault uses a mix of HSMs under the hood (Platform 1 or 2) to protect keys at FIPS 140-2/3 levels, whereas a Managed HSM is a true dedicated HSM device (FIPS 140-3 Level 3) for each customer. A Premium Key Vault’s “HSM Platform 2” uses FIPS 140-3 Level 3 HSMs. In either case, only the Key Vault service can unwrap key material; Microsoft employees cannot export your key in plaintext. Vaults are globally available (you choose a region), replicated across zones, and accessible via HTTPS REST endpoints. Key Vault supports RBAC and access policies for control. Managed HSM adds extra isolation (so that even other vaults in your tenant cannot see those HSM keys).
• Key Types & Algorithms: Azure Key Vault supports RSA keys (2048, 3072, 4096-bit) and ECC keys (curves P-256, P-384, P-521, and secp256k1). In a Premium vault or Managed HSM, you can generate or import RSA or EC keys. Managed HSM also supports symmetric keys (AES 128/192/256) for raw symmetric encryption and key wrap. Azure’s encryption operations match JSON Web Key algorithms: for example, RSA keys can do RSA-OAEP (with SHA-256) for wrap/unwrap and RSA-PSS or RS256/384/512 for signing. EC keys use elliptic curve ECDSA signatures (ES256, ES384, etc). For symmetric operations in Managed HSM, Key Vault supports AES key wrap (AES-KW) and AES-GCM for encryption. In practice, this means you can encrypt small payloads or wrap data keys using AES or RSA within Key Vault, and sign or verify hashes with RSA/ECDSA. All algorithms are industry-standard (NIST, ISO, RFC). Azure also notes that AES-256 (in GCM or CBC) is considered quantum-resistant (it references the US CNSS guidance). Internally, Key Vault uses Microsoft’s cryptographic libraries in HSMs.
• Key Vault Best Practices: Best practice in Azure is to isolate keys per application or environment. Microsoft recommends one vault per app/environment/region to minimize blast radius. Use access policies or Azure RBAC to tightly control which identities (users, managed identities, service principals) can get or list each key. Enable soft delete and purge protection so that even if a vault or key is accidentally deleted, it can be recovered. Use network restrictions (service endpoints or private endpoints) to limit Vault access to authorized subnets. Monitor Azure Monitor logs or Sentinel for all key usage and changes. For rotation, Key Vault supports rotation policies. You can set a key to auto-rotate monthly/quarterly, etc. Azure’s recommendation is to rotate keys at least every 2 years. Also, separate duties: have one team or service principal manage keys (Key Vault Crypto Officer role) and another use them (Crypto User role). Enforce logging of all key retrieval and cryptographic operations for audit. Use managed identities and avoid embedding key references in code; let Azure SDKs fetch keys via managed identity.
• Key Lifecycle: Keys in Key Vault have versions. When you “rotate” a key, Azure creates a new version of that key under the same name. Older versions remain, so existing encrypted data (under old key versions) can still be decrypted until those versions are retired. You can update a key’s metadata (activation date, expiration date) anytime. A key can be disabled to temporarily block use. To delete a key, you call the Delete API; the key goes into a soft-delete state (recoverable for up to 90 days by default), then eventually permanently purged. Azure also lets you backup a key (export in encrypted form) and restore it to the same or another vault. For HSM keys, Azure Managed HSM supports importing key material (BYOK) and generating keys in the HSM. Importantly, key material (especially for Managed HSM) never leaves the secure module unencrypted; even when you import, you package it with Azure’s encryption protocol.
• Rotation: As mentioned, Key Vault now has built-in auto-rotation. You can attach a rotation policy to a key (e.g. rotate every 30 days). When due, Key Vault will create a new version and (optionally) disable the old version. Key Vault alerts and Azure Policies can enforce rotation. Unlike AWS (which only rotates managed symmetric CMKs), Azure can rotate symmetric and asymmetric keys alike using this policy. The policy feature is relatively new (GA in 2021) and integrates with Azure Functions or Logic Apps if you need to propagate the new key (for example, to re-encrypt data).
• Key Vault Operations: Using Key Vault, your applications call the Key Vault API (or use SDK) to do cryptographic operations. For example, you might call wrapKey to encrypt a data key with an RSA key in the vault, or encrypt/decrypt for small data payloads. Certificates can also be created and auto-managed by Key Vault. Importantly, for secrecy, Azure KB recommends performing “unwrap” or heavy crypto on the client side when possible; Key Vault’s HSM Ops have quota, so complex operations should be batched. For higher throughput, use an Azure Managed HSM if you need HSM-scale crypto operations. Key Vault can integrate with Azure services: for instance, you can encrypt Azure SQL TDE keys in Key Vault, or configure Azure Storage to use a Key Vault key for server-side encryption, or have Azure Kubernetes fetch secrets via Key Vault Provider. Essentially, Key Vault is the central trust anchor for Azure’s CMK scenario.

Encryption Algorithms: AWS vs Azure

Both AWS and Azure use similar cryptographic primitives for protecting data, but let’s enumerate the key algorithms and protocols:

• Transport (In-Transit) Encryption: AWS and Azure both rely on TLS for securing traffic. The common ciphers are AES-GCM or AES-CBC for bulk encryption, with HMAC-SHA for integrity. By default, connections use AES-256-GCM (or sometimes AES-128-GCM) in TLS, along with ECDHE or DHE for key exchange. For example, AWS KMS endpoints accept only TLS ciphers that provide forward secrecy. Azure Front Door and other gateways support TLS 1.3, which by design uses AEAD ciphers (AES-GCM or ChaCha20-Poly1305) and X25519 or ECDH key exchange. Both clouds use RSA-2048 or stronger certificates for authentication of endpoints. Asymmetric key exchange: AWS often uses ECDH (Elliptic Curve Diffie-Hellman) in TLS, and Azure similarly uses ECDHE (elliptic-curve) or DHE. In practice, you needn’t specify algorithms for in-flight; enabling TLS 1.2/1.3 ensures AES-256 encryption with SHA256 integrity under the hood. AWS recently announced >80% of its API endpoints support TLS 1.3, meaning customers get even faster ciphersuites (zero-round-trip key agreement).
• Symmetric Encryption (At-Rest): For data at rest, AES-256 is the de facto standard. AWS uses AES-256 in GCM or CBC modes for S3, EBS, RDS, etc. In AWS KMS, AES-256-GCM is used for envelope encryption of data and keys. Azure similarly uses AES-256 everywhere: Blob Storage SSE, Disk encryption, SQL TDE (AES). Azure also allows AES key wrap (RFC3394) in Key Vault. Note that both clouds’ symmetric AES-256 provides an “effective 128-bit” strength against quantum attacks, but is still considered secure today.
• Asymmetric Encryption and Signatures: Both AWS and Azure support RSA and Elliptic Curve algorithms in their key services. AWS KMS supports RSA-OAEP (with SHA-1/256) for encrypt/decrypt, and RSA-PSS or PKCS1v1.5 for signatures. Key sizes up to 4096 bits are available. Azure Key Vault supports RSA-OAEP 256 (OAEP with SHA-256) and deprecation of PKCS1 v1.5, and RSA-PSS/RSASSA-PKCS1 for signing. For ECC, AWS KMS supports ECDSA on curves P-256, P-384, P-521 and even secp256k1. Azure supports ECDSA (ES256/384/512) on the same NIST curves. Both platforms internally use HMAC-SHA256 (and other SHA variants) in signatures and key derivations. In transit (TLS), AWS and Azure rely on the elliptical DHE/ECDHE handshake for key exchange. In essence, both clouds give you industry-standard asymmetric crypto: RSA 2048-4096, ECDSA (P-256 etc), and even specialized Chinese SM2 in AWS.
• Key Wrapping & Data Keys: A common pattern is envelope encryption. AWS KMS encrypts data keys with AES-GCM; Azure Key Vault provides AES-KW (key wrap) operations. Both clouds’ key services act as key-encrypting-key (KEK) stores. For example, Azure managed disks will generate a random AES DEK, encrypt disk data with it, then use your key (RSA in Key Vault) to wrap the DEK. Similarly, AWS S3 SSE-KMS will generate a data key, encrypt it under the CMK, and use the DEK to encrypt your object. These symmetric encryption algorithms are chosen for performance and are considered safe (AES-256 in GCM mode provides confidentiality and integrity).
• Special Ciphers (Optional): AWS KMS supports HMAC algorithms (SHA-256, SHA-512) for authentication codes, if you need to generate MACs. Azure Key Vault Managed HSM also supports HMAC keys. For streaming or bulk data, you might also find algorithms like ChaCha20-Poly1305 on TLS connections, but at rest AES dominates.

In summary, AWS and Azure use virtually the same set of strong ciphers: AES-256 for bulk encryption, ECDHE/ChaCha for ephemeral keys, and RSA/ECDSA for authentication. They ensure FIPS-compliance and regularly update cipher suites.

Post-Quantum (Quantum-Resistant) Encryption

Quantum computing threatens classical public-key crypto (RSA, ECC). Both AWS and Azure are proactively preparing post-quantum cryptography (PQC) to protect data long-term.

• AWS Approach: AWS has begun offering hybrid post-quantum TLS. For example, AWS KMS supports a hybrid key exchange combining ECDH with a post-quantum KEM (Module Lattice KEM or ML-KEM, specifically CRYSTALS-Kyber). In practice, this means when you enable PQ TLS (via the AWS Common Runtime SDK), your TLS handshake will do both ECDH and Kyber key exchanges in parallel, then XOR or combine the results. This hybrid suite (ECDH+ML-KEM) was the first standard by NIST for post-quantum key agreement. AWS’s s2n-tls library supports this so calls to KMS or other AWS endpoints can use it if configured. The benefit is that even if a future quantum computer breaks ECDH, the Kyber part keeps the session secure. Inside KMS itself, AWS already uses AES-256-GCM for actual data encryption, which NIST considers quantum-resistant (AES-256 has an effective 128-bit post-quantum security). AWS has publicly noted that it is collaborating with the crypto community and AWS service endpoints are being updated with post-quantum-safe cipher suites.
• Azure/Microsoft Approach: Microsoft (Azure’s parent) is also investing heavily in PQC. Azure’s current encryption uses AES-256 (already quantum-hardened) and RSA/ECDH, but Microsoft is integrating PQC algorithms into its platforms. For instance, Microsoft has added the LMS (Leighton-Micali Signature) scheme and Dilithium (a lattice-based signature) to its SymCrypt library. They are also working with the IETF on hybrid key exchange (for TLS and other protocols). The plan is to support these new algorithms in Windows TLS stacks (Schannel) and OpenSSL via the SymCrypt provider. In Azure services, we can expect “TLS 1.3 + PQC” options soon, similar to AWS. As a concrete note, Azure Key Vault’s documentation even cites that AES-256 is quantum-resistant (per CNSS guidance). In future, when NIST finalizes post-quantum standards, Azure will likely support key vault operations with PQC keys (just as AWS does with Kyber and others). Microsoft’s roadmap indicates that hybrid algorithms (e.g. X25519+Kyber) will be supported in Azure’s cryptographic stack.

In practical terms today, data encryption at rest (AES-256) and in transit (TLS) already provide strong security. But both AWS and Azure are equipping their platforms so that when quantum-safe encryption becomes necessary, customers can adopt it. For example, AWS already provides hybrid TLS for KMS API calls, and Azure customers can experiment with PQC in Windows/SQL if desired. The takeaway: quantum-resistant encryption is on the horizon for the cloud, and both providers are leading the way.

Real-World Use Cases

To make this concrete, let’s walk through some realistic scenarios on AWS and Azure that illustrate encryption in transit, at rest, and key management:

• AWS - Global Application with Compliance Needs: A multinational corporation runs a web application on AWS across several regions. User data is submitted via HTTPS (TLS 1.2+) to ELB/Application Load Balancer. Internally, all API calls between services (Microservices on ECS and Lambda) also occur over TLS. The company stores user data in Amazon RDS (MySQL) with RDS Encryption enabled (AES-256 TDE). Backups go to S3 with SSE-KMS (AES-256) using a customer-managed CMK in KMS. The CMK is rotated annually. EBS volumes for servers are encrypted at creation with the same KMS key. Database replicas in other regions use multi-Region KMS keys, so data encrypted in one region can be decrypted in another (supporting failover) without re-encrypting. All key usages and KMS operations are logged to CloudTrail. Security policy requires that data in transit be encrypted: the company enforces S3 bucket policies to deny any non-HTTPS requests. AWS WAF with TLS enforces this at the edge. In sum, this scenario uses TLS for all data in flight and AES-256 (via KMS) for all data at rest, with tight key management via AWS KMS.
• AWS - IoT Device Data Pipeline: An IoT platform ingests data from devices around the world. Devices publish to AWS IoT Core using MQTT over TLS. The payloads are encrypted in-transit with TLS. The IoT rules route data into Kinesis and S3. On storage, all streams and S3 buckets have default encryption enabled (SSE-S3 or SSE-KMS). The company uses a KMS key dedicated to IoT data, with key policies allowing only the data ingestion role to use it. The data pipeline (Kinesis, Glue, Redshift) automatically encrypts intermediate data with that key. Downstream analytics workloads decrypt the data in-memory only when needed, never storing unencrypted results. The platform leverages AWS’s internal VPC security and PrivateLink to keep traffic off the public Internet. This use case demonstrates TLS encryption from device to cloud and uniform at-rest AES encryption managed by KMS for all persisted data.
• Azure - Encrypted Cloud Storage and SQL: A healthcare provider stores patient records on Azure. Applications interact over HTTPS endpoints (Azure App Service with TLS 1.2 or 1.3). Sensitive files are kept in Azure Blob Storage with Server-Side Encryption. They choose to use a Customer-Managed Key in Azure Key Vault for SSE. The workflow is: data is encrypted by Azure with AES-256, and that AES key (DEK) is wrapped by the Key Vault key (using RSA-OAEP). The CMK resides in a managed HSM pool (FIPS 3) for extra assurance. Their SQL Server uses Transparent Data Encryption (TDE) with an Azure Key Vault certificate as the TDE protector (AES algorithm). All network traffic to Azure SQL is via TLS, and on the client side they also use Always Encrypted for the most sensitive columns (end-to-end encryption with .NET driver). Keys in Key Vault are rotated on a policy (every 6 months). Network connectivity to Key Vault is locked down via a virtual network rule. This use case shows Azure-managed AES encryption at rest with keys controlled by the customer, and TLS in transit.
• Azure - Hybrid Application and Secrets Management: A retail company has a hybrid setup with on-prem apps and Azure services. They establish an IPsec VPN (Azure VPN Gateway) between on-prem and Azure. Inside Azure, VMs communicate over an Azure Virtual Network (encrypted by IPsec). They store secrets (API keys, passwords) in Azure Key Vault and configure the Key Vault to require firewalled access. When deploying apps (AKS containers), each pod fetches secrets from Key Vault over the secure VNet connection. Storage accounts attached to the VMs use Azure Storage Service Encryption (AES-256, platform keys). The IT team uses Azure Policies to enforce that all storage and SQL instances use CMKs from Key Vault and rotate them annually. Logs of all Vault access go to Azure Monitor. In flight, all data transfer (both on-prem↔cloud and inter-service) is encrypted (VPN TLS + TLS 1.2). This scenario highlights hybrid networking with encrypted channels and centralized key vault use.
• AWS - High-Security Multi-Region Service: A financial services firm needs extreme security. They use AWS’s Dedicated HSM (CloudHSM) for some keys and AWS KMS with a custom key store (backed by HSM) for others. Their multi-AZ application in us-east-1 and us-west-2 uses a multi-Region key. Clients connect via TLS 1.3. All disk volumes (EBS) are encrypted with KMS (AES-256) and EBS snapshots replicate cross-region (and stay encrypted). They enable KMS CMK rotation annually. Every byte of data between regions is auto-encrypted by AWS’s backbone. The firm also uses Perfect Forward Secrecy ciphers and monitors for any non-TLS traffic. This use case underlines defense in depth: TLS + IPsec for transit, AES-256 for storage, HSM-backed key protection, and automated rotation.
• Azure - Cloud-First Application: A software vendor runs their app entirely in Azure. They use Azure Front Door with end-to-end TLS: incoming client TLS terminates at the edge, then Front Door re-encrypts to the origin server. The origin is an App Service with a private IP, also listening on TLS. All inter-service calls (App → SQL, App → Storage) go over HTTPS. Data at rest in SQL and Storage uses Azure-managed encryption (AES-256). Key Vault holds TLS certificates (secret), SQL TDE protector (certificate), and any CMKs for storage. Admin users use Azure AD and interact over TLS to Azure. Automated key rotation policies and logging complete the security posture. This illustrates Azure’s integrated encryption (TLS at front door, SSE at back end) with Key Vault as the trust anchor.

These scenarios show how AWS and Azure customers implement encryption-by-default in real architectures. The common threads are: using TLS/HTTPS for all communications, enabling service-side AES encryption for storage, using the cloud key management service (KMS or Key Vault) for key control, and following best practices (least privilege, logging, rotation).

Conclusion

Encrypting data both in transit and at rest is a foundational security measure in the cloud. AWS and Azure each offer mature, built-in encryption tools: TLS for network data, AES-256 for storage, and robust key management (AWS KMS, Azure Key Vault) to tie it together. As we’ve seen, AWS KMS and Azure Key Vault provide hardened HSM-backed key stores, flexible key policies, and integration with cloud services for seamless encryption. Both platforms keep pace with new threats: they’ve adopted TLS 1.3, plan for post-quantum cryptography (hybrid TLS suites), and continuously expand algorithm support.

For cloud architects and IT leaders, the takeaway is that both AWS and Azure make it easy to enforce strong encryption: enable default encryption on storage, enforce HTTPS for all traffic, use customer-managed keys for sensitive data, and rotate those keys. The technical details, AES modes, RSA vs ECC, rotation policies, are critical, but the bottom line is simple: data moving or resting in the cloud must be locked down with encryption. With the practices and tools described here, organizations can build cloud systems that meet the highest security and compliance requirements.

No matter which provider you choose, encryption in transit and at rest should be non-negotiable. By leveraging AWS KMS or Azure Key Vault (and staying alert to emerging standards like quantum-safe algorithms), you ensure your cloud data remains private and protected today and into the future.