Data in Transit on AWS: TLS, ACM, and End-to-End Encryption Design

Encryption in transit is a control only when the server refuses the unencrypted path. Each service has its own enforcement knob, and a client-side setting such as a connection string never counts, because each client can change it.

Amazon S3

Add a bucket policy statement with effect Deny, principal *, covering S3 actions on the bucket and its objects, with the condition aws:SecureTransport = false. Every HTTP request is rejected whatever the caller's IAM permissions, because an explicit deny always wins. An Allow conditioned on aws:SecureTransport = true is not equivalent: any other statement or identity policy that allows the action still lets plaintext through.

To also require a minimum TLS version, add a second deny on s3:TlsVersion (for example NumericLessThan 1.2). It supplements the aws:SecureTransport deny and never replaces it: a plain HTTP request carries no TLS version, so the s3:TlsVersion key is absent, the numeric condition does not match, and plaintext would stay open if that were the only statement.

The S3 static website endpoint serves HTTP only and requires a publicly readable bucket. To serve a static site over HTTPS end to end from a private bucket, put CloudFront in front of the S3 REST endpoint with origin access control (OAC), redirect viewers to HTTPS, and use a CloudFront Function to rewrite folder paths to their index documents (the behaviour the website endpoint used to provide). A bucket policy that allows reads only when a secret Referer header is present does not make a bucket private: it still grants anonymous reads to anyone who sends that header.

Amazon CloudFront

CloudFront splits the decision into two legs. The viewer protocol policy governs client to edge: Redirect HTTP to HTTPS answers HTTP requests with a 301 to the HTTPS URL, while HTTPS only answers HTTP requests with 403 and no redirect. The origin protocol policy governs edge to origin: HTTPS only forces every origin fetch onto TLS, Match viewer uses whatever the viewer used. The viewer's minimum TLS version is set by the distribution's security policy, and that choice depends on the certificate: with the default *.cloudfront.net certificate the security policy is fixed at TLSv1. Raising it requires an alternate domain name with a custom certificate — in ACM it must be in us-east-1 — served with SNI, which offers the TLSv1.2 policies (dedicated-IP serving exists for legacy clients without SNI and offers the older TLSv1 and SSLv3 policies).

Databases and caches

IAM database authentication requires TLS only for the users who sign in with IAM tokens; password users can still connect in plaintext unless the engine parameter is set. For the strongest posture, pair server-side enforcement with clients that verify the server certificate (for example sslmode=verify-full with the RDS CA bundle), so the client authenticates the endpoint instead of merely encrypting to it.

A load balancer's HTTPS or TLS listener negotiates TLS according to its security policy: a predefined, named set of protocol versions and cipher suites. Reading the names is a skill in itself. ELBSecurityPolicy-TLS13-1-2-2021-06 allows TLS 1.3 and TLS 1.2 (a TLS 1.2 minimum); ELBSecurityPolicy-TLS13-1-3-2021-06 allows TLS 1.3 only. Variants add FIPS-validated or post-quantum cipher suites, and older names such as ELBSecurityPolicy-2016-08 still accept TLS 1.0 and 1.1. Pair the HTTPS listener with an HTTP:80 listener whose default action redirects to HTTPS:443, so old http:// links reach the secure site instead of failing.

Defaults and governance

The default depends on how the listener is created. The console proposes a recommended TLS 1.3 policy, but a listener created through the AWS CLI, API or CloudFormation without an SslPolicy gets ELBSecurityPolicy-2016-08, which accepts TLS 1.0. Infrastructure-as-code templates that omit the property therefore deploy weak listeners silently.

To prevent that across an organization, use the ELB condition keys in a service control policy (or IAM policies): elasticloadbalancing:SecurityPolicy is evaluated on CreateListener and ModifyListener, so a Deny unless the value is in an approved list refuses weak policies — including the one a listener would inherit by default. elasticloadbalancing:ListenerProtocol controls which listener protocols may be created (for example, only HTTPS and TLS); on its own it forces encryption but says nothing about TLS versions. An SCP covers every principal in the member accounts; a permissions boundary covers only the role it is attached to; AWS Config detects weak listeners after they exist but does not stop their creation.

Certificates, SNI and key algorithms

A listener can hold several certificates. The load balancer chooses one per connection from the Server Name Indication (SNI) hostname in the client's ClientHello; a client that sends no SNI receives the listener's default certificate. Each ACM certificate has a single key algorithm — RSA or ECDSA — so serving ECDSA to modern clients while older clients keep RSA means adding two certificates for the same hostname. When several certificates match the hostname, the ALB's smart certificate selection picks the best one the client supports.

Deciding where TLS terminates is the core trade-off of this task. Termination at a load balancer or edge buys Layer 7 features — path routing, AWS WAF inspection, header manipulation — at the price of decryption on an AWS-managed component. True end-to-end encryption means one unbroken TLS session from client to target, which gives those features up.

An ALB always terminates TLS — it is a Layer 7 proxy. An HTTPS target group makes it open a second TLS session to each target, and the ALB does not validate the target's certificate, so self-signed or private-CA certificates on instances work: the hop is encrypted but the target is not authenticated. An NLB behaves according to its listener type, not its load balancer type. A TCP listener forwards bytes untouched — the client's handshake, SNI included, reaches the target, which holds the key. A TLS listener terminates with an ACM certificate; pointing it at a TLS target group re-encrypts to the targets, again without validating their certificates. This is the way to keep a public certificate's private key in ACM while still encrypting the hop for a non-HTTP protocol.

CloudFront always terminates the viewer session at the edge. With an HTTPS-only origin protocol policy it re-encrypts to the origin and — unlike a load balancer — it validates the origin certificate: it must be issued by a publicly trusted CA and cover the origin domain name. A self-signed or private-CA certificate on a custom origin causes 502 errors even though the same backend works behind an ALB.

Standard (one-way) TLS authenticates only the server to the client; anyone can open a session. Mutual TLS (mTLS) also requires the client to present a certificate that chains to a CA the server trusts, turning transport encryption into caller authentication. When a requirement says a service must authenticate its callers cryptographically, one-way TLS — an NLB TLS listener, an HTTPS endpoint — is not enough on its own.

API Gateway

Mutual TLS is configured on a custom domain name, with a truststore (a PEM bundle of trusted CA certificates, typically your private CA chain) stored in S3. Clients without a certificate that chains to it are rejected during the handshake. The control applies to the custom domain only: the default execute-api endpoint does not ask for a client certificate, so it remains a bypass until you disable the default endpoint. API Gateway does not check CRLs or OCSP itself; revoke access by updating the truststore or by checking certificate details in a Lambda authorizer.

Application Load Balancer

ALB mutual TLS has two modes. In verify mode the ALB validates the client certificate against a trust store (CA bundle from S3) during the handshake and rejects failures; it then passes details such as X-Amzn-Mtls-Clientcert-Subject and X-Amzn-Mtls-Clientcert-Serial-Number to targets in headers. A trust store can also hold certificate revocation lists imported from S3 — the ALB does not fetch CRLs from the CA by itself — so revoking one certificate means revoking it at the CA, exporting a CRL that lists it, and adding that CRL to the trust store. In passthrough mode the ALB does no validation and forwards the whole client certificate chain to targets in the X-Amzn-Mtls-Clientcert header, leaving verification to the application.

Client certificates are usually issued from a private CA (see the next section). Their keys are secrets whose storage and rotation belong to Task 5.3.

Every TLS endpoint in this lesson needs a certificate, and two questions decide where it comes from: who must trust it and where the private key may live. Public ACM certificates are free, trusted by browsers, and attach only to integrated services — Elastic Load Balancing, CloudFront (certificate in us-east-1), API Gateway — because their private key never leaves ACM. ACM renews certificates it issued while they are in use and still validate (DNS validation records left in place); imported certificates are never renewed by ACM. AWS Private CA issues certificates trusted only by clients you configure, which suits internal services, mTLS client certificates and machine identities — but CloudFront and public browsers will not accept them.

Issuance, validation, renewal, import and export, exportable certificates and Private CA hierarchy design are certificate management, which SCS-C03 places in Task 5.3 (Skill 5.3.5) — they are covered in depth in the lesson on protecting secrets, keys and confidential data.

Private access means a workload reaches a service without crossing the internet and without an internet gateway or NAT gateway in the path. AWS offers three building blocks, chosen by what you are reaching and from where.

Private DNS on an interface endpoint makes the service's default hostname (for example the Secrets Manager endpoint) resolve to the endpoint's private addresses inside the VPC, so code and SDKs need no change. On-premises hosts don't see that private hosted zone; they use the endpoint-specific DNS names, or a Route 53 Resolver inbound endpoint that forwards the service name.

A PrivateLink endpoint service is not routing. The provider publishes one service; each consumer reaches it through an endpoint with an IP address from the consumer's own subnet. Because no routes are exchanged between the two networks, their address ranges are irrelevant to each other, the provider network is never reachable beyond that service, and the provider has no path to initiate traffic back into consumer VPCs. Peering and transit gateways, by contrast, join whole networks and need non-overlapping CIDRs, which is why PrivateLink is the usual pattern for sharing a service with many accounts. The provider controls which principals may connect and can require acceptance of each endpoint connection. AWS SDKs and the CLI reach AWS-service interface endpoints over HTTPS by default, so that traffic is TLS-encrypted end to end; the endpoint itself provides privacy, not encryption.

For internet-facing content that should reach a private application, CloudFront VPC origins let a distribution front an internal ALB, NLB or EC2 instance in a private subnet, so the origin needs no public exposure. Endpoint policies and the network-layer controls around endpoints are covered in the network security controls lesson (Task 3.3).

Remote users reach private resources in two ways: AWS Client VPN gives them a network-level tunnel into the VPC, and AWS Verified Access gives them access to specific applications without a VPN, evaluating every request.

Client VPN design details

• Authentication. Mutual authentication uses a server certificate and client certificates; an endpoint accepts any client certificate that chains to its trusted client CA. Active Directory and SAML federation authenticate users against a directory or an identity provider (with its MFA).
• Authorization rules grant access to destination CIDRs, either for all users or for a specific group. Group-scoped rules need group information, so they work only with Active Directory or SAML authentication. With mutual authentication alone, the documented pattern is one endpoint per user group — and each endpoint must trust a separate client CA, or members of one group could connect to the other's endpoint. The server certificate can be shared.
• Split tunnel pushes only the endpoint route table's routes to the client, so VPC-bound traffic uses the tunnel and other traffic leaves through the user's local network. Full tunnel (the default) sends all of the user's traffic, including internet-bound traffic, into AWS; split tunnel reduces the traffic leaving AWS and so the data transfer cost (and any NAT gateway processing charges, if internet traffic exits through a NAT gateway).
• The client connect handler is a Lambda function run when a client connects; it can only allow or deny the connection (for example after a posture check). It does not assign routes or authorization.

Verified Access is built from an instance, trust providers, groups of applications with shared policies written in Cedar, and endpoints (for example a load balancer or network interface). Policy design and device-trust details are covered with the other hybrid-access controls in Task 3.3; for this task, the decision is choosing it when users need per-application, VPN-less, per-request checked access.

Some encryption AWS applies for you, and the design question is whether a given path is covered. Inside AWS, Nitro-based instance types that support in-transit encryption encrypt traffic between themselves in hardware, with no performance impact and nothing to install — but only when both instances are supported types, they are in the same VPC or peered VPCs, and the traffic does not pass through a virtual network device or service such as a load balancer or a transit gateway. Across Regions, AWS states that all data flowing over the AWS global network between Regions is encrypted at the physical layer before it leaves AWS secured facilities, and inter-Region VPC peering and transit gateway inter-Region peering traffic are documented as encrypted.

VPC Encryption Controls

VPC Encryption Controls turns that hardware encryption into something you can evidence and enforce within and across the VPCs in a Region, extending it to services such as ALB, NLB, Fargate and transit gateways.

• Monitor mode reports encryption status and lists the resources that would allow cleartext. Existing VPCs must start in monitor mode; enforce mode can be set directly only on a new VPC at creation.
• Evidence comes from the encryption-status field in VPC Flow Logs (not encrypted, Nitro-encrypted, application-encrypted, or both). The field is not added to existing flow logs — you create new flow logs that include it.
• Enforce mode blocks creating or attaching resources that permit unencrypted traffic, such as older instance types. A short fixed list of resource types can be excluded where you own the encryption — internet, NAT and egress-only internet gateways, virtual private gateways, peering to non-enforced VPCs, Lambda in the VPC, VPC Lattice and EFS. Nothing else is excludable.
• Traffic between VPCs through a transit gateway is covered only after you enable encryption support on the transit gateway.
• In an enforce-mode VPC, a Network Load Balancer cannot use a TLS listener to offload TLS; targets must terminate TLS themselves.

Hybrid paths

Traffic that leaves AWS is your responsibility. Site-to-Site VPN is IPsec by definition. Direct Connect is private but not encrypted by default; MACsec (IEEE 802.1AE, Layer 2 encryption at line rate, available on supported dedicated connections at MACsec-capable locations) or an IPsec VPN over the connection encrypts it — the connectivity design belongs to Task 3.3. For file transfer, AWS Transfer Family provides managed SFTP and FTPS endpoints in front of S3 or EFS in place of plain FTP.

Distributed frameworks often talk between nodes in plaintext. Each service has its own setting, and network isolation is never a substitute: private subnets, endpoints and network-isolation flags restrict where traffic can go but do not encrypt it.

Amazon EMR

In-transit encryption is part of an EMR security configuration, which is applied when a cluster is launched — it cannot be added to a running cluster, so an existing cluster is replaced. It enables TLS for inter-node and application traffic (for example Hadoop, Spark and Presto/Trino services). The certificates come from one of three providers:

• PEM files: a zip in S3 with fixed file names (privateKey.pem, certificateChain.pem, and optionally trustedCertificates.pem). Private keys must have no passphrase, because services start unattended; a passphrase-protected key makes clusters fail to start. Use a wildcard common name for the cluster's internal domain (for example *.ec2.internal) so one certificate covers every node.
• Custom provider: your Java class implementing TLSArtifactsProvider, stored in S3, which supplies the artifacts at launch.
• EMR-managed certificates (release 7.11.0 and later): EMR creates the certificates, so you do not package or store any. EMR does not rotate them; they carry a long default validity, and when the CA expires you re-create the security configuration and launch clusters with it.

Amazon EKS

With the Amazon VPC CNI, pods get VPC IP addresses, so traffic between pods on different nodes is instance-to-instance traffic. Running node groups on Nitro instance types that support in-transit encryption encrypts it in hardware, with no sidecars, no application change and no throughput cost (same-VPC and peering conditions apply). That encrypts but does not identify workloads. When a service must authenticate its callers cryptographically, use a service mesh that issues per-workload certificates for mutual TLS, plus an authorization policy. Kubernetes network policies and security groups for pods filter traffic by address or label; neither encrypts it nor authenticates the caller cryptographically. The Kubernetes API endpoint is always reached over TLS.

SageMaker AI

For distributed training and processing, set EnableInterContainerTrafficEncryption to true. It encrypts traffic between the job's ML instances using an IPsec-style tunnel, so the job's security group must allow UDP port 500 and the ESP protocol (IP protocol 50) among its own instances. It has no effect on single-instance jobs, and it can lengthen training time and raise cost in proportion to how much the instances communicate. Private VPC subnets, gateway endpoints and EnableNetworkIsolation keep training traffic private or block outbound calls; only inter-container traffic encryption encrypts the traffic between training instances.

Take a three-tier application — CloudFront in front of an ALB, EC2 targets, RDS for PostgreSQL — with the requirement that data is encrypted on every hop.

Hop 1, client to edge: add an alternate domain name with a public ACM certificate in us-east-1, serve it with SNI, set the viewer protocol policy to redirect HTTP to HTTPS, and choose a TLSv1.2 security policy (the default cloudfront.net certificate would pin the policy at TLSv1).

Hop 2, edge to ALB: set the origin protocol policy to HTTPS only. The ALB needs its own publicly trusted certificate in the ALB's Region that covers the origin domain name, because CloudFront validates it. Give the ALB a recommended TLS 1.3 security policy, and if the ALB should not be internet-facing, use a CloudFront VPC origin.

Hop 3, ALB to instances: use an HTTPS target group. Instances can present private-CA or even self-signed certificates, since the ALB does not validate target certificates.

Hop 4, application to database: set rds.force_ssl to 1 in the parameter group (explicitly, on versions before 15) so the engine refuses plaintext, and configure the driver to verify the server certificate.

Now change one requirement: TLS must not be decrypted anywhere between client and instance. CloudFront and the ALB both terminate, so the design becomes an NLB with a TCP listener passing 443 straight to instances that hold the certificates — giving up WAF and path routing for a single unbroken session. Change the constraint and the answer changes: if the rule is about who holds the certificate's private key rather than about decryption, a load balancer may decrypt, and the termination options in the table above are compared on that axis. Two questions settle every variant: may any hop between client and workload see plaintext, and must the private key stay inside ACM?

TLS troubleshooting starts from evidence, and each source answers a different question.

Raising a minimum TLS version: legacy clients — old Java runtimes, embedded devices — fail below the HTTP layer and see connection resets, not error pages. Query access logs (for example with Athena on ssl_protocol) before the change to list the clients still using TLS 1.0 or 1.1; after a change, connection logs identify the clients whose handshakes now fail. CloudFront standard logs report viewer TLS versions the same way.

Name mismatch for some clients only: clients that send no SNI receive the listener's default certificate, so a probe or old library calling a non-default hostname gets the wrong certificate while browsers work.

502 from CloudFront after switching the origin to HTTPS: the origin certificate is self-signed, private-CA issued, expired or does not match the origin domain. Redirect loops appear when the origin protocol policy is HTTP only while the origin redirects HTTP to HTTPS; align the two. Mixed content (an HTTPS page loading HTTP resources) is fixed in the page, not the TLS configuration.

Expired certificate on an ACM-backed endpoint: the usual causes are a removed DNS validation record or an imported certificate, which ACM never renews; monitoring and renewal design are covered with certificate management in Task 5.3.