How to reach cloud services over private endpoints

Why this matters

Every cloud service has a public endpoint. It resolves to a public address and packets cross the internet to reach it. A private endpoint gives the same service a private address inside your own network, and the traffic stays on the provider backbone. Clients use it and never notice.

The point is control. Once the service is reachable only through the endpoint, you can deny every request that arrives any other way. A stolen key is not enough to read a bucket from a coffee shop. You also drop the NAT gateway hop, which makes the egress path easier to account for.

Most of the work is DNS. A private endpoint nobody resolves is a private address doing nothing. Failed rollouts usually come down to one client group, often on premises or in a second account, still resolving the public name. Plan for that first.

Before you start

Write down every service in scope and every client that calls it. Include the batch job, the CI runner, the Lambda function and the analyst's laptop. A private endpoint only serves clients that sit on a network able to reach it.

Choose the endpoint type per service. On AWS, S3 and DynamoDB use gateway endpoints, which are route table entries rather than network interfaces. Everything else uses interface endpoints, which place an elastic network interface with a private IP in a subnet you pick. Azure calls its version a private endpoint, also a network interface in your subnet, and treats service endpoints as a route level allow list. Google Cloud uses Private Service Connect in both directions.

Reserve a subnet for endpoints. Each interface endpoint takes one private IP per availability zone, and that address stays with the endpoint for its life. Leave room to grow, and keep endpoints out of the subnet that holds your NAT gateway or your load balancer.

Find out who answers DNS for each group of clients. Inside a VPC or VNet it is the provider resolver. On premises it is your domain controllers or your own BIND servers. You need a forwarding path between them, and you need someone who can change both.

How to do it

Do one service end to end before you touch the next one. The first takes planning. The rest turn into a checklist.

The steps below cover consuming a provider service from your own networks. If you are publishing your own service to customer accounts instead, swap the endpoint creation step for an approval flow: the consumer creates the endpoint, you accept the connection request, then you associate the private DNS zone with their account.

1. Map the call path. For one service, list every client, its network and the DNS server it uses. You will come back to this list at the end to confirm nothing still resolves the public name.
2. Create the endpoint in every zone. Create the interface endpoint or private endpoint in each VPC or VNet and in each availability zone that runs workloads. Use a dedicated subnet with room to grow. For gateway endpoints, add the route to every subnet route table that needs it, including subnets behind a transit gateway.
3. Turn on private DNS. Enable private DNS on the endpoint, or attach the provider's private hosted zone to your VPC. This is the setting that rewrites the public name to the private address. Without it the endpoint exists and nothing uses it.
4. Forward DNS from everywhere else. Add conditional forwarders on your on premises resolvers pointing at an inbound resolver endpoint in the cloud. Point the cloud resolver back at your internal zones for company names. Test from a domain joined machine, not from a jump host you already proved.
5. Tighten the policies. Set the endpoint policy to the accounts, roles or resource names you expect. On the service side, add a condition that denies requests unless they arrive through the endpoint. Run it in report mode first where the provider offers one, then switch to deny.
6. Close the public path. Remove the public allow list entry, the public IP, or the route that lets the subnet reach the service over the internet. Keep it removed for a full business cycle, because the monthly job is the one that breaks.
7. Tag it and name an owner. Tag endpoints with service, environment and owner, and add them to your inventory report. Endpoints multiply quietly, and an untagged endpoint is one nobody dares delete.
8. Wire up monitoring. Watch endpoint state, connection counts and errors in the provider console. Alert on rejected connections, because a jump right after a policy change usually means a client was missed.

How to check it worked

Resolve the name from a host in each subnet that should use the endpoint. You want a private address from the endpoint range, not a public one. Repeat from a machine on premises and from a second account if you have one. A client that still returns a public address is not seeing the private zone, and that is the whole bug.

Break it on purpose. In a test account, remove public access to the service and try again from a client that has the endpoint. It should keep working. Then try from a client without the endpoint. It should fail with a timeout or a policy denial. That second test is the one that proves the endpoint is doing the work.

Watch the counters for a week. Bytes through the NAT gateway for that service should drop to near zero, and flow logs should show traffic heading to the endpoint addresses. Check every availability zone, then disable one endpoint and confirm the others carry the load.

Mistakes to avoid

Building the endpoint and stopping there. DNS is the feature. If the private zone is not attached to every VPC that has a client, and forwarded to every resolver outside the cloud, the endpoint is decoration.

One endpoint in one zone, and the public door left open. A single zone works in testing and then takes the whole service down when that zone has a bad day. Create the endpoint in each zone your clients use and let the service spread connections across them. Teams also add the private path and never remove the public allow list, so the service stays as exposed as before and now there are two ways in to audit.

Default policies, small subnets and overlapping ranges. A default endpoint policy allows every principal in the account, and an endpoint in the wrong subnet can exhaust addresses. Watch the CIDRs too when you advertise endpoint routes to on premises over a transit gateway or ExpressRoute. Colliding ranges send return traffic to the wrong place and you get timeouts that look random.

If the DNS path across accounts and on premises is the part you are unsure about, a second opinion before cutover can save a painful week. The Expert architecture session, $450 one-time, gives you 90 minutes with a senior architect, a pre-read of your diagrams and a written summary within two business days.

Frequently asked questions