Two microservices exchange sensitive permit payloads inside the city’s VPC. A developer claims private subnets make TLS unnecessary. What is the better guidance?
Select an answer to reveal the explanation.
Short Explanation
A private subnet is a fenced yard, not a locked envelope. Sensitive permit JSON still deserves TLS between services—defense in depth. Security groups and NACLs filter paths; they do not encrypt payloads.
Full Explanation
Private subnets and security groups constrain network paths; they do not encrypt application payloads. Two microservices exchanging sensitive permit data inside the city’s VPC should still use TLS for defense-in-depth so compromised hosts, misrouted traffic, or overly broad security groups cannot trivially read plaintext permit payloads on the wire. Network placement is necessary isolation, not a substitute for encryption in transit.
Private IP addressing does not automatically encrypt payloads. Security group rules and network ACLs filter packets; they do not encrypt layer-7 bodies. Mirroring internal traffic to a public S3 bucket for inspection instead of using TLS creates a new disclosure channel.
Exam caveat: service meshes and ALF/NLB patterns often terminate or pass through TLS—know whether TLS is end-to-end or hop-by-hop in your design. Operational check: capture a test call between services with TLS enabled and confirm payloads are not plaintext on the wire; temporarily force a cleartext lab listener and show that security groups alone still leave readable bytes to a colocated observer. For municipal workloads, document the chosen pattern in the runbook so the next on-call engineer applies the same control instead of inventing a weaker shortcut under pressure.