NAT Gateway practice questions

Add an internet gateway and move the instances into public subnets.

Why wrong: This changes the routing model and security exposure, but it does not reduce the amount of traffic the application sends to AWS services. It also does nothing to remove NAT-related charges for private service access.

Replace the NAT Gateway with a Site-to-Site VPN connection.

Why wrong: A VPN is meant for connectivity to on-premises or external networks. It does not eliminate the need to reach S3 and DynamoDB privately, so it does not directly solve the NAT data-processing-cost problem.

Create an interface endpoint for S3 instead of a gateway endpoint.

Why wrong: An interface endpoint can work for some S3 use cases, but it adds hourly and data-processing charges. For the specific goal of lowering NAT charges for S3 access from private subnets, the S3 gateway endpoint is the lower-cost choice.

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.

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.

A Gateway VPC endpoint for secretsmanager

Why wrong: Gateway endpoints are used for certain AWS services (commonly S3 and DynamoDB). Secrets Manager uses Interface endpoints, not gateway endpoints.

A NAT gateway in the private subnet route table

Why wrong: A NAT gateway provides outbound internet egress. This contradicts the stated constraint of no NAT gateway (and, by implication, no internet routing).

A VPC peering connection to the AWS public network hosting Secrets Manager

Why wrong: VPC peering is not the mechanism used to reach AWS service endpoints like Secrets Manager. The supported approach for private access to these APIs is AWS PrivateLink interface endpoints.

Continue using the NAT Gateway but reduce CloudWatch log retention to 1 day.

Why wrong: Reducing log retention can lower CloudWatch storage costs, but it does not reduce NAT Gateway data processing charges for outbound API calls from the workload.

Launch a bastion host in a public subnet and force private instances to use SSH tunneling for API calls.

Why wrong: SSH tunneling adds complexity and does not inherently remove NAT data charges. The bastion would still require outbound connectivity paths, which typically still involve NAT if access is not otherwise endpoint-based.

Switch to public subnets and attach security groups with the same rules to limit inbound access.

Why wrong: Moving to public subnets changes the exposure model and does not satisfy the requirement to avoid traversing the public internet. It also may not reduce NAT-related billing in the intended way.

Deploy a NAT Gateway in each Availability Zone and route artifact traffic through it.

Why wrong: A NAT Gateway would work for connectivity, but it creates exactly the cost the team wants to remove. The gateway endpoint is the cost-optimized private option.

Use the S3 static website endpoint because it automatically enforces HTTPS.

Why wrong: S3 website endpoints are not the right choice for private CI uploads and do not provide the required transport and encryption controls. They are intended for public website hosting patterns.

Keep the NAT gateway, but add AWS WAF rules to block non-service outbound requests to reduce NAT usage.

Why wrong: WAF rules don’t control arbitrary outbound TCP connections initiated from EC2 instances. NAT gateway charges are driven by actual outbound traffic volume (data processed) and active connections, not by WAF policy. Unless the instances themselves stop making those outbound calls, the NAT gateway still processes the traffic and continues to incur charges.

Disable IPv4 on the VPC subnets and rely on IPv6-only egress to reduce NAT gateway costs.

Why wrong: NAT gateways are used specifically for private IPv4 egress to reach the internet or other networks. Switching to IPv6-only does not inherently eliminate the cost drivers for private service connectivity; it also requires a correct egress architecture for reaching AWS services and may introduce other components/changes. This does not directly address the most direct cost lever: using VPC endpoints to avoid NAT for calls to S3 and Secrets Manager.

Replace the NAT gateway with a VPC firewall appliance instance to proxy outbound calls and reduce NAT fees.

Why wrong: Using a self-managed proxy/firewall appliance adds additional compute cost, scaling/availability overhead, and operational burden (patching, upgrades, monitoring). It also does not provide the same purpose-built, service-specific private connectivity model that VPC endpoints provide for S3 and Secrets Manager, so it is unlikely to be more cost-effective than adding the correct endpoints.

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.

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.

Keep the EC2 fleet and add more instances so the idle cost is less noticeable.

Why wrong: Adding more always-on servers increases idle spend and directly contradicts the goal of paying only for usage.

Move the API to an Application Load Balancer only, without changing compute.

Why wrong: An ALB can distribute traffic, but it does not remove the need to manage EC2 instances or eliminate idle capacity.

Store runtime secrets in user data on each instance.

Why wrong: This does not address variable traffic or cost optimization, and it creates a poor secret-handling pattern.

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.

A deny statement for all IAM users except the EC2 role

Why wrong: This controls identity but does not enforce the network path through the endpoint.

A security group rule that allows HTTPS to S3

Why wrong: Security groups do not attach to S3 buckets and cannot enforce S3 bucket access.

A condition that matches aws:RequestedRegion to the bucket Region

Why wrong: RequestedRegion limits API calls by Region but does not prove traffic used the endpoint.

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.

Place the instances in public subnets with an internet gateway.

Why wrong: Public subnets increase exposure and do not solve the cost goal in a better way. They also violate the requirement to keep traffic private where possible.

Keep the NAT Gateway and add a proxy instance for service access.

Why wrong: A proxy instance adds more management work and does not remove the NAT Gateway cost. It is a poor fit when AWS-native VPC endpoints can satisfy the requirement directly.

Add a NAT gateway to the private subnet route table and keep using the public Secrets Manager endpoint.

Why wrong: This restores connectivity, but it sends traffic through the internet path and adds NAT cost.

Create a gateway VPC endpoint for Secrets Manager and point the route table to it.

Why wrong: Gateway endpoints are not used for Secrets Manager; they are used for specific services like S3 and DynamoDB.

Use VPC peering to connect the application subnet to another VPC that already has internet access.

Why wrong: VPC peering does not provide internet egress or a private AWS service endpoint by itself.

Add an internet gateway to the VPC and route private subnet traffic through it.

Why wrong: An internet gateway exposes the VPC to the public internet and does not keep traffic private.

Use a security group rule that allows outbound traffic to the S3 public IP range.

Why wrong: Security groups control traffic, but they do not create private connectivity to S3 or prevent internet traversal by themselves.

Create a VPC peering connection to the S3 service VPC.

Why wrong: Amazon S3 is not accessed through customer-managed VPC peering connections, so this is not a valid design.

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.

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.

Create an S3 gateway endpoint for Secrets Manager and use the existing S3 gateway endpoint for both secret retrieval and KMS decryption.

Why wrong: Gateway endpoints are not used for Secrets Manager or KMS. They are specifically for supported services such as S3 and DynamoDB. The existing S3 endpoint does not provide network path or name resolution for the secret or decrypt operations.

Add a NAT gateway in a public subnet and route 0.0.0.0/0 from the private subnets to the NAT gateway.

Why wrong: A NAT gateway would allow outbound internet access, but the requirement says to keep traffic off the internet. It would also introduce additional cost and does not meet the private connectivity constraint. AWS PrivateLink endpoints are the correct design.

Move the application into a public subnet so it can call the public Secrets Manager endpoint directly.

Why wrong: Moving the workload to a public subnet increases exposure and violates the stated requirement to avoid internet egress. The goal is private service access from private subnets, not public internet connectivity.

Replace the NAT Gateway with an Internet Gateway and keep the current private subnet routes unchanged.

Why wrong: An Internet Gateway would expose instances to the public internet unless the design is changed substantially. It does not reduce cost safely for private-only workloads.

Add a second NAT Gateway in another Availability Zone to reduce cross-AZ data transfer charges.

Why wrong: A second NAT Gateway can improve availability, but it usually increases fixed hourly cost. It does not solve the core problem of paying for internet egress to AWS services.

Create only interface endpoints for all four services and keep the NAT Gateway for fallback.

Why wrong: Interface endpoints are not the cheapest or always the correct choice for S3 and DynamoDB. Keeping the NAT Gateway preserves unnecessary cost and the fallback is not required by the scenario.