Data Protection Day 4
SCS-C03 · Domain 5 · Data Protection (18%) · Day 4 of 5

Data in transit: TLS, private paths and inter-node encryption

Day 3 protected data where it sits. Today it moves: forcing TLS on S3, databases and CloudFront, choosing TLS policies and mutual TLS on load balancers, keeping traffic private with VPC endpoints, letting people in with Client VPN or Verified Access, and encrypting traffic between instances and cluster nodes.

Skill 5.1.1 require encryption in transitSkill 5.1.2 private and secure connectivitySkill 5.1.3 inter-node encryption~90 min read + 30 min lab
01

Requiring TLS when connecting to services

Most AWS endpoints accept HTTPS by default, but several still allow plaintext or old TLS versions unless you say no. The exam asks how to require encryption in transit for a named service, so you need one switch per service. For anything with a resource policy, the switch is the same condition key: aws:SecureTransport.

Concept profile

aws:SecureTransport condition

often confused with Encryption at rest settings
?What is it?

A global condition key that is true when the request arrived over TLS. A Deny statement with "Bool": {"aws:SecureTransport": "false"} in a bucket, queue or topic policy rejects every plaintext HTTP request.

⚙How does it work?
  • Add the Deny to the resource policy (S3 bucket policy, SQS queue policy, SNS topic policy, EFS file system policy).
  • Pair with s3:TlsVersion (NumericLessThan 1.2) to also block old TLS versions.
  • Databases use parameters instead: rds.force_ssl, require_secure_transport, Redshift require_ssl.
  • AWS Config rule s3-bucket-ssl-requests-only finds buckets missing the Deny.
{ }Structure
Amazon S3, SQS, SNSResource policy: Deny if aws:SecureTransport = falseRDS PostgreSQL / SQL ServerParameter rds.force_ssl = 1RDS / Aurora MySQLParameter require_secure_transport = ONAmazon RedshiftParameter group require_ssl = trueAmazon EFSMount with -o tls + file system policy on SecureTransportCloudFrontViewer protocol policy: Redirect to HTTPS or HTTPS onlyDynamoDB, KMS, most APIsEndpoints are HTTPS only already
One way to force TLS for each common service.
⇄aws:SecureTransport vs Encryption at rest settings
aws:SecureTransportDefault encryption at rest
ProtectsData moving over the networkData stored on disk
Where setResource policy DenyBucket / volume / DB setting
StopsHTTP requestsUnencrypted storage
Evidence403 on http:// callsEncryption field on object / volume
Config rules3-bucket-ssl-requests-onlys3-bucket-server-side-encryption-enabled
!Common mistakes the exam tests
  • Writing it as an Allow with SecureTransport true: other Allow statements still let HTTP through. Use an explicit Deny on false.
  • Thinking default encryption (SSE-S3) also protects data in transit: it doesn’t.
  • Forgetting databases ignore resource policies: set the parameter in the DB or cluster parameter group (and reboot if it is static).
  • Setting CloudFront viewer HTTPS but leaving the origin protocol policy on HTTP only: the second hop is plaintext.
  • For EFS, mounting without -o tls and with no file system policy to enforce it.
✓Benefits and use cases
  • Compliance rule “all data in transit must be encrypted”.
  • Blocking legacy clients that use TLS 1.0 or 1.1.
  • Detective control at scale with AWS Config across accounts.

CloudFront and API Gateway

CloudFront has two hops. The viewer protocol policy controls viewer to edge (Redirect HTTP to HTTPS or HTTPS only) and a security policy sets the minimum TLS version (for example TLSv1.2_2021). The origin protocol policy controls edge to origin (HTTPS only or Match viewer). API Gateway endpoints are HTTPS only; on a custom domain choose a TLS 1.2 security policy, and disable the default execute-api endpoint so clients can only use the custom domain.

Think of it like · a building with a security desk

Different doors, same rule: no one walks in without a badge.

AWS conceptFamiliar thing
aws:SecureTransport Deny≈A sign on the door: anyone without a sealed envelope is turned away
s3:TlsVersion≈Envelopes must use the new seal, not the old wax one
rds.force_ssl≈The database room has its own lock set from the inside
CloudFront viewer + origin policy≈Two doors in a row: the front door and the back door both need sealed envelopes
Config rule≈A guard who walks round every night checking each door has the sign
Real AWS example · deny plaintext and old TLS on a bucket

Two Deny statements every regulated bucket should have.

{ "Version": "2012-10-17", "Statement": [
  { "Sid": "DenyHTTP", "Effect": "Deny", "Principal": "*", "Action": "s3:*",
    "Resource": ["arn:aws:s3:::pii-data", "arn:aws:s3:::pii-data/*"],
    "Condition": {"Bool": {"aws:SecureTransport": "false"}} },
  { "Sid": "DenyOldTLS", "Effect": "Deny", "Principal": "*", "Action": "s3:*",
    "Resource": ["arn:aws:s3:::pii-data", "arn:aws:s3:::pii-data/*"],
    "Condition": {"NumericLessThan": {"s3:TlsVersion": "1.2"}} } ]}

Include both the bucket ARN and /* so bucket-level and object-level calls are covered.

Exam-style scenario

A security engineer must make sure that every request to an S3 bucket and to an RDS for PostgreSQL database uses encryption in transit. What should the engineer do?

  1. A. Enable default SSE-KMS on the bucket and storage encryption on RDS.
  2. B. Add a bucket policy that denies requests when aws:SecureTransport is false, and set rds.force_ssl = 1 in the DB parameter group.
  3. C. Put both behind an Application Load Balancer with an HTTPS listener.
  4. D. Add an IAM policy that allows access only when aws:SecureTransport is true.
Show the worked answer

Answer: B

S3 uses the resource-policy Deny; RDS PostgreSQL enforces TLS with the rds.force_ssl parameter.

Why not the others

  • A: Those are encryption at rest.
  • C: An ALB can’t front S3 or a database connection this way.
  • D: An Allow can be overridden by other Allows; resource-wide enforcement needs an explicit Deny.
How the exam tests this
  • “Deny HTTP to S3 / SQS / SNS”→ Deny on aws:SecureTransport = false.
  • “Block TLS 1.0 / 1.1 on S3”→ s3:TlsVersion NumericLessThan 1.2.
  • “Force TLS on RDS PostgreSQL”→ rds.force_ssl = 1.
  • “Force TLS on MySQL”→ require_secure_transport = ON.
  • “Find buckets that allow HTTP”→ Config s3-bucket-ssl-requests-only.
Must remember
  • SecureTransport: Deny on false, never Allow on true.
  • Databases: parameters, not policies.
  • Redshift: require_ssl.
  • EFS: -o tls + file system policy.
  • CloudFront: viewer and origin protocol policies.
02

TLS on load balancers

Load balancers are where most public TLS ends. The exam asks three things: which security policy (TLS versions and ciphers), where TLS ends (at the load balancer, re-encrypted, or passed through), and how to make clients prove who they are with mutual TLS.

Concept profile

ALB HTTPS listener + security policy

often confused with NLB TCP passthrough
?What is it?

An HTTPS listener on an Application Load Balancer ends TLS using a certificate from ACM (or IAM). Its security policy is a predefined set of TLS protocols and ciphers; ALBs don’t support custom policies.

⚙How does it work?
  • Console default policy today: ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09 (TLS 1.2 and 1.3, hybrid post-quantum key exchange). CLI and CloudFormation still default to ELBSecurityPolicy-2016-08, so set the policy explicitly.
  • FIPS policies use a FIPS-validated module; TLS13-1-3 policies accept only TLS 1.3.
  • Add an HTTP :80 listener whose only rule redirects to HTTPS :443.
  • Use an HTTPS target group to re-encrypt to targets; the backend policy follows the listener policy.
{ }Structure
1 · Terminate at the load balancerClientHTTPSALB (cert in ACM)HTTPTargetsEasiest. Traffic inside the VPC is plaintext at the app layer (Nitro may still encrypt it).2 · End-to-end: terminate and re-encryptClientHTTPSALB or NLB TLSHTTPSTargetsInspect at the load balancer, still encrypted to the target (HTTPS target group).3 · PassthroughClientTLSNLB TCP :443TLSTargetsLoad balancer never sees plaintext; the target holds the certificate and private key.
Where does TLS end?
⇄ALB TLS listener vs NLB TCP passthrough
ALB HTTPS listenerNLB TCP passthrough
TLS ends atLoad balancerTarget
Load balancer sees plaintextYes (can route on path, add WAF)No
Certificate lives inACM on the ALBYour target servers
AWS WAFYesNo
Mutual TLSBuilt in (verify or passthrough)Done by the target
!Common mistakes the exam tests
  • Creating the listener from the CLI and keeping the old 2016-08 default when the rule says TLS 1.2+ only.
  • Trying to build a custom cipher list on an ALB: pick the closest predefined policy.
  • Choosing ALB when the rule says the load balancer must never decrypt traffic: use an NLB TCP listener (passthrough).
  • Putting WAF on an NLB: WAF attaches to ALB, CloudFront, API Gateway and others, not NLB.
  • Expecting an ALB in passthrough mTLS mode to validate certificates: in passthrough the target must verify the chain.
✓Benefits and use cases
  • Public HTTPS with ACM certificates that renew automatically.
  • FIPS or TLS 1.3-only endpoints for regulated workloads.
  • Partner APIs where each client has its own certificate (mTLS).

Mutual TLS on ALB

With verify mode, the ALB checks the client certificate against a trust store (a PEM bundle of your CA certificates, optionally with revocation lists) and sends details to targets in headers such as X-Amzn-Mtls-Clientcert-Subject. With passthrough mode, it forwards the whole chain in X-Amzn-Mtls-Clientcert and the application verifies it. NLB TLS listeners also end TLS with ACM certificates and security policies, which is useful for non-HTTP TLS traffic.

Think of it like · a hotel reception

Where the guest’s sealed letter gets opened.

AWS conceptFamiliar thing
ALB terminates TLS≈Reception opens the letter, reads the room number, walks it up
Re-encrypt to targets≈Reception reads it, then reseals it in a new envelope for the room
NLB passthrough≈Reception just forwards the sealed letter; only the guest can open it
Security policy≈The list of seal types reception accepts
mTLS verify≈Reception also checks the sender’s ID card against an approved list
Real AWS example · HTTPS listener with a TLS 1.3 policy and redirect

Set the policy explicitly so CLI defaults don’t leave TLS 1.0 enabled.

$ aws elbv2 create-listener --load-balancer-arn $ALB --protocol HTTPS --port 443 \
    --certificates CertificateArn=$ACM_CERT \
    --ssl-policy ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09 \
    --default-actions Type=forward,TargetGroupArn=$TG

$ aws elbv2 create-listener --load-balancer-arn $ALB --protocol HTTP --port 80 \
    --default-actions 'Type=redirect,RedirectConfig={Protocol=HTTPS,Port=443,StatusCode=HTTP_301}'

List policies with aws elbv2 describe-ssl-policies.

Exam-style scenario

A payments company must make sure card data is never decrypted by any intermediate AWS component between the client and its EC2 instances, which hold the certificates in an HSM. It still needs to spread traffic across instances in several AZs. What should it use?

  1. A. ALB with an HTTPS listener and an HTTPS target group.
  2. B. NLB with a TCP listener on port 443 forwarding to the instances.
  3. C. CloudFront with an HTTPS origin.
  4. D. ALB with mutual TLS in verify mode.
Show the worked answer

Answer: B

A TCP listener on an NLB passes encrypted bytes through, so TLS ends only on the instances.

Why not the others

  • A: The ALB decrypts and re-encrypts, so it sees plaintext.
  • C: CloudFront terminates TLS at the edge.
  • D: Still terminates TLS on the ALB.
How the exam tests this
  • “Only TLS 1.2+ on ALB”→ Pick a TLS13-1-2 security policy.
  • “FIPS 140 validated TLS”→ A FIPS security policy.
  • “Load balancer must not decrypt”→ NLB TCP passthrough.
  • “Clients authenticate with certificates”→ ALB mTLS + trust store.
  • “Encrypt ALB to targets”→ HTTPS target group.
Must remember
  • ALB: no custom security policies.
  • CLI default is still 2016-08: set it explicitly.
  • Redirect :80 → :443 with a listener rule.
  • mTLS: verify (ALB checks) vs passthrough (app checks).
  • Passthrough = NLB TCP.
03

VPC endpoints and PrivateLink

Skill 5.1.2 is about keeping traffic to AWS services off the internet. VPC endpoints let instances in private subnets reach S3, KMS, Secrets Manager and others without an internet gateway or NAT, and they give you two extra policy hooks: an endpoint policy and the aws:SourceVpce condition.

Concept profile

Interface VPC endpoint (PrivateLink)

often confused with Gateway VPC endpoint
?What is it?

An elastic network interface with private IPs in your subnets that forwards traffic to an AWS service (or a partner or your own service) over the AWS network using AWS PrivateLink.

⚙How does it work?
  • Create it per service and per AZ subnet; attach security groups.
  • Turn on private DNS so the normal service name (for example kms.us-east-1.amazonaws.com) resolves to the endpoint’s private IPs.
  • Attach an endpoint policy to limit which principals, actions and resources can be used through it.
  • Share your own service: put it behind an NLB (or GWLB) and create an endpoint service; consumers connect with interface endpoints.
{ }Structure
VPC (no internet gateway) Private subnet EC2 app no public IP Route table entry pl-xxxx → vpce-gw Interface endpoint ENI + private IP + SG private DNS Gateway endpoint S3 and DynamoDB only Free · route table · same Region Not reachable from on-prem Interface (PrivateLink) KMS, SQS, Secrets Manager, S3… Hourly + per-GB cost Reachable over VPN / DX Your own service via NLB
Two kinds of VPC endpoint.
⇄Interface endpoint vs Gateway VPC endpoint
Interface endpointGateway endpoint
ServicesMost AWS services, SaaS, your ownS3 and DynamoDB only
How traffic gets thereENI + DNSRoute table prefix list
Security groupsYesNo
CostHourly + per GBFree
From on-prem / peered VPCYesNo
!Common mistakes the exam tests
  • Using aws:SourceIp in a bucket policy for traffic through an endpoint: requests carry private IPs, so use aws:SourceVpce, aws:SourceVpc or aws:VpcSourceIp.
  • Forgetting the default endpoint policy allows full access; scope it to your own buckets to stop data being copied to an attacker’s bucket.
  • Expecting a gateway endpoint to work from on-premises over VPN or Direct Connect: use an interface endpoint for S3.
  • Forgetting private DNS: without it, SDKs keep resolving the public endpoint.
  • Thinking endpoints add encryption: they keep traffic private; TLS is still what encrypts it.
✓Benefits and use cases
  • Private subnets that call KMS, Secrets Manager, STS without NAT.
  • Data perimeter: bucket only reachable from your endpoints, endpoints only reach your buckets.
  • Offer an internal API to other accounts without VPC peering.
Think of it like · a private corridor in an airport

Getting from your gate to another terminal without going outside.

AWS conceptFamiliar thing
Internet path via NAT≈Leaving the airport, taking a taxi round, and going through security again
Gateway endpoint≈A free staff corridor, only to two terminals (S3 and DynamoDB), signposted on the map (route table)
Interface endpoint≈A private door built into your own gate, with its own guard (security group)
Endpoint policy≈The guard at the corridor checking where you are allowed to go
aws:SourceVpce≈The destination shop only serves people who came through your corridor
Real AWS example · bucket reachable only through one endpoint

Deny anything that didn’t arrive through vpce-1a2b3c4d.

{ "Sid": "OnlyFromOurEndpoint", "Effect": "Deny", "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::payroll", "arn:aws:s3:::payroll/*"],
  "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-1a2b3c4d"}} }

Careful: this also blocks console access and AWS services calling on your behalf; add exceptions (for example an admin role) before applying.

Exam-style scenario

EC2 instances in private subnets with no NAT gateway must read objects from S3 and decrypt them with KMS. The security team also wants the bucket to accept requests only from this VPC. What is the most cost-effective design?

  1. A. A NAT gateway and a bucket policy with aws:SourceIp.
  2. B. A gateway endpoint for S3, an interface endpoint for KMS with private DNS, and a bucket policy denying requests where aws:SourceVpc isn’t this VPC.
  3. C. Interface endpoints for both S3 and KMS, and a bucket policy with aws:SourceIp.
  4. D. VPC peering to an S3 VPC.
Show the worked answer

Answer: B

Gateway endpoints are free for S3; KMS needs an interface endpoint; SourceVpc/SourceVpce identify endpoint traffic.

Why not the others

  • A: Costs more, uses the internet path, and SourceIp would be a NAT public IP that isn’t specific enough.
  • C: Works for S3 but costs more; SourceIp doesn’t match private endpoint traffic.
  • D: Not a thing; S3 isn’t in your VPC.
How the exam tests this
  • “Private S3/DynamoDB access, cheapest”→ Gateway endpoint.
  • “Private access to KMS, SQS, Secrets Manager”→ Interface endpoint + private DNS.
  • “S3 from on-prem privately”→ Interface endpoint for S3.
  • “Bucket only via our endpoint”→ aws:SourceVpce / aws:SourceVpc.
  • “Stop copying data to other buckets”→ Scope the endpoint policy.
Must remember
  • Gateway: S3 + DynamoDB, free, route table.
  • Interface: ENI, SG, private DNS, PrivateLink.
  • Through endpoints, aws:SourceIp doesn’t match.
  • Default endpoint policy = full access.
  • Share your service: NLB + endpoint service.
04

Client VPN, Site-to-Site VPN and Verified Access

People and offices also need encrypted paths into AWS. The exam gives a requirement such as “employees on laptops”, “branch office” or “no VPN, check the device” and expects one service. The newest and most tested is AWS Verified Access: zero-trust access to one application at a time.

Concept profile

AWS Verified Access

often confused with AWS Client VPN
?What is it?

A service that gives users access to internal applications without a VPN. It evaluates every request against policies that use identity and device signals, and logs every attempt.

⚙How does it work?
  • Add trust providers: a user identity provider (IAM Identity Center or an OIDC IdP) and optionally a device-management provider.
  • Create a Verified Access instance and groups; write group and endpoint policies in Cedar.
  • Create endpoints that point at a load balancer, a network interface, a network CIDR or an RDS instance, cluster or proxy.
  • Users reach the app at its domain name; nothing is exposed directly to the internet.
{ }Structure
Client VPN Laptop → VPC network OpenVPN (TLS) client Server cert in ACM Auth: AD · mutual cert · SAML (+ combos) Authorization rules Split tunnel option Whole-network access Site-to-Site VPN Office network → VPC IPsec, two tunnels VGW or Transit Gateway Direct Connect is NOT encrypted by default: use MACsec or run a VPN over DX Network-to-network Verified Access User → one application No VPN client needed Checks identity + device on every request Policies in Cedar Endpoints: load balancer, ENI, CIDR, RDS Logs every attempt Zero trust, per app
Three ways in, for three kinds of requirement.
⇄Verified Access vs AWS Client VPN
Verified AccessClient VPN
Grants access toOne application per endpointA network (subnets you authorize)
Client softwareBrowser for HTTP appsOpenVPN-based client
DecisionEvery request, identity + deviceAt connect time + authorization rules
Policy languageCedarAuthorization rules by group / CIDR
ModelZero trustTraditional remote access VPN
!Common mistakes the exam tests
  • Choosing Client VPN when the question says “without a VPN” or “check device posture on every request”.
  • Forgetting Client VPN always needs a server certificate in ACM, whatever the authentication type.
  • Thinking you can pick only one Client VPN auth method: you can combine mutual certificate with AD or SAML, and then both are required.
  • Assuming Direct Connect is encrypted: it isn’t by default. Use MACsec on supported dedicated connections, or run an IPsec VPN over DX.
  • Using Site-to-Site VPN for individual laptops: that’s Client VPN.
✓Benefits and use cases
  • Contractors reach one internal app from managed devices only.
  • Replace a corporate VPN for web apps.
  • Combine with WAF on the Verified Access endpoint for HTTP apps.

Client VPN and Site-to-Site VPN details

AWS Client VPN is a managed OpenVPN-based (TLS) endpoint. Authentication is Active Directory, mutual certificate, or SAML federation (alone, or mutual plus one of the other two). Authorization rules decide which networks each group can reach, split tunnel sends only VPC-bound traffic through the VPN, and a client connect handler (Lambda) can run extra checks at connect time. Site-to-Site VPN joins a whole network to a VGW or transit gateway with two IPsec tunnels.

Think of it like · visiting a company campus

How visitors get in.

AWS conceptFamiliar thing
Client VPN≈A visitor badge that opens the main gate; then you can walk to any building you’re authorized for
Site-to-Site VPN≈A private covered bridge between your office and the campus
Verified Access≈A receptionist at each building door who checks your ID and your phone’s health every time you enter
Direct Connect without MACsec≈A private road with no walls: private, but not sealed
Cedar policy≈The receptionist’s written rulebook
Real AWS example · a Verified Access policy in Cedar

Allow the finance group from devices with low risk.

permit(principal, action, resource)
when {
  context.idc.groups has "c242c5b0-6081-1845-6fa8-6e0d9513c107" &&
  context.jamf.risk == "LOW"
};

idc and jamf are the policy reference names you gave the trust providers.

Exam-style scenario

A company wants contractors to use one internal HR web application hosted behind an internal ALB. Access must not require a VPN, must check the user’s identity in IAM Identity Center and the device’s risk score on every request, and must be logged. What should it use?

  1. A. AWS Client VPN with SAML authentication.
  2. B. AWS Verified Access with an IAM Identity Center trust provider, a device trust provider, and a load balancer endpoint.
  3. C. A public ALB with Amazon Cognito authentication.
  4. D. Site-to-Site VPN to the contractor’s office.
Show the worked answer

Answer: B

Verified Access is VPN-less, evaluates identity and device signals on each request, and logs all attempts.

Why not the others

  • A: It is a VPN and gives network-level access.
  • C: Exposes the app publicly and doesn’t check device posture.
  • D: Network-to-network, no per-user or device checks.
How the exam tests this
  • “Employees’ laptops to VPC”→ Client VPN.
  • “Office network to VPC, encrypted”→ Site-to-Site VPN (IPsec).
  • “No VPN, check user + device per request”→ Verified Access.
  • “Encrypt Direct Connect”→ MACsec or VPN over DX.
  • “Client VPN with certificates and SSO”→ Mutual auth + SAML.
Must remember
  • Client VPN: server cert in ACM always.
  • Auth: AD · mutual · SAML; combos with mutual.
  • Verified Access: per request, Cedar, no VPN.
  • VA endpoints: LB · ENI · CIDR · RDS.
  • DX is not encrypted by default.
05

Nitro encryption and VPC encryption controls

Inside a VPC, many instances already encrypt traffic in hardware. The Nitro System offloads this, so there is no performance cost, but only under certain conditions. VPC encryption controls turn that into something you can prove and enforce.

Concept profile

Nitro in-transit encryption

often confused with Application TLS
?What is it?

Supported Nitro instance types automatically encrypt traffic between each other using AEAD algorithms with 256-bit keys, with no impact on network performance and nothing to configure.

⚙How does it work?
  • Both instances use supported types (for example M6i, C7g, R7i, M5n).
  • They are in the same Region.
  • They are in the same VPC or peered VPCs.
  • Traffic doesn’t pass through a virtual network device or service such as a load balancer or transit gateway.
{ }Structure
Encrypted automatically by Nitro m6i instance AEAD 256-bit c7g instance Supported types · same Region · same or peered VPC No load balancer or transit gateway in the path Not covered Older instance types (e.g. t2) Traffic through ALB/NLB, TGW Traffic to the internet, on-premises or other Regions → you still need TLS VPC encryption controls Monitor mode: flow log field encryption-status (0 none · 1 Nitro · 2 app · 3 both) Enforce mode: blocks resources that allow cleartext (existing VPCs: monitor first)
When Nitro encrypts for you, and how to prove it.
⇄Nitro encryption vs Application TLS
Nitro encryptionApplication TLS
SetupNone (right instance types)Certificates, config in app
ScopeInstance to instance, conditions applyEnd to end, any path
Authenticates the peerNoYes (certificate check)
Through a load balancerNot that hopYes
Performance costNoneSome CPU
!Common mistakes the exam tests
  • Assuming all EC2 traffic is encrypted: older types and traffic through load balancers or transit gateways aren’t covered.
  • Treating Nitro encryption as authentication: it doesn’t verify who the peer is. Regulated apps still use TLS.
  • Trying to switch an existing VPC straight to enforce mode: existing VPCs go through monitor first.
  • Expecting old flow logs to show the new field: create a new flow log that includes ${encryption-status}.
✓Benefits and use cases
  • Cheap baseline encryption for east-west traffic.
  • Evidence for auditors that VPC traffic is encrypted.
  • Find and migrate resources that block enforcement.

VPC encryption controls

Monitor mode shows the encryption status of flows through a new flow log field, encryption-status: 0 not encrypted, 1 Nitro-encrypted, 2 application-encrypted, 3 both. Enforce mode blocks features and resources that would allow cleartext inside the VPC. Resources that leave the AWS network, such as internet gateways, NAT gateways and virtual private gateways, can be excluded, and you remain responsible for encrypting those flows. GetVpcResourcesBlockingEncryptionEnforcement lists what still needs migrating.

Encryption controls also extend hardware encryption beyond plain EC2. When you turn on monitor mode, ALBs, NLBs, Fargate and the EKS control plane move automatically to hardware that encrypts natively. A transit gateway encrypts VPC-to-VPC traffic once you turn on its encryption support. Older instance types, RDS, ElastiCache, EMR and similar services you migrate yourself to modern instance types. There are only 8 exclusions: internet gateway, NAT gateway, egress-only internet gateway, peering to a non-enforced VPC, virtual private gateway, Lambda in the VPC, VPC Lattice and EFS. Gateway Load Balancer and Network Firewall can’t run in an enforce-mode VPC, and in enforce mode an NLB can’t terminate TLS (targets must). You can set it for a whole account, or across an organization with a declarative policy.

The plain Nitro rule (“not through a load balancer or transit gateway”) describes a VPC without encryption controls. If the question mentions VPC encryption controls, ALB, NLB and an encryption-enabled transit gateway are on encrypted hardware.
Think of it like · a city’s armoured tram network

Some routes are sealed automatically, others aren’t.

AWS conceptFamiliar thing
Nitro encryption≈Modern trams have sealed carriages built in; old trams don’t
Conditions≈Sealing only works on tracks inside the same city, with no change of line at a station (load balancer, TGW)
Application TLS≈Locking your own briefcase, whatever tram you ride
Monitor mode≈Cameras that log which carriages were sealed
Enforce mode≈Old unsealed trams are banned from the network
Real AWS example · find instance types that encrypt in transit

And log encryption status for a VPC.

$ aws ec2 describe-instance-types \
    --filters Name=network-info.encryption-in-transit-supported,Values=true \
    --query "InstanceTypes[*].InstanceType" --output text | tr '\t' '\n' | sort | head -3
c5n.18xlarge
c5n.2xlarge
c5n.4xlarge

$ aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-0abc \
    --traffic-type ALL --log-group-name vpc-enc \
    --deliver-logs-permission-arn arn:aws:iam::111122223333:role/flowlogs \
    --log-format '${encryption-status} ${srcaddr} ${dstaddr} ${dstport} ${traffic-path}'

A value of 0 in encryption-status marks a flow you still need to fix.

Exam-style scenario

An auditor asks a company to prove that traffic between its application servers inside one VPC is encrypted, and to prevent any new resource that would send cleartext. Most instances are M6i; a few are old T2 instances. What should the security team do?

  1. A. Enable VPC Flow Logs with the default format.
  2. B. Turn on VPC encryption controls in monitor mode with a flow log including encryption-status, migrate the T2 instances to supported types, then switch to enforce mode.
  3. C. Put all instances behind an internal ALB with HTTPS.
  4. D. Enable EBS encryption by default.
Show the worked answer

Answer: B

Monitor mode gives evidence per flow and lists blockers; once old types are migrated, enforce mode stops future cleartext.

Why not the others

  • A: The default format has no encryption-status field.
  • C: Adds a hop and doesn’t cover direct instance-to-instance traffic.
  • D: That is at rest.
How the exam tests this
  • “Encryption between instances, no app change”→ Nitro supported instance types.
  • “Traffic through ALB / TGW”→ Not Nitro-covered: use TLS (unless VPC encryption controls are on; then ALB/NLB and an encryption-enabled TGW are covered).
  • “Prove VPC traffic is encrypted”→ VPC encryption controls monitor + encryption-status.
  • “Block cleartext in the VPC”→ Enforce mode.
  • “What blocks enforce mode”→ GetVpcResourcesBlockingEncryptionEnforcement.
Must remember
  • Nitro: same Region, same/peered VPC, no LB/TGW.
  • AEAD 256-bit, no performance hit.
  • encryption-status: 0 · 1 · 2 · 3.
  • Existing VPC: monitor before enforce.
  • Exclusions (IGW, NAT, VGW…): you encrypt.
  • Not allowed in enforce mode: GWLB, Network Firewall.
06

Inter-node encryption in clusters

Skill 5.1.3 is about traffic between the nodes of a distributed service: Hadoop and Spark on EMR, distributed training on SageMaker AI, pods on EKS, and search or streaming clusters. Each service has its own setting, and many can only be turned on when the cluster is created.

Concept profile

EMR security configuration

often confused with SageMaker inter-container traffic encryption
?What is it?

A reusable EMR object that sets encryption in transit and at rest (and authentication) for clusters that reference it. In-transit encryption turns on TLS for supported open-source endpoints such as Hadoop RPC, HDFS block transfer and Spark.

⚙How does it work?
  • Create it once with create-security-configuration; pass its name when you launch each cluster.
  • Certificates for in-transit TLS: EMR-managed, a zip of PEM files in S3, or a custom Java provider.
  • At rest: EMRFS data in S3 with SSE-S3, SSE-KMS or client-side (CSE-KMS / CSE-C); local disks with EBS encryption (KMS) or LUKS.
  • Some endpoints use SASL, which needs Kerberos in the same security configuration.
{ }Structure
Amazon EMRsecurity configin-transit: TLS certs(EMR-managed, PEMzip in S3, or custom)SageMaker AIdistributed trainingEnableInterContainer-TrafficEncryption(slower training)Amazon EKSpod-to-pod: Nitroinstance types, orservice mesh mTLSor VPC Lattice TLSOpenSearchnode-to-nodeencryption +require HTTPS ondomain endpointMSK / ElastiCacheTLS within clusterand client to brokeror node; ElastiCachein-transit + AUTHEach cluster service has its own switch. The exam names the service and expects that switch.
The switch for each cluster service.
⇄EMR security config vs SageMaker inter-container traffic encryption
EMR security configurationSageMaker inter-container encryption
ServiceEMR clustersSageMaker distributed training jobs
Turned on bySecurity configuration at launchEnableInterContainerTrafficEncryption on the job
CoversOpen-source app endpoints between nodesTraffic between training containers
CertificatesYou choose the providerManaged by SageMaker
Trade-offKerberos for SASL endpointsLonger training time and cost
!Common mistakes the exam tests
  • Trying to add a security configuration to a running EMR cluster: it is chosen at launch.
  • Expecting SSE-C for EMRFS: not supported.
  • Forgetting SageMaker inter-container encryption is off by default and slows training.
  • Assuming EKS encrypts pod-to-pod traffic: use Nitro instance types that encrypt in transit, or a service mesh / VPC Lattice with TLS.
  • Confusing EKS secrets encryption (envelope encryption of Kubernetes Secrets at rest with KMS) with encryption in transit.
✓Benefits and use cases
  • Regulated data processed in Spark or Hive.
  • Distributed training on sensitive data.
  • Multi-tenant clusters where nodes must not talk in plaintext.

Other clusters to recognise

Amazon OpenSearch Service: turn on node-to-node encryption and require HTTPS for the domain endpoint with a TLS security policy. Amazon MSK: TLS between brokers and from clients to brokers. ElastiCache (Valkey/Redis OSS): enable in-transit encryption, usually with AUTH or IAM authentication. Amazon EKS: Nitro-based nodes encrypt pod traffic between supported instances automatically; for authenticated, application-level encryption use mTLS from a service mesh or Amazon VPC Lattice.

Think of it like · a team of chefs in a big kitchen

Ingredients pass between stations all the time.

AWS conceptFamiliar thing
EMR security configuration≈The head chef’s rulebook every new kitchen copies on opening day
Certificate provider≈Who prints the chefs’ ID badges: the restaurant, a box you supply, or your own printer
SageMaker inter-container≈Sealing every dish passed between stations; safer, but service slows
OpenSearch node-to-node≈Sealed trays between the kitchen’s own stations
EKS service mesh mTLS≈Every chef checks the other’s badge before handing anything over
Real AWS example · EMR security configuration with in-transit TLS

Certificates from a zip in S3, EBS encryption with KMS.

$ aws emr create-security-configuration --name pii-sec --security-configuration '{
  "EncryptionConfiguration": {
    "EnableInTransitEncryption": true,
    "EnableAtRestEncryption": true,
    "InTransitEncryptionConfiguration": {"TLSCertificateConfiguration": {
      "CertificateProviderType": "PEM", "S3Object": "s3://sec-certs/emr-certs.zip"}},
    "AtRestEncryptionConfiguration": {
      "S3EncryptionConfiguration": {"EncryptionMode": "SSE-KMS", "AwsKmsKey": "alias/emr"},
      "LocalDiskEncryptionConfiguration": {"EnableEbsEncryption": true,
        "EncryptionKeyProviderType": "AwsKms", "AwsKmsKey": "alias/emr"}}}}'

$ aws emr create-cluster ... --security-configuration pii-sec

Check exact field names against the CLI reference for your EMR release.

Exam-style scenario

A data science team runs distributed training on SageMaker AI with patient data across several ML instances. Compliance requires that data moving between the training instances is encrypted. What should they do?

  1. A. Enable a KMS key for the training output.
  2. B. Set EnableInterContainerTrafficEncryption to true on the training job.
  3. C. Use an interface VPC endpoint for SageMaker.
  4. D. Enable EBS encryption by default.
Show the worked answer

Answer: B

Inter-container traffic encryption encrypts traffic between the instances in distributed training (with some extra training time).

Why not the others

  • A: Protects output at rest.
  • C: Keeps API calls private; doesn’t touch traffic between training containers.
  • D: At rest only.
How the exam tests this
  • “Encrypt Spark / Hadoop traffic on EMR”→ Security configuration with in-transit TLS.
  • “EMR TLS certificates source”→ EMR-managed · PEM zip in S3 · custom provider.
  • “SageMaker distributed training”→ EnableInterContainerTrafficEncryption.
  • “OpenSearch between nodes”→ Node-to-node encryption.
  • “EKS pod traffic, authenticated”→ Service mesh mTLS / VPC Lattice.
Must remember
  • EMR: security configuration, at launch.
  • EMRFS: SSE-S3, SSE-KMS, CSE; no SSE-C.
  • SageMaker: inter-container flag, off by default.
  • OpenSearch: node-to-node + require HTTPS.
  • EKS secrets encryption = at rest.
07

Cheatsheet extras: Perfect Forward Secrecy, CloudFront certificates and field-level encryption

Three transit topics from your cheat sheet that this lecture only mentioned in passing: Perfect Forward Secrecy (which ciphers to pick), which Region a certificate must live in when CloudFront is involved, and field-level encryption for single sensitive form fields. A short table at the end updates old TLS facts.

Concept profile

Perfect Forward Secrecy (PFS)

often confused with certificate rotation
?What is it?

A property of a TLS connection: each session uses its own temporary key, so if someone later steals the server’s long-term private key, they still can’t decrypt past recorded sessions.

⚙How does it work?
  • The client and server agree a one-time session key with ephemeral Diffie-Hellman: cipher names start with ECDHE (or DHE).
  • The certificate’s private key only signs the handshake; it never encrypts the session key.
  • On ALB, NLB TLS listeners and CloudFront you get PFS by choosing a security policy that only offers ECDHE ciphers (for example ELBSecurityPolicy-TLS13-1-2-2021-06 or …-FS-… policies). TLS 1.3 always uses forward secrecy.
  • Old cipher suites with plain RSA key exchange (AES128-SHA, AES256-GCM-SHA384) do not give PFS.
{ }Structure
Without PFS (RSA key exchange)Session key is encrypted with the server’slong-term RSA key and sent over the wire.Attacker records traffic today, steals the keynext year → decrypts all old sessions.With PFS (ECDHE)Each side makes a throw-away key pair; thesession key is never sent. Certificate key only signs.Stolen certificate key → past sessionsstay safe.
PFS protects yesterday’s traffic from tomorrow’s key leak.
⇄PFS vs certificate rotation
PFSCertificate rotation
ProtectsPast sessions if the private key leaks laterFuture sessions after a known leak or expiry
Set bySecurity policy / cipher choiceACM renewal, re-import, new certificate
Changes the certificate?NoYes
Exam words“compromise of the private key must not expose previously captured traffic”“certificate expires”, “key was leaked, stop new use”
!Common mistakes the exam tests
  • Generating new certificates to fix a weak cipher: the fix is the load balancer security policy, not the certificate.
  • Picking an old policy “because it supports the most ciphers” (the cheat sheet suggests 2016-08): that includes non-PFS ciphers. Pick a TLS 1.2/1.3 FS policy unless old clients force you otherwise.
  • Thinking PFS needs a special certificate: any RSA or ECDSA certificate works with ECDHE ciphers.
✓Benefits and use cases
  • PCI DSS and banking rules that ask for strong cryptography and forward secrecy.
  • Fixing a reported weak protocol or cipher across every instance at once by changing one ELB policy.
  • Required by many AWS API endpoints, which accept TLS 1.2+ with ECDHE suites.

Where the certificate must live, and field-level encryption

CloudFront is global, but it reads viewer certificates from ACM in US East (N. Virginia), us-east-1 only. The load balancer behind it uses a certificate from its own Region. So “HTTPS from viewers to CloudFront and from CloudFront to an ALB in eu-west-1 with a custom domain” needs two ACM certificates: one in us-east-1, one in eu-west-1. Route 53 points the domain at CloudFront with an alias record (a CNAME can’t be used at the zone apex).

Field-level encryption lets CloudFront encrypt specific POST form fields (for example a card number) with a public key you upload, right at the edge. Every system between the edge and the one service that holds the private key only sees ciphertext, even after HTTPS has ended at the load balancer.

Older material saysToday
“For end-to-end encryption use NLB or Classic Load Balancer; ALB only terminates.”An ALB can re-encrypt to HTTPS targets. Choose an NLB TCP listener only when the load balancer must never decrypt (or targets must hold the only key). Classic Load Balancer is legacy.
“Origin Access Identity (OAI) keeps S3 private behind CloudFront.”Use Origin Access Control (OAC): it signs requests with SigV4, works with SSE-KMS objects and all Regions. OAI is legacy.
“CloudFront certificates can also come from the IAM certificate store.”Still possible, but ACM (us-east-1) is the normal answer: free and auto-renewed.
“AWS APIs accept TLS 1.0.”AWS API endpoints require TLS 1.2 or later.
“SES SMTP over TLS.”Still true: use STARTTLS on 587 (or 25/2587) or TLS wrapper on 465/2465; SES uses opportunistic TLS to receiving servers unless you require TLS in a configuration set.
Think of it like · secret phone calls

How you protect a conversation that might be recorded.

AWS conceptFamiliar thing
PFS (ECDHE)≈A new one-time code word for every call; stealing your diary later doesn’t reveal old calls
No PFS≈Every call uses the same code word written in your diary
Security policy≈The house rule listing which code systems are allowed
us-east-1 certificate for CloudFront≈The head office that prints every branch’s ID cards
Field-level encryption≈Putting the card number in a sealed envelope that only accounting can open
Real AWS example · switch an ALB listener to a forward-secrecy policy

One command fixes the cipher list for every connection to the load balancer.

$ aws elbv2 describe-ssl-policies --names ELBSecurityPolicy-TLS13-1-2-2021-06 \
    --query "SslPolicies[0].Ciphers[].Name"
[ "TLS_AES_128_GCM_SHA256", "TLS_AES_256_GCM_SHA384", "TLS_CHACHA20_POLY1305_SHA256",
  "ECDHE-ECDSA-AES128-GCM-SHA256", "ECDHE-RSA-AES128-GCM-SHA256", ... ]

$ aws elbv2 modify-listener --listener-arn arn:aws:elasticloadbalancing:eu-west-1:...:listener/app/web/... \
    --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06

Every TLS 1.2 cipher in this policy starts with ECDHE, and TLS 1.3 suites always have forward secrecy.

Exam-style scenario

A bank’s web application runs behind an ALB. Auditors require that if the server’s private key is ever compromised, previously recorded HTTPS traffic must not be decryptable. What should the security engineer do?

  1. A. Import a new certificate with a 4096-bit RSA key.
  2. B. Choose an ALB security policy that offers only ECDHE (forward secrecy) cipher suites with TLS 1.2 and 1.3.
  3. C. Rotate the ACM certificate every 30 days.
  4. D. Enable SSE-KMS on the ALB access log bucket.
Show the worked answer

Answer: B

Ephemeral key exchange means the long-term key never protects session keys, so a later key leak can’t decrypt old captures.

Why not the others

  • A: A bigger RSA key still exposes old sessions if non-PFS ciphers are allowed.
  • C: Rotation limits future exposure, not past captures.
  • D: Unrelated to traffic encryption.
How the exam tests this
  • “Past traffic safe even if the private key leaks”→ PFS / ECDHE security policy.
  • “Vulnerable protocol or cipher on the ELB”→ Change the security policy.
  • “Custom domain on CloudFront”→ ACM certificate in us-east-1.
  • “CloudFront → ALB in another Region over HTTPS”→ Second certificate in the ALB’s Region.
  • “Only one back-end service may see the card number”→ CloudFront field-level encryption.
Must remember
  • PFS = ECDHE ciphers; TLS 1.3 always.
  • Fix weak ciphers with the security policy, not new certificates.
  • CloudFront certificates: us-east-1 only.
  • Field-level encryption = public key at the edge.
  • OAI is legacy → OAC.
08

Lecture summary map

Day 4 on one screen.

1. Mind map

① Require TLSDeny SecureTransport falses3:TlsVersion < 1.2rds.force_ssl, require_ssl② Load balancersPredefined policies onlyNLB TCP = passthroughALB mTLS verify / pass③ VPC endpointsGateway: S3 + DDB, freeInterface: PrivateLinkaws:SourceVpce④ Remote accessClient VPN: ACM certVerified Access: no VPNDX: MACsec / VPN⑤ Nitro + controlsNo LB / TGW in pathencryption-status 0–3Monitor → enforce⑥ ClustersEMR security configSageMaker inter-containerOpenSearch node-to-nodeData Protection 4data in transit
Tap a branch to jump back to that part of the lecture. Try redrawing this map from memory on paper.

2. Match the requirement to the control

“Deny any HTTP request to the bucket”→aws:SecureTransport = false → Deny“Block old TLS versions to S3”→s3:TlsVersion < 1.2 → Deny“ALB must not see plaintext”→NLB TCP passthrough“Only clients with our certificates”→ALB mutual TLS (verify mode)“Private access to S3, no cost”→Gateway VPC endpoint“Bucket reachable only via our endpoint”→aws:SourceVpce in bucket policy“App access without a VPN, check device”→AWS Verified Access“Encrypt Direct Connect link”→MACsec or VPN over DX“Prove all VPC traffic is encrypted”→VPC encryption controls
The left column is the exam wording; the right column is the answer.

3. “If the question says… pick…”

Reject HTTP calls to a bucket or queueDeny on aws:SecureTransport false
Force TLS on RDS PostgreSQLrds.force_ssl = 1
TLS 1.3 only / FIPS on ALBMatching predefined security policy
Load balancer must never decryptNLB TCP listener
Partners authenticate with certificatesALB mTLS with a trust store
Private S3 access, no costGateway endpoint
S3 from on-prem without internetInterface endpoint for S3
Bucket policy for endpoint trafficaws:SourceVpce, not aws:SourceIp
Laptops into the VPCClient VPN
One app, no VPN, device postureVerified Access
Prove and enforce VPC encryptionVPC encryption controls
Encrypt distributed training trafficSageMaker inter-container encryption
Day 4 in one sentence

Deny plaintext at every door, keep traffic on private paths, and remember that Nitro covers only some hops: anything through a load balancer or out of the VPC still needs TLS.

09

Must-remember cheat sheet

1. Deny on aws:SecureTransport = false.
2. s3:TlsVersion NumericLessThan 1.2.
3. RDS PG/SQL Server: rds.force_ssl; MySQL: require_secure_transport.
4. Redshift: require_ssl. EFS: -o tls.
5. CloudFront: viewer and origin protocol policy.
6. ALB: predefined policies only; CLI default 2016-08.
7. Passthrough = NLB TCP.
8. ALB mTLS: verify or passthrough, trust store.
9. Gateway endpoint: S3 + DynamoDB, free.
10. Interface endpoint: ENI, SG, private DNS.
11. Endpoint traffic: aws:SourceVpce, not SourceIp.
12. Client VPN: server cert in ACM.
13. Verified Access: per request, Cedar, no VPN.
14. Direct Connect: not encrypted; MACsec.
15. Nitro: no LB/TGW, same/peered VPC.
16. SageMaker: EnableInterContainerTrafficEncryption.
17. PFS = ECDHE ciphers in the ELB/CloudFront security policy.
18. CloudFront certificates come from us-east-1; field-level encryption protects single form fields.
10

Core quiz

Check the basics first. Pick an answer, then press Check.

11

Hard quiz

Harder than most real exam questions on purpose, with one “choose two” and one matching question. Aim for 9 out of 12 before Day 5.

12

Practice test questions (from your mock exams)

These 9 questions match today’s topics. 7 come from your own mock exams (the “practice tests” folder); the wording was tidied, and where a mock answer was out of date or wrong, the explanation says so, with the mock and question number at the end. The last 2 are new exam-style questions (marked “New question”) written in October 2026 from the SCS-C03 exam guide and current AWS documentation, to cover recent changes.

13

Hands-on lab (30 minutes, low cost)

  1. Add the DenyHTTP and DenyOldTLS statements to a test bucket. Try curl http://BUCKET.s3.amazonaws.com/file on a public test object or a presigned URL and see the 403, then the same over https.
  2. Run aws elbv2 describe-ssl-policies --query "SslPolicies[?contains(SslProtocols,'TLSv1.3')].Name" and compare a FIPS policy with a PQ policy.
  3. In a VPC with a private subnet, create a free S3 gateway endpoint, then a bucket policy that denies when aws:SourceVpce doesn’t match. Test from an instance (via Session Manager) and from your laptop.
  4. Run the describe-instance-types filter for encryption-in-transit-supported and check whether your usual instance type is on the list.
  5. Create a flow log with ${encryption-status} in the format (needs VPC encryption controls in monitor mode to show values) and look at a few records.
  6. Clean up: delete the endpoint, the flow log and the test instance. Skip Client VPN and Verified Access in a personal account unless you delete them quickly; both charge by the hour.