Agentic Data Plane

Peer a VPC with an Environment

Peer a virtual private cloud (VPC) that you own with a private Agentic Data Plane environment. Self-managed agents, test harnesses, and applications that you run in your VPC can then reach the environment’s AI Gateway and API, without a VPN. Agents and MCP servers in the environment can reach services in your VPC, such as a database. Traffic between the two VPCs uses private IPv4 addresses.

After reading this page, you will be able to:

  • Peer a VPC you own with a private environment on AWS or Google Cloud

  • Configure routes so traffic flows in both directions

  • Verify a peering and run self-managed agents and test harnesses in your VPC against the environment

Prerequisites

  • An environment with Private access that shows Ready. To create one, see Create an Agentic Data Plane Environment.

  • Credentials for the cloud account or project where you deployed the environment, and for the one that owns your VPC.

  • To use the Terraform examples, Terraform 1.5 or later with the AWS provider or the Google Cloud provider.

  • A VPC that meets your cloud’s requirements:

    Requirement AWS Google Cloud

    Region

    Your VPC is in the environment’s region.

    Your clients run in the environment’s region, because the endpoints use a regional internal load balancer.

    Address ranges

    Your VPC’s IPv4 address range (CIDR block) doesn’t overlap the environment’s CIDR block.

    Your VPC’s subnet ranges don’t overlap the environment’s CIDR block. The environment’s subnet, pod, and service ranges are all inside its CIDR block.

    Client source addresses

    Your clients use addresses in 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 100.64.0.0/10. The endpoints accept connections only from these ranges.

    No restriction. You don’t need a firewall rule for clients to reach the endpoints.

How peering connects your VPC

Diagram of a customer VPC peered with a private Agentic Data Plane environment VPC, showing that public DNS resolves the AI Gateway hostname to the internal load balancer’s private address, HTTPS from self-managed agents and test harnesses in your VPC to that load balancer, agent and MCP server calls to services in your VPC, and no transitive routing from another peered VPC.
Figure 1. A VPC you own, peered with a private environment’s VPC (example address ranges)

An environment with Private access serves its AI Gateway and API endpoints from an internal load balancer in the environment’s VPC. The endpoint hostnames are in public DNS and resolve to the load balancer’s private address, so clients in a peered VPC need no DNS configuration. Requests use HTTPS on TCP port 443.

You create and manage the peering in your own cloud accounts. Redpanda Cloud doesn’t create, track, or remove it. On AWS, you add routes in both VPCs. On Google Cloud, the two VPCs exchange subnet routes once the peerings on both sides are active.

Peering connects exactly two VPCs and isn’t transitive. A VPC that is peered with yours can’t reach the environment through your VPC. To give people access from their computers or from an office network, connect them to the environment’s VPC through a VPN instead. See Connect to a Private Environment from Your Computer.

Find the environment’s network details

  1. In the Redpanda Cloud UI, open the environment’s detail page.

  2. In the Networking section, note the environment’s VPC and CIDR. In the Endpoints section, note the AI Gateway URL.

  3. Click Set up VPC peering. The VPC peering page shows the environment’s VPC name, region, and CIDR block, and the CLI commands in Create the peering with those values filled in.

The commands on this page use these placeholders for the environment’s values:

Placeholder Value

<network-id>

The environment’s Redpanda network ID. It’s the part of the VPC name after network- or redpanda-. On AWS, the environment’s VPC carries the Name tag network-<network-id>. On Google Cloud, the environment’s VPC is the network redpanda-<network-id>.

<region>

The environment’s region.

<environment-cidr>

The environment’s CIDR.

<ai-gateway-url>

The environment’s AI Gateway URL.

<environment-project-id>

Google Cloud only. The project you deployed the environment into.

Create the peering

Create the peering with the AWS CLI or the gcloud CLI, or declare it in Terraform. Each cloud’s section has a tab for each method. The Terraform examples look up the environment’s VPC by its tag or name, so they need only a few of the environment’s values: its network ID, plus its CIDR block on AWS or its project ID on Google Cloud.

This configuration refers to a third-party product. Specific UI elements may not be up to date. For current syntax, see the vendor documentation linked in each tab.

AWS

  • AWS CLI

  • Terraform

Run these commands with the AWS CLI, signed in to the accounts that each step names.

  1. Request a peering connection from the environment’s VPC to your VPC. Use credentials for the AWS account you deployed the environment into.

    ENV_VPC_ID=$(aws ec2 describe-vpcs --region <region> \
  --filters "Name=tag:Name,Values=network-<network-id>" \
  --query 'Vpcs[0].VpcId' --output text)
aws ec2 create-vpc-peering-connection --region <region> \
  --vpc-id "$ENV_VPC_ID" \
  --peer-vpc-id <peer-vpc-id> \
  --query 'VpcPeeringConnection.VpcPeeringConnectionId' --output text

    Replace <peer-vpc-id> with the ID of the VPC to peer with. If your VPC is in another AWS account, add --peer-owner-id <peer-account-id>, where <peer-account-id> is the ID of the AWS account that owns your VPC.

    The command prints the peering connection ID, which has a pcx- prefix. You use it as <peering-connection-id> in the next steps.

  2. Accept the request. Use credentials for the account that owns your VPC.

    aws ec2 accept-vpc-peering-connection --region <region> \
  --vpc-peering-connection-id <peering-connection-id>

  3. Add a route to your VPC in each private route table of the environment’s VPC. Use credentials for the AWS account you deployed the environment into.

    for route_table_id in $(aws ec2 describe-route-tables --region <region> \
    --filters "Name=tag:Name,Values=network-<network-id>" "Name=tag:purpose,Values=private" \
    --query 'RouteTables[].RouteTableId' --output text); do
  aws ec2 create-route --region <region> \
    --route-table-id "$route_table_id" \
    --destination-cidr-block <peer-vpc-cidr> \
    --vpc-peering-connection-id <peering-connection-id>
done

    Replace <peer-vpc-cidr> with your VPC’s CIDR block. The environment has one private route table for each of its private subnets. These routes carry the environment’s responses, and the calls that its agents and MCP servers make to your VPC.

  4. Add a route to the environment in each route table of the subnets that your clients run in. Use credentials for the account that owns your VPC.

    aws ec2 create-route --region <region> \
  --route-table-id <client-route-table-id> \
  --destination-cidr-block <environment-cidr> \
  --vpc-peering-connection-id <peering-connection-id>

    Replace <client-route-table-id> with the ID of one of those route tables. Run the command once for each route table.

For more about peering connections, see the AWS VPC peering documentation.

This example assumes that your VPC is in the same AWS account and region as the environment, so the same apply accepts the peering connection. For a VPC in another account, set peer_owner_id on the connection and remove auto_accept. Then accept the connection in the other account with an aws_vpc_peering_connection_accepter resource.

variable "network_id" {
  description = "The environment's Redpanda network ID."
  type        = string
}

variable "environment_cidr" {
  description = "The environment's CIDR block."
  type        = string
}

variable "peer_vpc_id" {
  description = "The VPC to peer with the environment."
  type        = string
}

variable "peer_route_table_ids" {
  description = "Route tables of the subnets your clients run in."
  type        = list(string)
}

data "aws_vpc" "environment" {
  tags = { Name = "network-${var.network_id}" }
}

data "aws_route_tables" "environment_private" {
  vpc_id = data.aws_vpc.environment.id
  tags   = { purpose = "private" }
}

data "aws_vpc" "peer" {
  id = var.peer_vpc_id
}

resource "aws_vpc_peering_connection" "environment" {
  vpc_id      = data.aws_vpc.environment.id
  peer_vpc_id = data.aws_vpc.peer.id
  auto_accept = true
}

# Environment side: each private route table routes to your VPC.
resource "aws_route" "environment_to_peer" {
  for_each                  = toset(data.aws_route_tables.environment_private.ids)
  route_table_id            = each.value
  destination_cidr_block    = data.aws_vpc.peer.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.environment.id
}

# Your side: each client route table routes to the environment.
resource "aws_route" "peer_to_environment" {
  count                     = length(var.peer_route_table_ids)
  route_table_id            = var.peer_route_table_ids[count.index]
  destination_cidr_block    = var.environment_cidr
  vpc_peering_connection_id = aws_vpc_peering_connection.environment.id
}

For resource arguments, see aws_vpc_peering_connection and aws_route.

Set the variables, then run terraform init and terraform apply.

Google Cloud

  • gcloud CLI

  • Terraform

Run these commands with the gcloud CLI, signed in to the projects that each step names.

  1. Create a peering from your VPC to the environment’s VPC. Use credentials for your VPC’s project.

    gcloud compute networks peerings create <peering-name> \
  --project=<peer-project-id> \
  --network=<peer-vpc-name> \
  --peer-project=<environment-project-id> \
  --peer-network=redpanda-<network-id>

    Replace <peering-name> with a name for this peering, and <peer-project-id> and <peer-vpc-name> with your VPC’s project and network name. The peering shows INACTIVE until you create the second one.

  2. Create the reverse peering from the environment’s VPC to your VPC. Use credentials for the project you deployed the environment into.

    gcloud compute networks peerings create <environment-peering-name> \
  --project=<environment-project-id> \
  --network=redpanda-<network-id> \
  --peer-project=<peer-project-id> \
  --peer-network=<peer-vpc-name>

    Replace <environment-peering-name> with a name for this peering.

  3. Confirm that both peerings show ACTIVE. Google Cloud exchanges the subnet routes after both are active.

    gcloud compute networks describe <peer-vpc-name> \
  --project=<peer-project-id> \
  --flatten=peerings --format="table(peerings.name,peerings.state)"
gcloud compute networks describe redpanda-<network-id> \
  --project=<environment-project-id> \
  --flatten=peerings --format="table(peerings.name,peerings.state)"

For more about peering, see the Google Cloud VPC Network Peering documentation.

The second peering depends on the first, so Terraform creates them one at a time.

variable "network_id" {
  description = "The environment's Redpanda network ID."
  type        = string
}

variable "environment_project_id" {
  description = "The project you deployed the environment into."
  type        = string
}

variable "peer_network" {
  description = "Your VPC's self link, projects/<project-id>/global/networks/<name>."
  type        = string
}

data "google_compute_network" "environment" {
  name    = "redpanda-${var.network_id}"
  project = var.environment_project_id
}

resource "google_compute_network_peering" "peer_to_environment" {
  name         = "peer-to-environment"
  network      = var.peer_network
  peer_network = data.google_compute_network.environment.self_link
}

resource "google_compute_network_peering" "environment_to_peer" {
  name         = "environment-to-peer"
  network      = data.google_compute_network.environment.self_link
  peer_network = var.peer_network
  depends_on   = [google_compute_network_peering.peer_to_environment]
}

For resource arguments, see google_compute_network_peering.

Set the variables, then run terraform init and terraform apply.

Verify the connection

From a machine in your VPC, send a request to the environment’s AI Gateway:

curl -sS --connect-timeout 5 -o /dev/null -w '%{http_code}\n' <ai-gateway-url>

Any HTTP status code means the network path works. A timeout means traffic doesn’t reach the environment.

To peer another VPC, repeat these steps for it.

Run agents and harnesses in your VPC

Once the peering is active, workloads in your VPC call the environment the same way they would call a public environment. This includes self-managed agents, test harnesses, CI jobs, and applications. They don’t need a VPN, because they run on the peered network.

  • Use the environment’s endpoints unchanged: the AI Gateway URL, LLM provider proxy URLs, MCP server URLs, and A2A endpoints. Their hostnames resolve to the environment’s private addresses, so the requests cross the peering.

  • Authenticate the way you would anywhere else. A self-managed agent or a CI job uses OpenID Connect (OIDC) client credentials, and a long-running script can use an API key. The token endpoint is on AI Gateway itself, at <ai-gateway-url>/oauth/idp/token, so a workload in your VPC gets its tokens over the peering too. For details, see Connect Your App to AI Gateway and Set Up a Self-Managed Agent.

  • Workloads don’t need internet access to call the environment, because AI Gateway calls the LLM providers from inside the environment. A host that runs rpk ai does need outbound internet access, because rpk ai signs in through Redpanda Cloud.

  • Run the workloads in subnets that meet the requirements in Prerequisites. On AWS, their route tables route the environment’s CIDR block to the peering connection. On Google Cloud, they run in the environment’s region.

People who also need to reach the environment from their own computers, for ai.redpanda.com or rpk ai, connect through a VPN into the environment’s VPC. See Connect to a Private Environment from Your Computer.

Allow traffic from the environment to your services

For agents and MCP servers to reach a service in your VPC, such as a database, allow inbound traffic from the environment’s CIDR block to that service. On AWS, add the rule to the service’s security group. On Google Cloud, add a VPC firewall rule in your VPC.

Reach the environment from networks behind your VPC

Peering carries traffic between your VPC and the environment’s VPC. It isn’t the way to give an office network, or people on their own computers, access to the environment. Instead, connect them to the environment’s VPC directly through a VPN. Use AWS Client VPN on AWS, or Google Cloud Classic VPN on Google Cloud. See Connect to a Private Environment from Your Computer.

On AWS, peering also can’t carry traffic from networks behind your VPC. It doesn’t carry traffic that enters your VPC through a Site-to-Site VPN connection, AWS Direct Connect, or an internet gateway, or traffic from a VPC peered with yours. For the full list, see VPC peering limitations in the AWS documentation.

Remove a peering

Delete a peering when you no longer need it, and before you delete the environment.

  • On AWS, delete the peering connection:

    aws ec2 delete-vpc-peering-connection --region <region> \
  --vpc-peering-connection-id <peering-connection-id>

    The routes that used the connection stay in the route tables in the blackhole state. Delete them with aws ec2 delete-route.

  • On Google Cloud, delete both peerings:

    gcloud compute networks peerings delete <peering-name> \
  --project=<peer-project-id> --network=<peer-vpc-name>
gcloud compute networks peerings delete <environment-peering-name> \
  --project=<environment-project-id> --network=redpanda-<network-id>

If you created the peering with Terraform, run terraform destroy for that configuration instead.

Troubleshooting

Symptom Action

The Redpanda Cloud UI doesn’t show Set up VPC peering.

The option appears only for an environment with Private access that shows Ready. A Public environment’s endpoints are reachable from the internet, so it doesn’t need peering.

Requests from your VPC to the environment time out.

Check each of these:

  • The peering is active. On Google Cloud, both peerings show ACTIVE.

  • On AWS, routes exist in both directions. The environment’s private route tables route to your VPC’s CIDR block, and your clients' route tables route to the environment’s CIDR block.

  • On AWS, your clients use addresses in one of the accepted ranges.

  • On Google Cloud, your clients run in the environment’s region.

Requests from a network behind your VPC time out, but requests from inside your VPC work.

Connect that network to the environment’s VPC through a VPN instead of through your VPC. See Reach the environment from networks behind your VPC.

The environment’s hostname resolves, but to an address your network can’t reach.

This is expected outside the peered network, because the hostname always resolves to the private address. Some corporate DNS resolvers drop public answers that contain private addresses. If yours does, ask your network team to allow the environment’s hostnames.

Agents or MCP servers can’t reach a service in your VPC.

Allow inbound traffic from the environment’s CIDR block in the service’s security group (AWS) or your VPC’s firewall rules (Google Cloud).

Creating the peering fails because the ranges overlap.

Your VPC and the environment use overlapping address ranges. Peer a VPC with a range that doesn’t overlap the environment’s CIDR block.

Next steps