S3 gateway or interface endpoint for an on-premises client?

Reaching S3 from an office network over a site VPN is not a routing problem a static route can solve on its own. A gateway endpoint is attached to route tables and serves requests that originate inside the VPC. An interface endpoint places elastic network interfaces with private addresses in your subnets, and those addresses are reachable from on premises across VPN or Direct Connect. Where the request starts decides which of the two you actually need, and the DNS, security group and policy work follows from that answer.

Separate the endpoint types by where the request starts

A gateway endpoint appears as a route-table entry pointing at a managed prefix list. It has no network interface, no security group and no private address of its own, which is exactly why an on-premises host cannot route to it: there is nothing on the far side to route to. Traffic from inside the VPC reaches S3 because the subnet route table sends that prefix to the endpoint. Traffic from anywhere else has no such entry to follow.

An interface endpoint is a set of network interfaces in subnets you choose, each with a private address from that subnet and a security group attached. That is the shape a hybrid client can use, because it is an ordinary destination your tunnel can carry packets to. It also means the endpoint consumes addresses in the subnet and can run out of them.

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

Read the Type column rather than the name. A single VPC commonly holds both kinds for the same service, and the one your on-premises application needs is the interface entry.

Build the path to the interface address before testing S3

Three things have to be true at once: the on-premises router has a route to the endpoint subnet, the return path from that subnet reaches the client network, and the endpoint security group admits the client source range. The subnet's network ACL can still drop the packet after all three pass, so check it as a fourth item rather than as an afterthought.

A working route to some EC2 instance in the VPC proves none of this. It shows that the tunnel is up, which is the one part of the path you already knew. Prove the endpoint address separately, then prove the name resolves to it.

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

The first command shows which interface the client would use. The second proves a TCP handshake. The third proves that TLS completes with a certificate valid for the endpoint name, which is the check that catches a wrong address before you blame permissions.

Decide which DNS answer the application receives

An interface endpoint existing in the VPC does not redirect an on-premises SDK by itself. The client either uses the endpoint-specific name that AWS publishes for that endpoint, or a private hosted zone that you have deliberately made resolvable from the office.

For hybrid resolution, the on-premises resolver needs a supported path into the VPC's DNS view, usually through a Resolver inbound endpoint. Enabling private DNS without understanding which query sources it affects is how a lookup starts returning an address the office cannot reach. The setting changes answers for queries that arrive through the VPC resolver, not for every client everywhere.

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

Run both from the application host, not from a jump box in the VPC. The resolver that answers there is the one your workload uses, and a different answer from a different host is the most common source of confusion in this design.

Reachability is not authorization

A request that arrives at the endpoint still needs an authorized principal and an applicable bucket permission. An endpoint policy can narrow what the endpoint allows, and a bucket policy can narrow it again. Reaching the interface says nothing about which objects the caller may read.

Test both directions: one harmless authorized call against the intended bucket, and one call expected to be denied for an identity or resource outside the policy. Keep the endpoint name, the resolved address and the policy context with the result so the next person can reproduce it. A denial that names the policy type saves an hour of guessing.

Finally, price the two options before provisioning. An interface endpoint bills per interface hour and per gigabyte, while a gateway endpoint does not, and that difference decides the question for many low-volume workloads that only need VPC-side access.