If you send your credit card number to an online shop and the data is readable by anyone on the network between your laptop and the shop's server, criminals can steal it instantly. Encryption in transit solves this by scrambling data so only the intended recipient can unscramble it. For the SCS-C02 exam, you must understand two things: how encryption travels with the data (TLS) and where decryption safely happens (TLS termination) — both are tested heavily in scenario-based questions.
Jump to a section
A simple way to picture Data Encryption in Transit and TLS Termination
The main post office in a busy city. You need to send a secret handwritten note to a friend in another country with the recipe for your famous sauce. You cannot just shove it in a regular envelope — anyone handling it could steam it open, read the recipe, and copy it.
Instead, you put the note inside a steel lockbox. You also buy a special tamper-proof seal from the post office that shows the box has not been opened in transit. You hand the locked box to the postal clerk, who records its journey at every checkpoint. When the box arrives at your friend's local post office, that office acts as a trusted middleman. Your friend must show their ID and sign a digital receipt before the local post office uses its own special key to open the box and give your friend the note. The note itself is never readable during the entire journey — it is only readable at the start (your hands) and at the end (your friend's hands).
This is exactly how encryption in transit works for data travelling across the internet. The steel lockbox is the encrypted data. The tamper-proof seal is the TLS protocol that verifies the data was not altered. The local post office is the TLS termination point — often an Application Load Balancer — that decrypts the traffic at the network edge so your friend's server can read it without doing the heavy cryptographic work itself.
Encryption in transit protects data while it moves from one place to another over a network. Think of a network as a series of tubes and wires connecting computers. When you send an email, visit a website, or upload a file to AWS, your data is broken into small chunks called packets. These packets travel through routers and switches owned by many different companies — your internet service provider, a backbone provider in another country, and finally the cloud provider's network. Without encryption, anyone who gains access to any of those intermediate devices can read your packets.
The standard technology for encryption in transit on the internet is called TLS, which stands for Transport Layer Security. TLS replaces its older, less secure predecessor SSL (Secure Sockets Layer). When you see "https" in a web address, the 's' means the connection is using TLS. HTTPS is simply HTTP (the protocol that web browsers and servers use to talk) running on top of TLS.
Here is how TLS works in a simplified form. First, your browser and the server go through a "handshake". Your browser asks the server to prove its identity. The server responds with a digital certificate issued by a trusted third party called a Certificate Authority (CA). A certificate is like a passport: it contains the server's public key and proof that a trusted authority verified the server's identity. Your browser checks that the certificate is valid, not expired, and matches the website you requested. If everything checks out, your browser generates a temporary secret key, encrypts it with the server's public key, and sends it to the server. Only the server, which holds the matching private key, can decrypt that secret key. From that point forward, both sides use that shared secret key to encrypt and decrypt all data in that session. This process is called symmetric encryption — once the handshake establishes the shared secret, the actual data transfer is fast because symmetric encryption uses one key for both encryption and decryption.
TLS termination refers to the point where the encrypted TLS connection ends and the data becomes plaintext again. In a typical AWS architecture, you do not want every individual server to handle the complex TLS handshake and certificate management. Instead, you place a load balancer — specifically an Application Load Balancer (ALB) or a Network Load Balancer (NLB) — at the edge of your network. The load balancer terminates the TLS connection: it receives the encrypted traffic from the client, decrypts it using the server certificate's private key, inspects the plaintext request (for example, to decide which backend server should handle it), and then forwards the request to the backend server. The traffic between the load balancer and the backend server may be unencrypted (HTTP) or encrypted again using a second layer of TLS, depending on your security requirements.
Why does TLS termination matter for security and performance? First, it centralises certificate management. Instead of installing a certificate on every web server, you install it only on the load balancer. Second, it offloads the CPU-intensive encryption and decryption work from your application servers to the load balancer, improving application performance. Third, it allows the load balancer to inspect traffic for malicious content and to route requests intelligently. However, there is a trade-off: between the load balancer and the backend server, the data is unencrypted unless you configure additional encryption. In many compliance frameworks (like PCI-DSS for credit card data), the entire path must be encrypted.
AWS offers several services for TLS termination and encryption in transit:
- Application Load Balancer (ALB): terminates HTTPS traffic at layer 7 (the application layer) and supports advanced routing rules. - Network Load Balancer (NLB): terminates TLS at layer 4 (the transport layer) for very high performance requirements. - CloudFront: AWS's content delivery network that can terminate TLS at its edge locations around the world. - AWS Certificate Manager (ACM): a service that creates, manages, and renews public and private TLS certificates automatically. - Amazon CloudFront and API Gateway: both can terminate TLS and then re-encrypt traffic to your backend. A common exam scenario involves a company that must comply with PCI-DSS or HIPAA regulations requiring encryption in transit for all traffic. You must choose the correct load balancer and decide where to place the TLS termination point. You also need to know that AWS Certificate Manager can provision certificates for use with ALB, NLB, CloudFront, and API Gateway, but it cannot export private keys — meaning you cannot use ACM certificates directly on EC2 instances or on-premises servers.
Client initiates TLS handshake
The client (browser or app) sends a 'ClientHello' message to the server, listing supported TLS versions and cipher suites. This starts the negotiation for a secure connection.
Server responds with certificate
The server replies with its TLS certificate, which contains its public key and identity information signed by a Certificate Authority. The client verifies the certificate's validity, expiry, and trust chain.
Client generates and encrypts session key
The client generates a random symmetric session key, encrypts it with the server's public key (from the certificate), and sends it to the server. Only the server's private key can decrypt it.
Server decrypts session key and establishes secure channel
The server decrypts the session key using its private key. Both sides now have the same symmetric key and begin encrypting all subsequent data with it. The handshake is complete.
Load balancer terminates TLS
The load balancer (ALB or NLB) receives the encrypted traffic, uses its private key to decrypt it, and inspects the plaintext request (e.g., HTTP path) for routing decisions.
Load balancer forwards request to backend server
The load balancer forwards the now-decrypted (or re-encrypted) request to the target backend server. If re-encryption is configured, the load balancer performs another TLS handshake with the backend server.
Sarah is the new cloud security engineer at a mid-sized e-commerce company called ShopFast. The company sells products online and processes credit card payments. ShopFast recently migrated its web application to AWS and is preparing for a PCI-DSS compliance audit. The auditors require that all credit card data be encrypted in transit everywhere — from the customer's browser to the backend payment processing server.
Sarah reviews the current architecture. Customers connect to the company's domain (www.shopfast.com) over HTTPS. The traffic hits an Application Load Balancer (ALB) in front of a fleet of EC2 instances running a web application. Those EC2 instances then make API calls to a separate payment service running on another set of EC2 instances. The ALB currently terminates TLS — it decrypts the incoming HTTPS traffic and forwards it as HTTP to the web servers. The web servers then connect to the payment service over HTTP.
Sarah identifies several problems. First, the traffic between the ALB and the web servers is unencrypted. If someone gains access to the VPC network, they could sniff that traffic and see credit card numbers. The same issue applies between the web servers and the payment service. Second, the payment service is directly exposed to the web servers with no additional TLS in front of it.
To fix this, Sarah takes the following steps:
- She requests a public TLS certificate from AWS Certificate Manager (ACM) for the domain shopfast.com. ACM handles automatic renewal, so she never has to worry about expiry dates. - She configures the ALB listener to use this certificate for TLS termination. She also enables a security policy that only allows strong cipher suites and TLS 1.2 or higher. - She creates a second ACM certificate for internal use on the payment service domain (payment.shopfast.internal). Because ACM cannot export private keys, she cannot install this certificate directly on EC2 instances. Instead, she places a second ALB in front of the payment service, attaches the certificate to that ALB, and configures the web servers to send requests to the payment ALB over HTTPS. - She configures the security groups (firewall rules) so that only the web servers can communicate with the payment ALB, and only over the TLS port (443). - She updates the web servers to trust the internal certificate by adding the ACM certificate's public key to the server's trust store. After these changes, the data path is fully encrypted: customer browser to public ALB (HTTPS), public ALB to web servers (HTTPS), and web servers to payment ALB (HTTPS). The compliance auditor approves the architecture. Sarah also sets up CloudWatch alarms to monitor for any expired certificates and for TLS handshake failures, which could indicate a misconfiguration or an attack.
In this scenario, Sarah used TLS termination in two places (the public ALB and the payment ALB) but also ensured that the traffic between those termination points was re-encrypted using separate certificates. This is a common pattern called "end-to-end encryption with termination at intermediary hops."
The SCS-C02 exam tests Data Encryption in Transit and TLS Termination heavily. Expect at least three to five questions on this topic. They appear in two main formats:
1. Scenario-based multiple choice: You are given a description of an architecture and a compliance requirement. You must identify the correct combination of services (ALB vs NLB vs CloudFront), where to place TLS termination, and which certificates to use. 2. Comparison questions: They ask you to differentiate between TLS termination at a load balancer versus end-to-end TLS, or between using ACM versus importing your own certificate. Specific concepts that appear repeatedly:
- TLS termination at the load balancer (ALB or NLB) is the default pattern for decoupling encryption from application logic. The exam loves asking whether to use ALB or NLB for TLS termination. The rule: ALB for HTTP/HTTPS traffic with routing rules (layer 7); NLB for TCP traffic where you need ultra-low latency (layer 4). - CloudFront supports TLS termination at edge locations. The exam often tests that CloudFront can use an ACM certificate in us-east-1 (only us-east-1 for CloudFront) and that it can also enforce HTTPS-only connections via the Viewer Protocol Policy. - AWS Certificate Manager (ACM) cannot export private keys. This is a trap: they might present a scenario where you need to install a certificate on an EC2 instance, and you must know to import your own certificate (from a third-party CA) rather than using ACM. - Mutual TLS (mTLS) is a newer concept on the exam. In mTLS, both the client and the server present certificates to authenticate each other. This is used for machine-to-machine communication, such as between microservices. - The difference between encryption in transit and encryption at rest. Encryption in transit protects data moving across the network; encryption at rest protects data stored on disk. They often combine these in a single question. - Wildcard certificates (e.g., *.shopfast.com) can be used with load balancers but have security trade-offs. The exam tests when a wildcard is appropriate versus when you need individual certificates. Common traps:
- Choosing CloudFront for internal applications when CloudFront is a public CDN. For internal TLS termination within a VPC, use an ALB or NLB, not CloudFront. - Assuming ACM certificates work on-premises. They only work with AWS services that integrate with ACM (ALB, NLB, CloudFront, API Gateway). If the question involves an on-premises server, they must import a certificate. - Confusing TLS termination with TLS pass-through. In TLS pass-through, the load balancer forwards the encrypted traffic to the backend without decrypting it. This is used for compliance requirements that demand end-to-end encryption without any intermediary decryption. The exam tests that NLB supports TLS pass-through with a listener on port 443. - Forgetting that security groups and network ACLs must allow the appropriate TLS ports. A common answer option is "Implement TLS on the load balancer" without also opening port 443 in the security group of the backend. Memorise these exact facts:
Only us-east-1 region can be used for CloudFront ACM certificates.
ALB requires an idle timeout setting (default 60 seconds) to handle slow clients.
ELB Access Logs can record TLS handshake details for auditing.
The TLS termination point must have access to the private key. In AWS, that service is always the one that holds the certificate (ALB, NLB, CloudFront, or API Gateway).
TLS is the protocol that encrypts data in transit between a client and a server, replacing the outdated SSL protocol.
TLS termination happens at a load balancer (ALB or NLB) where the encrypted traffic is decrypted before forwarding to backend servers.
AWS Certificate Manager (ACM) automatically renews certificates but cannot export private keys for use outside of integrated AWS services.
For end-to-end encryption, you must configure re-encryption between the load balancer and backend servers, not just at the client-facing endpoint.
Network Load Balancers (NLB) support TLS pass-through, meaning the encrypted traffic goes straight to the backend without decryption at the load balancer.
CloudFront TLS certificates must be requested in the us-east-1 region only.
Security groups must allow inbound TCP traffic on port 443 (HTTPS) to the TLS termination point.
Wildcard certificates only cover a single level of subdomain (e.g., *.example.com covers foo.example.com but not foo.bar.example.com).
These come up on the exam all the time. Here's how to tell them apart.
TLS Termination at Load Balancer
Decryption happens at the load balancer, reducing backend CPU load
Traffic between load balancer and backend can be plaintext
Certificate management centralised on the load balancer
End-to-End TLS
Encryption maintained from client to backend server without intermediate decryption
Backend server must perform all cryptographic operations
Each backend server needs its own certificate and private key
Application Load Balancer (ALB)
Operates at Layer 7 (application layer)
Supports content-based routing and HTTP/HTTPS
Can terminate TLS and modify headers
Network Load Balancer (NLB)
Operates at Layer 4 (transport layer)
Ultra-low latency for TCP traffic
Supports TLS pass-through without decryption
ACM Public Certificate
Publicly trusted by browsers
Issued by AWS's public Certificate Authority
Automatic renewal with domain validation
ACM Private Certificate
Trusted only by your internal systems
Issued by a private CA you manage in ACM
Used for internal service-to-service encryption
Mistake
TLS and SSL are the same thing and SSL is still widely used today.
Correct
TLS is the modern secure protocol. SSL (versions 2 and 3) are deprecated and insecure. All current systems use TLS (1.2 or 1.3), but people often say SSL out of habit.
The term SSL was the original name and became a generic term for encrypted connections, even after TLS replaced it.
Mistake
If I use TLS on my load balancer, all data between the client and my backend servers is automatically encrypted.
Correct
TLS termination at the load balancer decrypts the traffic. The data between the load balancer and the backend server is plaintext unless you explicitly configure re-encryption (e.g., HTTPS to the backend).
Beginners assume that once TLS is set up, the entire path is secure, but they do not consider where the decryption happens.
Mistake
AWS Certificate Manager (ACM) certificates can be downloaded and installed on any server, including on-premises.
Correct
ACM does not allow exporting private keys. ACM certificates can only be used with integrated AWS services (ALB, NLB, CloudFront, API Gateway). For on-premises or EC2 instances, you must import your own certificate.
ACM's UI says 'issue a certificate,' which sounds like you get a file, but the private key is kept secret by AWS for security.
Mistake
A wildcard certificate (*.example.com) can be used on a load balancer to secure any subdomain, including subdomains of subdomains like a.b.example.com.
Correct
Wildcard certificates only cover one level of subdomain. *.example.com secures anything.example.com but NOT a.b.example.com. For deeper subdomains, you need a separate certificate or a SAN certificate.
People assume the asterisk matches everything, but DNS wildcards follow the same single-level rule.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
TLS (Transport Layer Security) is the modern, secure version of SSL (Secure Sockets Layer). SSL is deprecated and insecure. All current systems use TLS 1.2 or 1.3, though people often still say 'SSL' out of habit.
Yes, you can import a certificate from any trusted Certificate Authority (including Let's Encrypt) into AWS Certificate Manager (ACM) and then associate it with your ALB. ACM will not auto-renew it, so you must manually renew and re-import.
TLS termination is the point where encrypted traffic is decrypted. It is used at a load balancer to offload the CPU-intensive decryption work from backend servers and to centralise certificate management.
No, TLS only protects data while it is moving across the network. Data at rest (stored on disk) requires separate encryption, such as AWS KMS or server-side encryption with S3.
When a TLS certificate expires, clients will display a security warning and may refuse to connect. The service will become unreachable over HTTPS. AWS Certificate Manager can auto-renew certificates for integrated services.
Yes, you can associate the same certificate from ACM with multiple load balancers, as long as they are in the same region (except CloudFront, which requires us-east-1).
You've finished Data Encryption in Transit and TLS Termination. Continue through the SCS-C02 study guide to build a complete picture of the exam.
Done with this chapter?