Encryption In Transit Tls Vpn

What "Encryption in Transit" Actually Means on AWS

Encryption in transit is the cryptographic protection of data as it moves across any network — between a user and a load balancer, between two VPCs, between a VPC and on-premises, or between an application and an AWS API endpoint. For SCS-C02, encryption in transit is the headline of Domain 5 task 5.1, and the exam tests whether you can pick the right primitive (TLS, IPsec, MACsec, SSH-over-Session-Manager) for each scenario, whether you can enforce that primitive when users try to bypass it, and whether you understand the certificate lifecycle that makes encryption in transit operationally sustainable.

The exam-relevant promises of encryption in transit are three: confidentiality (eavesdroppers cannot read the payload), integrity (tampering en route is detected), and authenticity (the peer is who it claims to be, proven by a certificate or pre-shared key). Whenever a question asks you to "ensure data cannot be intercepted between client and server," the answer is some flavour of encryption in transit — usually TLS for application traffic, IPsec for site-to-site network traffic, MACsec for layer-2 fibre, and Session Manager or EC2 Instance Connect for human-to-instance access.

Encryption in transit also sits next to encryption at rest as the second half of AWS's "encrypt everything, everywhere" mantra. The two are complementary but not interchangeable — encryption at rest protects data on disk, encryption in transit protects data on the wire. SCS-C02 likes to mix them in the same scenario to see whether you can keep them straight.

TLS Fundamentals You Must Know for Encryption in Transit

Transport Layer Security (TLS) is the most common form of encryption in transit on AWS. The handshake establishes session keys, the record protocol then uses those keys to encrypt and authenticate every byte. The current versions you should know cold are TLS 1.2 and TLS 1.3.

TLS 1.2 uses a five-step handshake: ClientHello, ServerHello, Certificate + ServerKeyExchange, ClientKeyExchange + ChangeCipherSpec, Finished. It supports a wide cipher suite menu including RSA key transport (which lacks forward secrecy) and ECDHE-based cipher suites (which provide perfect forward secrecy, or PFS).

TLS 1.3 simplifies the handshake to a single round-trip, removes legacy cipher suites entirely, mandates ephemeral Diffie-Hellman for forward secrecy, and authenticates the entire handshake transcript. Every cipher suite in TLS 1.3 provides perfect forward secrecy by design — there is no opt-out, and there is no RSA key transport.

For encryption in transit on AWS, "perfect forward secrecy" is a frequent exam keyword. PFS means that even if a long-term private key is later compromised, prior session traffic cannot be decrypted because each session derived an ephemeral key that was discarded. CloudFront, ALB, and API Gateway all support PFS-capable cipher suites in their security policies — choosing the right policy is part of designing strong encryption in transit.

Cipher Suites and Security Policies

A TLS connection picks a cipher suite during the handshake — the cipher suite specifies the key-exchange algorithm (ECDHE), the authentication algorithm (RSA or ECDSA), the bulk cipher (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305), and the MAC (often implicit when using AEAD ciphers like GCM). AWS load balancers, CloudFront, and API Gateway expose this choice through security policies — named bundles like ELBSecurityPolicy-TLS13-1-2-2021-06 or TLSv1.2_2021. Picking a stricter policy is the easiest lever to harden encryption in transit at the edge.

ACM — The Certificate Engine Behind Encryption in Transit

AWS Certificate Manager (ACM) is the service that provisions, deploys, and renews the X.509 certificates that make encryption in transit possible. ACM has three modes you must distinguish on the SCS-C02 exam:

1. Public ACM certificates — issued from Amazon's public CA, free of charge, valid for 13 months, and only usable with integrated AWS services (ALB, NLB with TLS listener, CloudFront, API Gateway, App Runner, Verified Access). You cannot export the private key. ACM auto-renews these certificates 60 days before expiry as long as DNS or email validation is intact.
2. Imported certificates — you bring a certificate and private key issued by an external CA. ACM stores them and serves them to integrated services, but it cannot auto-renew them. You must rotate manually before expiry, and CloudWatch + EventBridge can fire on the ACM Certificate Approaching Expiration event.
3. ACM Private CA certificates — issued from a private CA hierarchy you operate inside AWS, used for internal encryption in transit (mTLS, internal microservices, EKS pod identity, IoT device identity). Private certificates can be exported (private key included) for non-AWS workloads.

ACM Private CA Hierarchy

For internal encryption in transit at scale, ACM Private CA gives you a managed CA hierarchy. The recommended pattern is three tiers:

• Root CA — offline-style, signs only subordinate CAs, very long validity (10+ years), kept in a dedicated security account.
• Subordinate CA — signs end-entity certificates, validity ~3-5 years, can be regional and shared via AWS RAM.
• End-entity certificates — short-lived (hours to days for mTLS, 13 months for general TLS), issued automatically by Lambda/EventBridge automation or by services like EKS Pod Identity and IoT Core.

Short-lived end-entity certificates are an explicit SCS-C02 best practice for encryption in transit because they limit blast radius if a key is exfiltrated and reduce reliance on certificate revocation, which is notoriously brittle.

Encryption in Transit for AWS Managed Services

Each managed service has its own encryption-in-transit knobs. The exam tests them as a set of patterns, so memorise the per-service surface.

CloudFront

CloudFront enforces encryption in transit on two legs: viewer-to-edge and edge-to-origin.

• Viewer protocol policy — redirect-to-https or https-only forces clients to use TLS for the viewer leg. The viewer certificate comes from ACM in us-east-1 (CloudFront is a global service that pulls certs from the N. Virginia region only).
• Origin protocol policy — https-only or match-viewer ensures CloudFront re-encrypts traffic to the origin. The origin's certificate must be valid and chain to a CA in CloudFront's trust store. Self-signed origins break encryption in transit and will be rejected unless the origin is an S3 website endpoint, which uses HTTP only and should be replaced by an OAC-protected S3 REST endpoint.
• Security policy — selects the minimum TLS version and cipher suite menu offered to viewers. Use TLSv1.2_2021 or stricter for new distributions.

ALB and NLB

Application Load Balancers terminate TLS at the listener; the certificate comes from ACM in the same region. ALB supports SNI so a single listener can serve up to 25 default certificates plus additional ACM certificates per listener rule. Network Load Balancers (NLB) also support TLS listeners using ACM certs and forward decrypted traffic to targets, or you can use a TCP listener for end-to-end encryption in transit where the target terminates TLS itself.

ALB additionally supports mTLS in two flavours:

• mTLS passthrough — ALB just forwards the client certificate to the target via the X-Amzn-Mtls-Clientcert header.
• mTLS verification — ALB validates the client certificate against a trust store backed by an S3 bucket of CA bundles, rejecting unauthenticated clients before they ever reach the target.

API Gateway

REST and HTTP APIs use TLS by default at the *.execute-api.<region>.amazonaws.com endpoint. Custom domain names attach an ACM certificate (regional) or an ACM cert in us-east-1 for edge-optimised endpoints. API Gateway supports mTLS on custom domains, validating client certs against a trust store object in S3 — the typical use case is B2B partner APIs that need stronger encryption in transit than bearer tokens alone provide.

RDS

RDS supports TLS for in-flight database connections via the rds.force_ssl parameter group setting (PostgreSQL) or require_secure_transport (MySQL). The server certificate is signed by Amazon's RDS CA — historically rds-ca-2019, then rds-ca-rsa2048-g1 and rds-ca-rsa4096-g1. The lifecycle matters: when the CA bundle approaches expiry, AWS sends notifications and you must update both the database and any client trust stores. Failing to update breaks every encryption-in-transit connection from clients that pin the old CA.

S3, DynamoDB, and Other Object/API Services

All AWS service endpoints support HTTPS by default, and most disable HTTP entirely. For S3, however, HTTP requests still succeed unless you explicitly deny them — which is why the aws:SecureTransport condition exists.

Enforcing TLS on AWS APIs with aws:SecureTransport

Encryption in transit is only useful if it cannot be bypassed. The canonical enforcement primitive on AWS is the global IAM condition key aws:SecureTransport, which evaluates to true when the request used HTTPS and false when it used HTTP. Attaching a deny-on-false statement to a resource policy blocks plaintext requests at the API layer — even if the caller has otherwise valid credentials.

The most-tested example is an S3 bucket policy:

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

IPsec Site-to-Site VPN — Encryption in Transit Across the Internet

When the leg you need to protect runs between AWS and on-premises (or between two VPCs over the public internet), TLS is rarely the right primitive — too many protocols, too many ports. AWS Site-to-Site VPN uses IPsec to provide encryption in transit at the network layer, transparently to applications.

A Site-to-Site VPN connection terminates on a Virtual Private Gateway (VGW) or Transit Gateway on the AWS side and a customer gateway device on-premises. Each connection has two tunnels for redundancy, each terminating in a different AWS Availability Zone, each with its own pre-shared key or certificate.

IPsec runs in two phases:

• Phase 1 (IKE — Internet Key Exchange) — peers authenticate (PSK or X.509 cert), negotiate Diffie-Hellman parameters, and derive a Security Association (SA) used to protect Phase 2 negotiation.
• Phase 2 (ESP — Encapsulating Security Payload) — peers negotiate the SA used to protect actual user data, including the cipher (AES-256-GCM is the modern default) and integrity algorithm. ESP provides confidentiality, integrity, and replay protection.

Modern AWS Site-to-Site VPN supports IKEv2, AES-256-GCM, SHA-2 family integrity, DH groups 14 through 24, and perfect forward secrecy via fresh DH exchanges in Phase 2 rekeys. These knobs are configurable per tunnel — pick the strongest values your customer gateway supports.

MACsec on Direct Connect — Layer-2 Encryption in Transit

MACsec (IEEE 802.1AE) is a layer-2 encryption-in-transit standard that sits between Ethernet and IP. On AWS, MACsec is available on dedicated Direct Connect connections at 10 Gbps and 100 Gbps speeds (not on hosted connections, not on 1 Gbps connections, not on lower-tier ports).

How it differs from IPsec:

You configure MACsec by uploading a Connection Key Name (CKN) and Connectivity Association Key (CAK) pair to the Direct Connect connection and to your router. The keys must match exactly. AWS rotates the session keys derived from the CAK using MKA (MACsec Key Agreement) automatically.

MACsec is often the right answer when the question stresses line-rate encryption with minimal overhead on a private fibre link. IPsec is the right answer when the path traverses the public internet or needs to run over a hosted/sub-line-rate Direct Connect.

Systems Manager Session Manager — SSH Without SSH

SCS-C02 has retired the bastion host as a recommended pattern. The modern AWS answer for human encryption in transit to EC2 instances is AWS Systems Manager Session Manager.

Session Manager opens an interactive shell session to an EC2 instance (or on-premises managed node) over a WebSocket tunnelled via the SSM agent. The traffic is TLS 1.2 from end to end — your laptop talks to the SSM regional endpoint, the SSM agent on the instance polls the same endpoint, and the two ends are cryptographically pinned together by the session ID. There is no SSH port, no SSH key pair, no inbound rule on the security group.

Why this is the SCS-C02 default for encryption in transit to instances:

• No inbound port — the security group can deny all inbound traffic. The instance only needs outbound 443 to the SSM, EC2 messages, and S3 endpoints (or VPC interface endpoints for these services if the instance is private).
• IAM-based access — you grant ssm:StartSession via IAM policy. Revocation is instant and there are no SSH keys to rotate.
• Session logging — every keystroke and command output can be streamed to CloudWatch Logs or S3, optionally with KMS encryption. This satisfies most audit requirements that demanded auditd on the bastion.
• Port forwarding — Session Manager can forward an arbitrary local port to a port on the instance or to a remote host the instance can reach. This replaces the SSH tunnel pattern for accessing private RDS, ElasticSearch, or admin web UIs while keeping encryption in transit end-to-end.

EC2 Instance Connect — Short-Lived Keys for Direct SSH

EC2 Instance Connect (EIC) is the second AWS-native option for encryption in transit to instances. EIC injects a one-time SSH public key (valid for 60 seconds) into the instance via the EC2 Instance Connect API, then connects over normal SSH (port 22) using the matching private key.

There are two flavours:

• Public-subnet EIC — works only for instances in a public subnet with a public IP, because the SSH session originates from the user's machine over the internet. Security group must allow port 22 from a defined source.
• EIC Endpoint (EICE) — a managed gateway that lets you reach private-subnet instances without a bastion or NAT. The SSH connection is tunnelled via the endpoint, end-to-end TLS-wrapped. Security group must allow port 22 from the EICE endpoint's security group.

EIC is appealing because the public-key push gives you just-in-time credential issuance with full CloudTrail audit and IAM gating (ec2-instance-connect:SendSSHPublicKey). It is, however, still SSH — the protocol assumptions, key types, and host-key verification all live in the SSH layer. For most SCS-C02 scenarios that ask "secure remote access to EC2 with encryption in transit and least operational overhead," Session Manager beats EIC because it removes SSH entirely.

Decision Tree — Picking the Right Encryption-in-Transit Primitive

When the SCS-C02 exam shows you a scenario, walk this decision tree:

1. Is it a human accessing an EC2 instance?
   • Default → Session Manager (no inbound port, IAM gated, TLS 1.2, audit logs).
   • Need real SSH semantics? → EC2 Instance Connect (short-lived keys) over EICE.
   • Legacy must-have-bastion? → bastion + SG + key rotation, but treat as last resort.
2. Is it an application connecting to an AWS-managed HTTPS endpoint?
   • Always TLS by default. Enforce with aws:SecureTransport on the resource policy.
3. Is it a public-facing web app?
   • CloudFront with ACM cert, viewer policy redirect-to-https, security policy TLSv1.2_2021 or stricter, origin protocol https-only.
4. Is it a private microservice mesh inside a VPC?
   • mTLS on ALB or VPC Lattice, end-entity certs from ACM Private CA, short rotation.
5. Is it on-premises talking to a VPC?
   • Public path → IPsec Site-to-Site VPN.
   • Private DX path with strict crypto requirement → MACsec (10/100 Gbps dedicated) or IPsec over DX.
6. Is it traffic between two VPCs?
   • Same account/region → VPC peering or Transit Gateway, application-layer TLS still recommended for defence in depth.
   • Different accounts/regions → Transit Gateway peering with TLS at the application layer; or PrivateLink for service-to-service.

This decision tree is the mental model the exam expects.

TLS 1.2 vs TLS 1.3 — Concrete Differences That Show Up on the Exam

For SCS-C02 encryption-in-transit questions about modernisation: TLS 1.3 wins on every dimension except client compatibility. Pick a security policy that allows TLS 1.3 with TLS 1.2 fallback unless you have hard regulatory or client constraints.

Certificate Lifecycle — The Operational Heart of Encryption in Transit

A certificate that has expired stops encryption in transit cold. The exam tests whether you can build automation around the lifecycle.

• ACM auto-renewal for public certs requires that domain validation remains intact — DNS validation (CNAME left in place) is the recommended and most reliable path. Email validation can break renewals if the listed contact email no longer works.
• ACM Certificate Approaching Expiration is an EventBridge event that fires 45 days before expiry. Wire it to SNS or a Lambda that opens a ticket — this is the canonical answer when the question says "alert me before encryption in transit breaks."
• AWS Config has a managed rule acm-certificate-expiration-check that flags certificates expiring within a configurable window (default 14 days), useful for SCP/Audit Manager evidence.
• ACM Private CA end-entity certs should be re-issued by automation, not by humans. Pair with EKS Pod Identity Webhook, IoT Core, or a custom Lambda that re-issues every N hours.

mTLS — Mutual Encryption in Transit Authentication

Standard TLS authenticates only the server. mTLS (mutual TLS) authenticates both ends — the client also presents a certificate, which the server validates against a trust store. mTLS is the SCS-C02-favoured pattern for B2B APIs, IoT fleets, and zero-trust microservice meshes.

AWS surfaces for mTLS:

• API Gateway — mTLS on REST/HTTP APIs with custom domain; trust store is an S3 object containing CA bundle PEMs; client cert validation happens in API Gateway before the request hits Lambda or the integration backend.
• ALB — mTLS in passthrough or verification mode; verification mode uses a Trust Store resource (separate ACM-adjacent service) backed by an S3 CA bundle.
• VPC Lattice — auth policies can require mTLS-presented identities and combine them with IAM-based authorization.
• IoT Core — every device gets a unique X.509 certificate, mutual TLS is enforced by default; mTLS is the foundational encryption-in-transit primitive of IoT on AWS.
• EKS service mesh (App Mesh, Istio, Linkerd) — mTLS between pods using ACM Private CA-issued certs.

mTLS is more operationally expensive than server-only TLS because every client needs its own cert, lifecycle, and revocation path. The payoff is strong identity binding — knowing exactly which device or service is on the other end of an encryption-in-transit connection without trusting bearer tokens or shared secrets.

Encryption in Transit for Hybrid and Cross-Region Designs

The exam loves hybrid scenarios. Here is the canonical mapping:

• Branch office → AWS — IPsec Site-to-Site VPN to TGW, redundant tunnels.
• Datacenter → AWS, low latency — Direct Connect with MACsec (dedicated 10/100G) or IPsec over Direct Connect public/transit VIF.
• Datacenter → AWS, multi-account — Direct Connect Gateway with TGW associations, IPsec on top for encryption in transit.
• Region A → Region B — TGW inter-region peering (encrypted by AWS), or VPC peering, with application-layer TLS on top.
• AWS service → AWS service in same region — already encrypted by default on every public endpoint. Use VPC interface endpoints (PrivateLink) to keep traffic off the internet entirely.

Logging, Monitoring, and Auditing Encryption in Transit

Encryption in transit you cannot prove is encryption in transit you cannot defend in an audit. The SCS-C02 mindset is "design the proof, not just the control."

• CloudFront access logs record cs-protocol (http/https) and ssl-protocol (TLSv1.2/1.3) — query in Athena to confirm 100% TLS adoption.
• ALB access logs include ssl_cipher and ssl_protocol columns; flag any non-TLS lines.
• VPC Flow Logs show that traffic flowed but not the cipher; pair with packet capture (Traffic Mirroring) for forensics.
• CloudTrail records every StartSession, SendSSHPublicKey, ACM RenewCertificate, KMS use, and Site-to-Site VPN CreateVpnConnection — central to proving who initiated which encryption-in-transit channel.
• AWS Config rules — s3-bucket-ssl-requests-only, acm-certificate-expiration-check, alb-http-to-https-redirection-check, cloudfront-viewer-policy-https, elbv2-acm-certificate-required — wire all of these into Security Hub for an organisation-wide encryption-in-transit posture dashboard.

Common Pitfalls and Anti-Patterns

Other recurring traps:

• Believing that aws:SecureTransport=true alone provides encryption at rest. It does not.
• Forgetting that public ACM certs are region-bound (CloudFront pulls only from us-east-1; ALB pulls from its own region).
• Using port 22 with a key pair when Session Manager would satisfy the same requirement with no inbound port and full audit.
• Skipping MACsec because "Direct Connect is already private" — DX is private, not encrypted.
• Mixing up Phase 1 (IKE, key negotiation) and Phase 2 (ESP, data encryption) in IPsec questions.
• Treating mTLS as authorisation. mTLS is authentication only; you still need an authz layer (Cognito, IAM, Verified Permissions, Lattice auth policy).

Frequently Asked Questions

Q1: When should I use IPsec VPN versus MACsec for encryption in transit between on-premises and AWS?

Use MACsec when you have a dedicated 10 Gbps or 100 Gbps Direct Connect link, your customer router supports MACsec (CKN/CAK), and you need line-rate throughput with near-zero overhead. Use IPsec Site-to-Site VPN when the path traverses the public internet, when your DX is hosted or sub-10G (MACsec is unsupported there), or when you need encryption in transit on top of an existing public VIF. You can also stack them — IPsec over Direct Connect — to satisfy compliance regimes that demand cryptographic protection regardless of physical layer privacy.

Q2: How do I enforce TLS for every S3 request across an entire AWS Organization?

Combine three layers. (1) Apply an SCP at the org root that denies s3:* when aws:SecureTransport is false, blocking plaintext requests across all member accounts. (2) Deploy the AWS Config managed rule s3-bucket-ssl-requests-only via a Config Conformance Pack so every bucket policy is independently verified. (3) Surface failures in Security Hub. This is the canonical SCS-C02 answer for organisation-wide encryption-in-transit enforcement on object storage.

Q3: What is the difference between mTLS passthrough and mTLS verification on ALB?

In passthrough mode, ALB does no certificate validation — it terminates outer TLS but forwards the client cert in the X-Amzn-Mtls-Clientcert header for the target to inspect. Use this when your application has its own PKI and authorisation logic. In verification mode, ALB validates the client certificate against a Trust Store (S3-backed CA bundle) and rejects unauthenticated clients before they reach the target. Verification mode is the stronger encryption-in-transit posture because unauthenticated traffic never enters the application tier.

Q4: Why might encryption in transit "break" 13 months after deploying a public ACM certificate?

ACM auto-renews public certificates 60 days before expiry, but renewal silently fails if domain validation has been broken — most commonly when the validation CNAME record was removed from Route 53, or when the listed validation email mailbox no longer accepts mail. The fix is to use DNS validation with the CNAME left in place permanently, and to wire the ACM Certificate Approaching Expiration EventBridge event to SNS so you have 45 days of warning. Imported certs do not auto-renew at all and must be rotated manually.

Q5: Can Session Manager replace every bastion-host use case?

Almost. Session Manager covers interactive shell, command execution, and port forwarding (including to remote hosts the instance can reach), so it replaces 95% of what bastions did — including ssh -L tunnels to private RDS or admin web UIs. The remaining gap is rare cases where you need to use SSH-specific features (Git over SSH to a private repo on the instance, specific SSH key-based agent forwarding flows). For those, EC2 Instance Connect Endpoint (EICE) provides a TLS-wrapped SSH tunnel that still avoids inbound port 22 from the internet. Combined, Session Manager and EICE retire the traditional bastion architecture for encryption in transit to compute.

Q6: How does encryption in transit interact with encryption at rest in the same architecture?

They are independent and complementary. Encryption in transit (TLS, IPsec, MACsec, Session Manager) protects data while it moves on a network. Encryption at rest (KMS, SSE-S3, EBS encryption, RDS encryption) protects data while it sits on a disk. A request can be encrypted in transit and stored in plaintext (bad), or unencrypted in transit and stored encrypted (also bad). For SCS-C02, design both layers explicitly: aws:SecureTransport=true to require TLS on the API call, and s3:x-amz-server-side-encryption=aws:kms (or SSE-S3 default bucket encryption) to require encryption at rest on the stored object. Same pattern for KMS, Secrets Manager, SQS, SNS — encrypt in transit on the wire, encrypt at rest in the store.

Q7: What's the recommended certificate hierarchy for internal mTLS using ACM Private CA?

A three-tier hierarchy is the AWS-recommended pattern for encryption in transit at scale: (1) Root CA in a hardened security account, used only to sign subordinates, with a 10+ year validity. (2) Subordinate CAs per environment or business unit, signed by the root, with 3-5 year validity, shared via AWS RAM to workload accounts. (3) End-entity certificates with short validity (hours to days for mTLS, 13 months for general TLS), issued by automation. Short-lived end-entity certs minimise the operational burden of revocation and limit blast radius if a private key leaks — both core SCS-C02 themes around encryption in transit.