Can This Caller Use Your S3 Gateway Endpoint?

Separate S3 caller location, DNS answers, route-table association and address-family evidence before assuming a gateway endpoint serves remote or same-VPC traffic.

An S3 gateway endpoint serves eligible traffic from its VPC; it is not a shared gateway for every caller that can reach that VPC. A VPN, Direct Connect, peering or transit-gateway connection does not extend its connection to a remote caller. Even inside the VPC, the caller's effective route and selected destination address matter.

Start with the caller, hostname, DNS answer and route evidence, not the existence of an endpoint icon. This article supplies a caller-path worksheet for general-purpose S3 buckets using regional endpoints. It separates network eligibility, policy authorization and observed access. The examples and figures are hypothetical. No AWS account, DNS environment or network was queried, and no endpoint or policy was changed. Directory buckets, S3 Express, website endpoints and production deployment procedures are outside scope.

1. Locate the process that makes the request

“The application uses our VPC” can mean a worker runs there, a developer reaches it remotely, or an on-premises job connects through it. Those are different callers. Record the actual execution location of the process that opens the S3 connection, including its network context and observation time. The person operating the application is not necessarily where its network request originates.

The S3 gateway endpoint guidance says gateway connections cannot extend outside a VPC through VPN, peering, transit gateway or Direct Connect. It also requires the endpoint and bucket to be in the same Region. Do not treat same-Region peering as an exception to the stated VPC boundary. A remote caller needs its own assessed path rather than borrowing the gateway by routing toward its VPC.

Keep an application proxy distinct from endpoint sharing. If a remote client asks an authorized in-VPC service to read an object, the S3 caller may be that service. Its identity, data handling and product behavior need a separate design decision. This is not evidence that the remote client's original S3 connection can use the gateway. Do not invent such a proxy as an unreviewed connectivity fix.

2. Check the same-VPC route instead of assuming it

Record the caller subnet's effective route table and gateway association, bucket/service Region, exact hostname and selected destination address. Preserve a dated configuration reference. The endpoint can exist while the caller's route table is not associated with it, or while a different destination falls outside the intended service prefix.

The gateway routing reference describes the associated route-table entry and Region-specific service prefix. Routing uses the most specific matching route; a more-specific route can take precedence. Public S3 destination addresses are compatible with the gateway mechanism. Seeing a public address in a DNS response does not establish that the request used NAT, nor that it traversed the public internet.

For the worksheet, distinguish a documented candidate route from an observed request path. A configuration snapshot supports a hypothesis under its assumptions. It does not prove which address a dual-stack client chose or whether the application used a different hostname or proxy. If route identity or the effective caller context is missing, record UNKNOWN rather than choosing the architecture diagram's preferred path.

3. Resolve the hostname from the caller's DNS context

Capture the exact requested hostname, A/AAAA query type, resolver/forwarding context, returned addresses and the address family actually used. A DNS query from an operator's laptop can answer a different question from the running worker's query. Keep those records separately labeled instead of promoting a convenient lookup to application evidence.

AWS's S3 interface/private-DNS guidance documents an inbound-only private-DNS option when a gateway endpoint is retained. Under that configured arrangement, on-premises queries using the inbound Resolver path can receive interface endpoint addresses while in-VPC traffic can retain the gateway path. Clearing that option is a different DNS choice, not an equivalent configuration. Actual resolver forwarding and endpoint settings must be established before applying either description.

There is also a specific compatibility gate: for inbound-only private DNS, the gateway's DNS-record IP type must match the interface endpoint's type or be service-defined. Record both values and the comparison result. Another combination is unsupported; a missing value remains UNKNOWN and holds this arrangement's eligibility conclusion. The presence of both endpoint types alone does not pass that gate.

*Illustrative inbound-only arrangement with IPv4 addressing and matching IPv4 DNS-record types on both endpoints. Dashed gray means a DNS query/answer relationship. It is not a deployed resolver topology, captured lookup or permission result. Object requests do not travel through the Resolver merely because it answered the name.*

The documentation currently presents service-defined DNS behavior in prose alongside tables with differing default descriptions for interface options. Do not settle an actual diagnosis by choosing one remembered default. Retain the configured IP type, DNS-record type and private-DNS flags, plus the caller's real query result. Where those inputs cannot be obtained, hold the route conclusion.

4. Treat IPv4 and IPv6 as separate route evidence

Do not use an old “S3 gateway endpoints are IPv4 only” rule. Current gateway IP/DNS guidance includes IPv4, IPv6 and dualstack configurations. The selected IP type affects the service prefixes in the route table; the requested hostname and DNS-record settings affect which addresses a caller can receive.

One important diagnostic case is an IPv4 gateway with service-defined DNS and a dualstack S3 hostname. AWS documents that traffic using AAAA records does not traverse that IPv4 gateway; it may be dropped or use another IPv6-compatible path if present. Do not label the alternative NAT without evidence. A hostname resolving successfully is not proof that every returned address has the intended endpoint route.

Record both the available answers and actual connection family where approved observations can establish it. A successful IPv4 fixture cannot validate an IPv6 path the client may select later. Conversely, an IPv6 mismatch does not establish that the same client's IPv4 path is invalid. Keep each selected family as a separate worksheet row when the evidence differs. This article does not supply a command to change endpoint or bucket-policy settings.

The interface case has a different boundary. AWS's interface endpoint considerations say an IPv4 interface endpoint with IPv4 DNS-record type does not support dualstack service hostnames: neither the hostname's A-record nor AAAA-record traffic traverses that interface endpoint. It can be dropped or follow another compatible path if one exists. Do not substitute the gateway's AAAA-only mismatch rule here, or infer NAT from an alternative path.

5. Compare interface capability without promising access

An interface endpoint is a different candidate for remote callers, not a gateway toggle. The S3 PrivateLink reference describes its private network interfaces and supported remote connectivity. That capability still needs a valid client-to-endpoint route, compatible DNS/address choice, permitted network traffic and authorization for the exact S3 operation.

Before marking an interface candidate, check the exact hostname, operation and negotiated TLS protocol against that reference's current limitations. It excludes website, legacy global and dash-Region endpoints, cross-Region CopyObject and UploadPartCopy, TLS 1.0, 1.1 and 1.3, and hybrid post-quantum TLS. Retain a dated capability result separately from policy approval. Missing hostname, operation or protocol evidence is a hold, not a supported-path assumption. The figures stipulate a compatible regional hostname and operation/protocol; they do not test them.

*Conditional data paths to the same general-purpose bucket in symbolic Region R. The remote path assumes a separately established private connection and compatible routing. Blue means object-request direction, not a successful response. The gateway connection itself never extends to the on-premises caller.*

Keep policy review separate from these network relationships. A route can be eligible while a bucket, identity or endpoint policy prevents access. A permitted principal can still have no usable network path. Do not respond to a connectivity worksheet by removing an explicit deny or granting broad S3 access. The exact authorization diagnosis is a different task with its own evidence owner.

Endpoint alternatives also have different operating and billing implications. The beyond-rightsizing article owns that broader comparison. This article does not quote rates, declare a saving or decide whether additional endpoints are economical. Establish the caller/path requirement before asking finance to price an alternative.

6. Work a fictional caller matrix

All records below are stipulated, NOT EXECUTED, with general-purpose bucket Region R. Candidate means documented path eligibility under the listed premises, not actual access. Policy authorization and real application result remain UNKNOWN in every row.

Packet B is different from packet C: one lacks the required local route evidence, while the other crosses a documented gateway boundary. Packet E does not mean all traffic from the worker is broken. Packet D is deliberately conditional; DNS and route premises are not an observed successful GET. Preserve these distinctions when explaining a failure or proposing another endpoint type.

7. Copy one evidence record without collecting object payloads

Use approved configuration and metadata access. Network inventories, bucket names, endpoint IDs and resolver relationships can reveal sensitive operational context. Share aliases and source references where possible, with exact identities stored in the permitted evidence location. No object contents, credentials or customer payloads are needed for the worksheet.

Record / decision time / caller owner / authorized evidence collector:
Actual process location / account / VPC or remote network / subnet:
Bucket type / bucket and service Region / exact hostname / client context:
DNS query time / resolver and forwarding path / A or AAAA / answers:
Actual connection address and family / source reference or UNKNOWN:
Endpoint type / Region / configured IP and DNS-record types:
Private DNS / inbound-only option / required gateway retained:
Gateway and interface DNS-record types / compatibility PASS, FAIL or UNKNOWN:
Caller route table and association / winning route / dated source:
For interface: private connection, ENI route and network-rule evidence:
Exact hostname / S3 operation / negotiated TLS / dated capability reference:
Interface capability PASS, FAIL or UNKNOWN (missing input holds):
Missing or denied inputs / source discrepancy / evidence owner:
Network disposition: candidate / not established / outside gateway / UNKNOWN:
Separate policy-review reference / operation / principal / unresolved fields:
Actual application result: NOT EXECUTED unless observed and referenced:
Next bounded action / owner / stop condition / recheck trigger:

A denied read is not proof that an endpoint is absent. An empty resolver record is not proof the application uses public DNS. Request the missing evidence from its authorized owner instead of expanding access. No new logging, packet capture, paid query or endpoint deployment is required or authorized by this article.

8. Hand off the path conclusion, not a cost or access claim

Complete one record from the caller's real context. Resolve location, Region, hostname, query answers, selected address family and effective route before classifying the gateway path. Assess an interface alternative only with its separate prerequisites. Keep policy and observed application results alongside the network conclusion without merging them into one green status.

Recheck after endpoint, DNS, route, subnet, proxy, client or bucket changes. The S3 gateway guide warns that endpoint route changes can interrupt existing TCP connections. A separately authorized implementation must plan and validate that behavior; this reference does not perform it.

If the next question is which data flow caused a charge, use the egress attribution worksheet. If it is whether a priced placement change is justified, use the egress investigation playbook. The output here is narrower: a dated, defensible caller-path eligibility record with UNKNOWN fields preserved, ready for the appropriate owner to decide what evidence or change comes next.