Constrain private paths to approved APIs

Learning objective

Isolate model and data APIs with VPC endpoints, AWS PrivateLink, and endpoint policies.

Core idea

A private network path and an authorization decision solve different problems. A VPC endpoint changes how a request reaches an AWS service. An endpoint policy restricts which requests can use that endpoint. Neither mechanism replaces the service’s identity and resource policies, and neither establishes which business records an application user may read.

Design the complete request path before declaring an agent isolated. A private model invocation is only one hop: document retrieval, credentials, and tool calls need their own paths and permissions. Treat isolation as a set of verified routes plus enforced access boundaries, rather than the presence of an endpoint in a network diagram.

How it works

Select the endpoint for the API

Amazon Bedrock uses interface VPC endpoints powered by AWS PrivateLink. AWS creates an endpoint network interface in each selected subnet. Instances can reach Bedrock without public IP addresses, an internet gateway, or a NAT device for that connection.

Bedrock API surfaces include separate control-plane, runtime, and agent endpoints. The service name com.amazonaws.REGION.bedrock targets control-plane operations; com.amazonaws.REGION.bedrock-runtime targets runtime operations. The agent surfaces use com.amazonaws.REGION.bedrock-agent and com.amazonaws.REGION.bedrock-agent-runtime. Here, REGION means the deployment Region. Choose the surface your client actually calls. A runtime endpoint does not provide a private path to every Bedrock operation or to a separate storage service.

When you enable private DNS on a Bedrock interface endpoint, the normal Regional service name resolves to the endpoint for requests from within the VPC. This lets clients retain standard service hostnames. Without private DNS, explicitly configure the endpoint URL, such as the SDK client’s endpoint_url or the AWS CLI’s --endpoint-url. Check the resolved destination from the workload environment rather than assuming a configuration applied elsewhere controls that client.

Private DNS requires both VPC DNS hostnames and DNS resolution. The endpoint network interface’s security group must admit the expected inbound HTTPS traffic from the workload. Network ACLs must also allow traffic between workloads and those interfaces. A permissive IAM policy cannot repair a blocked network path; a reachable interface cannot repair a denied API operation.

Choose the data path separately

Amazon S3 supports gateway and interface endpoints. A gateway endpoint becomes a route-table target for S3 traffic from the VPC. It lets those workloads reach S3 without an internet gateway or NAT device and has no additional endpoint charge. Create it in the same Region as the relevant buckets and associate the route tables used by the workloads.

An S3 gateway endpoint cannot be extended to resources across a VPN connection, VPC peering connection, transit gateway, or Direct Connect connection. For those access patterns, select an S3 interface endpoint and design the corresponding connectivity and DNS. Interface endpoints incur additional cost. Choosing a gateway endpoint because it is cheaper fails when the caller cannot use its route.

Keep the model and data decisions independent. A service call initiated by a managed service is not automatically a request originating from your application subnet. Inventory both application-originated requests and service-to-service requests before requiring a particular endpoint on every data access. Otherwise, a restriction intended to protect the application can break a legitimate ingestion or logging path.

Restrict endpoint use and resource access

The default endpoint policy grants full access through the endpoint. Replace that default with a reviewed policy covering the required principals, actions, and resources. The policy’s Principal, Action, Resource, and optional Condition elements describe the allowed request set. Confirm that the service supports endpoint policies; support is not universal across AWS services.

AWS’s Bedrock example allows bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream for all principals and resources. Narrow that example to a workload role and approved foundation model:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
    "Resource": "arn:aws:bedrock:REGION::foundation-model/MODEL_ID",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalArn": "WORKLOAD_ROLE_ARN"
      }
    }
  }
}

Replace REGION, MODEL_ID, and WORKLOAD_ROLE_ARN with the deployment Region, approved model ID, and workload role ARN. The resource ARN narrows model access; the condition narrows Principal: "*" to that role.

For gateway endpoint policies, Principal must be "*". Restrict the caller with the aws:PrincipalArn condition key rather than substituting a role ARN directly in that element. This is a policy-format distinction, not a reason to let every role use the endpoint. An endpoint accepts one endpoint policy, with a maximum size of 20,480 characters including whitespace; keep the policy focused on the access boundary instead of duplicating a large permissions catalog.

An endpoint policy does not replace identity-based or resource-based policies. It restricts requests that traverse the endpoint. If an application can also reach a public service endpoint, the endpoint policy alone does not restrict that alternate path. Decide whether to eliminate the alternate route, constrain access at the resource, or use both controls.

For S3, bucket policies can restrict access by aws:sourceVpce or aws:sourceVpc. Apply those restrictions with explicit consideration for administration and managed-service access. A policy that denies every request outside a specified endpoint can also deny console access or necessary service operations. Validate approved paths before rollout and retain a deliberate recovery path. The bucket policy sees requests on every path, while the endpoint policy sees only those that traverse the endpoint.

For S3 requests traversing a VPC endpoint, do not use aws:SourceIp to match the workload address. AWS documents aws:VpcSourceIp for that context. Network source conditions describe how a request arrived; they do not encode a user’s tenant or document entitlement. Keep record-level authorization in the application, as discussed in 3.2.2.

Key distinctions and trade-offs

Interface endpoint versus gateway endpoint: An interface endpoint provides network interfaces through AWS PrivateLink. An S3 gateway endpoint changes route tables. Their connectivity scope and cost differ, so the two are not interchangeable deployment choices.

Endpoint restriction versus endpoint-only access: A restrictive endpoint policy constrains traffic using that endpoint. Enforcing endpoint-only access requires examining alternate paths and resource-policy conditions as well.

Private DNS versus permission: Private DNS selects a destination. Endpoint security groups admit network traffic. IAM and resource policies authorize API operations. Diagnose these layers separately when an invocation fails.

Private connection versus residency: A private ingress path says how the caller reaches a service. It does not, by itself, prove every processing and storage location; see 2.3.8 for residency decisions.

Architecture / decision scenario

A support agent invokes Bedrock and reads approved manuals from S3. Its application workers run inside a VPC; an on-premises review tool also needs access to the manuals.

The team selects a Bedrock runtime interface endpoint for model calls and enables private DNS. It checks inbound HTTPS on the endpoint security group and verifies name resolution from the workers. An endpoint policy admits the application role’s bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream calls on the approved foundation-model ARN.

For the VPC workers, the team associates an S3 gateway endpoint with their route tables. The on-premises tool uses an S3 interface endpoint through the designed private connectivity and DNS path. The team reviews the bucket policy’s endpoint conditions against both approved callers and the ingestion service before applying a deny outside those paths.

Acceptance includes allowed reads, rejected writes, an unapproved principal, and a request outside the approved endpoint path. A successful model response alone would prove only one of these boundaries.

Common exam traps

• Assuming one Bedrock endpoint covers every API surface and downstream service.
• Treating the default endpoint policy as least privilege.
• Using an S3 gateway endpoint for an on-premises caller.
• Expecting an endpoint policy to constrain requests that bypass the endpoint.
• Confusing private DNS, security-group rules, and IAM authorization.
• Restricting every bucket access to one endpoint without checking service callers.

What to remember

• Match each API surface to its own private path.
• Choose S3 endpoint types from connectivity requirements.
• Narrow endpoint policies and retain service-level authorization.
• Test allowed and denied requests from the actual workload environment.
• Network isolation does not establish end-user data entitlements.

Knowledge check

References

• AWS, Use interface VPC endpoints (AWS PrivateLink) to create a private connection between your VPC and Amazon Bedrock
• AWS, Create an interface endpoint
• AWS, Control access to VPC endpoints using endpoint policies
• AWS, Gateway endpoints for Amazon S3