Integrating Bedrock With VPC

In this lesson you’ll learn how to integrate Amazon Bedrock with a Virtual Private Cloud (VPC) so Bedrock access remains private and secure. The objective is to reach the Bedrock service without traversing public networks and to apply familiar VPC networking controls to that traffic. We’ll cover:

• The risks of traversing the public internet.
• How VPC endpoints (PrivateLink) enable private access to Bedrock.
• Implementation steps and operational considerations.
• What you achieve and recommended next steps.

Let’s get started.

​

Why avoid the public internet for Bedrock traffic

When your application sends requests over the public internet, traffic flows across untrusted networks, increasing attack surface and complicating network-layer protection. Workloads that must call Bedrock via the internet often require NAT gateways or public-subnet routing, which expands exposure and operational complexity. Most compute resources in an AWS account—EC2 instances, ECS tasks, Lambda functions with VPC access—are deployed inside a VPC, an isolated IP address range. If Bedrock is reachable as a private service inside that VPC, your application can call Bedrock without leaving the VPC, removing the need for internet gateways or NAT for those flows and improving security posture.

​

How VPC endpoints (AWS PrivateLink) provide private Bedrock access

VPC interface endpoints (PrivateLink) present Bedrock as a private service in your VPC. Under the hood, an interface endpoint provisions elastic network interfaces (ENIs) with private IP addresses in the subnets you select. Traffic is routed privately from your VPC to the Bedrock service without using the internet gateway. When you deploy an endpoint inside your VPC:

• Clients (EC2, ECS tasks, Lambda with VPC access) see the endpoint as a private peer and can connect directly.
• Standard VPC controls—security groups and subnet placement—govern who can reach Bedrock.
• API-level access still depends on IAM permissions; network reachability and IAM authorization are both required.

​

Typical VPC architecture and private access pattern

A common VPC design uses both public and private subnets. Public subnets have a route to an internet gateway and host internet-facing resources. Private subnets lack direct internet access and typically use NAT for outbound calls. If Bedrock is accessed over the internet, private workloads require NAT or a public subnet path—adding exposure. By placing a Bedrock interface endpoint in private subnets, private workloads can call Bedrock without a NAT or internet gateway. The endpoint gives a private path so tasks that never leave private subnets can still perform inference and control-plane actions (subject to security group and IAM policies). Important details for connectivity:

• Both the client’s security group (allowing outbound to the endpoint) and the endpoint’s security group (allowing inbound from the client) must permit traffic.
• The client’s IAM role or credentials must be authorized for the Bedrock actions it intends to perform.
• Endpoints consume private IP addresses in the subnets where ENIs are created.

​

Creating a VPC endpoint for Bedrock — console workflow

To provision a Bedrock interface endpoint:

1. In the AWS Management Console, open the VPC service and click Create endpoint.
2. Choose the endpoint type for an AWS service (Interface endpoint / PrivateLink).
3. Search for Bedrock-related service names. Bedrock exposes multiple service endpoints depending on features (runtime, control plane, agents). Select the service(s) your application requires.
4. Select the VPC, choose subnets (typically one per Availability Zone for resilience), and attach security groups to the endpoint.

Which endpoints you need depends on your usage: Be mindful of cost and IP consumption: each interface endpoint creates at least one ENI (one private IP) per subnet you attach, and AWS charges hourly and data-processing fees for interface endpoints. When choosing subnets and security groups:

• Select subnets that provide AZ redundancy (attach the endpoint to at least one subnet per AZ you care about).
• Plan IP addressing to account for ENIs and their private IP consumption.
• Use security groups to explicitly permit only the clients or CIDR ranges that should call Bedrock.

​

Summary — benefits and outcomes

Using VPC interface endpoints with Bedrock provides:

• Private, secure communication between VPC workloads and Amazon Bedrock without traversing the public internet.
• The ability to apply familiar VPC controls—security groups, subnet placement, AZ redundancy—to restrict and manage access to Bedrock.
• Reduced exposure for regulated or sensitive workloads by avoiding NAT or internet routing for model calls and control-plane actions.

Next recommended topics:

• Observability and monitoring for endpoint traffic and Bedrock usage (CloudWatch, VPC Flow Logs, endpoint metrics).
• IAM best practices for least-privilege Bedrock access.
• Planning IP addressing and costs for large-scale endpoint deployments.

​

Links and References

• AWS PrivateLink (VPC endpoints)
• Amazon Bedrock documentation
• VPC Flow Logs
• AWS IAM best practices