An order-processing service runs on EC2 instances inside a private subnet. It writes receipts to S3 and reads a secret from an AWS API. A diagram shows no public IPv4 address on the instances, so the design is described as entirely private. In reality, its outbound API calls may use a shared NAT gateway to reach regional service endpoints, and the operations team may be paying for inter-Availability-Zone traffic as well as NAT processing. Private compute placement does not, by itself, define a private path to every dependency.
The AWS SAA-C03 blueprint requires network segmentation, service endpoint decisions, VPC routing, secure workloads, and cost-aware architecture. The public-versus-private subnet analysis establishes what a route table and an Internet gateway imply. This discussion begins where that one ends: a private workload still needs to reach AWS services, and each service requires a specific network and authorization contract.
Trace one real request before choosing an endpoint
List the caller’s subnet and VPC, DNS resolver, destination AWS service and Region, selected route-table entry, egress appliance if any, and actual target policy. An EC2 instance that queries S3 is not necessarily communicating directly with a local address in the VPC. The service hostname may resolve to public addresses while AWS routing mechanisms still keep the path on the AWS network when an appropriate gateway endpoint is configured.
Start with the existing route and observed source/destination packets. A security group can allow HTTPS while DNS resolves the wrong endpoint. A NAT gateway can provide connectivity while adding needless shared-egress costs. A successful API call says the overall path works, not that it meets the architecture’s private-access or segmentation requirement.
Use gateway endpoints for the services they actually support
VPC gateway endpoints provide route-table-based access to supported services such as Amazon S3 and DynamoDB without relying on an Internet gateway or NAT gateway. AWS’s S3 gateway endpoint documentation confirms that the gateway endpoint itself carries no additional endpoint charge. It also documents important limitations: it does not provide direct gateway-endpoint access from on-premises, across the specified cross-Region peering cases, or through a transit gateway.
A gateway endpoint is associated with selected route tables. If a workload is in a subnet whose route table lacks that association, the intended path may not be used. During setup, confirm every required Availability Zone’s subnet has the correct route-table behavior. Do not create an endpoint in one place and assume it becomes universal to every VPC in an organization.
Understand interface endpoints and AWS PrivateLink
Interface endpoints create private IP network interfaces in chosen subnets and expose supported services through AWS PrivateLink. Their private DNS options can make existing service hostnames resolve to the endpoint’s private addresses where supported. Unlike gateway endpoints, interface endpoints can support additional access patterns, including appropriate on-premises connectivity through Direct Connect or Site-to-Site VPN, subject to routing, DNS, and service support.
They also have distinct costs, including endpoint-hour and data-processing charges in applicable configurations. Place them in appropriate Availability Zones for availability and local traffic. A central shared-endpoint VPC may reduce duplicated endpoints but introduces DNS, network, policy, data-processing, and routing trade-offs. A statement that centralization is always cheaper ignores cross-zone and transit charges and the operational cost of a shared failure domain.
Separate endpoint policy from identity and resource policy
Creating a VPC endpoint does not authorize all callers to read all objects or secrets. Endpoint policies can limit actions and resources where supported, while IAM identity policies and service resource policies continue to apply. An S3 bucket policy can impose additional conditions that distinguish approved endpoint or VPC access for an intended workflow. Restricting one policy layer never replaces reviewing the others.
Test two principals against the same endpoint: the intended application role and an unauthorized test role. The authorized request should succeed; the other should receive an expected denial. Also test a request from an unintended subnet or network route. The S3 public-access and bucket-policy specialist is useful for understanding why a private transport path and a valid object authorization are separate properties.
Pay attention to DNS and interface security groups
An interface endpoint can exist and remain unreachable because its endpoint network interface’s security group does not permit the application source on the relevant port. DNS can also return an unexpected destination if a custom resolver does not forward the private domain correctly. When on-premises clients share access with in-VPC clients, private DNS and inbound resolver endpoint choices can influence which traffic uses a paid interface endpoint versus a no-charge S3 gateway endpoint.
Do not repair every endpoint failure by enabling all outbound traffic through an unrestricted NAT gateway. Check the name returned by DNS, intended endpoint IPs, network ACLs, security groups, route tables, and any hybrid DNS rules. Restore only the missing permission or resolution path. Correcting one network control should not silently bypass the organization’s inspection and data-exfiltration policy.
Know when NAT is still needed
A private service may also need third-party updates, public SaaS APIs, or external package repositories. A VPC endpoint for AWS APIs does not make those external destinations reachable. NAT gateways remain useful when outbound internet access is a justified requirement, but egress filtering, patch mirrors, centralized proxies, or narrower service destinations may be appropriate depending on policy.
The existing NAT gateway versus NAT instance comparison discusses management and resilience. In an endpoint design, the decision extends to routing costs: can S3 traffic stop traversing NAT without disrupting the application’s other legitimate internet dependencies? Monitor per-destination and per-AZ egress after the change to prove the intended reduction.
Test a multi-AZ application with an endpoint failure
Create a test workload in two Availability Zones and document each subnet’s relevant route table. Verify a signed request to a test bucket and a supported Secrets Manager endpoint, if used, from both zones. For the interface endpoint, confirm private DNS resolution, healthy endpoint network interfaces, and the allowed security-group source. Deliberately deny one endpoint security-group flow in a controlled lab to see the failure without changing the rest of the VPC.
Add a cost check to the acceptance criteria: record endpoint count, hourly charges where applicable, expected traffic volume, NAT charges, and any cross-AZ or transit transfer. An architecture that improves isolation but unexpectedly routes every byte through a distant shared endpoint may need revisiting. The objective is neither ‘no NAT anywhere’ nor ‘every AWS service gets an interface endpoint.’ It is one documented, secure, observable, and economically justified path for each application dependency.