How to Add a Neocloud to AWS or GCP Without Running a Second Stack

TL;DR

There is no single best neocloud for AWS or GCP teams. The right one depends on the workload. Bursty fine-tuning and batch jobs reward flexible billing and low hourly rates. Always-on inference and agents reward capacity you can keep plus a second place to run, and data-heavy pipelines reward cheap data movement.

• Score every candidate on six criteria: GPU types and availability, price per GPU-hour, contract terms, network and egress costs, data location and compliance, and Kubernetes access. The tables below give each provider’s published facts for seven neoclouds so you can score them yourself.
• The cost most teams miss is the second stack: a separate deployment path, identity model, network, and monitoring, plus egress between clouds.
• Control Plane combines any cloud, neocloud, and bare metal into one Global Virtual Cloud (GVC), so GPU capacity from any provider becomes another location next to your AWS or GCP regions. The same inference workload runs active-active in every location, and when one provider fails, traffic keeps flowing to the healthy ones. A 99.999% availability SLA covers workloads running at least two replicas in at least two locations. You get the neocloud’s GPUs and you stay up when others are down.

The hidden cost of adding a neocloud: a second stack

Beyond the GPU price, a neocloud usually adds four costs:

• A second console and set of credentials. Your team learns another IAM model and another set of long-lived keys to rotate.
• A second network. The neocloud cluster is not in your VPC, so you connect it over the public internet, a VPN, or a paid direct connection.
• A second monitoring and deployment path. Dashboards, alerts, and CI/CD now have two targets.
• Egress between clouds. Model weights and data in S3 or Cloud Storage have to reach the GPUs, and your source cloud’s data transfer pricing applies.

None of this appears in the price per GPU-hour. Engineering time spent running two of everything can erase the GPU savings. A single provider also stays a single point of failure. Multiple zones cover a data center failure and multiple regions cover a regional one, but only a second provider covers a provider-wide outage like the October 2025 AWS us-east-1 outage.

Six criteria for choosing a neocloud

1. GPU types and availability

Match the GPU to the model first: memory per GPU and interconnect decide whether a model fits on one node or needs a cluster. Then check how you get capacity. Some GPUs are self-serve and others are sales-gated; at the time of writing, GB300 NVL72 shows “contact sales” or “contact us” on the CoreWeave, Nebius, Together AI, and Vultr pages. Availability also moves: Together AI says on-demand cluster capacity is “based on real-time availability” (source). Ask for a written answer on how many GPUs you can get in the region you need, and by when.

2. Price per GPU-hour

Compare the same GPU, interconnect, and commitment, and include the CPU, RAM, and storage that come with it. Listed on-demand H100 prices run from $2.30 (Vultr) to about $6.16 (CoreWeave) per GPU-hour. Configurations differ (single GPU or 8-GPU node, bare metal or VM, bundled CPU and RAM), so the range is not like-for-like. Run your own workload on two or three candidates before you decide, and compare the pricing modes:

• On-demand for demand you cannot forecast.
• Spot or preemptible for work that can restart from a checkpoint.
• Reserved or committed for baseline load you can forecast.

3. Contract terms

• Billing runs from per-second (Runpod) to per-minute (Lambda) to hourly (Vultr). Crusoe bills on-demand per hour or per second, and CoreWeave, Nebius, and Together AI publish hourly rates.
• Some providers publish commitment discounts: up to 60% off on-demand for committed usage at CoreWeave, and up to 35% off on-demand at Nebius for reserving large clusters for multiple months.
• Lambda lists 1-Click Cluster prices for 2-week to 1-year terms, with longer terms through sales (source), and Together AI lists reserved tiers from 3 days upward (source).
• Ask what happens when a preemptible instance is reclaimed, and whether a reserved term can be cancelled or resized.

4. Network and egress costs

Weights, datasets, and logs have to move. Check what the provider charges for data leaving its network, what your hyperscaler charges for data leaving yours, and whether you need a private link. Five of the seven providers below list free internet egress. Storage and private-link charges vary: Nebius charges $0.015 per GiB for Standard-tier object storage egress, and CoreWeave prices Direct Connect separately, for example $1,250 per month for a dedicated 10G link (source). Your AWS or GCP data transfer pricing is a separate line item. The cheapest pattern is to keep weights close to the GPUs that serve them and cache them there, so each model version crosses clouds once per location instead of on every cold start.

5. Data location and compliance

Check where the provider’s regions are and whether the one you need is self-serve. Check the certifications each provider publishes, and ask for the reports. CoreWeave says detailed compliance reports are available on request, and Runpod states that compliance coverage can vary by workload, region, provider, and deployment model. If customer data crosses into the neocloud, your own compliance scope grows with it, so decide which datasets are allowed there before you move any.

6. Kubernetes access

If you run on EKS or GKE today, a managed Kubernetes service on the neocloud keeps your deployment model the same. Six of the seven providers below list managed Kubernetes or Slurm on Kubernetes. Runpod states that its Clusters are not compatible with Kubernetes. To add GPU capacity to a Control Plane virtual cloud, an existing Kubernetes cluster joins as a location through BYOK, and plain Linux GPU servers join through Control Plane Managed Kubernetes.

Adding a neocloud to AWS vs GCP

• On AWS, your weights and data usually sit in S3, identity is IAM roles, and private connectivity runs through your VPCs.
• On GCP, they usually sit in Cloud Storage, identity is service accounts, and private connectivity runs through your VPC networks.

Either way, the practical question is how a workload running in the neocloud gets credentials and reaches data that lives in your hyperscaler.

Which criteria to weight for which workload

Neocloud GPU pricing compared: CoreWeave, Lambda, Nebius, Crusoe, Together AI, Vultr, Runpod

Each row uses the provider’s own pages, retrieved October 14, 2026. Prices are list prices and change often. “Not stated” means the pages reviewed did not say.

GPUs, price, and contract terms

Regions, data movement, and Kubernetes

Compliance, as each provider states it

Three ways to connect a neocloud to AWS or GCP

1. Run it as a separate stack

You open an account, deploy your service to the neocloud’s Kubernetes or VMs, and point part of your traffic at it. Good for: a first proof of concept, or a batch workload with no coupling to your main app. What you take on: the full second stack described above, plus your own routing and failover, repeated for every new provider.

2. Orchestrate jobs across clouds

A scheduler or job orchestrator picks where each training or batch job runs and launches it there. Good for: batch and training jobs that can restart from checkpoints and tolerate a few minutes of startup. What you take on: it is built to place jobs, not to route each live request to the nearest healthy location. Credentials, networking, and data access still have to be set up in every cloud the jobs can land in.

3. Join it as a location of one virtual cloud (Control Plane)

The neocloud’s GPU capacity becomes another location in the same virtual cloud as your AWS or GCP regions. You get one workload definition, one identity model, one private network, and one console, API, and CLI to deploy, monitor, and audit every location. Good for: always-on inference and agents, where the same service runs in more than one place and traffic moves on its own when a location is unhealthy. What you control: which neoclouds, regions, and servers make up the virtual cloud, and where data sits. Control Plane handles deployment, routing, identity, and failover across them. Data moving between clouds is still billed by the cloud it leaves.

How to add a neocloud to AWS or GCP, step by step

1. Profile the workload. Write down model size, GPU memory needed, batch or always-on, tokens per second, and latency target.
2. Map your data. Note where weights and datasets live (S3 or Cloud Storage), how large they are, and which datasets may leave your cloud.
3. Shortlist two or three providers using the six criteria. Request their trust documentation and a written answer on capacity in your region.
4. Benchmark one real workload on on-demand capacity for a week, and measure cost per unit of work, not cost per GPU-hour.
5. Choose how to connect it. For one-off batch work, a separate stack or job orchestrator can be enough. For always-on inference, join the capacity to a virtual cloud.
6. Join the neocloud as a location. With Control Plane, GPU servers from any provider join through Managed Kubernetes, and an existing Kubernetes cluster joins through BYOK.
7. Create a Global Virtual Cloud whose locations include your AWS or GCP regions and the neocloud location.
8. Deploy one inference workload to at least two locations with at least two replicas each.
9. Wire up identity and data. Universal Cloud Identity lets the workload reach the S3 or Cloud Storage bucket holding your model weights without long-lived keys in your code, and Cloud Wormhole reaches private VPCs and data centers.
10. Test a failure. Take one location out of service and confirm requests keep flowing to the healthy ones, then compare cost per unit of work across locations.

How Control Plane adds a neocloud to your AWS or GCP footprint

Control Plane is the platform for running unbreakable apps and agents. It combines any cloud, neocloud, and bare metal into one virtual cloud built to stay up when a zone, region, or provider fails, and adds a neocloud as one more location next to your AWS or GCP regions.

• One virtual cloud across providers. A Global Virtual Cloud combines any cloud, neocloud, and bare metal: AWS, GCP, and Azure regions, GPU servers from any provider, your own clusters, and on-premises hardware. A workload deployed to it runs active-active in every location, and a global endpoint routes each request to the nearest healthy location.
• GPU capacity from any provider. GPU Ocean lets you pull GPU capacity from any provider. Today you join plain Linux GPU servers from any provider as a location with Managed Kubernetes, and Control Plane provisions and operates the Kubernetes cluster on them. An existing Kubernetes cluster joins as a location through BYOK.
• Or use Control Plane GPUs. For another failure domain or burst capacity without a new contract, Control Plane’s pricing page lists pay-as-you-go NVIDIA GPUs from T4 through B200. H100 is $4.18 and B200 is $7.93 per GPU-hour, with per-second billing, subject to availability.
• Short-lived access to your cloud services. Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, such as the S3 bucket holding your model weights, with no long-lived cloud keys in your code.
• Private networks. Cloud Wormhole connects workloads to private VPCs and data centers.
• Day-two operations built in. Autoscaling, readiness-gated rollouts, logs and metrics, mutual TLS, a deny-by-default internal firewall, and a tamper-proof audit trail apply in every location, including the neocloud. The same platform runs AI agents and the inference layer they call.
• Availability. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations, and those locations can be on different providers. During the October 2025 AWS us-east-1 outage, 20% of Control Plane customers had us-east-1 in their Global Virtual Clouds. Their workloads were active and running in healthy locations within 10 seconds, with no customer downtime, according to Control Plane internal incident telemetry.
• Cost. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.

Frequently asked questions

What’s the best neocloud to add if I’m already on AWS?

It depends on the workload. Weight price and billing flexibility for batch and fine-tuning, and weight availability, Kubernetes access, and a second location for always-on inference. Use the six criteria and the tables above, then benchmark one real workload on two or three providers. Your weights usually sit in S3, so check the data path from S3 to the neocloud before you commit. To add one without a second stack, Control Plane joins neocloud GPU servers or clusters to a Global Virtual Cloud as another location next to your AWS regions.

What’s the best neocloud to add if I’m already on GCP?

The same framework applies. Your weights usually sit in Cloud Storage and identity is service accounts, so the key questions are how the neocloud workload gets credentials and what moving data out of Google Cloud costs. Shortlist two or three providers and test one workload on each. Control Plane joins the neocloud to a Global Virtual Cloud as another location next to your GCP regions, so one inference workload runs active-active on both.

Can I run the same workload on a hyperscaler and a neocloud interchangeably?

Yes, if the workload is containerized and does not depend on a provider-specific managed service. Kubernetes on both sides makes this simpler. In a Global Virtual Cloud, one workload definition runs in every location, so the hyperscaler region and the neocloud capacity serve the same service.

How do I add a neocloud without rearchitecting my app?

Keep the app as containers and join the neocloud to your existing environment as a location instead of building a parallel deployment. With Control Plane, GPU servers or a cluster from any neocloud join a GVC as a location, and the same workload definition runs there.

How do I switch between neoclouds without vendor lock-in?

Keep provider-specific services out of the serving path, keep model weights in storage you control, and treat each GPU cluster as a location you can add or remove. In a GVC, adding or removing a location changes where the workload runs, not how you define or deploy it.

How long does it take to add a new cloud provider to a production app?

The provider side varies. Lambda, Together AI, and Crusoe describe self-serve GPU instances or clusters that are ready in minutes, while reserved capacity and large GPUs such as GB300 NVL72 go through sales. Your own effort depends on data movement, security review, and how much deployment tooling you would otherwise build twice.

Does adding a neocloud improve uptime?

Yes, when the neocloud runs as an active-active location next to your AWS or GCP regions. If one provider fails, the global endpoint keeps routing requests to the healthy locations. Control Plane’s 99.999% availability SLA applies to workloads running at least two replicas in at least two locations, and those locations can be on different providers.

Does a virtual cloud eliminate egress costs?

No. It replaces the second deployment path, identity model, network, and monitoring setup with the ones you already use. Data moving between clouds is still billed by the cloud it leaves, so keep weights near the GPUs that serve them and cache them there.

Next step: Talk to the Control Plane team about adding neocloud GPU capacity to your AWS or GCP footprint, or sign up free and deploy one inference workload to two locations.

Sources

All provider facts come from each provider’s own pages, retrieved October 14, 2026.

• CoreWeave pricing, trust center
• Lambda pricing, GPU instances, 1-Click Clusters
• Nebius pricing, trust center
• Crusoe pricing, Crusoe Cloud, data preparation
• Together AI pricing, GPU Clusters
• Vultr pricing, Cloud GPU, compliance
• Runpod pricing, Pods pricing docs, Clusters, compliance