> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Integrating Bedrock With VPC > Guide to privately integrating Amazon Bedrock with an AWS VPC using VPC interface endpoints (PrivateLink), covering architecture, provisioning steps, security, IAM, IP planning, and costs. 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. A slide titled "Solution: Use VPC Endpoints for Private Bedrock Access" showing a Virtual Private Cloud (VPC) icon linked by an arrow to an Amazon Bedrock icon. Below the diagram are benefit boxes listing communication with AWS, reduced exposure, and enhanced security. ## 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. VPC endpoints enable private network connectivity but do not replace IAM. You must still configure the correct IAM permissions for Bedrock APIs or model invocations. ## 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). A network diagram titled "Workflow: Access Bedrock Privately Without Using Public Internet" showing a Virtual Private Cloud with public and private subnets. The private subnet contains an ECS service and a VPC Endpoint for Bedrock that connects privately to the Bedrock service below. 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: | Endpoint type | Primary use case | Notes | | - | - | - | | Runtime / Inference | Invoking models for predictions | If you only call model endpoints, this is the primary endpoint you need. | | Control plane | Managing resources (create/modify resources, knowledge bases, guardrails) | Required for management operations beyond inference. | | Agent / Advanced features | Agent orchestration and specialized features | Some agent capabilities may expose separate endpoints. | 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. A split-screen slide with a dark left panel listing "Workflow: VPC Endpoint" steps in purple buttons. On the right is an AWS console screenshot showing the "Create endpoint" VPC Endpoint settings and a services list filtered for "bedrock." 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. A presentation slide titled "Workflow: VPC Endpoint" showing an AWS console screenshot for creating a VPC endpoint (selecting VPC, subnets and security groups). Purple callout boxes on the left list the steps: Select VPC, choose subnet(s) for endpoint access, and pick a security group. Interface endpoints consume private IP addresses and incur hourly and data-processing charges. Plan subnet capacity and budget for endpoint costs before provisioning multiple endpoints across AZs. ## 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)](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) * [Amazon Bedrock documentation](https://docs.aws.amazon.com/bedrock/) * [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) * [AWS IAM best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.