Encryption in Transit

Encryption in transit protects data while it travels between endpoints, such as a browser and an application, an application and a database, or an on-premises network and a cloud network. Secure protocols combine encryption with integrity protection and endpoint authentication to defend against interception and modification. This differs from encryption at rest, which protects stored data on disks, databases, and object storage. A workload commonly needs both: encrypting a database volume does not encrypt a client's database connection.

Transport Layer Security, or TLS, is widely used to protect application traffic. HTTPS is HTTP carried over TLS; database clients and other application protocols can also use TLS. Clients should validate the server certificate's trust chain, expiration, and hostname rather than merely establish an encrypted session. Mutual TLS additionally authenticates the client using a certificate. Use supported modern protocol versions, normally TLS 1.2 or TLS 1.3, with security policies appropriate to the workload.

The protection boundary depends on where encryption starts and terminates. For example, an HTTPS connection from a browser to a load balancer protects that segment only. If the load balancer forwards requests to application servers using HTTP, the backend segment is unencrypted. Configuring HTTPS to the targets creates a separate encrypted connection; it does not automatically provide the same certificate-validation behavior as a browser. Check the specific proxy or load balancer's backend authentication capabilities. A TLS-terminating intermediary can access plaintext, so this architecture is not equivalent to encryption that remains intact between the original client and final application.

Hybrid connectivity requires separating private connectivity from cryptographic protection. AWS Site-to-Site VPN uses IPsec to encrypt traffic between a customer gateway device and an AWS VPN endpoint, commonly across the internet. AWS Direct Connect provides dedicated connectivity but does not encrypt traffic by default. When confidentiality is required, use application TLS, an appropriate IPsec VPN design over Direct Connect, or MACsec where supported. These mechanisms protect different portions of the path and can be combined.

MACsec provides Layer 2 encryption on supported Direct Connect connections between the customer router and the Direct Connect device. It is not end-to-end encryption from an on-premises application to a cloud workload, and availability depends on connection capabilities and location. For hybrid or multi-cloud designs, identify every provider, carrier, gateway, and termination point rather than assuming that one encrypted link protects the entire route. VPN gateways decrypt tunnel traffic before forwarding it, so application TLS can remain valuable beyond the tunnel boundary.

Operational trade-offs include cryptographic processing, handshake latency, certificate lifecycle management, and reduced visibility for network inspection. VPN encapsulation can also reduce the effective maximum transmission unit, causing fragmentation or stalled transfers if path MTU discovery is blocked. Troubleshooting should distinguish certificate or protocol negotiation failures from routing, firewall, DNS, and tunnel problems. Test the intended hostname and inspect negotiated protocols, certificate chains, and actual backend connection settings.

Private subnets, security groups, private endpoints, and dedicated circuits constrain connectivity but do not themselves guarantee encryption. Likewise, an encrypted connection does not authorize the caller or protect plaintext at a compromised endpoint. Under the shared responsibility model, cloud providers offer secure protocols and managed capabilities, while customers remain responsible for selecting suitable configurations, enforcing secure access, and validating every required traffic segment.