Private Network Perimeter for AI Inference Services: Verifying Private Endpoint, DNS, and Routes Avoid the Public Internet

A cloud console showing a Private Endpoint as Available proves only that a network object exists. The application may still resolve a public address and make calls through NAT; private DNS may work in only some VPCs; and after a failure, the SDK may fall back to the default public domain. For inference paths containing a Prompt, attachments, and embedding, acceptance must prove that actual traffic traverses an approved endpoint instead of trusting a resource name. Cloud Networking Fundamentals explains VPCs, subnets, and security groups; this article focuses on end-to-end data-plane verification for managed AI APIs and cross-account inference services.

Start by Defining the Service Perimeter as an Inventory

Define ai.private-service.v1 and record each provider, region, service, endpoint ID, owner account, consumer VPC, subnet, private DNS name, allowed caller, port, endpoint-policy digest, and public-fallback status. AWS PrivateLink, Google Private Service Connect, and Azure Private Link have different resource models; their differences cannot be flattened into a single private=true Boolean. The validator reads the actual state through each cloud provider's APIs and generates a normalized report.

The application configures only a stable internal name, such as inference.prod.internal, and its configuration version is bound to a specific endpoint generation. The platform manages DNS A/AAAA or CNAME records, and application containers must not allow request parameters to override the base URL. Dual-stack environments must validate both IPv4 and IPv6. Making only the A record private while leaving the AAAA record pointing to the public Internet allows some clients to bypass the controls.

The capabilities of the three providers must not be conflated. An AWS interface endpoint has an endpoint policy only when the target AWS service explicitly supports one. A resource policy should likewise use aws:SourceVpce/aws:SourceVpc constraints only when the service supports them, while a private endpoint service relies on allowed principals, connection approval, and the service's own authentication. Google PSC uses the service attachment's accept/reject lists and consumer project to control connections; data perimeters for supported Google APIs additionally require VPC Service Controls, IAM, and organization policies. Azure Private Endpoint works with the target resource's firewall and RBAC, and sets publicNetworkAccess=Disabled when the service supports it, with Azure Policy preventing it from being reopened. Each provider profile records which controls are actually available; a field from another cloud cannot substitute for a missing control.

Regardless of provider, explicitly disable public network access when the target service supports it. When it does not, combine resource-side source conditions with workload-side default-deny egress to complete the perimeter. The inference subnet permits only the registered endpoint addresses, ports, and private DNS; public provider FQDNs, backup regions, and Internet/NAT egress are denied by default. Authentication still follows MCP Server Authentication Boundaries; private-network reachability does not imply authorization to call the service.

DNS, Routing, and Egress Evidence Must Corroborate One Another

Acceptance probes run from every production subnet, standby zone, and workload type. They resolve the internal name and confirm that the result belongs to the registered endpoint ENIs or private-address set; establish a TLS connection and validate the trusted service identity; send a minimal request carrying a unique canary ID; and then correlate the server-side access logs, endpoint connection, and VPC flow logs. The route table must prove that the destination does not depend on an Internet Gateway. If the design requires avoiding NAT entirely, the increase in NAT bytes during the same observation window must be zero.

Critical negative probes must reuse the production workload identity, SDK configuration, and resource permissions. In an isolated test, bypass private DNS and directly connect to the provider's canonical public hostname, a backup region, and a public-IP path, asserting that network egress or resource-side source-endpoint/VPC-SC/firewall conditions reject them. The same call should succeed only when switched to the private endpoint. An uncredentialed public runner can supplement testing for Internet exposure, but it cannot prove that a principal holding a production identity is unable to bypass the private network. Historical NAT byte counts of zero also cannot prove that future fallback has been blocked.

Do not draw conclusions from traceroute alone, because many cloud virtual networks do not expose their actual hops. The evidence must combine control-plane resource snapshots, public-access status, DNS answers, resource-policy denial events, flow logs, and server-side request IDs.

A Service Mesh can provide in-cluster mTLS and service identity, but whether traffic enters a cloud private endpoint after leaving the mesh must still be proven separately. Agent Egress Protection addresses untrusted URLs, redirects, and SSRF. Arbitrary URLs are not allowed here; this article verifies that a fixed inference destination does not drift onto the public Internet because of cloud-network changes.

Fault Injection Must Cover Hidden Fallbacks

In staging, inject the following faults in sequence: delete the private DNS record, return a stale public CNAME, remove one subnet association, reject the endpoint connection, tighten the endpoint policy, remove a security-group rule, make the private domain time out, produce a public IPv6 answer, and unset the SDK endpoint parameter. Calls must either fail explicitly or move to another registered private endpoint; they must never fall back to the provider's public domain.

Production gates include the following: private-resolution coverage is 100%; every canary correlates with the expected endpoint ID; public network access is entirely disabled or has registered compensating controls; the number of successful direct connections by the same production identity to every public or backup path is zero; both default-deny egress and resource-side source conditions pass validation; and unknown generations, unapproved connections, and inference traffic through NAT/IGW are all zero. Audit records retain the provider capability, DNS generation, public-access status, policy digest, flow tuple, request ID, and release version, but do not record the Prompt.

Continuous drift checks cannot rely solely on a daily IaC plan. Every change to an endpoint, DNS zone, route, security group, NAT configuration, or SDK base URL triggers the probes. Missing flow logs are also treated as an evidence gap and generate an alert. If a provider offers private access in only some regions, the scheduler must not silently move sensitive tenants to a public region.

Dual-Endpoint Migration and Reversible Rollback

During a change, first create a new endpoint generation, complete connection approval, policies, and probes from every subnet, and then shift a small amount of traffic using weighted internal DNS or application bucketing. Keep the old endpoint verifiable and its configuration read-only. Observe connection errors, latency, and server-side request IDs before expanding traffic. Rollback only switches the alias back to the old private generation and refreshes controllable DNS caches. Do not delete the new endpoint and lose forensic evidence.

If the old endpoint policy has been incorrectly loosened or its owner account has been compromised, it cannot be used for rollback. Pause sensitive calls or switch to another qualified region instead. Cloud Disaster Recovery must validate the standby region's DNS, endpoint approval, and logging chain in advance instead of temporarily opening public access during an incident.

The private-network perimeter is complete not when an endpoint has been created, but when DNS, routing, endpoint identity, and flow logs can prove that every real request followed an approved path, and when the application does not silently choose the public Internet after that path fails.

Further Reading

• Cloud Networking Fundamentals
• MCP Server Authentication Boundaries
• Agent Egress Protection
• Cloud Disaster Recovery