GCP Out of Capacity? How to Offload Workloads to AWS Without Running a Second Platform

Key Points:

• Google says capacity is the constraint. Sundar Pichai said in April 2026 that Google is "compute constrained in the near-term" and that cloud revenue "would have been higher" if Google could meet demand. In July the CFO repeated that Alphabet is "still in a supply-constrained environment", with Google Cloud growing 82% year over year.
• The shortage reaches CPUs, not only GPUs. ZONE_RESOURCE_POOL_EXHAUSTED means the zone has no hardware left for your request, and Google's docs state that it is not a quota problem. In July 2026, GitLab.com documented GKE scale-ups failing on N4D zonal stockouts in us-east1.
• Google's own advice is to plan for it. Reserve capacity ahead of time, use Dynamic Workload Scheduler, and keep "ranked lists of acceptable alternatives" for when a machine type, size or zone is unavailable.
• A second cloud is the widest fallback list you can have. AWS holds the largest share of the market, plans about $220 billion of capex in 2026, and lets an autoscaler like Karpenter choose from hundreds of instance types. It is also capacity constrained on AI hardware, so what it adds is a second, independent pool.
• Offloading is a platform problem first. Most GCP teams don't burst to AWS because it means a second Kubernetes setup, second IAM model, second pipeline and second on-call. Qovery runs GKE and EKS clusters from one control plane, so moving an environment to AWS is a clone to another cluster and a deploy.

Over the last few months, the same conversation has come up again and again with teams running on Google Cloud. The nodes don't come up. The autoscaler logs fill with ZONE_RESOURCE_POOL_EXHAUSTED. Someone opens a support case, Google suggests another zone, and the other zone is out too. Deployments that used to take minutes wait for hours.

These teams chose GCP for good reasons, and most of them want to stay. What they need is somewhere to put the workloads that cannot wait. AWS is the obvious second pool, as long as running it doesn't mean building and staffing a second platform.

What does the GCP "resource pool exhausted" error mean?

ZONE_RESOURCE_POOL_EXHAUSTED (and its variant ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS) means Google does not have enough physical capacity in that zone to create the VMs you asked for. The full message reads: "The zone 'projects/PROJECT_ID/zones/ZONE' does not have enough resources available to fulfill the request."

Google's troubleshooting documentation is explicit that this has nothing to do with your quota: "Resource errors aren't related to your Compute Engine quota." Raising your quota will not fix it. The error can carry a reason such as cpu_availability, memory_availability, local_ssd_availability or gpu_availability.

On GKE, it shows up as nodes that never join the cluster. Pods stay Pending, the cluster autoscaler reports failed scale-ups, and the GKE node pool troubleshooting guide lists "resource pool exhausted" among the causes. With GKE Autopilot you don't see the node pool at all, only the pods waiting.

Google's documented fixes are:

1. Retry later, since "resource availability can be transient".
2. Try another zone or region.
3. Change the machine series, the instance count, or the disk and GPU sizes.
4. Switch provisioning model to Flex-start or Spot VMs, which draw from "different capacity pools".
5. Reserve capacity ahead of time.

All five keep you inside GCP. When a whole region is tight on the machine family you depend on, options 1 to 3 buy you time, and option 5 means paying for capacity before you need it.

Is Google Cloud really capacity constrained in 2026?

Yes, by Google's own account.

The Financial Times also reported that Google told Meta in March 2026 that it could not buy all the capacity it wanted, and that other customers were limited to a lesser extent.

Google Cloud is growing much faster than the market. Synergy Research puts Google at 15% of cloud infrastructure spend in Q2 2026, against 28% for AWS and 20% for Microsoft. An 82% growth rate on that base, much of it AI, consumes new data center capacity as fast as Google can build it. The $514 billion backlog is demand Google has already signed.

Is the GCP shortage only about GPUs?

No. GPUs get the headlines, but the 2026 reports that hurt day-to-day operations are about general-purpose CPU families.

• N4D on GKE, July 2026. GitLab.com opened a production issue titled "Investigate and resolve GKE node pool constraints causing slow deployments (N4 vCPU limits + N4D stockouts)". Their summary: "Scale-ups on N4 fail against a vCPU quota limit, and scale-ups on N4D fail against zonal stockouts", with "extreme N4D node stock outs" in us-east1-c.
• N4D in us-central1, August 2026. On Google's developer forum, users reported n4d-standard-2 stockouts lasting hours. One reply: "It's the same in us-west1 hopeless."
• N2D and E2 Spot in europe-west1, November 2025. A team running GKE CI on Spot nodes reported daily "out of resources" errors in two zones, "after years of stability".

Google's August guidance lists "some CPU-based virtual machine families" next to GPUs and TPUs, which matches what these teams saw. If your cluster is pinned to one or two machine families in one region, you are exposed even if you never touch a GPU.

What does Google recommend when capacity runs out?

Google's answers are reservations, Dynamic Workload Scheduler, and fallback planning.

• Reservations. Google's docs say: "To help prevent resource availability errors in the future, we recommend that you reserve Compute Engine resources ahead of time." Reservations work, but you pay for the capacity whether you use it or not, and you have to forecast it.
• Dynamic Workload Scheduler. Flex-start mode queues your GPU or TPU request and provisions the VMs once capacity frees up. Calendar mode books fixed blocks ahead of time. Both are good for training jobs that can wait. Neither helps a production service that needs to scale now.
• Ranked fallbacks. Google recommends lists of acceptable alternatives "if a preferred machine type, size or zone is unavailable". The widest fallback list you can build includes a second cloud.

Does AWS have more capacity than GCP?

AWS is bigger on most capacity measures, and it is also capacity constrained on AI hardware.

What AWS has going for it:

• The largest footprint by spend. 28% of the market against 15% for Google in Q2 2026, per Synergy Research.
• Aggressive build-out. AWS added 3.8 GW of data center capacity in the twelve months to Q3 2025, and Amazon now plans roughly $220 billion of capex for 2026.
• Instance diversity. AWS offers hundreds of EC2 instance types across Intel, AMD and Graviton, plus its own Trainium and Inferentia chips. When one family is tight, an autoscaler like Karpenter can pick another that fits the pod's requests.
• Capacity products for GPUs. EC2 Capacity Blocks for ML let you book GPU instances up to eight weeks ahead, for 1 to 14 days or longer blocks.

The fair caveat: Andy Jassy said in July 2026 that Amazon "will not have enough capacity to meet all of its 2026 demand" and expects "the same dynamic in 2027". The pressure is sharpest on AI hardware. Latest-generation GPUs are tight everywhere.

So the case for AWS is diversification. A second cloud has a different supply chain, different chips, different regions and different demand peaks. An N4D stockout in a GCP zone tells you nothing about EC2 supply in us-east-1, and an autoscaler that can choose among many EC2 families has more ways to find a node that fits.

Which workloads should you offload from GCP to AWS?

Start with the workloads that move easily and hurt the most when they wait. Keep the ones tied to your data where they are.

flowchart TD
    A[Workload waits for GCP nodes<br/>or fails to scale] --> B{Stateful, data-heavy on GCP,<br/>or latency-critical next to GCP?}
    B -- Yes --> K[Keep on GCP<br/>and reserve capacity]
    B -- No --> O[Offload to EKS on AWS<br/>CI runners, batch jobs, queue workers,<br/>stateless APIs, GPU inference]

Network cost is the main trade-off. Data leaving Google Cloud for the internet is billed per GB, and so is data leaving AWS. If an offloaded service reads heavily from a GCP database, the egress bill and the latency will tell you it is in the wrong place. Since April 2026, AWS Interconnect - multicloud offers managed private links with Google Cloud as the first partner, which helps for steady cross-cloud traffic.

Why don't more GCP teams burst to AWS already?

Because it usually means running two platforms. Renting the compute is easy, and everything around it doubles:

• Two Kubernetes flavors. GKE (often Autopilot) and EKS behave differently: node provisioning, load balancers, storage classes, upgrades.
• Two identity models. GCP IAM and service accounts on one side, AWS IAM roles and IRSA or Pod Identity on the other.
• Two networks. VPCs, firewall rules, DNS and private connectivity between them.
• Two pipelines. Your CI/CD was written for one cluster. Now every service needs a second target, second secrets, second environment variables.
• Two on-call surfaces. Logs, metrics and alerts in two consoles.

A company with a dedicated platform group can absorb this. A team without one usually waits for GCP capacity and accepts slower deployments, because building the second platform costs more than waiting.

How do you offload workloads from GCP to AWS with Qovery?

Qovery removes the second platform. It is an Agentic DevOps platform that deploys and runs your workloads inside your own cloud accounts, and one Qovery organization can manage clusters on GCP and AWS side by side. Your applications, environment variables, secrets, pipelines and access rules are defined once in Qovery. The cluster is a target you choose.

Here is the path we follow with GCP teams:

1. Connect your AWS account. Qovery creates and manages an EKS cluster in your account, with Karpenter for autoscaling, Spot and On-Demand nodes, and GPU node pools if you need them. Your GKE cluster keeps running as it is.
2. Clone the environment to the AWS cluster. In the Console, or from the CLI (commands below). The clone keeps the services, configuration and deployment pipeline, and you choose which services to include. Custom domains are not copied, so you decide when traffic moves.
3. Route the work. For queue workers and batch jobs, point them at the same queue and let them pull. For CI runners, register the new runners. For APIs, add the AWS endpoint behind your load balancer or DNS.
4. Keep data where it lives. Leave the primary database on GCP, connect over private networking or authenticated endpoints, and move data only when you plan a migration. Managed AWS services such as RDS or ElastiCache can be provisioned from the same Qovery environment when a workload needs local state.
5. Scale it back when you want. Stop or delete the AWS environment when GCP capacity returns, or keep it as a standing second region.

From the CLI, the clone and the first deploy are two commands:

qovery environment clone -e workers -n workers-aws -c aws-us-east-1
qovery environment deploy --environment workers-aws

Because it is the same environment definition, your developers keep the same workflow. They push code, Qovery builds it once and deploys it to whichever cluster the environment targets. The same goes for the agents your team uses: Claude Code, Cursor or Codex connect through the Qovery MCP server with a scoped token, and the AWS environment shows up next to the GCP one. If you prefer infrastructure as code, the Qovery Terraform provider declares both clusters and the mirrored environment in the same configuration.

Everything runs in your own accounts. The GKE cluster stays in your GCP project, the EKS cluster sits in your AWS account, and you keep your committed-use discounts on GCP and your Savings Plans on AWS.

Checklist before you offload from GCP to AWS

1. List the services that failed to scale or waited for nodes in the last 30 days, and the machine families involved.
2. Mark each one as stateless, queue-driven, batch, or stateful.
3. Estimate cross-cloud traffic for each candidate. High read volume from a GCP database means it stays on GCP.
4. Check that your container images are reachable from both clouds (a shared registry, or one registry per cloud).
5. Decide how traffic or work reaches AWS: shared queue, DNS weight, load balancer, or a separate CI runner pool.
6. Pick the AWS region closest to your GCP region to limit latency.
7. Start with CI runners or preview environments, measure, then move production workers.