Connect AI Agents Across AWS, GCP & Azure Without a VPN

The Multi-Cloud Networking Nightmare

Consider a concrete scenario. Your organization runs agents in three clouds:

• AWS us-east-1: Research agents with access to internal databases
• GCP europe-west1: Analysis agents near European data sources (GDPR residency)
• Azure eastus2: Customer-facing agents integrated with Microsoft 365

To connect these with VPN, you need:

• AWS-to-GCP VPN tunnel (2 tunnel endpoints)
• AWS-to-Azure VPN tunnel (2 tunnel endpoints)
• GCP-to-Azure VPN tunnel (2 tunnel endpoints)

That is 6 tunnel endpoints for 3 clouds. Add a fourth cloud or on-premises location, and you need 12 endpoints. This is the combinatorial explosion problem: the number of VPN tunnels grows as N*(N-1)/2 where N is the number of sites. "When managing hundreds of applications, you are quickly talking about managing hundreds of VPN tunnels."

VPN throughput limitations

VPN gateways have throughput limits that are often lower than you expect. Industry reports note that organizations are "very much limited by the throughput of the various VPNs -- around 300 Mbps." AWS VPN connections support up to 1.25 Gbps per tunnel, but real-world throughput is often lower due to encryption overhead, MTU limitations, and the single-threaded nature of IPsec processing on many gateway implementations.

For bulk data transfer between agents (model weights, datasets, training outputs), VPN throughput becomes a bottleneck. For control-plane traffic (task delegation, status updates, coordination), the throughput is sufficient but the operational cost of maintaining VPN infrastructure for lightweight agent communication is disproportionate.

The skills and cost gap

Multi-cloud networking requires expertise in each cloud provider's networking model. AWS networking (VPCs, subnets, security groups, NACLs, route tables, transit gateways) is different from GCP networking (VPC networks, subnets, firewall rules, Cloud Router, Cloud NAT) is different from Azure networking (VNets, subnets, NSGs, route tables, Virtual WAN). A survey of cloud professionals found that 93% expressed concern about cloud security skills shortage.

The cost is equally problematic. "The costs for multi-cloud are enormous -- support and operation cost easily more than doubles." VPN gateway hours, data transfer between regions, cross-cloud egress fees, and the engineering time to manage it all add up quickly. For agent communication that might transfer megabytes per day, you are paying for gigabit-class infrastructure.

Why VPNs Do Not Scale for Agent Communication

VPNs solve the wrong problem for AI agents. VPNs provide network-level connectivity: they make two remote networks appear as if they are on the same LAN. This is useful for applications that need to access databases, file shares, and services using IP addresses and ports. It is overkill for agents that need to exchange messages, delegate tasks, and stream events.

The mismatch shows up in several ways:

• All-or-nothing access: A VPN connects networks, not applications. Once the tunnel is up, any application on one network can reach any application on the other. This violates the principle of least privilege. Agent A needs to talk to Agent B, but the VPN gives Agent A access to everything on Agent B's network.
• Static configuration: VPN tunnels are configured with static endpoints. Agents are dynamic -- they spin up, move between machines, and shut down. Reconfiguring VPN routes every time an agent moves defeats the purpose of automation.
• No identity layer: VPNs authenticate at the network level (certificates, pre-shared keys), not at the application level. There is no concept of "Agent A trusts Agent B but not Agent C" at the VPN layer. You need a separate identity and access management system on top.
• Operational burden: VPN tunnels need monitoring, certificate rotation, failover configuration, and capacity planning. Each tunnel is a potential point of failure. For agent communication where reliability matters, the VPN infrastructure becomes the weakest link.

Virtual Addresses: One Identity Regardless of Cloud

Pilot Protocol assigns each agent a 48-bit virtual address in the format N:NNNN.HHHH.LLLL. This address has two components: a 16-bit network ID and a 32-bit node ID. The registry assigns the address when the agent first registers and binds it to the agent's Ed25519 key, so it remains stable for the agent's lifetime, regardless of where it runs.

An agent on AWS us-east-1 might have address 0:0000.0000.0017. If you migrate that agent (with its identity file) to GCP europe-west1, its address stays 0:0000.0000.0017. Other agents continue to reach it at the same address. The Pilot daemon handles re-registration with the registry when the physical endpoint changes, and peers automatically reconnect to the new location.

# Agent identity is portable across clouds

  AWS us-east-1            GCP europe-west1          Azure eastus2
  +------------------+    +------------------+      +------------------+
  | Agent: research  |    | Agent: analysis  |      | Agent: customer  |
  | 0:0000.0000.0017 |    | 0:0000.0000.0042 |      | 0:0000.0000.0063 |
  | IP: 10.0.1.15    |    | IP: 10.128.0.5   |      | IP: 10.1.0.8     |
  +------------------+    +------------------+      +------------------+
          |                        |                         |
          +------------------------+-------------------------+
                        Pilot overlay network
                    (same virtual address space)
                    (direct encrypted tunnels)

The physical IP addresses (10.0.1.15, 10.128.0.5, 10.1.0.8) are cloud-specific and can change. The Pilot addresses are stable. Your application code references Pilot addresses, not IP addresses. This decouples agent identity from infrastructure, which is exactly what you need for multi-cloud deployment.

Example: Agent on AWS Talks to Agent on GCP

Here is a complete walkthrough. We will deploy one agent on an AWS EC2 instance in us-east-1 and another on a GCP Compute Engine instance in europe-west1, and have them communicate.

Step 1: Start agent on AWS

# On AWS EC2 instance (us-east-1)
curl -fsSL https://pilotprotocol.network/install.sh | sh

# Start daemon and set identity
pilotctl daemon start --email research@company.com
pilotctl set-hostname research-aws
pilotctl set-public
pilotctl extras set-tags aws us-east-1 research  # up to 3 labels, a-z 0-9 -

Step 2: Start agent on GCP

# On GCP Compute Engine instance (europe-west1)
curl -fsSL https://pilotprotocol.network/install.sh | sh

# Start daemon and set identity
pilotctl daemon start --email analysis@company.com
pilotctl set-hostname analysis-gcp
pilotctl set-public
pilotctl extras set-tags gcp europe-west1 analysis

Step 3: Establish trust and communicate

# From AWS agent: discover and trust GCP agent
pilotctl find analysis-gcp
# Address:   0:0000.0000.0042

pilotctl handshake 0:0000.0000.0042 "Cross-cloud research collaboration"

# From GCP agent: approve trust
pilotctl approve 0:0000.0000.0017

# Communicate: send a message
pilotctl send-message 0:0000.0000.0042 --data "Run sentiment analysis on Q1 customer feedback"

# Send a file
pilotctl send-file 0:0000.0000.0042 dataset.csv

# Benchmark the connection
pilotctl bench 0:0000.0000.0042

That is the complete setup. One install command per agent, a daemon start on each, one trust handshake, and the agents are communicating across clouds with end-to-end encryption. No VPN tunnels. No cloud interconnect products. No inbound firewall rules: the daemon needs outbound TCP 9000 to the registry and UDP to the beacon and its peers, or only outbound TCP 443 in compat mode.

NAT Traversal Handles the Networking Automatically

The example above used VMs with public IPs and set-public. For cloud VMs with a known public IP you can also pass the daemon's --endpoint flag to register a fixed endpoint and skip STUN. But many cloud deployments use private-only VMs (no public IP) behind Cloud NAT or similar services. Pilot handles this automatically.

When an agent starts without the --endpoint flag, the daemon performs STUN discovery to determine its public-facing IP and port. It doesn't classify the NAT type: for each peer it tries a direct connection, then hole punching coordinated by the beacon, then the relay. Which one ends up carrying the traffic depends on the NATs on both sides:

Cloud NAT services (AWS NAT Gateway, GCP Cloud NAT, Azure NAT Gateway) typically implement Port-Restricted Cone or Symmetric NAT. Between two agents behind different cloud NATs, Pilot attempts hole-punching first. If hole-punching fails (Symmetric NAT on both sides), it falls back to relay through the beacon. The fallback is automatic -- your application code does not change. For a deeper look at how NAT traversal works across different network configurations, see NAT traversal for AI agents: a technical deep dive.

# Agent behind AWS NAT Gateway (no public IP)
pilotctl daemon start --email agent@company.com
# STUN discovery handles NAT automatically

# Agent behind GCP Cloud NAT (no public IP)
pilotctl daemon start --email agent@company.com
# Same: automatic hole-punching or relay

Performance: Direct Tunnels vs VPN Overhead

Pilot's UDP tunnels introduce less overhead than VPN tunnels for agent communication patterns. Here is why.

A VPN tunnel encapsulates IP packets inside encrypted IP packets. Each packet gets an outer IP header (20 bytes), a UDP or ESP header (8-24 bytes), and encryption overhead (16-32 bytes for AES-GCM). This reduces the effective MTU and can cause fragmentation, especially for larger payloads. VPN gateways also introduce an extra network hop, adding latency.

Pilot tunnels carry application data directly in UDP packets: a 34-byte Pilot header, encrypted with AES-256-GCM inside a 36-byte frame (4-byte magic, 4-byte sender ID, 12-byte nonce, 16-byte auth tag). There is no IP-in-IP encapsulation because Pilot is an overlay network, not a VPN -- it does not route arbitrary IP traffic, only agent communication, so there is no inner IP or TCP header either. Stream segments can be up to 4 KB, so on a 1500-byte link a full segment is fragmented at the IP layer.

Side by side:

The advantage is not per-packet overhead (Pilot's framing is larger than WireGuard's). It is the elimination of the gateway hop and the zero-configuration NAT traversal. With VPN, traffic routes through gateway VMs that become bottlenecks. With Pilot, traffic flows directly between agent VMs over peer-to-peer tunnels. See a detailed comparison of Pilot vs Tailscale vs Nebula vs ZeroTier for more context on how these approaches differ for agent workloads.

Comparison: Pilot vs Tailscale vs ZeroTier vs Site-to-Site VPN

Tailscale and ZeroTier are excellent products for connecting devices and services across networks. They solve the connectivity problem well. But they are general-purpose network tools, not agent communication platforms. They provide a tunnel -- you still need to build agent naming, trust management, messaging and event streaming on top.

Pilot provides these as built-in services on well-known ports. An agent on Pilot can resolve peers by hostname, establish trust with justifications, stream events (port 1002), and exchange messages and files (port 1001) -- all without additional infrastructure. The networking is just the foundation.

Cost Comparison

The cost difference for multi-cloud agent communication is significant:

With site-to-site VPN you pay for every tunnel-hour before data transfer, and the tunnel count grows as N*(N-1)/2: 3 tunnels for 3 clouds, 10 for 5, 45 for 10 sites. And each tunnel requires configuration, monitoring, and maintenance.

Pilot does not require a site-to-site VPN or cloud interconnect. Default UDP mode needs outbound TCP 9000 to the registry and UDP to the beacon and peers; compat mode uses outbound TCP/443 for supported environments that block UDP. Adding a new cloud still requires installing the daemon, establishing trust with the peers it needs, and applying the appropriate egress policy.

Scaling Beyond Three Clouds

The real advantage of Pilot for multi-cloud appears as you scale. Adding agents does not require new tunnels or configuration changes. Each new agent:

1. Installs pilotctl
2. Starts the daemon
3. Establishes trust with the specific peers it needs to communicate with

# Add a new agent on Azure (or any cloud, or on-premises, or a laptop)
curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl daemon start --email agent@company.com
pilotctl set-hostname new-agent-azure
pilotctl extras set-tags azure eastus2 customer-support

# Resolve the peers it needs by hostname
pilotctl find research-aws
# Address:   0:0000.0000.0017

# Establish trust with specific agents (not entire networks)
pilotctl handshake 0:0000.0000.0017 "Cross-cloud task delegation"

There are no site-to-site VPN tunnels or cloud routing tables to add. The agent registers, resolves its peers, and establishes an encrypted tunnel using a direct path when available or ciphertext relay fallback otherwise. Operators still need to allow the selected transport and apply environment-specific identity and network policy.

The overlay keeps the agent-facing addressing and trust workflow consistent across supported environments. Cross-organization deployments can use the same transport model, but they still require security, privacy, governance, and contractual review appropriate to the data and parties involved.

Getting Started

Deploy agents across any combination of clouds:

# 1. Install on each agent (any cloud, any location)
curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl daemon start --email agent@company.com --hostname <name> --public

# 2. Agents resolve each other, establish trust and communicate
pilotctl find analysis-gcp
pilotctl handshake <peer-address> "Multi-cloud collaboration"
pilotctl send-message <peer-address> --data "Task: analyze Q1 data"

No VPN. No cloud interconnect. No per-cloud networking configuration. One overlay network that spans all of them.