SkaleData DocsCloud quotas
The per-region cloud quotas a SkaleData cluster needs, their fresh-account defaults, and the command to raise each one.
Every SkaleData cluster runs in your cloud account, so it consumes your account's
quota. Fresh accounts ship with limits that are smaller than one cluster needs —
on Azure pay-as-you-go, a new subscription grants 10 total vCPUs against a
cluster baseline of roughly 32. SkaleData checks these limits when you create a
cluster or add an application and refuses at submit, with the quota code and the
increase command, rather than letting terraform apply fail 15 minutes later.
This page lists what a cluster needs so you can request the increases up front.
What one cluster costs
| Resource | Per cluster | Why |
|---|---|---|
| Base node pool | 2 nodes x 4 vCPU = 8 vCPU | Runs ingress, system add-ons, and anything not pinned to a dedicated pool. |
| CNPG data pool | 1 node x 8 vCPU | The shared PostgreSQL cluster's dedicated, tainted pool. |
| Airflow control-plane pool | 2 nodes x 8 vCPU = 16 vCPU | One dedicated pool per Airflow instance, so a task-pod burst can't evict the scheduler. The Small environment size runs a single node (8 vCPU); every other size runs two for node-level HA. |
| Task autoprovisioning headroom | 1 node x 4 vCPU | KubernetesExecutor task pods provision nodes on demand. Without headroom the cluster comes up and no DAG can be scheduled. |
| Network | 1 VPC or virtual network, 1 NAT gateway, 1 egress IP | One isolated network per cluster. |
A cluster with Airflow needs about 36 vCPU in one region, before any worker pools. Worker pools are sized separately when you pick a worker size, and add their own floor on top.
Amazon Web Services
Non-compute limits bite before vCPU does on AWS: the defaults are five per region, and your account's default VPC already holds one VPC slot and one internet gateway slot. That makes cluster four or five the one that fails.
| Quota | Code | Service | Default | Per cluster |
|---|---|---|---|---|
| Running On-Demand Standard instances (vCPU) | L-1216C47A | ec2 | 5–96 | ~36 with Airflow |
| VPCs per region | L-F678F1CE | vpc | 5 | 1 |
| EC2-VPC Elastic IPs | L-0263D0A3 | ec2 | 5 | 1 |
| Internet gateways per region | L-A4707A72 | vpc | 5 | 1 |
| EKS clusters | L-1194D53C | eks | 100 | 1 |
Note the service code: VPC and internet-gateway quotas live under vpc, not
ec2.
Check a current limit:
aws service-quotas get-service-quota \
--service-code vpc --quota-code L-F678F1CE --region us-east-1Request an increase:
aws service-quotas request-service-quota-increase \
--service-code vpc --quota-code L-F678F1CE \
--desired-value 20 --region us-east-1Reading a quota requires servicequotas:GetServiceQuota on the SkaleData
deployer role. Roles created before that permission was added don't have it —
SkaleData then skips the AWS quota checks rather than guessing, so an apply can
still fail on a limit it couldn't read. Re-run skale cloud setup --provider aws
to refresh the role.
Google Cloud
| Quota | Metric | Scope | Default | Per cluster |
|---|---|---|---|---|
| CPUs | CPUS | Region | 24 | ~36 with Airflow |
| CPUs (all regions) | CPUS_ALL_REGIONS | Global | 32 | ~36 with Airflow |
| VPC networks | NETWORKS | Global | 5 | 1 |
| Cloud Routers | ROUTERS | Global | 10 | 1 |
| In-use IP addresses | IN_USE_ADDRESSES | Region | 8 | 2 |
| Service accounts | — | Project | 100 | ~4 |
The default network counts against NETWORKS, so a fresh project fits four more
clusters before that limit binds. The service-account limit binds at roughly 24
clusters in one project; SkaleData warns in its logs as you approach it but never
blocks on it, because no API reports that limit.
Check current usage and limits:
gcloud compute project-info describe --project PROJECT_ID \
--format="table(quotas.metric,quotas.usage,quotas.limit)"
gcloud compute regions describe us-central1 --project PROJECT_ID \
--format="table(quotas.metric,quotas.usage,quotas.limit)"Request an increase from the quotas page for your project, filtered to the metric you need.
Microsoft Azure
| Quota | Name | Default | Per cluster |
|---|---|---|---|
| Total regional vCPUs | cores | 10 on pay-as-you-go | ~36 with Airflow |
Family vCPUs (for example standardDSv5Family) | per family | 10 on pay-as-you-go | 24 general purpose |
| Virtual networks | VirtualNetworks | 1000 | 1 |
| Standard public IPv4 addresses | IPv4StandardSkuPublicIpAddresses | 20 | 1 |
| NAT gateways | NatGateways | 100 | 1 |
Azure enforces both a per-family vCPU limit and a total regional limit, and a new pay-as-you-go subscription grants 10 of each. That is below one cluster's base pool plus data pool, so a quota increase is the first step on a new subscription.
Azure also restricts which VM generations a subscription can run. SkaleData resolves each pool's VM size against what your subscription actually offers, so a subscription with only v7-generation sizes still provisions — you don't need to request the exact sizes named here, only enough vCPU.
Check current usage:
az vm list-usage --location eastus -o table
az network list-usages --location eastus -o tableRequest an increase from the Quotas blade in the portal, or with the CLI:
az quota update --resource-name standardDSv5Family \
--scope /subscriptions/SUBSCRIPTION_ID/providers/Microsoft.Compute/locations/eastus \
--limit-object value=64When a check can't run
The quota pre-flight never blocks a cluster on a quota it couldn't read. A cloud-API error, a missing permission, or a quota your provider doesn't report all cause SkaleData to skip that check and continue — provisioning re-checks everything and remains the authoritative gate. So a create that succeeds is not proof that every limit was verified. If an apply fails on a quota error, compare the tables above against your account and request the increase.