This article explains how to route traffic between Vultr VPCs. This feature is called VPC Peering.
A Vultr Virtual Private Cloud (VPC) is a private network that connects two or more cloud servers in the same Vultr location.
Here's an example scenario:
Alice is a Vultr customer that needs to replicate data between two web servers. She prefers to do this through a VPC for privacy and to reduce her bandwidth charges.
Alice also has two database servers with similar requirements, so she set up a second VPC for her database servers. She named her VPCs LAX1 and LAX2. Her network now looks like this:
VPCs are entirely private, even from each other. Neither of Alice's VPCs can see the other's traffic, so her web and database servers must connect over the public internet. This isn't ideal for privacy or bandwidth.
VPC peering routes traffic between two VPCs. You can establish VPC peering within the same account or between accounts.
Because both of Alice's VPCs are in the same location, she can use VPC peering to connect them like this:
Now her web servers can communicate with the databases privately without any risk of bandwidth overage charges.
Bob wants to connect his web servers to Alice's databases. They have different accounts, but they are both in Los Angeles.
They exchange their network information and create a VPC peering connection like this:
Vultr's VPC peering creates some exciting new capabilities. Now that we've demonstrated the high-level concepts, let's learn how it works.
The subnets in both VPCs must be compatible with RFC1918. The valid IP ranges are:
When you create a VPC peering connection, a requester initiates the connection request to an accepter, who approves or denies the request. When you set up a VPC peering within the same account, you are the accepter and the requester.
Here's how Alice creates the connection between LAX1 and LAX2, step-by-step.
She enters the VPC connection request by filling out this form.
Alice clicks Request Connection to start the process, which puts the VPC peering connection in Pending status.
Alice clicks the edit icon to view the request. It looks like a pencil. Because Alice is both the requester and the accepter, she sees both sides of the request.
If Alice decides to cancel the request, she can click either Cancel Request or Deny. In this case, they both mean the same thing.
Because Alice wants to proceed, she clicks Accept, and the connection begins provisioning. In a couple of minutes the status changes to Active, and the process is complete.
When Alice wants to end the peering connection, she navigates back to the connection page and clicks Close this Connection.
To create a VPC peering connection between accounts, the requester account initiates a request to the accepter account, who can approve or deny the request.
Here's how Alice and Bob create their VPC peering connection, step-by-step.
Bob enters the VPC connection request:
Bob clicks Request Connection, which puts the VPC peering connection in Pending status until Alice accepts the request.
While waiting for Alice to accept, Bob has the option to cancel the request.
Alice can Accept or Deny the request.
Alice clicks Accept, and the connection begins provisioning. In a couple of minutes the status changes to Active, and the process is complete.
Either Alice or Bob can end VPC peering by clicking Close this Connection.
If your operating system uses the latest cloud-init, you do not need any manual configuration when attaching a server to your VPC. Vultr pre-loads the newest version of cloud-init for these operating systems:
If you use a different operating system, you must add a persistent route that forwards your subnet's traffic to the VPC's gateway.
The VPC gateway is always the
.1IP address of your VPC subnet.
For example, if your VPC's subnet is
10.10.10.0/20, then your gateway is
If you need to add routes manually, please see the documentation for your operating system. You may also find these articles helpful: