CloudConnector -- Overview v1.0.0

CloudConnector joins a VPC in AWS to a VPC in Google Cloud at layer 3. Hosts on either side reach the other side by its private addresses, and every packet arrives carrying the address of the host that sent it: nothing is NATed and no address is handed over. It is one of the four modes of the relay that ships inside Cloud Spectra Gateway, and everything it runs -- relays, load balancers, the controller -- runs in your own cloud accounts.

What CloudConnector is

Each side of the pipe runs a fleet of relays -- ordinary instances in your account, behind that cloud's own load balancer. Every relay keeps an encrypted WireGuard tunnel to every relay on the far side, and a controller in your AWS account tells each relay which side it is on and who is on the other side. Your route tables send traffic for the far side's ranges to the local relays; the relays carry it across and deliver it to the destination host unchanged.

What that gives you:

• Private addressing across clouds. A service in AWS calls a database in Google Cloud at its private address, and the reverse.
• The real source on every packet. The far side's firewall rules, security groups and logs see the sending host's own address, so rules written per host or per subnet keep meaning what they say.
• No circuit to order. Traffic between the clouds crosses the internet inside WireGuard tunnels between your own relays.
• Capacity that follows the fleet. Each relay is sized as 3 Gbps of pipe; add relays on both sides and the pipe can carry more flows in parallel.

In Terraform and on the wire the mode is called cloud_connector.

CloudConnector or another mode?

The relay has four modes. They build different infrastructure, so the mode is always stated explicitly: an intent without one is refused at plan time rather than defaulted. All four are licensed the same way, per relay vCPU.

CloudConnector is the mode with relays at both ends and nothing installed on your workloads: hosts send ordinary IP packets to the other side's private addresses, and the routes you add carry them into the pipe.

How it works

flowchart LR
    subgraph AWS["AWS VPC"]
        direction TB
        HA["Workload
10.60.1.10"]
        EP["GWLB endpoint
(one per zone)"]
        RA["Relay fleet
Auto Scaling group per zone
behind a Gateway Load Balancer"]
        HA -->|"route: Google Cloud range"| EP
        EP --> RA
    end
    subgraph GCP["Google Cloud VPC"]
        direction TB
        RG["Relay fleet
regional managed instance group
behind an internal passthrough NLB"]
        HG["Workload with the client tag
10.70.1.20"]
        HG -->|"route: AWS range"| RG
    end
    RA <-->|"WireGuard bond
every relay to every far-side relay"| RG
    CTL["Controller
pipe config, relay registry, rosters"]
    CTL -.->|"register, read far-side roster"| RA
    CTL -.->|"register, read far-side roster"| RG
    style AWS fill:#eef2ff,stroke:#6366f1,color:#312e81
    style GCP fill:#ecfdf5,stroke:#10b981,color:#065f46
    style CTL fill:#fef3c7,stroke:#f59e0b,color:#92400e

Illustrative addresses. A packet from 10.60.1.10 reaches 10.70.1.20 still carrying 10.60.1.10 as its source.

The components

The path of a packet

1. A host sends to a private address on the far side. Your route delivers the packet to a local relay: on AWS a route-table entry whose target is the zone's GWLB endpoint, on Google Cloud a route for instances with the client tag whose next hop is the internal load balancer. The load balancers are used for ingress only.
2. The relay's eBPF datapath matches the packet -- source inside this side's ranges, destination inside the far side's -- clamps the TCP MSS to fit the tunnel, hashes the flow onto one member of its bond and sends it through that member's WireGuard tunnel to one far-side relay.
3. The far-side relay decrypts the packet and hands it straight to the destination host. There is no source NAT anywhere on this path; the destination sees the original sender.
4. Replies travel the same way in the other direction.

The bond

Each relay holds one WireGuard tunnel -- a bond member -- for every relay on the far side, up to 32. A flow is hashed on its addresses, protocol and ports, the same way in both directions, so every packet of one connection rides the same member and stays in order; different flows spread over the members in proportion to each far relay's capacity, which the controller derives from the relay's instance type. A far relay that stops registering leaves the roster after 90 seconds, and the bond is rebuilt without it.

Two consequences shape capacity planning: one conversation between two hosts enters the pipe through one relay, and the number of members on each relay is the number of relays on the far side -- so the pipe grows when both sides grow. See Sizing and scaling.

Registration and the controller

Every relay registers with the controller every 30 seconds, presenting its side's announce credential. The controller places the relay on the side that credential belongs to -- a relay cannot name its own side -- and each relay reads the far side's roster every 30 seconds: every far relay's endpoint, public key, advertised ranges and weight. A relay that stops registering drops out of the roster after 90 seconds. When the number of relays on the far side changes, a relay rebuilds its bond with a brief restart of its datapath.

If the controller cannot be reached, relays keep forwarding with the roster they already hold. After 300 seconds without a fresh roster they mark it stale and log a warning; they do not tear the pipe down on their own.

Encryption and keys

Relay-to-relay traffic is kernel WireGuard. Each relay generates its own key pair when it first boots and keeps the private key on the instance; only the public key goes to the controller, so no relay private key is ever in Terraform state. Relays also check in with the Cloud Spectra licence service every two minutes and fetch their signed datapath from it at boot; a relay that cannot confirm its licence for 48 hours parks and stops forwarding. Details are in the security model.

Supported clouds

Both ends run on amd64 or arm64; the architecture is one input and the instance types follow from it:

The AWS shapes are network-optimised; on Google Cloud, egress bandwidth scales with vCPU count, so raise the machine size for more. Both can be overridden (see the configuration reference).

Requirements

• An AWS account and a Google Cloud project with permission to create networking, compute and load-balancing resources (listed in the Quick Start). The Compute Engine API must be enabled in the project.
• A Cloud Spectra licence key. Both ends run under the same licence.
• Terraform 1.5 or later with the cloudspectra/gateway provider, plus the hashicorp/aws, hashicorp/google and hashicorp/random providers.
• Non-overlapping IPv4 ranges. Each side advertises the ranges reachable through it: IPv4 only, at most eight prefixes per side, no 0.0.0.0/0, and no overlap between the two sides.
• Reachable relays. Every relay needs outbound internet access (to the controller, to the far-side relays and to the Cloud Spectra licence service) and an address the far side can dial: an IPv6 global address or a public IPv4 address. The WireGuard port band, from UDP 28302 upwards, must be open between the two sides.
• Routes and firewall rules you control. On AWS you add routes to the route tables of your workload subnets; on Google Cloud you tag the VMs that should use the pipe. Because sources are preserved, each side's firewall rules must admit the other side's ranges.

Pricing

CloudConnector is licensed like every Cloud Spectra Gateway feature: per relay vCPU, metered hourly, on both ends of the pipe. Each relay instance bills max(1, min(vCPUs, 64) - 1) vCPUs -- the second vCPU of every instance is free.

For example, the smallest pipe -- one c5n.large relay (2 vCPUs, bills 1) and one n2-standard-4 relay (4 vCPUs, bills 3) -- bills 4 vCPUs. The controller is not licensed or metered. Your cloud providers bill the relay and controller instances, the load balancers and endpoints, Cloud NAT, and the data the pipe carries between the clouds as internet egress -- see Cost considerations. Current rates and lane details are on the pricing page.

Limits

The full list of known limitations is at the end of the FAQ.