InsufficientInstanceCapacity is the error AWS returns when it does not have enough available On-Demand capacity to fill a launch request [1]. AWS's launch troubleshooting page sets no instance type apart, so a GPU launch meets the same error [1]. Every cloud launch passes two separate checks. Quota is an account's permission to deploy resources, and capacity is the hardware available in a region or zone at that moment. Microsoft's documentation states it directly: "Quota and capacity are separate checks" [36]. Google's adds that a quota increase does not resolve a capacity error [20].
This explainer reads the documents of AWS, Google Cloud, Microsoft Azure and the GPU cloud Lambda as they stood on 8 November 2026. It sets out what each launch error means, where AWS's default GPU quotas start at zero, which reservations hold GPUs for which window, and which discounts hold none.
InsufficientInstanceCapacity on GPU instances: what it means
AWS sorts its EC2 API errors into client errors, with 400-series codes, usually caused by something the client did, and server errors, with 500-series codes, usually caused by an issue on AWS's side [2]. The quota errors InstanceLimitExceeded and VcpuLimitExceeded are client errors. InsufficientInstanceCapacity is a server error, returned when an instance is launched or restarted, or a Capacity Reservation created or modified [2]. The other clouds draw the same line.
| Provider | Quota error | Capacity error |
|---|---|---|
| AWS | InstanceLimitExceeded, VcpuLimitExceeded [2] | InsufficientInstanceCapacity, and ReservationCapacityExceeded when a targeted reservation is full [2] |
| Google Cloud | QUOTA_EXCEEDED, HTTP 403 [21] | ZONE_RESOURCE_POOL_EXHAUSTED and related codes [20] |
| Microsoft Azure | OperationNotAllowed, exceeding quota limits [34] | AllocationFailed or ZonalAllocationFailed [32] |
| Lambda | global/quota-exceeded [39] | instance-operations/launch/insufficient-capacity [39] |
Lambda is the one neocloud read here: both codes sit among the common errors of its launch endpoint [39].
The fixes providers list for a capacity error change the request. AWS suggests waiting a few minutes and retrying, because "capacity can shift frequently", splitting a large request into smaller ones, launching without naming an Availability Zone, or choosing another instance type [1]. Azure lists retrying later, another VM size, another region or zone, and fewer constraints such as Accelerated Networking or a proximity placement group [32]. Google's gpu_availability error means the zone lacks capacity for the requested GPU model. Its fixes are another zone with the same GPU model or another provisioning model, because "Different provisioning models draw from separate capacity pools" [20]. Google also warns against stopping or deleting running instances that have no reservation behind them to fix the error, since that returns their GPUs to the zone [20].
Default GPU quotas start at zero on AWS
AWS counts On-Demand quotas in vCPUs, whatever the instance type [4]. On 8 November 2026, the default for Running On-Demand P instances was 0 vCPUs, as were the defaults for All P Spot Instance Requests and for the G and VT families [3]. Concurrent P5 Capacity Blocks also defaulted to 0, and every one of these quotas is adjustable [3]. A p5.48xlarge has 192 vCPUs and eight H100 GPUs, and the p5en, p6-b200 and p6-b300 instances, with eight H200, B200 or B300 GPUs, also have 192 [6]. One such node needs 192 vCPUs of P quota (computed for this report from [3, 6]).
AWS raises On-Demand quotas automatically based on usage, and accepts requests [3]. Smaller increases are usually approved automatically. Larger ones go to Support, "take time to review, process, approve, and deploy", and can be approved, denied or partially approved [5]. Capacity Reservations count toward the On-Demand quota even when unused [4].
Google Cloud counts GPUs: a global GPU quota for all regions, a quota per GPU model per region, and "Running instances and reservations consume GPU quotas" [22]. As its quota table read on 8 November 2026, A4 (B200), A3 Ultra (H200), A4X (GB200), A4X Max (GB300) and A5X (Vera Rubin) have no standard (on-demand) quota, only quota for committed use and for preemptible VMs such as Spot and Flex-start [22]. The H100 and A100 series keep standard quota [22].
Azure checks two vCPU quotas in each region, the regional total and the VM-size family, and refuses a deployment that exceeds either [33]. Deallocated VMs still count against quota [33].
Reservations that hold GPU capacity
A reservation holds capacity before it is needed, and each product below charges for that hold.
| Product | Window | Billing | GPU coverage, as read 8 November 2026 |
|---|---|---|---|
| AWS On-Demand Capacity Reservation | Any duration, no term for immediate use [7] | On-Demand rate, used or not [10] | Future-dated requests only for C, G, I, M, R, T, U and X families [7] |
| AWS Capacity Blocks for ML | 1 to 14 days, or multiples of 7 days up to 182 [13] | Paid up front, no cancellation [12, 14] | Includes p6-b300, p6-b200, p5, p5e, p5en and p4d instances and P6e-GB200 UltraServers [12] |
| Google on-demand reservation | Until modified or deleted [24] | The reserved resources' rates, used or not [25] | All families except A5X, A4X Max, A4X, A4, A3 Ultra and A3 High under 8 GPUs [24] |
| Google calendar mode | 1 to 90 days, at least 87 hours ahead [26] | From fulfilment, discounted up to 53% [24, 26] | A4, A3 Ultra, A3 Mega, A3 High with 8 GPUs, A3 Edge [26] |
| Azure on-demand capacity reservation | Until deleted [36] | The VM size's rate, used or not [36] | Listed NC, NV and NG series, with ND-series and NCads H100 v5 not supported [36] |
The open-ended reservations bill idle capacity. In AWS's example, 20 reserved m4.large instances with 15 running are charged as 15 active instances and 5 unused instances in the reservation [10]. Azure's example bills 10 reserved D2s_v3 VMs with 6 deployed as 6 VMs and 4 unused reservations [36]. Google bills a reservation for as long as it exists, used or not [25].
Reservations meet the same two checks as launches. Creating one on AWS can fail when EC2 lacks the capacity or the quantity exceeds the account's On-Demand limit [9]. Azure's fails without the capacity or without adequate quota [36]. Google's on-demand reservations consume quota the moment they are created [25], while calendar mode needs no quota for GPU machine types [26].
The family lists matter for the 8-GPU instances. AWS's future-dated reservations, requested 5 to 120 days ahead, are offered for C, G, I, M, R, T, U and X instances, so the P family with H100, H200, B200 and B300 GPUs is outside them [6, 7, 8]. Capacity Blocks reach P5 and P6 instances up to eight weeks ahead [12]. On Google Cloud, as the pages read on 8 November 2026, B200 and H200 VMs run only as Spot, Flex-start or reserved capacity, and GB200 and GB300 VMs only on capacity reserved through Google's account team [22, 23, 24, 27]. The provisioning models page puts Vera Rubin (A5X) VMs in the second group, while the Flex-start page excludes only A4X Max and A4X [23, 27]. A standalone Flex-start VM waits up to 7,200 seconds for capacity, while a managed instance group keeps trying until it succeeds or the request is cancelled, and the VMs then run for up to seven days [27].
Where Capacity Block fees and reservation prices appear in the providers' price APIs is covered in Reading GPU prices from cloud pricing APIs.
Discounts that hold no capacity
A discount on the bill holds no capacity unless it carries reservations or reserves capacity itself. AWS's comparison table marks regional Reserved Instances and Savings Plans "No capacity reserved", while a zonal Reserved Instance reserves capacity in its Availability Zone [7, 16]. Azure says Reserved Instances "provide a billing discount only and don't guarantee capacity" [36], and its savings plans are billing offers that leave the runtime state of resources unchanged [37]. Google's flexible commitments "don't offer the assured capacity that comes with attached reservations", and its resource-based GPU commitments require reservations attached to them [28, 29].
Spot capacity is a discount on capacity the provider can take back. AWS reports a Spot request it cannot fill as capacity-not-available [19], and Azure's Spot VMs carry no SLA [38]. What interruptions cost a training run is covered in What research shows about training on spot GPUs.
What availability data can and cannot tell you
Providers publish a few availability signals, and each says what it does not promise. AWS's Spot placement score estimates how likely a Spot request is to succeed and "does not provide any guarantees in terms of available capacity or risk of interruption" [18]. Google's obtainability score, in Preview, rates a request from 0.0 to 1.0, and "Obtainability scores don't guarantee capacity" [31]. Lambda's API lists the regions where each instance type is available [39]. A 2023 study of a cross-cloud broker found that clouds do not publish availability explicitly, so a broker may have to learn it from the allocation failures and preemptions it observes [40]. The same limits apply to the flags beside posted prices, as What posted GPU cloud prices tell you, and what they do not sets out.
In Rillor's GPU and neocloud pricing method, availability means what a provider reports as available to rent, recorded as published beside the price at the moment of capture, and it describes rentable offers at that moment. Whether a launch of a given size succeeds is a separate question, and no provider score guarantees it [18, 31].
Read the full report
The full report lists each error code with its documented cause, AWS's default quota table, the terms of the reservation and scheduled capacity products it covers, the commitments that hold capacity and those that do not, and all 41 sources.