NAT Gateway practice questions

Replace the security group egress rule to allow all outbound traffic to 0.0.0.0/0 on TCP 443.

Why wrong: Allowing 0.0.0.0/0 does not create a route to the S3 service without NAT. Security groups do not override routing; if traffic is not routed through the S3 VPC endpoint, the connection will still time out.

Add an Internet Gateway to the VPC and route the private subnet’s 0.0.0.0/0 to the IGW.

Why wrong: Adding an Internet Gateway and public routing would defeat the purpose of using private subnets without NAT and increases exposure. The correct solution is service-specific private connectivity using a VPC endpoint for S3.

Switch from network ACLs to security groups by removing the existing NACL allow rules for ephemeral ports.

Why wrong: If DynamoDB works, NACL rules are likely not the blocker for outbound traffic in general. Also, the primary requirement for reaching S3 without NAT is routing via the S3 endpoint. NACL changes would be unnecessary if endpoint routing is already correct.

Create an S3 Gateway VPC endpoint and use it for Secrets Manager requests because both services use HTTPS.

Why wrong: Gateway VPC endpoints are service-specific (for S3 and a limited set of related services) and do not provide connectivity for Secrets Manager API calls. HTTPS does not make an S3 endpoint usable for other services.

Assign a public IP address to the tasks so they can call Secrets Manager over the internet without NAT.

Why wrong: Assigning a public IP address to the microservice tasks would allow them to communicate with AWS Secrets Manager, but this communication would occur over the public internet. This approach directly contradicts the implicit requirement for private networking, as it introduces public internet egress for the microservice. Furthermore, exposing backend tasks directly to the internet via public IPs is generally considered a security anti-pattern, increasing the attack surface.

Change the route table to send all 0.0.0.0/0 traffic directly to an Internet Gateway.

Why wrong: Changing the route table to direct all 0.0.0.0/0 traffic to an Internet Gateway would indeed enable the microservice to reach Secrets Manager. However, this configuration routes all outbound traffic from the private subnet, including that destined for AWS services, through the public internet. This violates the principle of maintaining private network connectivity for sensitive service interactions and introduces unnecessary public exposure for all outbound traffic from the microservice.

Create an Interface VPC endpoint for S3 and point the instances to it

Why wrong: Interface VPC endpoints (powered by AWS PrivateLink) use elastic network interfaces (ENIs) in your subnets and are supported for many services, but Amazon S3 is a special case. For S3, the supported private connectivity model is a Gateway VPC endpoint that integrates with route tables, not an interface endpoint.

Create a NAT gateway and allow outbound HTTPS to S3

Why wrong: A NAT gateway provides outbound internet connectivity. Even if the destination is S3 over HTTPS, traffic still traverses the NAT gateway and leaves the VPC via the internet path, which violates the requirement to avoid NAT/internet egress.

Create a VPC endpoint service and manually register S3 as a provider endpoint

Why wrong: VPC Endpoint Services are for exposing your own services privately (or consuming privately exposed endpoint services). S3 is not registered as a provider endpoint service by customers. The correct AWS-managed approach for S3 is a Gateway VPC endpoint.

Increase the Lambda timeout so the function has more time to initialize during the spike.

Why wrong: A longer timeout does not remove cold starts or pre-initialize execution environments. It only changes how long a function may run before timing out. The user-facing latency issue would remain, so this does not solve the core problem.

Double the memory size during the spike without changing the concurrency model.

Why wrong: More memory can improve CPU allocation and sometimes reduce execution duration, but it does not guarantee that the environment is already warm. Without provisioned concurrency, the first requests can still incur cold-start penalties. The scenario specifically calls for stable p95 latency.

Move the function into more Availability Zones so the platform can spread cold starts across regions.

Why wrong: Lambda already runs as a managed regional service and does not need the customer to place individual functions across AZs. Spreading across AZs does not eliminate cold starts. The issue is initialization time, not geographic distribution.

Add an S3 bucket policy Deny statement that blocks requests unless the principal uses MFA.

Why wrong: MFA affects authentication for interactive identity flows. It does not provide any guarantee about the network path or whether the request traversed a specific VPC endpoint, so it cannot enforce the required endpoint-level routing constraint.

Enable Block Public Access and remove the public bucket policy statement.

Why wrong: Block Public Access prevents public exposure of the bucket, but it does not restrict access to a specific VPC endpoint. Private requests from other network locations (that can still reach S3 with valid credentials) would remain possible.

Attach an IAM policy to the workload role that allows s3:PutObject only to the bucket ARN.

Why wrong: Least-privilege IAM limits which actions and resources are permitted, but IAM cannot constrain the origin network path (for example, forcing traffic to traverse vpce-0abc123example). A valid principal could still call S3 from anywhere that has network reachability and credentials.

S3 Object Lambda

Why wrong: Object Lambda transforms S3 responses and does not remove NAT gateway traffic cost.

AWS Shield Advanced

Why wrong: Shield Advanced protects against DDoS and does not reduce S3 NAT traffic charges.

A larger NAT gateway

Why wrong: NAT gateways scale automatically; increasing size is not a cost optimization option.

API keys only

Why wrong: API keys identify clients for usage plans but do not authenticate users securely.

IAM authorization for all internet users

Why wrong: IAM authorization is suited to AWS principals, not general OIDC-authenticated application users.

A VPC endpoint policy

Why wrong: Endpoint policies restrict private endpoint use, not public API user authentication.

Place instances in private subnets but use NAT gateways so traffic to S3 and Secrets Manager goes through the internet; restrict security groups to instance-to-instance only.

Why wrong: NAT still routes traffic through the internet path and contradicts the cost and private-connectivity requirement. Restricting instance-to-instance rules does not prevent public service access through NAT.

Use public subnets with instances that have no security group rules; rely on AWS services to reject unauthorized traffic.

Why wrong: Public subnets plus missing security controls violates baseline security. Relying on AWS service rejection does not provide explicit network segmentation or deterministic access control.

Create an S3 bucket policy that allows requests from the application instances’ private IP addresses and enable public access to Secrets Manager via the default service endpoint.

Why wrong: Bucket policy cannot safely replace network-level private connectivity. Secrets Manager still requires private endpoint configuration or NAT/IGW routing for private subnets; public access contradicts requirements.

Add a condition that allows secretsmanager:GetSecretValue only when aws:SourceIp is within 10.0.0.0/8.

Why wrong: Source IP conditions cannot reliably prove that the traffic used the required Interface VPC endpoint. Requests can be translated by NAT gateways, proxies, or load balancers, and the observed Source IP may not uniquely identify the endpoint path.

Require TLS by adding a condition on aws:SecureTransport for the Secrets Manager permission.

Why wrong: aws:SecureTransport enforces that the request uses HTTPS, but it does not restrict which network path was used to reach Secrets Manager. A call could still reach the public endpoint over an unintended route while using TLS.

Add a KMS condition using kms:ViaService=secretsmanager.us-east-1.amazonaws.com instead of restricting Secrets Manager directly.

Why wrong: The kms:ViaService condition affects whether a key can be used via a particular AWS service context, but the question’s requirement is about the network path to the Secrets Manager API. This does not constrain the request to originate from the specified Interface VPC endpoint.

Enable S3 Transfer Acceleration on the bucket to reduce the number of S3 calls that go through the NAT Gateway.

Why wrong: S3 Transfer Acceleration changes how clients connect to S3 at the edge (typically for publicly addressed buckets and internet clients). It does not change the network path used by EC2 instances in private subnets. Without an S3 VPC endpoint, the instances’ traffic to S3 will still be routed to the NAT Gateway for reaching the public S3 endpoints.

Switch the EC2 instances to public subnets so S3 calls can use direct internet routing without NAT.

Why wrong: Moving instances to public subnets changes the network exposure model and does not align with the stated requirement to keep the application in private subnets. Even if S3 connectivity works, this does not directly target NAT cost drivers for private-subnet S3 access and may increase security and management overhead.

Increase the NAT Gateway TCP idle timeout so fewer connections are billed separately for S3 traffic.

Why wrong: NAT Gateway billing is based on gateway uptime (per-hour) and the amount of data processed (per-GB), not on how long TCP connections remain idle. Adjusting timeouts does not eliminate or significantly reduce the NAT data-processing charges for S3 traffic; routing S3 through a VPC endpoint is the effective approach.

Move the instances into a public subnet and restrict inbound access with security groups.

Why wrong: That would expose the workload to the internet, which directly violates the private connectivity requirement. Security groups do not replace the need for private network design.

Add a NAT instance and disable the managed NAT gateway to lower cost.

Why wrong: A NAT instance still sends traffic through an internet path and adds operational overhead. It does not remove public exposure for AWS service calls.

Use VPC peering to a shared services VPC and route all AWS service traffic through that VPC.

Why wrong: VPC peering does not provide native endpoints for AWS managed services and does not eliminate the internet path for those service APIs. It also adds routing complexity without solving the core problem.

Add a public DNS entry in the instance /etc/hosts pointing Secrets Manager to the instance’s private IP so requests do not leave the VPC.

Why wrong: Secrets Manager is not reachable by mapping it to arbitrary private IPs; you need an AWS-managed private endpoint or NAT/internet for real service routing.

Attach an internet gateway to the private route table so that Secrets Manager traffic can reach public endpoints without NAT.

Why wrong: An internet gateway on a private route table effectively makes the subnet internet-reachable, violating the stated NAT-free and tightened network requirement.

Enable S3 VPC endpoint and store the secrets in an S3 bucket instead of Secrets Manager, then retrieve them using S3 gateway endpoints.

Why wrong: This changes the service and does not solve the Secrets Manager connectivity failure. It also weakens secret lifecycle controls provided by Secrets Manager.

Place instances in private subnets but use NAT gateways so traffic to S3 and Secrets Manager goes through the internet; restrict security groups to instance-to-instance only.

Why wrong: NAT still routes traffic through the internet path and contradicts the cost and private-connectivity requirement. Restricting instance-to-instance rules does not prevent public service access through NAT.

Use public subnets with instances that have no security group rules; rely on AWS services to reject unauthorized traffic.

Why wrong: Public subnets plus missing security controls violates baseline security. Relying on AWS service rejection does not provide explicit network segmentation or deterministic access control.

Create an S3 bucket policy that allows requests from the application instances’ private IP addresses and enable public access to Secrets Manager via the default service endpoint.

Why wrong: Bucket policy cannot safely replace network-level private connectivity. Secrets Manager still requires private endpoint configuration or NAT/IGW routing for private subnets; public access contradicts requirements.

Use an interface VPC endpoint for S3 only, because gateway endpoints cannot be used with bucket policies.

Why wrong: Gateway endpoints are the standard and recommended private-connectivity mechanism for S3 from EC2 instances in VPCs, and they can absolutely be combined with S3 bucket policies. The claim that gateway endpoints cannot be used with bucket policies is incorrect. In fact, aws:SourceVpce is a common condition key used specifically to restrict access to a particular endpoint.

Add a NAT gateway and remove the bucket policy condition because the NAT route will automatically secure the S3 traffic.

Why wrong: A NAT gateway provides outbound internet access for private subnets, but it does not keep S3 traffic private in the way a VPC endpoint does. It also does not enforce endpoint-based authorization. This option fails both requirements: it introduces internet egress and removes the access control that limits the bucket to the approved endpoint.

Move the bucket policy restriction to a security group attached to the S3 bucket so only the VPC endpoint can reach it.

Why wrong: Security groups do not apply to S3 because S3 is a managed regional service, not an ENI-backed resource in your VPC. S3 access is controlled with IAM, bucket policies, endpoint policies, and condition keys such as aws:SourceVpce. The correct enforcement point is the bucket policy, not a security group.

Increase the Lambda function’s memory setting; cold starts will always be eliminated regardless of traffic patterns.

Why wrong: Increasing memory can improve CPU allocation and may reduce execution duration and sometimes initialization time. However, it does not guarantee that initialized environments are available after idle periods. Cold starts can still occur without provisioned concurrency.

Switch the Lambda runtime to a newer language version and remove any VPC configuration so the function never cold starts.

Why wrong: Changing the runtime or removing VPC configuration can reduce initialization overhead in some cases (for example, by reducing ENI setup time for VPC). However, these changes do not provide deterministic warm capacity. Cold starts can still happen depending on traffic patterns and scale-down behavior.

Set an API Gateway stage variable to "warm" the function at request time, which forces immediate initialization.

Why wrong: API Gateway stage variables do not create a pre-initialized warm pool of Lambda execution environments. Even if the application reads a stage variable, it still cannot deterministically avoid cold starts without a Lambda feature such as provisioned concurrency.

Create a gateway VPC endpoint for S3 and route the STS traffic through the S3 endpoint gateway.

Why wrong: Gateway endpoints are for specific services (like S3/DynamoDB) and cannot be used to route STS traffic to the correct API.

Open an inbound rule in the instances’ security group to allow outbound HTTPS to the internet CIDR block directly.

Why wrong: Security groups control allowed traffic, but the subnet route table still needs a path. Without NAT/endpoint routing, traffic cannot reach STS.

Attach an Internet Gateway to the private subnet route table so the STS API can be reached over public internet.

Why wrong: Adding an Internet Gateway to private subnets contradicts the requirement to keep instances private and increases exposure.

Expose the NLB with an Internet Gateway route and restrict access using a security group attached to the NLB.

Why wrong: Security groups cannot be attached directly to NLBs for this purpose in the way implied, and exposing the service via the public internet violates the private-only requirement. PrivateLink is designed for private connectivity without relying on public exposure.

Create an S3 Gateway endpoint in the consumer VPC and store the service hostname in SSM Parameter Store so clients can resolve privately.

Why wrong: S3 Gateway endpoints are unrelated to reaching an internal NLB-based application service. Using SSM for hostname resolution does not create private network connectivity to the service, nor does it implement PrivateLink.

Use a bastion host in the provider VPC and allow the consumer VPC to SSH to it; from there, the consumer makes HTTP calls to the NLB.

Why wrong: A bastion host provides interactive SSH access, not a private, scalable network endpoint for service-to-service calls; PrivateLink uses Elastic Network Interfaces (ENIs) in the consumer VPC to connect directly to the NLB, bypassing any intermediate jump server. This option is tempting because bastion hosts are a common solution for administrative access to private instances, and they would be correct if the consumer needed to perform occasional manual troubleshooting rather than automated HTTP traffic.

Create a gateway VPC endpoint for S3 and route the STS traffic through the S3 endpoint gateway.

Why wrong: Gateway endpoints are for specific services (like S3/DynamoDB) and cannot be used to route STS traffic to the correct API.

Open an inbound rule in the instances’ security group to allow outbound HTTPS to the internet CIDR block directly.

Why wrong: Security groups control allowed traffic, but the subnet route table still needs a path. Without NAT/endpoint routing, traffic cannot reach STS.

Attach an Internet Gateway to the private subnet route table so the STS API can be reached over public internet.

Why wrong: Adding an Internet Gateway to private subnets contradicts the requirement to keep instances private and increases exposure.

Disabling route tables

Why wrong: Route tables are required for subnet routing.

Replacing every NAT gateway with an internet gateway attached to private subnets

Why wrong: Private subnets cannot use an internet gateway directly without public IP routing.

Moving all workloads to public subnets

Why wrong: This weakens security posture and is not a cost-first best practice.

Place a NAT gateway in the public subnet so the private instances can reach AWS services.

Why wrong: A NAT gateway sends outbound traffic to the internet and adds cost and exposure that the requirement explicitly forbids. It is not a private-only connectivity solution.

Assign public IPv4 addresses to the instances and restrict them with security groups.

Why wrong: Public IPs contradict the requirement to stay private and do not remove internet exposure. Security groups alone do not make a workload private.

Use VPC peering to the AWS service endpoints instead of VPC endpoints.

Why wrong: VPC peering is for connectivity between VPCs, not for reaching managed AWS service endpoints. It is not the right mechanism for private service access.