Transport Layer Security

Transport Layer Security, usually called TLS, establishes a protected communication channel over an untrusted network. During the handshake, endpoints negotiate protocol parameters and establish cryptographic keys. In a typical HTTPS connection, the server presents a certificate, and the client verifies its trust chain, validity period, and hostname. Session keys then protect application traffic against disclosure and undetected modification. Mutual TLS additionally authenticates the client using a certificate, but application authorization remains a separate responsibility.

In cloud architectures, start by mapping where connections originate, terminate, and restart. A browser might connect over HTTPS to a load balancer, which then opens another connection to an application. TLS on the public listener protects only the first connection. If the application connection uses HTTP, that second hop is not protected by TLS. Configure HTTPS targets when backend encryption is required, or use a TCP listener to pass TLS through to the application when the application must own the TLS session.

Requiring encryption is different from merely supporting it. Select listener security policies that permit the required modern protocols and cipher suites, typically TLS 1.2 and TLS 1.3 where supported. Disable obsolete protocols and reject plaintext connections where strict encryption is required. An HTTP-to-HTTPS redirect helps clients find the secure endpoint, but the original HTTP request has already traveled without TLS. Security groups restrict network reachability and ports; allowing port 443 alone does not verify that traffic actually uses TLS.

Certificate validation is as important as encryption. A client that ignores certificate errors can establish an encrypted connection to an attacker rather than the intended server. Maintain appropriate trust stores, protect private keys, automate certificate renewal, and test hostname validation. Do not assume every managed proxy validates backend certificates: an Application Load Balancer encrypts connections to HTTPS targets but does not validate their server certificates. If authenticated backend identity is required, choose an architecture that explicitly supplies that verification.

Inter-resource protection also applies to distributed workloads. Amazon EMR security configurations can enable in-transit encryption for supported application traffic, with certificate material and application-specific settings appropriate to the release. Check coverage for each framework and traffic path rather than assuming every cluster connection uses TLS. In Amazon EKS, the Kubernetes API endpoint supports TLS, but that does not automatically encrypt arbitrary application traffic between pods. Applications or appropriately configured proxies must provide TLS or mutual TLS for those connections.

For supported distributed training workloads in Amazon SageMaker AI, enable inter-container traffic encryption to protect communications between training containers on different instances. Treat this separately from HTTPS access to service APIs and from encryption of training data at rest. Similarly, supported Amazon EC2 instance types provide automatic Nitro-based encryption for qualifying traffic between instances. Nitro network encryption is not TLS, does not provide application certificate authentication, and has documented instance and network-path constraints. It does not replace TLS for connections outside its coverage.

TLS introduces handshake work, certificate lifecycle management, and potential compatibility issues with older clients. Connection reuse and session resumption can reduce overhead. Termination at a managed load balancer centralizes certificate operations and traffic inspection, while passthrough keeps TLS ownership with the application and limits intermediary visibility. Validate the design with successful secure connections, rejected plaintext and obsolete-protocol attempts, certificate-error tests, and checks of every backend hop. Encryption at rest, private subnets, and private connectivity are complementary controls, not substitutes for authenticated encryption in transit.