Skip to main content
CoreWeave offers compute in multiple geographically diverse locations to ensure high availability, resilience, global coverage, and low-latency access for your applications. CoreWeave organizes these locations into Geos, Super Regions, Regions, and Availability Zones (AZs). Regions and Availability Zones (AZs) are the core concepts to understand when you deploy applications on CoreWeave. These are located within Super Regions and Geos, which are explained in more detail in the Geographical hierarchy section. Regions contain one or more AZs. CoreWeave categorizes AZs as General Access or Dedicated Access. For a list of every AZ and its access type, see All Availability Zones.

​
General access

General Access AZs are available to all CoreWeave customers, subject to capacity. VPCs isolate tenant workloads, with per-tenant network segmentation enforced at the hardware layer by DPUs.

​
Dedicated access

CoreWeave manages Dedicated Access AZs and reserves them for select customers. Infrastructure in a Dedicated Access AZ is single-tenant: no other customer’s workloads run in the AZ, and no other tenant shares the underlying network fabric. This provides full network isolation in addition to the platform-wide VPC and DPU-based tenant segmentation.

​
Region features

All CoreWeave Regions offer these features:
  • Free data transfer: move data between Regions without incurring additional costs.
  • Fast and reliable internet access: each Region has redundant, 200 Gbps+ public internet connectivity from Tier 1 global carriers.
  • High-speed, private dark fiber backbone: all Regions connect through 400 Gbps+ of dark fiber to enable rapid data movement and synchronization.
  • Distributed File Storage: each Region offers high-performance shared filesystems for your applications.
  • Virtual Private Clouds: all Regions provide VPCs for network isolation and security.
  • CoreWeave AI Object Storage: available in select Availability Zones.

​
Geographical hierarchy

The following terms describe how CoreWeave structures its global infrastructure:
TermDescriptionExample
GeoA large geographic area, such as a continent or a large country. CoreWeave uses Geos to manage global infrastructure, ensure compliance with regulatory requirements, and optimize for large-scale redundancy and disaster recovery.All locations in the United States reside in the US Geo.
Super RegionA large section of a Geo that typically contains multiple Regions. Super Regions group Regions together for administrative purposes and provide a high-level view of the infrastructure in a geographic area.All locations in the eastern United States are part of the US-EAST Super Region.
RegionAn area within a Geo that contains multiple Availability Zones (AZs). Regions provide the infrastructure foundation for resiliency. When you deploy across multiple AZs within a Region, you can design failover-ready workloads that minimize downtime. CoreWeave places Regions to offer low latency, high-performance connectivity, and to meet data residency requirements.Region US-EAST-05 resides in the US-EAST Super Region.
Availability Zone (AZ)A partition within a Region that hosts one or more data halls. AZs are physically and operationally independent from each other to prevent failures from propagating across them.Availability Zone A in the US-EAST-05 Region is named US-EAST-05A.
Together, these concepts provide the foundation for high availability, fault tolerance, and disaster recovery for your applications and workloads.

​
Region and AZ labels

CoreWeave exposes Region and AZ information through two different sets of labels depending on the context: Kubernetes Node labels for scheduling, and metrics labels for queries, APIs, and CRDs.

​
Kubernetes Node labels

Use these labels in nodeSelector, affinity rules, and topology spread constraints:
LabelValueExample
topology.kubernetes.io/regionRegion nameUS-EAST-04
The standard Kubernetes label topology.kubernetes.io/zone is present on CoreWeave Nodes but doesn’t hold the AZ name. It holds a rack number for use by topology-aware schedulers. No AZ-level Kubernetes Node label exists. Because CKS clusters are single-AZ, AZ affinity within a cluster isn’t needed.

​
Metrics and API labels

Use these labels in metrics queries, API calls, and CRDs. They appear on kube_node_info and in CoreWeave CRDs, but aren’t Kubernetes Node labels.
LabelValueExample
regionRegion nameUS-EAST-04
zoneAZ nameUS-EAST-04A

​
Single-AZ CKS clusters

CoreWeave Kubernetes Service (CKS) clusters are zonal. CoreWeave provisions each cluster within a single AZ. All Nodes in a cluster belong to the same AZ, so you don’t need AZ affinity rules within a cluster. If you need rack-level placement within an AZ (for example, to co-locate Nodes on the same NVLink fabric), use the node.coreweave.cloud/rack label. See InfiniBand and RoCE node labels for details.

​
Speedtest

To verify network performance for a Region or AZ before you deploy workloads, run speed tests with ping, curl, or another method of your choice. Each Availability Zone in the All Availability Zones table lists speed and latency test endpoints in its Network information section. For example, to measure name lookup, connect, and total transfer times with curl, use the following command:
Example curl command
curl [SPEEDTEST-URL] \
       --write-out '\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTotal: %{time_total}s\n' \
       --output /dev/null
Result
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1024M  100 1024M    0     0  37.2M      0  0:00:27  0:00:27 --:--:-- 38.9M

DNS: 0.001822s
Connect: 0.091322s
Total: 27.465658s
Last modified on June 4, 2026