Your Cloud's Network,
Everywhere You Need It.
Four products on one relay that runs in your own cloud accounts: give a device your cloud's IP, put a whole team behind one, make compute in another cloud a member of your VPC, and route VPCs across clouds with their source addresses intact.
runs in your own cloud accounts
Your Laptop, Inside Your Cloud.
CloudAddress gives your laptop, desktop or phone a real, dedicated IP from your own cloud account. Reach private databases and services in your VPC by name, take inbound connections on a static address, and -- when you want to -- send everything out through your cloud.
Three Steps. One Address.
Create a relay in your account
One command -- or one terraform apply -- launches a relay in the cloud and region you choose. It is your instance, on your bill, in your VPC.
Connect a device with a token
Mint a short-lived token from the relay's dashboard. A laptop joins with one connect command; after that it reconnects with no token at all.
Connect and wear the address
The device now wears the relay's address. Your VPC, cloud DNS and private services ride the tunnel; everything else stays on your own connection.
# 1. a relay in your own account -- state lives in its cloud tags $ cloudspectra_relay_client create --provider aws --region us-east-1 --project acme --name edge # 2. wear its address -- the token comes from the relay's dashboard $ sudo cloudspectra_relay_client connect --project acme --name edge --token ‹token› # 3. later, from the same machine: no token, no dashboard, no cloud credentials $ sudo cloudspectra_relay_client connect --project acme --name edge $ cloudspectra_relay_client status
Everything Your Device Needs to Belong in the Cloud
A real public IP, from your account
Your device wears a dedicated public address from your own cloud account. Inbound connections reach it directly; with a full tunnel, everything leaves from it too.
A member of your VPC
On AWS, Azure, Google Cloud and Oracle Cloud your device wears the relay's private address, so private hosts in the VPC are a hop away. Peered VPCs on AWS, too.
Cloud DNS from your device
Internal names resolve through the cloud's own resolvers, scoped to the tunnel where the OS allows -- and your settings come back when you stop.
The relay's cloud identity
Your laptop reads the relay's instance metadata through the tunnel -- and, with a role attached to the relay, its cloud credentials -- instead of long-lived keys.
Split or full tunnel
Split by default: only your cloud's ranges ride the tunnel. Add --full-tunnel and your whole machine leaves the internet from your cloud.
Inbound on every port
Run a server on your laptop: every port on the worn address reaches your device, except the relay's own 28300-28349. The cloud firewall decides who gets in.
IPv4 and IPv6
Your device wears the relay's IPv6 address alongside the IPv4 one. Or reach an IPv6-only relay with no billed public IPv4 at all.
Share with client-less devices
Consoles, NAS boxes and cameras behind a machine that runs the client wear the cloud address too, with port forwards to reach them.
Phones by QR code
The relay's dashboard shows a QR code with a standard WireGuard configuration. Scan it with the WireGuard app -- there is no extra app to install.
Move your address
Hand the address to another machine with a fresh token and an explicit takeover. The same machine reconnects later with no token at all.
Addresses that stick
Destroying a relay keeps its address. Rebuild it and it comes back on the same public IP on AWS, Oracle Cloud, Azure and Google Cloud.
A cloud drive that follows you
Add a cloud disk and the relay serves it as a file share over the tunnel. It outlives the relay and follows the address to your next machine.
A Real Member of Your VPC -- From Anywhere
On AWS, Azure, Google Cloud and Oracle Cloud your device wears the relay's private address, and the cloud's one-to-one NAT brings the public IP with it. To the VPC, your laptop is one more host in the subnet.
- Reach private databases, clusters and internal APIs by address or by cloud DNS name
- Same-subnet instances answer through the relay; on AWS, so do tagged peered VPCs
- The default split tunnel follows your VPC's ranges as peering changes
Split by Default. Full When You Ask.
The default connect is a split tunnel: your VPC ranges, cloud DNS and cloud metadata go to the relay, and your video calls and downloads stay on your own connection. When you need the whole machine to leave from the cloud, ask for a full tunnel.
- No surprise reroute: split is the default, full is a flag
- A full tunnel makes the relay's public address your machine's egress
- Stop the client and your machine gets its own egress back
Scan a Code. Your Phone Wears the Cloud Address.
The relay's dashboard -- or the qr command -- shows a QR code holding a standard WireGuard configuration. Scan it with the WireGuard app; there is no Cloud Spectra app to install.
- A split tunnel by default, sized for mobile networks
- Ask for
--full-tunneland the phone sends everything through your cloud - Join tokens are single-use and expire in two minutes by default
Your Console, NAS and Camera Wear It Too
Consoles, NAS boxes, cameras and smart TVs cannot install anything. Point them at a Windows, macOS or Linux machine that runs CloudAddress, name them with --share-with, and they leave the internet as your cloud address too.
- Nothing is shared until you name a device
--forwardsends a port on the cloud address to a shared device- The relay sees one client; your LAN keeps its own addresses
Take Your Address With You
Move the address from the office desktop to the travel laptop and every allow-list follows, because the address is the same. The machine that gave it up is evicted; reconnecting it later needs a new token.
- Join tokens are single-use; minting a new one kills the old
- While a session is live, connect refuses unless you pass
--takeover disconnect --vacategives the address back whenever you are done
Stays Up Through a Working Week
What Teams Do With a Cloud Address
Private databases without a bastion
Engineers reach RDS, clusters and internal APIs from their laptops by private address and cloud DNS name.
One IP for every allow-list
With a full tunnel, partners and SaaS admin consoles allow-list one static cloud address -- not a list of home IPs.
Behind CGNAT? Host anyway
Run a server at home on a real public IP: inbound connections reach it on every port but the relay's own.
A cloud IP for the living room
Give a console, NAS or camera the cloud address, with a forwarded port that reaches it from anywhere.
Another Cloud's Compute, Inside Your VPC.
CloudVpc lets a machine in another cloud wear a private address from your VPC. The VPC's metadata service and your instance role work through the tunnel, so security groups, IAM and private endpoints treat it as a native member -- and only VPC traffic crosses clouds.
Your VPC Stays. The Compute Moves.
A relay per worker, in your VPC
Each relay is a small instance in your VPC. It holds one private address and the instance profile the worker will use -- strictly one worker per relay.
The worker wears that address
Over WireGuard, the worker in the other cloud takes the relay's private address, with routes for your VPC range and the metadata service only -- read from the VPC itself.
It works like a native member
Security groups, IAM and private endpoints see a VPC address. Workers in the same subnet talk to each other directly and fall back to the relays when they can't.
# one relay in your AWS VPC, one Oracle Cloud worker that wears its address $ terraform -chdir=cloudvpc/aws-oci-minimal apply # EKS nodes in Oracle Cloud that follow your relay Auto Scaling group $ terraform -chdir=cloudvpc/eks-oci-asg apply
Everything a Worker Needs to Belong
A private VPC address
The worker wears a relay's private IPv4 address, so the VPC sees a member, not a VPN client. One worker per relay, always.
Metadata and IAM, natively
The VPC's metadata service answers through the tunnel, so the worker uses your instance role instead of long-lived keys. In the Terraform examples, its containers can't reach the role.
Only VPC traffic crosses
Routes cover your VPC range and the metadata service, read from the VPC itself. A default route is refused; everything else stays local.
Direct worker-to-worker paths
Workers in the same subnet talk directly over GENEVE, spread across four source ports, and fall back to the relays when a path is missing.
Kubernetes nodes
An Oracle Cloud worker joins your EKS cluster as a Ready node, networked with Calico.
A fleet that follows your relays
With the Cloud Spectra controller in your account, Oracle Cloud workers launch and retire as your AWS relay group scales -- and a ceiling refuses runaway launches.
EKS Nodes on Another Cloud's GPUs
Add GPU nodes in Oracle Cloud to the EKS cluster you already run. They register as Ready nodes, wear addresses from your VPC, and talk to each other directly instead of hairpinning through AWS.
- Nodes join the cluster you have -- no second control plane
- Direct node-to-node and pod-to-pod paths, with the relays as the fallback
- Retire the nodes and the cluster is exactly as it was
What Teams Do With CloudVpc
GPUs where they're cheaper
Run inference or training on another cloud's GPUs while the VPC, IAM and data stay where they are.
Burst EKS into another cloud
Add Oracle Cloud nodes to the EKS cluster you already run.
Reversible migration
Move compute first and keep the network; destroy the workers to move back.
Keyless access off-cloud
Machines outside AWS use your instance role through the tunnel instead of stored keys.
One Cloud IP for the Whole Team.
A shared relay gives every device its own encrypted tunnel and its own tunnel address, and sends their internet traffic out through one public IP from your cloud account. Nothing on the internet can reach back in.
--full-tunnel. Proven live on AWS and Oracle Cloud with two devices; shared relays on Azure, Google Cloud and DigitalOcean are in preview. VPC peering by tag is available on AWS.One Relay. Every Device.
Create a shared relay
One command launches a relay in your account that serves many devices, instead of lending its address to one.
Each device joins with its own token
Every device gets its own tunnel address, and the relay accepts only that address from that device's key.
Send everything through it
Connect with --full-tunnel and the device's internet traffic leaves as the relay's public IP. Split tunnel stays the default.
# a relay that a whole team shares $ cloudspectra_relay_client create --provider aws --project acme --name team --shared-relay # on each device, with that device's own token from the dashboard $ sudo cloudspectra_relay_client connect --project acme --name team --token ‹token› --full-tunnel
Shared Egress, Without the Exposure
One egress IP for everyone
With --full-tunnel, every device's internet traffic leaves as the relay's public IP. Allow-list one address for the whole team.
A tunnel per device
Each device gets its own tunnel address, and the relay accepts only that address from that device's key -- no spoofing a neighbour.
Closed to inbound
Unsolicited traffic from the internet ends at the relay and is never forwarded to a device. Port forwarding is refused by design.
Translated per flow
The relay's eBPF datapath maps each TCP and UDP flow to its own address and port, and returns every reply to the device that opened it.
No per-seat licence
The licence sets no device limit. You pay per relay vCPU, not per person.
Your AWS VPCs, by tag
On AWS, the relay's Cloud VPN page peers the VPCs you tag and routes them, so devices reach private addresses without a Transit Gateway.
Your AWS VPCs, by Tag
Tag the VPCs that hold your databases and internal APIs. The relay builds the peerings, routes, prefix list and security group, and keeps them in sync -- turn it off and they are withdrawn.
- No Transit Gateway and no AWS Client VPN to run
- Pick VPCs by tag or from a list on the relay's dashboard
- Runs on an IAM role you attach to the relay, with only the access you grant
What Teams Do With CloudVpn
One IP on every allow-list
SaaS admin consoles, partner APIs and payment gateways allow-list the relay's address, not every home IP.
Safer on public Wi-Fi
Every device's traffic rides an encrypted tunnel to a relay you own.
Nothing to expose
Devices only make outbound connections; nothing on the internet can reach back to them.
Private AWS services
Tag the VPCs that hold your databases and internal APIs, and the team reaches them through the relay.
VPC to VPC, Across Clouds.
CloudConnector is a private, IP-level pipe between a VPC in one cloud and a VPC in another. Every packet keeps its original source address, there is no circuit to order, and capacity grows as you add relays to either side.
Two Relay Groups. One Pipe.
A relay group on each side
On AWS, an Auto Scaling group behind a Gateway Load Balancer; on Google Cloud, a managed instance group behind an internal load balancer.
Describe the pipe once
A Cloud Spectra controller in your account holds the pipe: the ranges each side advertises -- up to eight per side -- and which relays belong where.
Traffic routes, untranslated
Every relay links to every relay on the far side, and flows spread across those links in proportion to each relay's capacity. Nothing is translated on the way.
A Pipe That Grows With You
Source addresses intact
No NAT on the pipe. The far side sees the real source of every packet, so its security rules and logs stay meaningful.
Capacity that scales out
Add relays and aggregate bandwidth grows with them. One connection rides one relay; many hosts spread across all of them.
Re-meshes by itself
Resize either side -- by hand or by autoscaling -- and the far side widens or narrows its links on its own.
Autoscales with load
The controller grows the AWS relay group under load and shrinks it again when the load stops.
Keys never leave the relay
Every relay generates its own WireGuard identity. Private keys never appear in Terraform state.
Full-size packets
MSS clamping and fragmentation-needed replies keep large packets flowing across the pipe, at no measurable cost on the fast path.
Capacity Follows Your Fleet
Double the relays on both sides and the pipe carries nearly twice as much: 6.87 Gbps became 12.84 Gbps in one measured AWS-to-AWS run, and fell back to 6.92 Gbps when the groups shrank again.
- Every relay links to up to 32 relays on the far side
- Flows spread by each relay's capacity, read from its instance type
- Across four runs, doubling both sides gave 1.63x to 1.95x
What Teams Do With CloudConnector
Split stacks across clouds
Services in AWS call databases in Google Cloud by their private addresses.
No circuit to order
Connect VPCs where no interconnect exists, or before one is provisioned.
True sources for audits
The far side's firewall rules and logs see the real origin of every flow.
Bandwidth that follows demand
Scale relays with load instead of buying a fixed circuit size.
Wherever Your Accounts Already Are
| Product | AWS | Azure | Google Cloud | Oracle Cloud | DigitalOcean |
|---|---|---|---|---|---|
| CloudAddressa device wears a cloud IP | ✓ | ✓ | ✓ | ✓ | ✓ |
| CloudVpcanother cloud's compute in your VPC | ✓your VPC | — | ◐GKE | ✓compute | ◐compute |
| CloudVpna team behind one cloud IP | ✓+ VPC peering ✓ | ◐ | ◐ | ✓ | ◐ |
| CloudConnectorVPC to VPC across clouds | ✓ | ◐ | ✓ | ◐ | — |
- CloudAddress -- tagged VPCs can be peered to the relay on AWS; on DigitalOcean a rebuilt relay comes back on a new address.
- CloudVpc -- proven live with your VPC on AWS and compute on Oracle Cloud; Google Cloud (GKE) as the VPC and DigitalOcean as compute are in preview.
- CloudVpn -- proven live on AWS and Oracle Cloud with two devices; Azure, Google Cloud and DigitalOcean are in preview; VPC peering by tag is available on AWS.
- CloudConnector -- proven live between AWS and Google Cloud; Azure and Oracle Cloud ends are in preview.
Not Another Gateway
The gateway
Your VPCs' own data plane on AWS: the traffic that already lives in the cloud, moved, translated and inspected at a flat fee.
The relay family
Identity and connectivity for what sits outside the VPC: devices that wear a cloud address, teams that share one, compute in other clouds that joins your VPC, and VPCs routed across clouds.
Both ship in the same Cloud Spectra software. Run either, or both.
Built the Same Way, Every Time
Good to Know
Which product do I need?
One laptop, desktop or phone that needs your cloud's IP: CloudAddress. A team that should reach the internet from one cloud IP: CloudVpn. Compute in another cloud that must behave as a member of your VPC: CloudVpc. Two VPCs in different clouds that need to talk privately: CloudConnector.
Does my traffic pass through Cloud Spectra?
No. Relays are instances in your own cloud accounts, and every tunnel ends at one of them. Cloud Spectra licenses the relays; it does not sit in your data path.
How is this different from the Cloud Spectra gateway?
The gateway is the data plane inside your AWS VPCs -- NAT, transit, firewall and load balancing for traffic that already lives in the cloud. The relay family connects what sits outside the VPC: devices, teams, compute in other clouds, and other clouds' VPCs. Both ship in the same software.
Is CloudConnector a replacement for a cloud interconnect?
Where there is no interconnect, or you need capacity that follows your fleet, it fills that gap: there is no circuit to order and bandwidth grows with relays. Traffic crosses the internet and your clouds bill it as egress, so where a zero-egress interconnect already exists, that lane stays cheaper.
How is CloudAddress different from a VPN?
A VPN or overlay network gives your device an address from its own pool. CloudAddress gives it your cloud's own address -- the relay's public IP and, on AWS, Azure, Google Cloud and Oracle Cloud, its private VPC address -- so every rule already written for that address applies to the device directly.
What does it cost?
Relay instances, addresses and traffic are billed by your cloud provider at your rates. The Cloud Spectra licence is priced per relay vCPU -- see pricing.
Start With One Relay.
Put it in your own cloud account, then add devices, sites and clouds as you need them.