Encryption in Transit

Encryption in Transit protects data while it travels over a network, between your application and an AWS service, between AWS services, or between your users and your application. The most common protocol is TLS (Transport Layer Security), which provides three guarantees at once: confidentiality (nobody can read the traffic), integrity (nobody can tamper with it undetected), and authentication (you are talking to the endpoint you think you are).

AWS Implementation

• HTTPS: all AWS API endpoints use TLS, and since the deprecation of TLS 1.0 and 1.1 was completed in early 2024, they require TLS 1.2 or later
• ACM: free TLS certificates for CloudFront, ALB, API Gateway
• VPN: encrypted IPsec tunnels for hybrid connectivity
• Direct Connect: private dedicated connection (not encrypted by default; use MACsec for link-layer encryption or layer a VPN on top for IPsec encryption)
• Post-Quantum TLS: available on CloudFront since September 2025 for protection against harvest-now-decrypt-later attacks

Enforcing TLS, Not Just Offering It

Supporting HTTPS is not the same as requiring it. Several AWS services still accept plaintext access unless you forbid it, S3 being the classic example: the API answers on both HTTP and HTTPS. The enforcement mechanism is the global IAM condition key aws:SecureTransport, a Boolean present in every request context that is false when the call arrived without TLS. A deny statement conditioned on it makes plaintext requests fail regardless of what other permissions the caller holds:

{"Sid": "DenyInsecureTransport", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"], "Condition": {"Bool": {"aws:SecureTransport": "false"}}}

Adding this statement to bucket policies (and its equivalents to SQS, SNS, and Secrets Manager resource policies) is one of the cheapest wins in AWS data protection, and it is exactly what several Security Hub controls check for. The console path for verification is the S3 bucket's Permissions tab, under Bucket policy.

How It Goes Wrong in Practice

The most common gap is TLS termination theater: a team runs HTTPS from browsers to the Application Load Balancer, then plain HTTP from the ALB to the targets, reasoning that "it is inside the VPC anyway". The connection drawn on the architecture diagram is encrypted; the actual hop carrying the data to the application is not. This matters for more than purism: compliance frameworks such as PCI DSS expect end-to-end protection for cardholder data, a misconfigured peering or an over-broad security group can expose plaintext east-west traffic to more of the network than intended, and any node capable of packet capture on that segment sees everything. The pattern repeats wherever traffic is relayed: CloudFront configured with an HTTP-only origin protocol, or an internal reverse proxy stripping TLS. The fix is terminating TLS at the edge and re-encrypting to the origin, with certificates on the targets themselves. The second recurring failure is the forgotten enforcement side: HTTPS is available on a bucket or queue, every SDK uses it by default, and then one legacy script or misconfigured client quietly talks plaintext for years because nothing denied it.

Frequently Asked Questions

Is traffic between AWS availability zones encrypted?

Yes. AWS documents that all traffic between AZs, and all cross-Region traffic on the AWS global network, is automatically encrypted at the physical layer before leaving AWS-controlled facilities. That baseline is a strong safety net, but application-layer TLS on top remains the norm for anything sensitive, because it protects the traffic on every segment including inside your own VPC and satisfies auditors who cannot inspect AWS's physical layer.

Do I really need TLS between services inside a private VPC?

For sensitive data, yes. The VPC boundary protects you from the internet, not from lateral movement after a foothold, misrouted traffic, or an insider with capture capability. Zero trust architectures treat the network as untrusted everywhere, and modern tooling (ACM for private certificates, service meshes with mutual TLS) has removed most of the historical operational pain.

What minimum TLS version should I configure?

TLS 1.2 as the floor, TLS 1.3 where both ends support it. AWS finished deprecating TLS 1.0 and 1.1 on its own API endpoints across all Regions in early 2024, and for your own listeners the same floor applies: choose an ALB or CloudFront security policy that refuses anything below 1.2, and prefer 1.3 policies for the performance and forward-secrecy gains.