DigitalOcean’s private networking feature allows you to create a Virtual Private Cloud (VPC) within a datacenter, enabling your Droplets to communicate with each other without traversing the public internet. This is crucial for security, performance, and cost savings, as inter-Droplet traffic within a VPC is free and significantly faster.
Let’s see this in action. Imagine you have two Droplets, web-droplet-nyc3 and db-droplet-nyc3, both in the same NYC3 region.
First, create a VPC:
doctl compute vpc create "my-app-vpc" --region nyc3
This command creates a VPC named my-app-vpc in the nyc3 region. You’ll get back a JSON response with the VPC ID. Let’s say it’s a1b2c3d4-e5f6-7890-1234-567890abcdef.
Now, attach your existing Droplets to this VPC. If you’re creating new Droplets, you can specify the VPC during creation. For existing Droplets, you’ll use the update command.
First, find the Droplet IDs.
doctl compute droplet list --format ID,Name,Region
Suppose web-droplet-nyc3 has ID 12345678 and db-droplet-nyc3 has ID 87654321.
Attach them to the VPC:
doctl compute droplet update 12345678 --vpc-uuid a1b2c3d4-e5f6-7890-1234-567890abcdef
doctl compute droplet update 87654321 --vpc-uuid a1b2c3d4-e5f6-7890-1234-567890abcdef
Once attached, each Droplet will have a new private IP address assigned to it within the VPC’s subnet. You can see these IPs using:
doctl compute droplet get 12345678 --format ID,Name,PrivateIPv4
doctl compute droplet get 87654321 --format ID,Name,PrivateIPv4
You’ll notice a PrivateIPv4 field with an IP address like 10.10.0.5 or 10.10.0.6. These are the IPs within your VPC.
Now, you can configure your applications to use these private IP addresses for communication. For instance, in your web application’s configuration, instead of using the public IP of the database Droplet, you’d use its private IP.
# On web-droplet-nyc3, edit your database connection string
# From: DB_HOST=YOUR_DB_PUBLIC_IP
# To: DB_HOST=10.10.0.6 # Assuming this is the private IP of db-droplet-nyc3
You can then ssh into your web-droplet-nyc3 and ping the db-droplet-nyc3 using its private IP:
ping 10.10.0.6
This ping will succeed, demonstrating that the Droplets are communicating over the private network.
The core problem VPCs solve is the inherent insecurity and performance bottleneck of exposing all inter-service communication to the public internet. By default, Droplets in the same datacenter can often talk to each other using their public IPs, but this traffic is metered, slower, and vulnerable. VPCs create an isolated, high-speed, and free network segment exclusively for your Droplets within a specific datacenter. DigitalOcean manages the underlying network fabric, assigning RFC 1918 IP addresses (like 10.x.x.x) to your Droplets within the VPC’s subnet. This means you don’t need to configure complex routing or firewall rules for basic private communication; it’s enabled by default once Droplets are attached.
The most surprising true thing about DigitalOcean VPCs is that even though your Droplets are assigned private IPs, you can still access them over the public internet for management (like SSHing to the Droplet’s public IP) simultaneously with private communication happening on the 10.x.x.x interface. This dual-homed nature is handled transparently by the DigitalOcean network.
To enforce stricter isolation and ensure that certain Droplets can only communicate via private IPs, you’d typically leverage ufw (Uncomplicated Firewall) or iptables on the Droplets themselves. For example, to block all incoming traffic on port 22 (SSH) from any source except your management IP, you would run:
ufw allow from YOUR_MANAGEMENT_IP to any port 22
ufw deny 22
ufw enable
This configuration on your web-droplet-nyc3 would prevent any SSH access except from your specific management IP, while still allowing it to reach db-droplet-nyc3 on its private IP for database queries.
The next concept to explore is how to manage network traffic between VPCs in different regions or how to connect your VPC to external networks using VPNs.