NAT Gateway practice questions

A VPC endpoint policy

Why it fails: A VPC endpoint policy governs access to the API through a VPC endpoint, controlling which principals and actions can use that private connection. It does nothing to authenticate individual application users on the public internet, and it cannot validate OIDC tokens or establish user identity. It is an authorization mechanism for network-level access, not a user authentication mechanism.

API keys only

Why it fails: API keys issued by API Gateway identify the calling client application for usage plans and throttling quotas, but they are shared secrets that can be extracted and reused. They do not verify an end user's identity, carry no claims about the user, and provide no support for standard federation or OIDC token validation. In a public image-sharing app, API keys alone leave the API open to any client that obtains a key, making them unsuitable for secure user authentication.

IAM authorization for all internet users

Why it fails: IAM authorization on API Gateway requires the caller to sign requests with AWS credentials (SigV4) and is designed for AWS principals like EC2 roles or Lambda functions. Internet users of a public image-sharing app typically do not have AWS IAM credentials, and exposing temporary AWS credentials to every end user is both insecure and operationally unmanageable. It also lacks built-in support for OIDC identity federation for arbitrary public users.

Internet gateway attached to the VPC

Why it fails: An internet gateway only enables public IPv4 connectivity for resources with public addresses; private subnets have no route to it, so S3 and Parameter Store traffic cannot traverse it. It is tempting because it is the standard egress path for public subnets, and would be correct if the instances held Elastic IPs and the requirement permitted internet routing.

NAT gateway in each Availability Zone

Why it fails: A NAT gateway routes traffic to the public internet via an internet gateway, which the stem explicitly forbids; it also cannot reach S3 or Parameter Store without public endpoints. It is tempting because NAT gateways are the usual answer for private-subnet egress, and would be correct if outbound internet access were permitted.

A VPC endpoint policy

Why it fails: A VPC endpoint policy is a resource-based policy that governs which principals and actions are permitted through a private network connection, such as an AWS PrivateLink or gateway endpoint. It only applies to traffic routed through that VPC endpoint and does not evaluate user identity, OIDC tokens, or bearer credentials. Because the API is public and accessed over the internet, an endpoint policy would not affect authentication at all and cannot replace an API Gateway authorizer.

API keys only

Why it fails: API keys in Amazon API Gateway are designed for identifying a client for usage plans, quotas, and throttling, not for authenticating individual users. They are static, long-lived tokens that can be easily shared or extracted, and they carry no information about the user's identity, group, or OIDC claims. An API key alone does not validate a user's credentials, so it cannot provide secure authentication for a public-facing image sharing application with diverse internet users.

IAM authorization for all internet users

Why it fails: IAM authorization for API Gateway relies on AWS Signer (SigV4) requests signed with AWS access key and secret key, and it is designed for AWS principals such as IAM users, roles, or federated identities using STS. Internet users of a public image sharing application generally do not have AWS credentials, and distributing long-lived AWS access keys to them is a severe security risk. The IAM authorizer validates IAM policies against the caller's AWS identity, not the OIDC claims of the application user, so it is inappropriate for this authentication use case.

Internet gateway attached to the VPC

Why it fails: An internet gateway is a horizontally scaled, redundant component that enables communication between a VPC and the public internet. It is not used by private subnets because private subnets have no route to an internet gateway, and even if one were added, traffic would traverse the public internet and not be private. Internet gateways also do not provide private connectivity to AWS services, so this option cannot satisfy the requirement.

NAT gateway in each Availability Zone

Why it fails: A NAT gateway allows instances in private subnets to initiate outbound internet traffic, but it does so by routing packets through the internet gateway to the public internet. For private access to Systems Manager, this would mean traffic leaving the AWS network and traveling over public infrastructure, violating the requirement for private connectivity. Additionally, NAT gateways incur hourly charges and data processing fees, and they are not designed as a private endpoint service.

A VPC endpoint policy

Why it fails: A VPC endpoint policy governs access to the API through a private VPC endpoint, restricting which principals and actions are allowed, but it does not validate the identity of end users calling the public endpoint. Since the API is public, users bypass VPC endpoints entirely, so the policy cannot enforce authentication or verify OIDC tokens; it is purely a network-level access control, not an identity layer.

IAM authorization for all internet users

Why it fails: IAM authorization is inappropriate for all internet users because IAM credentials are designed for AWS principals (IAM users, roles, or AWS services), not for arbitrary application users holding OIDC tokens from an external identity provider. To use IAM, each student or educator would need AWS credentials, and the client would have to sign every request with Signature Version 4—an impractical and insecure way to expose a public e-learning API. IAM also fails to integrate with the platform's existing identity provider, whereas a JWT authorizer natively trusts that provider.

API keys only

Why it fails: API keys only identify the calling application or project for usage plans, quotas, and throttling; they do not authenticate an individual user's identity or verify any claims about who they are. An API key can be extracted from a client and reused by anyone, so it offers no assurance that the caller is a legitimate student or educator with valid OIDC credentials. For public APIs, API keys are insufficient for security and must be combined with an authentication mechanism such as a JWT authorizer.

S3 Object Lambda

Why it fails: S3 Object Lambda lets you add custom code to process data returned from S3 GETs, but it operates at the request/response layer, not the network path. It does not remove the need for traffic to traverse a NAT gateway, nor does it affect data processing charges. In fact, it adds per-request Lambda costs and can increase latency, making it the opposite of a cost-saving network solution.

AWS Shield Advanced

Why it fails: AWS Shield Advanced is a Distributed Denial of Service (DDoS) protection service that provides enhanced detection and mitigation for sophisticated attacks, along with cost protection against scaling incurred during an attack. It does not modify the network architecture or reduce NAT gateway data processing charges for normal traffic. Its purpose is security posture, not cost optimization for VPC-to-S3 connectivity.

A larger NAT gateway

Why it fails: NAT gateways are managed services billed by hourly usage and data processing per GB; they scale automatically to support increased throughput, so choosing a larger size is not even a configurable option—all NAT gateways support up to 100 Gbps. Even if you could select a larger size, it would increase the hourly cost without affecting the per-GB processing charge, making it more expensive, not cost-optimized. The only way to avoid NAT processing costs is to bypass the NAT gateway entirely.

API keys only

Why it fails: API keys are static, shared secrets that merely identify a client project for usage plans, throttling, and quota tracking; they do not prove the identity of an end user. Because the key is sent in the request header and can be replayed by anyone who obtains it, it is not a secure authentication factor for a public B2B file exchange. API Gateway does not validate any OIDC token claims when using API keys, so they cannot enforce per-user authorization. Therefore, API keys alone are fundamentally inadequate for authenticating internet users.

IAM authorization for all internet users

Why it fails: IAM authorization is designed for AWS principals—IAM users, roles, or federated identities—that must sign requests with AWS Signature Version 4 using long-term or temporary AWS credentials. General internet users of a public API do not possess IAM credentials, and distributing static AWS keys to external clients would create a severe security risk. Moreover, SigV4 signing is impractical for typical browser-based or third-party OIDC-authenticated clients. Thus, IAM authorization cannot authenticate individual users whose identities come from an external OpenID Connect provider.

A VPC endpoint policy

Why it fails: A VPC endpoint policy controls which AWS principals and actions are permitted to use a particular VPC endpoint when accessing a service from inside a VPC—it is an IAM-based resource policy for private network connections. It does not validate user identities, tokens, or OIDC claims, and it applies only to traffic routed through the endpoint, not to the public internet path. Since the B2B API is explicitly public, internet requests will never traverse the VPC endpoint, so the policy would have no effect on them. Therefore, a VPC endpoint policy cannot authenticate or authorize external end users.

A Gateway VPC endpoint for secretsmanager

Why it fails: Gateway VPC endpoints are only supported for Amazon S3 and DynamoDB. They work by adding a prefix list entry to the route table, not by attaching an ENI. Secrets Manager does not offer a gateway endpoint; the only private connectivity option is an Interface VPC endpoint (AWS PrivateLink), so a gateway endpoint would not be able to route traffic to the Secrets Manager API.

A NAT gateway in the private subnet route table

Why it fails: A NAT gateway provides outbound internet access from private subnets, but the question explicitly states there is no NAT gateway and, by implication, no internet routing. Even if one existed, using a NAT gateway would force Secrets Manager API calls to travel over the internet to the public endpoint, which violates the requirement to keep traffic private. A NAT gateway is also an egress-only mechanism and does not provide the secure, native private connectivity that an interface endpoint offers.

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

Why it fails: VPC peering establishes connectivity between two VPCs, not between your VPC and AWS managed services like Secrets Manager. There is no 'AWS public network' VPC available to peer with, and the supported way to privately access Secrets Manager APIs is via an Interface VPC endpoint (AWS PrivateLink). Peering would not give your subnets a private, stable route to the Secrets Manager service endpoint and is not a valid pattern for this scenario.

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

Why it fails: 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 it fails: 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 it fails: Moving the application into a public subnet still uses the public Secrets Manager endpoint, which requires an internet path and exposes the workload to a broader network attack surface. This directly contradicts the stated requirement to keep all traffic within AWS private networking and avoid internet egress. It also does nothing to address the need for private access to the customer-managed KMS key for decryption, so the application would still need a way to reach KMS securely. Proper architecture uses interface VPC endpoints with private DNS to keep both Secrets Manager and KMS traffic fully inside the AWS backbone.

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

Why it fails: A NAT gateway gives your private subnet outbound internet connectivity, so the application could reach the public Secrets Manager endpoint, but that path travels through the internet gateway and leaves the AWS private network. This exposes sensitive API traffic to the public path, incurs NAT gateway hourly and data-processing charges, and adds a single point of failure. It also requires a public IP for the NAT gateway and an internet gateway, which is less secure and more expensive than using a VPC endpoint.

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

Why it fails: Gateway VPC endpoints are route-table-based and are only supported for Amazon S3 and DynamoDB; AWS Secrets Manager is not eligible. A gateway endpoint works by adding a prefix list to a route table, which does not apply to Secrets Manager because it is a Regional service exposed through an API. Pointing the route table to such an endpoint would not create any path to the Secrets Manager API, leaving the application without connectivity to retrieve secrets.

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

Why it fails: VPC peering connects two VPCs privately, but it does not let you use the peered VPC's internet gateway for egress because peering does not support transitive or shared internet access. Even if the peered VPC has full internet connectivity, your application subnet would still need its own NAT gateway or internet gateway to reach the public Secrets Manager endpoint. If the peered VPC instead contained an interface endpoint, you would need custom routing and additional components like a Network Load Balancer to make it usable, so this option is not a direct or simple solution.

Disabling route tables

Why it fails: Disabling route tables would not reduce cost and would actually break all network traffic in the sandbox. Route tables are mandatory for any subnet to function; they determine how traffic is directed, including the default route to the NAT gateway. Removing or disabling them would make private subnets unable to route any packets, not even to the VPC's local network, thus undermining the entire environment. Cost optimization must not sacrifice fundamental routing, and this option is neither practical nor targeted at the NAT gateway expense.

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

Why it fails: An internet gateway (IGW) does not perform NAT for private instances; it only enables communication for resources with public IP addresses. If you attach an IGW to a private subnet, instances still lack public IPs and a route to the IGW, so outbound internet traffic will simply fail. To make it work, you would have to assign public IPs and convert your private subnets into public ones, which defeats the purpose of having a private subnet and exposes instances directly to the internet. Thus, this is not a like-for-like replacement and does not address the NAT gateway cost while maintaining the same architecture.

Moving all workloads to public subnets

Why it fails: Migrating all workloads to public subnets would eliminate the need for NAT gateways, but at the cost of removing the security boundary provided by private subnets. Public instances are directly reachable from the internet, requiring tight security group rules and exposing the attack surface; this is a security regression, not a cost-first best practice. Even if you maintain security groups, anything accidentally misconfigured could lead to data exposure. The question is focused on cost reduction without compromising the sandbox's architectural integrity, so this option is wrong because it trades security for cost rather than optimizing within the existing design.

Create an Interface VPC endpoint (powered by PrivateLink) for S3

Why it fails: Interface endpoints are used by many AWS services, but S3 is specifically accessed via a Gateway endpoint. Using an Interface endpoint for S3 would not provide the intended S3 connectivity pattern for private subnets in the standard AWS design.

Use a Transit Gateway to route to S3 over the internet

Why it fails: A Transit Gateway routes traffic between networks/VPCs, but it does not replace the service-specific private connectivity required to reach S3 without public internet. You would still need an appropriate private path (such as a gateway endpoint) rather than sending traffic over the internet.

Place a NAT Gateway and restrict security group egress to port 443 to reduce exposure

Why it fails: Adding a NAT Gateway would directly violate the stated constraint of having no NAT Gateway, and a NAT Gateway requires an internet gateway and public subnet to function. Even if you restrict security group egress to HTTPS port 443, the NAT route would force S3 traffic out to the public internet, incurring data transfer costs and exposing traffic to potential interception. A Gateway VPC endpoint instead keeps S3 traffic entirely within the AWS network, without any NAT device.

Add a more permissive security group rule allowing outbound 0.0.0.0/0 on all ports.

Why it fails: Security group rules are evaluated after routing decisions, so adding an outbound 0.0.0.0/0 rule does not provide a path to the internet or to AWS services. Without a route through a NAT gateway/internet gateway or a VPC endpoint, traffic is still dropped. Moreover, Systems Manager requires interface endpoints for each service, and S3 requires a gateway endpoint or NAT; a permissive SG alone cannot enable these private connections.

Replace the NAT gateway with a network ACL that allows ephemeral ports to the internet.

Why it fails: A network ACL is a stateless packet filter, not a routing or connectivity construct. Even if you allow ephemeral ports, the subnet has no route to an internet gateway or NAT device, so outbound traffic cannot leave the VPC. Additionally, Session Manager and S3 access in a private subnet rely on VPC endpoints or NAT, and NACLs cannot create those private connections.

Move the instances to public subnets so they can reach AWS services directly.

Why it fails: Moving instances to public subnets would route S3 and Systems Manager traffic through an internet gateway, violating the requirement to keep traffic on the AWS private network. Public subnets also assign public IPs and expose instances to inbound internet traffic, increasing the attack surface. A private subnet with VPC endpoints is the correct way to reach these AWS services without traversing the internet.

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

Why it fails: An internet gateway (IGW) is a VPC-level resource, not a per-subnet device, and it cannot be 'attached' to private subnets. When a private subnet routes 0.0.0.0/0 to an IGW, instances would need public IP addresses to actually reach the internet; without them the route is ineffective, and with them the subnet is effectively public. An IGW permits bidirectional traffic, so inbound connections from the internet can reach those resources, completely undermining the isolation that private subnets and NAT gateways are designed to provide. Replacing NAT gateways with IGWs does not preserve outbound-only access and is not a valid cost optimization.

Disabling route tables

Why it fails: Disabling route tables is not a valid operation in AWS, and more importantly, route tables are the essential mechanism that tells each subnet where to send traffic. Every private subnet that uses a NAT gateway must have a route table with a 0.0.0.0/0 entry pointing to that gateway; without that route, the batch job's outbound internet traffic would have no path and would be dropped, breaking the analytics pipeline. Disabling or deleting route tables would also disrupt internal VPC routing, not just internet access, so it would cause a full network outage rather than any cost savings. The correct optimization is to simplify or consolidate routing, not to remove the routing layer itself.

Moving all workloads to public subnets

Why it fails: Moving all workloads to public subnets would require assigning public IP addresses and routing traffic directly through an internet gateway, which exposes the batch analytics instances to unsolicited inbound internet traffic. This fundamentally violates defense-in-depth principles because private subnets exist to keep sensitive data and processing logic inaccessible from the public internet, and many compliance frameworks mandate that data-processing workloads remain private. While this change could eliminate NAT gateway costs, it is not a cost-first best practice because the security risk and potential compliance breach far outweigh the savings; a better cost play is to right-size the NAT gateway count, not expose the workload.

S3 Object Lambda

Why it fails: S3 Object Lambda enables you to run custom Lambda code on the object content returned by S3 GET requests, primarily for transforming or filtering data in real time. It does not provide or modify VPC routing; requests still originate from the instance and traverse whichever network path exists, including a NAT gateway. It adds compute time and Lambda invocation costs while leaving NAT data processing charges on the underlying S3 traffic fully intact.

AWS Shield Advanced

Why it fails: AWS Shield Advanced is a managed DDoS protection service that operates at the network edge to absorb volumetric attacks; it does not change the network path between a private subnet and Amazon S3. Because media processing still egresses through a NAT gateway, S3 traffic continues to incur NAT data processing charges. Shield Advanced protects availability, not cost, so it cannot address the NAT cost issue.

A larger NAT gateway

Why it fails: NAT gateways do not have a user-selectable 'larger' size; they are managed, horizontally scaled resources that automatically adjust to handle traffic up to their bandwidth limits. The NAT gateway pricing model includes both an hourly charge and a per-GB data processing fee, so attempting to increase capacity would either have no effect on the per-GB fee or increase the monthly cost. To reduce S3-related charges, you must route S3 traffic away from the NAT gateway entirely, not increase its size.

Attach Elastic IP addresses to instances in private subnets

Why it fails: Elastic IP addresses are static public IPv4 addresses that require an instance to reside in a public subnet with a route to an Internet Gateway to be useful for egress; they do not create any private path from a private subnet to AWS service APIs. Even if you attach an EIP to an instance in a private subnet, outbound traffic would still need a NAT Gateway or similar egress device, so it cannot satisfy the cost-avoidance goal. EIPs also incur additional charges for idle addresses and fail to provide the PrivateLink-like connectivity that VPC endpoints offer.

Install a NAT Gateway in every subnet to minimize routing hops

Why it fails: Installing a NAT Gateway in every subnet does not remove the need for an Internet Gateway (IGW) nor does it bypass pay-per-hour and per-GB data processing charges; in fact, it compounds those costs across multiple gateways. NAT routing still forces traffic through the public border (IGW) before reaching AWS services, adding latency and complexity, which is the opposite of the low-hop private path provided by a VPC endpoint. The premise of 'minimizing routing hops' is also incorrect: a gateway endpoint for S3 or an interface endpoint for other services routes directly from your VPC to the service, without any NAT device.

Open outbound internet access with a security group rule to reach service endpoints directly

Why it fails: Reaching AWS service endpoints via the internet typically reintroduces outbound connectivity (and associated data-transfer costs and security considerations). It also does not provide the NAT-avoidance behavior of VPC endpoints for private access to AWS services.

A deny statement for all IAM users except the EC2 role

Why it fails: A bucket policy that denies all IAM users except the EC2 role controls only which identity can call S3 APIs, not how the traffic traverses the network. Even if the role is assumed solely by the EC2 instance, that instance could use a NAT gateway, internet gateway, or a different VPC endpoint to reach S3, and the policy would not detect the scenario. This approach lacks any source network validation, so it cannot guarantee that requests originated from the private subnet through the intended VPC endpoint.

A security group rule that allows HTTPS to S3

Why it fails: Security groups are stateful firewalls attached to an EC2 instance's elastic network interface; they do not attach to S3 buckets and cannot be used to enforce S3 bucket permissions. Allowing HTTPS to S3 IP ranges only authorizes outbound traffic from the instance, but it does not restrict which S3 bucket is accessed or require that traffic flow through a VPC endpoint. S3 bucket policies and VPC endpoint policies are the correct controls to enforce bucket-level access, while security groups are not a mechanism for S3 authorization.

A condition that matches aws:RequestedRegion to the bucket Region

Why it fails: The aws:RequestedRegion condition key limits API requests to a specified AWS Region, such as ensuring S3 operations target the bucket's home Region, but it does not inspect the source network path. A request could be sent from anywhere—a different VPC, an on-premises network over the internet, or another endpoint—while still specifying the same requested Region. Since this condition has no relationship to how the traffic reached S3, it cannot prove that the request used your VPC endpoint and thus fails to enforce the private-subnet requirement.

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

Why it fails: A NAT gateway routes traffic through the public subnet and the internet, giving instances public-facing egress and contradicting the requirement to avoid both. It is tempting because NAT gateways commonly grant private-subnet access to AWS services, and would be correct if internet egress were permitted.

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

Why it fails: Public IPv4 addresses expose the instances to the internet and route S3 and Secrets Manager traffic over public endpoints, breaching the no-public-IP requirement. It is tempting because security groups can restrict inbound access, and would be correct if internet-based access with tight filtering were acceptable.

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

Why it fails: VPC peering connects VPCs to each other, not to AWS service endpoints, and S3 and Secrets Manager are not reachable through a peering connection. It is tempting because peering keeps traffic on the AWS backbone, and would be correct for private connectivity between two customer VPCs.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.