A connection-level review of private AI networking using Amazon Bedrock, AWS PrivateLink, and NIST guidance. It distinguishes endpoint families, authorization, managed execution, external dependencies, and failure-path evidence.
At a glance
Key findings
- A private inference connection describes one path. Retrieval, tools, administration, and telemetry can use different paths and identities.
- Endpoint policies complement identity and resource policies; they do not replace them.
- Define the network objective precisely and collect connection-level evidence before describing an entire AI application as private.
Define the network objective precisely
Private can mean several different things in an AI design review. A team may want inference traffic to avoid a public-internet route, prevent an application from contacting unapproved destinations, restrict who may invoke a model, or control where data is processed. These are different objectives. A private endpoint is not evidence that all of them have been satisfied.
NIST's zero-trust architecture guidance rejects implicit trust based only on network location and focuses on access to resources. That principle is useful here: placing a connection inside a preferred network path does not establish the caller's authority for every resource reached through it. [3]
State the objective in a form that can be checked. For example, an application might require specified inference calls to use an approved private endpoint while permitting a separately documented external notification service. That is more precise than calling the whole system private. The review can then identify each permitted exception and the evidence needed to confirm the intended behavior.
Inventory the API families the application calls
Amazon Bedrock documents separate endpoint families for runtime, control-plane, and agent operations, along with other supported interfaces. Creating an endpoint for one family should not be treated as proof that every API used by the application follows that path. Review the actual client calls and their configured destinations. [1]
Build the inventory from the application outward. Include startup and refresh behavior as well as ordinary user requests. A model call may be obvious in the main request handler while a configuration lookup, model listing, or management operation occurs in a different component. Assign each call an owner so the review does not stop at the best-understood path.
For each family, record the service name, region, hostname behavior, client configuration, and intended endpoint. Separate what the documentation supports from what the deployment has been observed to use. The former tells you what can be configured; the latter requires evidence from the environment. Neither a diagram nor a successful API response alone proves the network route.
The inference endpoint is one hop
Review each surrounding connection on its own routing and authorization terms.
Source. Bedrock and PrivateLink documentation and NIST SP 800-207 [1]-[4].
Method. Original connection-review map. Edges identify relationships to inspect, not verified packet routes. Managed-service calls are not assumed to traverse a customer's VPC endpoint.
Accessible table and figure data
| Connection | Initiator to identify | Separate review question |
|---|---|---|
| Inference | Application runtime | Which endpoint and policy govern the actual call? |
| Administration | Deployment or management component | Does this API use a different endpoint family? |
| Retrieval | Application or managed retrieval service | Where are documents read and authorized? |
| Tool execution | Agent action component | Which identity and network execute the action? |
| External integration | Tool or application | Is this destination and data transfer approved? |
| Telemetry | Application or service exporter | Where does operational or content data leave the path? |
| Connection | Initiator to identify | Separate review question |
|---|---|---|
| Inference | Application runtime | Which endpoint and policy govern the actual call? |
| Administration | Deployment or management component | Does this API use a different endpoint family? |
| Retrieval | Application or managed retrieval service | Where are documents read and authorized? |
| Tool execution | Agent action component | Which identity and network execute the action? |
| External integration | Tool or application | Is this destination and data transfer approved? |
| Telemetry | Application or service exporter | Where does operational or content data leave the path? |
Follow retrieval and actions beyond inference
An assistant may retrieve documents, query a search service, invoke a tool, store an output, and emit telemetry around the inference call. Treat those as separate connections. The caller, destination, authorization, and data class can change at each step. A single line from application to model cannot represent that complete relationship.
Bedrock's action-group documentation describes invoking Lambda functions with information elicited for an agent action. That adds a distinct execution component. The function's own downstream operations and network configuration belong in the review; they should not be assumed to inherit the application's inference endpoint configuration. [4]
Distinguish customer-controlled network paths from managed-service execution. A diagram that places every service-to-service call inside the customer's VPC can imply controls that do not exist on that path. Label the boundary honestly and document the supported controls for each connection. If an external API is required, make it an explicit dependency with an approved purpose rather than hiding it behind the model endpoint.
Combine endpoint policy with resource authorization
AWS documents endpoint policies as resource policies attached to VPC endpoints, and explicitly states that they do not override or replace identity-based or resource-based policies. Bedrock's endpoint documentation also describes the default endpoint policy and the ability to apply a custom policy. Review those layers together. [1][2]
A useful policy review asks which principal may perform which operation on which resource through the endpoint. Then it checks the corresponding identity and service-resource permissions. A restrictive network path does not justify a broad application role, and a narrow role does not by itself establish the network path used by the client.
Keep the policy intent readable. If an application only requires inference against approved resources, make unrelated administration a separate role or workflow where the service supports that distinction. Test allowed and denied operations under the actual application identity. Avoid copying a broad documentation example into production and describing the example's successful request as evidence of least privilege.
Review alternate paths and failure behavior
A network design also needs an answer for failure. What happens if the intended endpoint is unavailable, private DNS is misconfigured, or a new library chooses a different hostname? The application might fail clearly, retry, or use another configured route. The acceptable behavior should be decided before an incident, not inferred from a convenience fallback.
Create a proposed acceptance matrix that names the expected path and the outcome when that path cannot be used. For a strict private-routing requirement, an unapproved public fallback should fail the test even if it improves apparent availability. For an intentionally mixed design, record the approved exception and the data permitted to use it. These are policy decisions, not universal settings for every workload.
Inspect configuration sources as well as application code. Environment variables, SDK endpoint overrides, proxy settings, DNS, and deployment templates can influence where requests go. Keep the evidence scoped to the tested environment and version. A local test using a different network cannot establish the behavior of a production VPC. Include scheduled maintenance and credential refresh paths in the test inventory, since a rarely used connection can remain invisible during an otherwise representative interactive session.
Keep a connection register with the release
The final review artifact should be a connection register, not only an architecture picture. For runtime, administration, retrieval, tool execution, external integrations, and logging, record the initiator, destination, operations, data class, intended route, authorization control, owner, and evidence collected. Mark unknown paths as unresolved rather than filling them with assumptions.
Use an authorized test environment to exercise normal requests and selected failures. Correlate application observations with the network and service evidence available for that deployment. Retain enough identifiers to connect a request to the intended endpoint without publishing sensitive account details or customer content. If a path cannot be observed directly, describe the supporting configuration evidence and its limits.
Update the register when a new retrieval source, tool, model API, or exporter is added. Each addition can create a connection outside the boundary reviewed for the previous release. The resulting statement can be precise: these operations use these approved paths under these identities. That is a stronger operational claim than describing an entire agent as private because one inference endpoint was created.
Method and provenance
Primary documentation review completed August 28, 2026, with an original connection inventory and proposed network acceptance matrix.
No AWS account, VPC endpoint, packet path, regional availability, or account eligibility was verified. The diagram is a review model and does not establish residency or complete egress confinement.
AI assistance. AI assistance was used to research sources, draft and structure the article, and prepare the visual specification. No human technical review is claimed.
Published under the Cloud Security Desk organizational byline. Read the series policy.
References
- Interface VPC endpoints for Amazon Bedrock AWS. Accessed .
- Control access to VPC endpoints using endpoint policies AWS. Accessed .
- NIST SP 800-207 Zero Trust Architecture, August 2020 NIST. Accessed .
- Configure Lambda functions for Amazon Bedrock agents AWS. Accessed .