Network Isolation and Data Residency for Agents
Interface VPC endpoints keep Bedrock traffic off the public internet and let you enforce policy at the network edge, while inference profiles and logging decide where your data is processed and stored.
Amazon Bedrock is a regional AWS service reached over public endpoints by default. Calls are TLS-encrypted and authenticated with SigV4, so "public endpoint" is not the same as "insecure" — but for regulated workloads you usually need to prove that traffic never traverses the internet, and you want a second place to enforce policy that the application cannot bypass.
VPC endpoints and PrivateLink
Create interface VPC endpoints, powered by AWS PrivateLink, for the Bedrock services you use: the control plane (bedrock), the data plane (bedrock-runtime), and for agents the corresponding agent control-plane and agent-runtime endpoints. Each endpoint puts an elastic network interface with a private IP inside your subnets, and private DNS makes the standard service hostnames resolve to it, so no SDK change is needed. Your action-group Lambda functions and any application compute then run in the VPC with no internet gateway and no NAT, which is the point: a compromised agent loop has nowhere to send data.
Attach an endpoint policy to make this a control rather than just plumbing. An endpoint policy can restrict which principals may call through it and which resources they may reach — a specific list of model ARNs, a specific agent alias — and can require conditions such as a matching account. Pair it with security groups that allow only HTTPS to the endpoint, and with an organisation-level aws:PrincipalOrgID condition so credentials stolen from your environment cannot be used from outside it. This is where you stop an agent quietly switching to an unapproved model.
Where the data goes
Inference happens in the Region you call. Your prompts and completions are not used to train the foundation models, and Bedrock does not retain them for that purpose. Two things move data around, and both appear in exam questions:
- Cross-region inference profiles. These improve throughput and resilience by routing a request to another Region for processing. Crucially, the routing stays within a defined geography — a US profile stays in the United States, an EU profile within the EU — so you choose a profile whose geography matches your residency commitment, or use a Region-specific model identifier and accept the throttling risk. Read the profile's member Regions before promising a customer that data never leaves one country.
- Model invocation logging. Enabled per Region, it can deliver full prompts and responses to Amazon S3 and Amazon CloudWatch Logs. That makes your log destination a copy of your most sensitive data: encrypt it with a customer-managed KMS key, restrict who can read it, and set retention deliberately. Knowledge-base sources in S3 and vector stores such as Amazon OpenSearch Serverless are likewise regional resources with their own encryption and network settings.
Guardrails, agent definitions and knowledge bases are all regional too, so a multi-Region design means duplicating and versioning them consistently — a common operational trap when a guardrail version exists in one Region and not another.
What this does not do
A VPC endpoint does not authenticate users, does not stop prompt injection, and does not prevent an over-privileged agent from reading data it should not. It removes an exfiltration path and gives you a network-layer choke point; identity still comes from IAM and tool-side authorisation. Use it as the outermost ring, not as the answer.
Example
// VPC endpoint policy on the com.amazonaws.eu-west-1.bedrock-runtime endpoint.
// Only approved models, only from this organisation, guardrail always attached.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ApprovedModelsOnly",
"Effect": "Allow",
"Principal": "*",
"Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
"Resource": [
"arn:aws:bedrock:eu-west-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0",
"arn:aws:bedrock:eu-west-1:111122223333:inference-profile/eu.anthropic.claude-3-5-sonnet-20241022-v2:0"
],
"Condition": {
"StringEquals": { "aws:PrincipalOrgID": "o-abc123def4" }
}
},
{
"Sid": "DenyInvokeWithoutGuardrail",
"Effect": "Deny",
"Principal": "*",
// Converse/ConverseStream are authorised as InvokeModel /
// InvokeModelWithResponseStream - deny BOTH, or the streaming path
// becomes a way to call the model with no guardrail attached.
"Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
"Resource": "*",
"Condition": {
"Null": { "bedrock:GuardrailIdentifier": "true" }
}
}
]
}
// Terraform-style sketch of the endpoint itself:
// resource "aws_vpc_endpoint" "bedrock_runtime" {
// service_name = "com.amazonaws.eu-west-1.bedrock-runtime"
// vpc_endpoint_type = "Interface"
// private_dns_enabled = true // no SDK changes needed
// subnet_ids = var.private_subnet_ids
// security_group_ids = [aws_security_group.https_only.id]
// policy = file("endpoint-policy.json")
// }When to use it
- A bank runs its agent's Lambda functions in private subnets with Bedrock interface endpoints and no NAT gateway, so there is no route out for exfiltrated data.
- A platform team uses an endpoint policy to deny any InvokeModel call that does not carry a guardrail identifier.
- An EU customer contract requires processing within the EU, so the team selects an EU inference profile and encrypts model invocation logs with a customer-managed KMS key.
Discussion