VPC Endpoint practice questions

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.

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.

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.

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.

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

Why it fails: 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 it fails: An S3 Gateway endpoint is a route-based mechanism that grants private connectivity only to S3 and DynamoDB; it cannot reach an arbitrary internal service hosted behind a Network Load Balancer. Storing the service hostname in SSM Parameter Store merely lets clients look up a DNS name—it does not create any private network path, and the clients would still try to traverse the public internet or existing routes. PrivateLink requires an interface VPC endpoint, which is an elastic network interface with a private IP in the consumer VPC, not a gateway device. This option conflates centralised configuration with connectivity and selects the wrong endpoint type for the required AWS PrivateLink architecture.

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 it fails: A bastion host provides interactive SSH access for administrative tasks, not a scalable, least-privilege service endpoint; the consumer team would need to manage SSH keys and sessions, and the NLB’s traffic remains unexposed to PrivateLink’s VPC endpoint security groups. This option is tempting because bastion hosts are a common pattern for secure remote administration of private resources, and they would be correct if the consumer needed occasional SSH-based management of the provider’s instances rather than automated HTTP calls from another VPC.

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.

A security group rule that allows HTTPS to S3

Why it fails: Security groups are stateful filters that attach to Elastic Network Interfaces of EC2 instances; they cannot be attached to an S3 bucket, which is a regional service with no ENI. A rule allowing HTTPS to S3 might govern outbound traffic from the instance, but it cannot validate that the traffic actually reached the S3 endpoint as intended. More importantly, it provides no way to restrict the S3 bucket to accept requests only from that specific instance, so it fails to enforce the private, endpoint-based network path.

A condition that matches aws:RequestedRegion to the bucket Region

Why it fails: The aws:RequestedRegion condition key in IAM or bucket policies restricts the AWS Region to which the API call is destined, but it has no knowledge of the network path taken. A request from a public IP to the S3 endpoint in the same Region would satisfy this condition just as easily as a request traveling through the VPC endpoint. Therefore, it cannot prove that the EC2 instance's traffic used the VPC endpoint, leaving the public internet path available and violating the 'must access via endpoint' requirement.

A deny statement for all IAM users except the EC2 role

Why it fails: A deny statement for all IAM users except the EC2 role is an identity-based restriction that limits which principals can call S3, regardless of where they are located. This does nothing to control the network route; the EC2 role's credentials could be used from any machine, and requests could still travel over the internet. It also would block legitimate access from other services like Lambda or other VPCs, whereas the requirement is specifically about network path enforcement, not principal scoping.

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.

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

Why it fails: Adding an internet gateway (IGW) and routing private-subnet traffic through it would make the instances effectively public or at least give them direct internet egress, violating the requirement that they remain in private subnets. An IGW is used for bidirectional communication with the public internet, and it does not provide any private or encrypted path specifically to S3. While you could combine an IGW with a NAT device to allow outbound-only access, that adds cost and complexity and still sends traffic over the internet. The correct private-connectivity mechanism is a gateway VPC endpoint, which keeps S3 traffic within the AWS network without requiring an IGW or NAT.

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

Why it fails: A security group rule permitting outbound traffic to the S3 public IP range only authorizes the traffic path; it does not establish a private, non-internet route. Security groups are stateful virtual firewalls that filter traffic at the instance level, but they have no effect on how packets are routed. Without a gateway VPC endpoint or NAT device, the instance's route table would still send S3-destined traffic to the internet gateway, defeating the private-subnet requirement. Moreover, S3 public IP ranges are shared and dynamic, making this approach both insecure and operationally brittle.

Create a VPC peering connection to the S3 service VPC.

Why it fails: VPC peering connects your VPC to another customer-controlled VPC over the AWS backbone; it cannot connect to a managed AWS service like S3 because S3 is not exposed as a peer VPC. Amazon S3 is a regional service with publicly routable endpoints, so there is no S3 service VPC available for peering. Peering also does not support transitive routing, and even if you attempted to reach S3 via a peered VPC, that VPC would still need an internet path or a gateway endpoint. This option is based on a fundamental misunderstanding of how AWS service connectivity works.

Create a Gateway VPC endpoint for Secrets Manager.

Why it fails: Gateway VPC endpoints operate by adding route table entries with prefix lists, and AWS only supports them for Amazon S3 and DynamoDB. Secrets Manager is not a service that offers a gateway endpoint; it uses an interface endpoint backed by AWS PrivateLink. Attempting to create a gateway endpoint for Secrets Manager is impossible, and it would not provide the private connectivity required to keep traffic off the public internet.

Use a Transit Gateway attachment to route traffic to the public internet for Secrets Manager.

Why it fails: A Transit Gateway attachment is designed for interconnecting VPCs, VPN connections, and Direct Connect gateways; it does not, by itself, provide a path to Secrets Manager. To reach the public internet via Transit Gateway, you would still need an internet gateway, a NAT gateway, or a virtual appliance, which would force traffic through the public internet. That contradicts the requirement, and Transit Gateway offers no built-in private connectivity to Secrets Manager.

Deploy a NAT gateway and allow outbound HTTPS traffic to Secrets Manager.

Why it fails: Deploying a NAT gateway and allowing outbound HTTPS would route Secrets Manager traffic through the public internet, because a NAT gateway provides outbound-only internet access via the VPC's internet gateway. Although HTTPS encrypts the session, the traffic still traverses public infrastructure, violating the explicit need to avoid public internet egress. Moreover, a NAT gateway does not create a private connection to Secrets Manager; it only grants internet access, which is not the correct architectural solution.

Internet gateway attached to the VPC

Why it fails: An internet gateway attached to the VPC is not used by private subnets because the route table for a private subnet does not have a route to the internet gateway, and a subnet must be public with a 0.0.0.0/0 route pointing to an internet gateway to access it. Even if it were utilized, traffic would leave the AWS private network and traverse the public internet, which would not keep the communication private. Since the application is in private subnets, an internet gateway does not provide the required private connectivity.

NAT gateway in each Availability Zone

Why it fails: A NAT gateway in each Availability Zone provides outbound internet access, but it still routes traffic through the public side of the VPC via an internet gateway, so traffic to AWS services like Systems Manager would leave the AWS private backbone and travel over the public internet. This does not keep traffic fully private, and a NAT gateway is not a substitute for VPC endpoints. Additionally, a NAT gateway still requires an internet gateway to function, which reintroduces the public internet dependency and fails the private-only requirement.

A larger NAT gateway

Why it fails: NAT gateways are managed services that automatically scale up to 45 Gbps, so there is no larger instance type to choose; resizing is not an option, and the per-GB data processing charge applies to every byte sent through the gateway. Increasing the NAT gateway’s capacity would simply raise cost, not remove the S3 download traffic from the gateway. Therefore this change does nothing to lower the largest cost driver in the risk simulation workload.

S3 Object Lambda

Why it fails: S3 Object Lambda is a feature that runs a Lambda function to transform data returned by S3 GET requests before it is sent to the caller, not a network-routing control. It leaves the underlying network path unchanged, so downloads still egress through the NAT gateway and incur the same data processing charges. Adding Object Lambda would actually add Lambda invocation fees and introduce processing latency, making the workload more expensive rather than cheaper.

AWS Shield Advanced

Why it fails: AWS Shield Advanced is a managed DDoS protection service that gives enhanced detection, mitigation, and cost protection against volumetric attacks, but it has a monthly subscription fee and does not alter any network routing or data paths. Since it does not influence whether S3 traffic flows through the NAT gateway, the NAT data processing charges for the simulation's large downloads remain exactly the same. This is a security control, not a network-cost optimization mechanism.

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

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