Answers to the questions engineers ask most about CloudConnector, followed by the known limitations of this release. For a guided deployment see the Quick Start; for every input and behaviour, the User Guide.
General
What is CloudConnector?
An L3 pipe between a VPC in AWS and a VPC in Google Cloud. A relay fleet runs in each cloud, in your own accounts; every relay keeps a WireGuard tunnel to every relay on the far side, and packets cross with their source address intact -- no NAT, no address transfer. It is one of the four modes of the relay in Cloud Spectra Gateway, named cloud_connector in Terraform. See the Overview.
Which clouds can it connect?
In 1.0.0, one end on AWS and the other on Google Cloud. Other cloud pairs are not supported in this release.
Do I install anything on my workloads?
No. Workloads send ordinary IP packets to the far side's private addresses. On AWS you add a route to the GWLB endpoint in each workload subnet's route table; on Google Cloud you give the VMs the pipe's client network tag. Both sides also need firewall rules that admit the other side's ranges. See Routing.
Does my traffic pass through Cloud Spectra?
No. The relays and the controller run in your accounts, and every tunnel ends at one of your relays. The relays do contact the Cloud Spectra service -- to check their licence every two minutes and to fetch their signed datapath at boot -- but your traffic never goes there.
How does it compare with a cloud interconnect?
There is no circuit to order, and capacity is added by adding relays. The trade-off is the path: traffic between the clouds crosses the internet inside WireGuard, and both clouds bill it as internet egress. Where a private interconnect with cheaper transfer already exists, compare the costs for your volume.
Traffic and routing
Is the source address really preserved?
Yes. Neither relay translates anything: the packet that reaches the destination carries the sending host's own private address. That is why the far side's security groups and firewall rules must explicitly admit the near side's ranges -- and why they can be as specific as you like.
Which ranges can each side advertise?
IPv4 ranges only, at most eight per side, never 0.0.0.0/0, with no overlap between the two sides, and none overlapping 169.254.0.0/16 or containing 168.63.129.16. A relay deployed with ranges that break these rules refuses to start and says why in its log.
Can IPv6 traffic cross the pipe?
No. The pipe carries IPv4 between the two sides' ranges. The tunnels between relays can themselves run over IPv6 -- Google Cloud relays use external IPv6 addresses by default -- but the traffic inside them is IPv4.
Does the pipe change my packets?
Only in three ways, none of which touches addresses or ports. TCP connections have their MSS clamped to 1340 so that segments fit the 1380-byte tunnel. A packet too large for the tunnel with "don't fragment" set is answered with an ICMP "fragmentation needed" message from the relay, so allow ICMP from the relays to your hosts. And packets leave the pipe with a TTL of at most 16, which stops a routing loop quickly.
Can workloads on either side open connections?
Connections opened from AWS to Google Cloud are the direction Cloud Spectra's live tests carry. On the AWS end the Gateway Load Balancer handles only traffic entering the pipe, and replies from AWS hosts to connections opened from Google Cloud would re-enter through a load balancer that never saw the connection start -- which a Gateway Load Balancer does not forward. Validate connections opened from the Google Cloud side before relying on them. See Which side opens connections.
Why must the relays' own subnets not route into the pipe?
Because the relays are what the route delivers to. On AWS, the relay subnets' route table must not send the far side's ranges to the GWLB endpoint; on Google Cloud, the steering route is scoped to client tags and must never include the relays' tag. Otherwise a relay becomes the next hop for traffic it is forwarding, and the packet loops.
Capacity and scaling
How much throughput does a pipe have?
Each relay is sized as 3 Gbps of pipe, and target_gbps becomes ceil(target_gbps / 3) relays per end. That capacity is aggregate: different flows spread across all relays, but every flow between one pair of addresses enters the pipe through a single relay, so one bulk transfer between two hosts never gets more than one relay's throughput.
Does adding relays to one side help?
Very little on its own. Each relay bonds with every relay on the far side, so a side's bond width follows the other side's relay count. Grow both sides together.
How quickly does the pipe follow a scale event?
The far side notices a new relay when it registers and drops a removed one when its 90-second registration lapses; each far relay then rebuilds its bond with a brief datapath restart. In Cloud Spectra's measurements the far side widened about 2.5 minutes after a relay was added and narrowed about 7 minutes after one was removed, with traffic flowing again within seconds of each rebuild.
Does the pipe autoscale?
Only if you turn it on. The relay groups carry no scaling policy of their own; the controller can resize the groups of one cloud, manually on request or automatically from the relays' load, and its scaling is off by default. See Scaling by the controller.
How many relays can a pipe have?
A relay bonds with at most 32 relays on the far side; beyond that, the highest-numbered far relays carry no traffic. The controller's registry holds up to 500 relays per fleet. In practice size each side to what tunnel_members -- the WireGuard port band, 2 to 32 -- covers.
Security
How is traffic between the clouds protected?
By WireGuard, between your own relays. Each relay generates its key pair on first boot and keeps the private key on the instance; the controller only ever sees and distributes public keys.
Are relay keys rotated?
Not automatically in this release. A relay keeps its key for its lifetime; a replacement instance generates a new one.
What ends up in Terraform state?
The licence key, because the relays receive it in their instance user data. In the evaluation root, also every fleet credential, which it generates. No relay private key is ever in state. Keep the state file encrypted and access-controlled.
Is the controller's API encrypted?
No. The controller serves plain HTTP on port 8080 at its Elastic IP, and the deployment roots configure no TLS certificate for it, so the bearer tokens relays and operators present cross the network unencrypted. Limit the controller's relay_cidrs to the addresses that need to reach it.
Billing and cost
How is CloudConnector billed?
Per relay vCPU, metered hourly, on both ends of the pipe. Each instance bills max(1, min(vCPUs, 64) - 1) vCPUs -- the second vCPU is free. The Developer lane is $10 and the Enterprise lane $30 per vCPU-month; see the pricing page.
Which lane do I need?
The Developer lane covers development, evaluation and personal use, and allows at most 16 raw vCPUs per account across all relays: relays beyond that are parked until room frees up. The Enterprise lane is for production use, with no account limit, but every relay instance needs at least 4 vCPUs -- so raise the AWS relay shape (aws_instance_type), whose defaults have 2 vCPUs or fewer.
Is the controller billed?
Not by Cloud Spectra: the controller is not licensed or metered. Your AWS bill carries its instance, its Elastic IP and its DynamoDB table.
What will my cloud providers charge?
The relay instances on both sides, the Gateway Load Balancer and its endpoints on AWS, the internal load balancer and any Cloud NAT on Google Cloud, the controller's resources -- and the data the pipe carries, which each cloud bills as internet egress as it leaves. For a busy pipe the egress usually dominates. See Cost considerations.
Does destroying the deployment cancel my subscription?
No. Destroying infrastructure and cancelling a subscription are separate acts; relays that no longer run simply stop accruing hours.
Operations
What happens if the controller goes down?
The pipe keeps carrying. The controller is not on the data path: relays keep forwarding with the roster they hold, mark it stale after 300 seconds, and never tear the pipe down on their own. What stops is following change -- a relay added or removed while the controller is away is not picked up until it returns. The controller runs as an Auto Scaling group of one with its state in DynamoDB, and a replacement takes over its Elastic IP.
What happens if a relay fails?
Its load balancer stops sending it new traffic and the cloud replaces it. On the far side, the bond member to the failed relay stays until its 90-second registration lapses and the bond is rebuilt; flows hashed onto that member are lost until then. An end with a single relay stops carrying until the replacement registers.
How do I know the pipe is healthy?
Ask the controller: GET /fleet/v1/pipe/status?fleet=<fleet-id> with the fleet's read token returns up, degraded, down or unknown, per-side relay counts, idle relays, and anything unplaced or stranded. Poll it from your monitoring: alerts -- logged, and POSTed to pipe_alert_webhook when set -- are evaluated when it is read. See Monitoring.
How are relays upgraded?
Relays run the software in their image, chosen by release. Changing it affects new instances only; replace running relays a few at a time to move them. With package_version set on the production pipe root, each relay installs that exact signed package at boot. See Upgrades.
Where are the logs?
On each relay, journalctl -u cloudspectra-relay; /run/cloudspectra/relay-facts.json records what the datapath was loaded with. The controller logs every pipe alert.
Known limitations
These hold for release 1.0.0.
| Area | Limitation |
|---|---|
| Clouds | One end on AWS and one on Google Cloud. No other pair, and no third side: a pipe has exactly two. |
| Address families | IPv4 ranges only, at most 8 per side, no 0.0.0.0/0, no overlap between the sides. |
| Per-conversation throughput | All flows between one pair of addresses enter the pipe through one relay; adding relays does not speed up a single host-to-host transfer. |
| Growth | A side's bond width follows the far side's relay count, so growing one side alone adds little. A relay bonds with at most 32 far relays, and the WireGuard port band (tunnel_members, 2-32) must cover the largest side. |
| Connection direction | Connections opened from Google Cloud to AWS hosts depend on the AWS Gateway Load Balancer forwarding replies to flows it did not see start, which it does not do. Validate this direction before relying on it. |
| Scale events | A change in the far side's relay count restarts each relay's datapath briefly. A failed relay's share of flows is lost on the far side until its registration lapses (90 seconds) and bonds are rebuilt. |
| Key rotation | Relay WireGuard keys are not rotated automatically. |
| Pipe configuration | Relays apply only the sides and their ranges from the stored configuration. Its bond, MTU, weight-policy, compression and timing fields are stored but not applied: bond width follows the far side, weights follow instance types, the tunnel MTU is 1380, and compression is set on the fleets. |
| Monitoring | Pipe health is a JSON endpoint on the controller; there is no dashboard view of the pipe, and the relay's own dashboard has none. Alerts are evaluated only when that endpoint is read. Per-relay packet-drop counters are not exposed. |
| Controller | Plain HTTP on port 8080, with no TLS configured by the deployment roots. A single active instance; it can scale the relay groups of one cloud only, and its scaling is off by default. |
| Group sizes | After the first apply, Terraform ignores the AWS groups' desired capacity and the Google Cloud group's target size; resizing is done on the groups or by the controller. |
| Zones | Each end starts in a single zone unless you list more. |
| Upgrades | Changing release does not replace running relays, and relays upgrade in place at boot only when package_version is set. |
| State | The licence key -- and, in the evaluation root, every fleet credential -- is stored in Terraform state. |
| Teardown | The controller protects its Elastic IP and DynamoDB table by default, and the protection cannot be lifted on a live deployment; destroying it takes the manual steps in the Quick Start. |
| Lanes | Developer: 16 raw vCPUs per account across all relays. Enterprise: at least 4 vCPUs per relay instance, which the default AWS relay shapes do not meet. |
| Cost | Traffic between the clouds crosses the internet and is billed as egress by both providers. |