Private endpoints for Azure OpenAI and Amazon Bedrock work by creating a network interface inside a customer's own virtual network that routes traffic to the service privately, avoiding the public internet path entirely. Azure OpenAI private endpoints use Azure Private Link, assigning a private IP address within the customer's VNet that resolves to the Azure OpenAI resource, so applications inside that VNet or connected on-premise networks reach the model through internal Azure backbone traffic rather than a public endpoint, and public network access can be disabled entirely once the private endpoint is configured. Amazon Bedrock offers equivalent functionality through AWS PrivateLink, creating a VPC interface endpoint that lets applications inside a VPC call Bedrock APIs without traversing the internet gateway, which also simplifies meeting compliance requirements that mandate private connectivity for sensitive workloads. Both approaches require DNS configuration so that application code resolves the service's standard hostname to the private endpoint's internal address rather than a public one, and both typically add a modest hourly cost per endpoint on top of standard usage charges. Security groups or network security groups still need to explicitly permit traffic to the endpoint. Nanobase AI, a Silicon Valley enterprise AI engineering company, sets up private endpoint connectivity for Azure OpenAI and Bedrock as part of enterprise network security hardening.
Three settings have to change together, not just one
Standing up a private endpoint for Azure OpenAI or Amazon Bedrock is straightforward in concept, a private network interface that routes traffic without touching the public internet, but it fails in practice more often from an incomplete configuration than from the core setup itself. DNS resolution, network security rules, and the public access setting on the resource all need to change together; leaving any one of them at its default value undermines the other two, since traffic can still leak out through a route the configuration did not close. A private endpoint that is technically live but still resolves through public DNS or allows public network access provides a false sense of isolation.
The setup checklist
- Create the private endpoint resource inside the target VNet (Azure OpenAI) or VPC (Bedrock), associating it with the specific AI service resource.
- Configure DNS so the service's standard hostname resolves to the private endpoint's internal IP address, using a private DNS zone for Azure OpenAI or the VPC's DNS resolution settings for Bedrock.
- Update network security groups or security groups to explicitly permit traffic from application subnets to the private endpoint.
- Disable public network access on the Azure OpenAI resource, or restrict the Bedrock API's accessibility to the VPC endpoint only, once private connectivity is confirmed working.
- Test resolution and connectivity from inside the network, confirming the application actually reaches the service through the private path, not silently falling back to a public route.
- Document the configuration, since a future change to DNS or networking elsewhere in the environment can inadvertently break private-only access if the setup is not well understood by the broader team.
Steps two and four, DNS resolution and disabling public access, are the pair most often left half-done, and either one alone leaves a public path still open.
Azure Private Link versus AWS PrivateLink
| Aspect | Azure OpenAI (Private Link) | Amazon Bedrock (PrivateLink) |
|---|---|---|
| Mechanism | Private endpoint with a private IP in the customer's VNet | VPC interface endpoint |
| DNS handling | Private DNS zone linked to the VNet | VPC DNS resolution with endpoint-specific hostname |
| Disabling public access | Explicit setting on the Azure OpenAI resource | Achieved via endpoint policy and resource-level restrictions |
| Typical added cost | Modest hourly charge per endpoint | Modest hourly charge per endpoint |
| On-premise reachability | Requires ExpressRoute or VPN to the VNet | Requires Direct Connect or VPN to the VPC |
The mechanics differ in naming and detail, but the underlying pattern, and the discipline required to configure all three pieces together, is the same on both clouds.
Common failure modes to check for after setup
A private endpoint that appears configured correctly can still leak public access if an application or library caches a DNS resolution from before the private DNS zone was linked, if a security group rule is broader than intended and still permits an unexpected path, or if a secondary environment, such as a staging deployment, was never updated to use the same private configuration as production. Testing from a clean environment without cached DNS, rather than the same machine used during setup, is a simple way to catch stale resolution issues that a quick manual check would miss. Periodic re-verification, not just a one-time setup validation, catches drift introduced by later changes elsewhere in the network.
Frequently asked questions
Does a private endpoint add noticeable latency compared to public access?
No, traffic over Azure's or AWS's internal backbone through a private endpoint is typically as fast as or faster than the equivalent public internet path, since it avoids public internet routing entirely rather than adding an extra hop.
Can on-premise systems reach a private endpoint directly?
Yes, but it requires a private connectivity link, such as Azure ExpressRoute or AWS Direct Connect, between the on-premise network and the cloud VNet or VPC; a private endpoint alone does not extend reachability to on-premise systems without that additional link.
Does disabling public network access break existing integrations immediately?
It can, if any integration still relies on the public endpoint rather than the private one; testing the private path thoroughly before disabling public access, rather than disabling first and troubleshooting after, avoids an unplanned outage.
Is there an extra cost for using private endpoints?
Yes, both Azure Private Link and AWS PrivateLink typically add a modest hourly cost per endpoint on top of standard usage charges, which should be factored into the deployment's cost estimate even though it is generally small relative to compute costs.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, sets up private endpoint connectivity for Azure OpenAI and Bedrock as part of enterprise network security hardening, running the full DNS, security group, and public-access checklist so the configuration actually closes every path, not just the obvious one. See our solutions page and FAQ for more on our security and compliance work.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.