How do you give workloads in a private subnet access to AWS services without routing through a NAT gateway, and why would you?

technical-conceptual · Mid level · cloud-devops-security

What the interviewer is really asking

Assess VPC egress design judgment — knowing gateway vs interface (PrivateLink) endpoints, the security benefit of keeping traffic off the public internet, and the data-transfer cost difference versus a NAT gateway, rather than treating NAT as the only way out.

What to say

• Name the alternative and the two endpoint types: VPC endpoints let a private subnet reach AWS services without a NAT gateway or internet gateway. Gateway endpoints (free, route-table based) cover S3 and DynamoDB; interface endpoints (PrivateLink, an ENI in your subnet) cover most other services — SQS, ECR, Secrets Manager, SSM, and so on — and even private/SaaS services.
• Lead with the security win: traffic to the service stays on the AWS network and never traverses the public internet, so you shrink the attack surface and can drop the NAT path (and even the internet gateway) for workloads that only talk to AWS services. You scope an endpoint policy to restrict which principals/resources it allows, tightening it further.
• Bring in the cost angle concretely: a NAT gateway charges an hourly fee per AZ plus a per-GB data-processing charge, and high-volume AWS-bound traffic (pulling container images from ECR, shipping logs) through NAT gets expensive fast — gateway endpoints are free and interface endpoints are far cheaper per GB, so for AWS-service traffic endpoints usually beat NAT on both security and cost. The trade-off is interface endpoints have their own per-AZ hourly cost, so for genuinely tiny traffic a NAT can still be simpler.

What to avoid

• Assuming a NAT gateway is the only way for a private subnet to reach AWS services, when endpoints keep the traffic private and usually cost less.
• Confusing gateway endpoints (S3/DynamoDB, free, route-table) with interface endpoints (PrivateLink ENI, most other services, hourly cost), or thinking one type covers everything.
• Ignoring that NAT gateway data-processing charges dominate the bill for high-volume AWS-bound traffic like ECR image pulls, so 'just use NAT for everything' quietly burns money.

Example answers

Strong: Our EKS nodes in private subnets were pulling images from ECR and shipping logs to CloudWatch entirely through a NAT gateway, and the NAT data-processing line was our biggest networking cost. I added gateway endpoints for S3 (ECR layers live in S3) and interface endpoints for ECR API, CloudWatch Logs, and SSM. The bulk of the traffic stopped hitting NAT — cost dropped sharply and the traffic now stays on the AWS network instead of egressing to the internet and back.

Weak: I'd put a NAT gateway in front of the private subnet — that's how instances without public IPs reach AWS services.