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

AWS Certificate Manager (ACM) issues free public TLS certificates and owns their lifecycle. DNS validation is the design default: ACM generates a CNAME record, you publish it in the domain's zone, and issuance completes once ACM observes it. That CNAME is not a one-time artifact — managed renewal re-checks it, so as long as the record stays published and the certificate is associated with an AWS service, ACM renews it automatically before expiry with no action from you. Delete the validation CNAME and the next renewal quietly fails; the exam loves this failure mode. Email validation still exists but requires a human to approve each renewal, which makes it the wrong answer in any automation scenario.

Imported certificates are the second classic trap. You can import a third-party certificate into ACM and attach it to the same integrations, but ACM never renews imported certificates — renewal means importing a fresh certificate yourself. Monitor expiry with the ACM DaysToExpiry CloudWatch metric or the acm-certificate-expiration-check AWS Config rule rather than a calendar entry.

Coverage decisions are simpler. A wildcard name such as *.example.com secures one subdomain level — not the bare apex and not nested levels — and a single certificate can carry multiple subject alternative names (SANs) for additional hostnames. Placement is the last rule: standard public ACM certificates never expose their private key, so they attach only to integrated services — Elastic Load Balancing, CloudFront (the certificate must live in us-east-1 for CloudFront), and API Gateway — never directly to an EC2 instance. When a workload genuinely needs key material on a host, ACM offers exportable public certificates for a fee, and AWS Private CA issues exportable private certificates.

Public ACM certificates only help when the client trusts public certificate authorities and the hostname is publicly registered. For internal microservices, private API endpoints, and machine identities, you run AWS Private CA: a managed certificate authority whose root of trust you control and distribute to your own fleet.

The recommended structure mirrors classical PKI. Keep the root CA reserved for one job — signing subordinate CAs — and issue end-entity certificates from one or more subordinates. Subordinates bound the blast radius: revoking or replacing a compromised issuing CA does not force you to re-establish trust in the root, and separate subordinates let you delegate per-environment or per-team issuance under distinct IAM permissions. Private CA integrates with ACM, so certificates it issues into ACM attach to ALBs and API Gateway custom domains exactly like public ones, and ACM manages their renewal.

Private CA is also the issuer for the client side of mutual TLS designs: issue each workload, partner, or device a certificate from a subordinate CA, then configure the server (for example, API Gateway mutual TLS) to trust that CA's chain. One design input the exam expects at the cost level: Private CA carries a significant fixed monthly price per CA plus per-certificate issuance fees, so you provision a small, deliberate hierarchy rather than one CA per application. When a question contrasts a free public ACM certificate against Private CA, the deciding factor is who must trust the certificate — the public internet, or only endpoints you control.

Encryption in transit is only a control when the unencrypted path is refused, not merely unused. Each service has a specific enforcement mechanism, and the exam tests whether you know which knob belongs to which service.

For S3, attach a bucket policy statement with effect Deny, principal *, covering S3 actions, conditioned on aws:SecureTransport being false. Any request arriving over HTTP is rejected regardless of the caller's IAM permissions — an explicit deny always wins. To also require a modern protocol version, add a deny keyed on the s3:TlsVersion condition.

For Elastic Load Balancing, the HTTPS or TLS listener's security policy is the contract: a predefined policy such as ELBSecurityPolicy-TLS13-1-2-2021-06 pins the minimum protocol version and the cipher suites offered. Pair it with a port-80 ALB listener rule that issues an HTTP-to-HTTPS redirect so users never remain on plain text.

CloudFront splits the decision in two: the viewer protocol policy (redirect HTTP to HTTPS, or HTTPS only) governs the client-to-edge leg, while an origin protocol policy of HTTPS only forces the edge-to-origin leg to re-encrypt. A separate security policy sets the minimum viewer TLS version.

Databases enforce transport in engine parameters: rds.force_ssl for RDS PostgreSQL and SQL Server, require_secure_transport for MySQL and MariaDB — both reject non-TLS connections at the engine, which is stronger than trusting every client's connection string. Amazon Redshift has an equivalent require_ssl parameter, and ElastiCache exposes an in-transit encryption flag on the replication group. When a question says clients must be unable to connect without TLS, look for the server-side enforcement option, never a client-side setting.

Deciding where TLS terminates is the core trade-off of Task 5.1. Termination at a load balancer buys Layer 7 features — path routing, WAF inspection, header manipulation — at the price of decrypting traffic on an AWS-managed device. True end-to-end encryption means one unbroken TLS session from client to target, which sacrifices those features.

An ALB always terminates TLS — it is a Layer 7 proxy. Configuring an HTTPS target group makes the ALB 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 are fine: this encrypts the hop without authenticating the target. An NLB with a TCP listener forwards bytes untouched — the certificate lives on the targets, the client's handshake (including SNI) reaches them directly, and the session is genuinely end to end. Give that same NLB a TLS listener and it terminates like an ALB, so read NLB questions carefully: the listener type, not the load balancer type, decides. CloudFront always terminates the viewer session at the edge; with an HTTPS-only origin protocol policy it re-encrypts to the origin and — unlike an ALB — it validates the origin certificate, which must chain to a trusted CA and match the origin domain name.

Standard TLS authenticates the server to the client; mutual TLS (mTLS) additionally requires the client to present its own certificate during the handshake, turning transport encryption into transport-layer authentication. On AWS the packaged implementation is API Gateway mutual TLS: you create a custom domain name, upload a truststore — a PEM bundle of the CA certificates you trust, typically your AWS Private CA chain — to an S3 bucket, and API Gateway rejects any client whose certificate does not chain to that truststore before a single request byte is processed.

Two operational details decide exam answers. First, mTLS is a property of the custom domain; the default execute-api endpoint does not enforce it, so you must disable the default endpoint or clients can simply walk around your control. Second, API Gateway does not consult CRLs or OCSP for you — the truststore is your revocation surface, and removing trust means publishing an updated truststore version.

The issuance side pairs naturally with the previous section: mint client certificates from an AWS Private CA subordinate, distribute them to device fleets or B2B partners, and rotate by issuing fresh certificates before expiry. Application Load Balancer also supports mutual TLS in two modes — verify (the ALB validates the client chain against a trust store) and passthrough (the ALB forwards the client certificate to targets in headers for the application to validate) — worth recognizing when a question puts mTLS in front of an ALB rather than API Gateway. Private keys for these certificates are secrets; their storage and rotation discipline belongs to Task 5.3.

Traffic that leaves AWS, or rides your own circuits, makes the path itself a design input. AWS Site-to-Site VPN is encrypted by definition: each connection is a redundant pair of IPsec tunnels between your customer gateway and AWS. Direct Connect is the opposite, and the exam's favorite trap — it is a private, dedicated circuit, but private is not encrypted; by default frames cross a DX port in the clear. There are two documented fixes. MACsec provides Layer 2, line-rate encryption on supported dedicated connections at MACsec-capable locations — the modern answer when the port and location support it. The classic answer is running an IPsec Site-to-Site VPN over the Direct Connect connection via a public virtual interface, trading throughput for encryption on any DX port. Application-layer TLS on every flow is the compensating control either way.

Inside AWS, the guide expects you to know what is already encrypted for you: traffic crossing inter-Region VPC peering and Transit Gateway inter-Region peering traverses the AWS global backbone and is encrypted by AWS at the network layer, and current-generation Nitro-based instance types transparently encrypt traffic between themselves. A requirement to encrypt cross-Region replication traffic is therefore often already satisfied — the differentiator in a question is usually whether traffic leaves the AWS network at all.

For bulk file movement, retire plain FTP: AWS Transfer Family provides managed SFTP and FTPS endpoints in front of S3 or EFS, keeping the transfer channel encrypted with no servers of your own to patch.

Walk through a design the exam could hand you: a three-tier web application — CloudFront in front of an ALB, EC2 targets, RDS PostgreSQL — with the requirement that data is encrypted in transit on every hop.

Hop 1, client to edge: request a public ACM certificate in us-east-1 (CloudFront requires that Region), attach it to the distribution, set the viewer protocol policy to redirect HTTP to HTTPS, and pin the security policy to a TLS 1.2 minimum.

Hop 2, edge to ALB: set the origin protocol policy to HTTPS only. The ALB needs its own ACM certificate issued in the ALB's Region, and CloudFront validates it — the origin certificate must cover the origin domain name.

Hop 3, ALB to instances: use an HTTPS target group. Instances run a local web server with a certificate issued by AWS Private CA — or even self-signed, since the ALB does not validate target certificates — so the hop is encrypted even though the ALB terminated the viewer session.

Hop 4, application to database: set rds.force_ssl in the parameter group so the engine refuses plaintext, and configure the driver with the RDS CA bundle in verify-full mode so the client authenticates the endpoint rather than merely encrypting to it.

Now the twist the exam adds: compliance states TLS must not be decrypted anywhere between client and instance. The CloudFront-plus-ALB design cannot satisfy that — both terminate. The architecture changes to an NLB with a TCP listener passing port 443 straight through to instances that hold the certificates, giving up WAF and path routing in exchange for a single unbroken session. Recognizing which requirement wording forces which architecture is exactly what this task tests.

Task 5.1 troubleshooting stems describe symptoms; you supply the diagnosis. The certificate-expiry outage: users see browser trust errors, the certificate has expired, yet ACM was supposed to renew it. Two root causes dominate — the DNS validation CNAME was deleted, common after a zone migration (restore the identical record and managed renewal can proceed), or the certificate was imported, which ACM never renews. Prevent recurrence with the DaysToExpiry metric or the acm-certificate-expiration-check Config rule.

Handshake failures after a hardening change: raise an ALB security policy's minimum to TLS 1.2 or 1.3 and legacy clients — old Java runtimes, embedded devices, unpatched operating systems — fail below the HTTP layer, so they see connection resets rather than error pages. The evidence lives in the ALB access logs, which record the negotiated ssl_protocol and ssl_cipher for every request: query them before raising the minimum to inventory exactly which clients will break. CloudFront logs report viewer TLS versions the same way.

SNI mismatches: a load balancer or distribution serving multiple certificates selects one using the SNI hostname in the ClientHello; a client that omits SNI receives the default certificate and fails validation with a hostname mismatch. Ancient clients and naive monitoring probes are the usual culprits.

Two mention-level patterns round it out: mixed content, where an HTTPS page loads HTTP sub-resources that browsers block (fix the URLs, not the TLS configuration), and redirect loops behind CloudFront, which appear when the origin protocol policy is HTTP only while the origin itself redirects HTTP to HTTPS — CloudFront keeps fetching over HTTP and the origin keeps redirecting. Align the origin protocol policy with the origin's redirect behavior.