Yes — you can call Bedrock and Azure OpenAI with zero packets crossing the public internet. On AWS, a VPC endpoint does the job: interface endpoints keep Amazon Bedrock traffic inside the AWS backbone without an internet gateway, NAT device, VPN connection, or Direct Connect connection. On Azure, private endpoints plus resource firewall rules achieve the same outcome for Azure OpenAI. This guide covers both setups, the policy layers that make them enforceable, and the DNS traps that quietly break them in production.
If you already operate under strict residency or retention constraints, start from the EU data residency setup guide and treat private connectivity as the network half of that story.
Why Private Access Matters
Model prompts are business data. When your application calls a managed inference API over its public endpoint, every request leaves your network boundary and re-enters the provider’s. Egress IP allowlisting helps, but it fails the moment a NAT range changes, a SaaS vendor adds an address, or an unrelated tenant shares an allowed range. Private connectivity replaces “probably our traffic” with verifiable network identity: on AWS the request rides the PrivateLink path between your subnet and the service, and on Azure it terminates on a network interface inside your own virtual network. Audit evidence improves too — a flow log pointing at a named endpoint is easier to defend in a review than a stale allowlist of public addresses, and it maps cleanly onto the region commitments regulators keep asking about in the EU.
Bedrock Interface Endpoints Setup
Create an interface endpoint for the service names your workload actually uses: com.amazonaws.<region>.bedrock for the control plane and com.amazonaws.<region>.bedrock-runtime for inference. AWS places an endpoint network interface in each subnet you enable, and instances need no public IP addresses to reach the service. Enable the private DNS name when you create the endpoint: with it, the standard regional hostname such as bedrock-runtime.<region>.amazonaws.com resolves to the endpoint and your existing SDK code needs no changes. Without it, pass the endpoint URL explicitly — for example https://<vpce-id>.bedrock-runtime.<region>.vpce.amazonaws.com as endpoint_url in boto3 or --endpoint-url in the AWS CLI.
Network plumbing alone does not constrain what callers can do. The default endpoint policy allows full access to Amazon Bedrock through the interface endpoint, so an unlocked endpoint is only half a control. Attach a custom endpoint policy that limits actions — a policy granting only bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream turns the endpoint into an inference-only door, and IAM still governs which roles may walk through it.
Azure Private Endpoints and Rules
Azure’s model starts from the resource, not the endpoint. Set the Foundry or Azure OpenAI resource’s default network action to deny first, then grant access to specific subnets and IP ranges. Two facts drive the design: each Azure AI resource supports up to 100 virtual network rules, which can be combined with IP network rules; and turning on firewall rules blocks incoming requests for data by default, including requests from other Azure services, the Azure portal, and logging and metrics services. Plan your exceptions before you flip the default, or your dashboards go dark at the same time as your attackers.
For full private connectivity, create a private endpoint for the resource. Requests then resolve through the privatelink subdomain to a private IP inside your virtual network. If you run custom DNS, delegate that subdomain to the private DNS zone or add the A records yourself — otherwise hybrid resolvers will happily return the public address, and your “private” path silently degrades back to the public one.
DNS and Policy Pitfalls
- Split-horizon DNS: on-premises resolvers that bypass the privatelink zone send traffic back out the public path. Test resolution from every call site, not just the virtual network.
- Portal and telemetry lockout: Azure’s deny-by-default behavior blocks logging and metrics services too; allow them explicitly or accept operating blind.
- Trusted services: Azure can let selected services such as Azure Machine Learning and Azure Search reach your resource through managed identity when you configure the network bypass — scope that exception deliberately and review it quarterly.
- Endpoint sprawl: delete endpoints for retired regions and abandoned projects during cleanup; stale endpoints make network inventory audits harder than they need to be.
AWS Versus Azure at a Glance
| Dimension | AWS (Bedrock) | Azure (OpenAI) |
|---|---|---|
| Mechanism | Interface VPC endpoint over PrivateLink | Private endpoint plus resource firewall rules |
| DNS | Private DNS hostname for standard regional names | privatelink subdomain delegated to a private DNS zone |
| Policy layer | Endpoint policy combined with IAM | Network ACLs combined with RBAC |
| Default behavior | Open until you attach a custom policy | Denied until you grant explicit access |
| Blocked traffic | None by default; you restrict actions | Portal, logging and metrics until excepted |
Migration Checklist
- Inventory every caller of the model API — service, region, subnet and current egress path.
- Create the endpoint (AWS) or private endpoint (Azure) in the same regions as your callers.
- Enable private DNS and verify name resolution from each call site before touching any firewall default.
- Attach a least-privilege endpoint policy on AWS, or explicit subnet and IP rules on Azure.
- Flip the resource default to deny on Azure, remove public-path dependencies on AWS, then watch error rates and flow logs for a full day.
- Re-check your data controls end to end — private networking complements, not replaces, the audit described in zero data retention defaults you inherit.