VPC Endpoint 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.

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.

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.

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.

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.

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 to the internet with an Elastic IP and restrict access using the NLB’s security group only.

Why wrong: Exposing the internal Network Load Balancer to the internet with an Elastic IP immediately violates the requirement for an 'internal' HTTP API, regardless of security group restrictions. While security groups can filter source IP addresses, the service's public exposure inherently increases its attack surface and introduces unnecessary risk. This approach fundamentally contradicts the need for a non-public, internal service and is not a secure method for partner integration.

Use VPC peering between VPC A and the partner VPC and update route tables to resolve the overlap.

Why wrong: VPC peering fundamentally requires non-overlapping CIDR blocks between the peered VPCs to establish proper routing and avoid IP address conflicts. Attempting to update route tables to 'resolve' an overlap is not feasible, as the underlying network architecture cannot distinguish between identical IP addresses in different VPCs. This method would lead to routing failures and is an architectural limitation that VPC peering cannot overcome.

Deploy a NAT gateway in VPC A and route the partner’s traffic to the NLB through the NAT gateway.

Why wrong: A NAT Gateway is designed primarily to enable instances in private subnets to initiate outbound connections to the internet or other AWS services, translating private IP addresses to public ones. It does not facilitate inbound private access from another VPC or account to an internal service like an NLB. Routing partner traffic through a NAT Gateway for inbound access is an incorrect application of its purpose and would not establish the required private connectivity.

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.

Expose the NLB to the internet with an Elastic IP and restrict access using the NLB’s security group only.

Why wrong: Making the NLB internet-facing violates non-public requirements, even if security groups limit allowed sources.

Use VPC peering between VPC A and the partner VPC and update route tables to resolve the overlap.

Why wrong: VPC peering cannot handle overlapping CIDRs, and route-table changes cannot resolve IP address overlap safely.

Deploy a NAT gateway in VPC A and route the partner’s traffic to the NLB through the NAT gateway.

Why wrong: NAT gateways enable outbound internet egress for instances, not private, deterministic access to internal load balancers across accounts.

Internet gateway attached to the VPC

Why wrong: An internet gateway is not used by private subnets for private AWS service access.

NAT gateway in each Availability Zone

Why wrong: A NAT gateway allows outbound internet access but does not keep traffic fully private.

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.