IBM Cloud region and data center locations for resource deployment

Regions

IBM® offers two types of regions: MZRs and single-campus MZRs and both are considered an MZR. The underlying infrastructure in both types provides the same SLA. A region is an independent geographic territory that consists of one or more zones and is typically referred to by the metropolitan (metro) city area name like Dallas or London.

Each zoneA location within a region that acts as an independent fault domain. within the region assists with improved fault tolerance and decreased latency. A zone is identified by using two separate names. There is a zone name, for example us-south-1 that is a logical identifier for a zone in the context of the current account. There is also a universal zone name that is the identifier for a zone that is consistent across IBM Cloud, for example us-south-dal10-a. The universal zone name provides the location specification for VPC resources by mapping the zone name to a physical location, such as a data center. Alternatively, the location for classic resources is not specified by zone and instead uses the specific data center within the region, such as DAL10. For more information about zone information specific to your account, see Zone mapping per account.

By distributing your workloads across three zones and consuming highly available regional cloud resources through virtual private endpoints, you can increase regional availability. Distributing a workload across multiple regions can provide higher availability and serve as the foundation for a disaster recovery plan. There are zonal, regional, and global cloud services that provide a consistent set of resources across regions. The IBM regional services are distributed across zones in an MZR and generally provide 99.99% (tier 3) availability.

Multizone regions

MZRs are composed of three or more data centers in multiple zones with independent power, cooling, and network connectivity to help ensure that failures in these components will be isolated to a single zone. MZRs provide low latency (< 2-milliseconds latency) and high bandwidth (> 1000 Gbps) connectivity within a zone.

Offering the highest level of redundancy and availability by leveraging three separate sites within a region, MZRs have a minimum distance of at least 1 mile between zones and exact distances vary by region. Zone-to-zone latency can be found in the network latency dashboards.

MZRs support different types of compute for both VPC and classic infrastructure resources. The location of classic resources is specified by a data center while VPC resource locations are specified by the zone. For more information about the physical locations available for your account per region for VPC resources, see Zone mapping per account.

The following table lists the IBM Cloud MZR locations and zones for each.

MZRs in North and South America
Use the buttons before the table to change the context of the table. The column headers identify the location type in the specific geographical area.

Region	Zone
Dallas (us-south)	us-south-1 us-south-2 us-south-3
Sao Paulo (br-sao)	br-sao-1 br-sao-2 br-sao-3
Toronto (ca-tor)	ca-tor-1 ca-tor-2 ca-tor-3
Washington DC (us-east)	us-east-1 us-east-2 us-east-3

MZRs in Europe
Use the buttons before the table to change the context of the table. The column headers identify the location type in the specific geographical area.

Region	Zone
Frankfurt (eu-de)	eu-de-1 eu-de-2 eu-de-3
London (eu-gb)	eu-gb-1 eu-gb-2 eu-gb-3
Madrid (eu-es)	eu-es-1 eu-es-2 eu-es-3

MZRs in Asia Pacific
Use the buttons before the table to change the context of the table. The column headers identify the locaiton type in the specific geographical area.

Region	Zone
Sydney (au-syd)	au-syd-1 au-syd-2 au-syd-3
Tokyo (jp-tok)	jp-tok-1 jp-tok-2 jp-tok-3

If you're referencing a region when using the CLI, API, SDK, or Terraform, ensure that you're using the programmatic region name. For example, use us-south to target the Dallas (us-south) region.

Single-campus MZRs

Single-campus MZRs (SC-MZR) contain three zones in different sections of the same building or within multiple buildings on a campus where the power, cooling, networking, and physical security dependencies overlap but are not identical between any two zones. This setup ensures a level of continuous availability and survivability of any one system outage, planned or unplanned.

SLAs are maintained because the infrastructure is set up in a concurrently maintainable fashion so that a single failure does not affect all three zones in the same campus. This setup is ideal for services that support local users as it reduces latency or to support disaster recovery workloads.

The following table lists the SC-MZR locations that are available in IBM Cloud and the associated regions and zones.

single-campus MZRs

Region	Zone
Osaka (jp-osa)	jp-osa-1 jp-osa-2 jp-osa-3

Viewing resources by location

You can view all resources and locations from the Resource list page in the console. If you want to view and work with resources in a specific location, expand the Location filter, and select a location from the list. By expanding a specific location, you can select to filter by regions, zones, or individual data centers.

Depending on the type of resource, you might be interested in only specific types of location data. For example, if you created a service or VPC infrastructure service, you can filter the Resource list page by the region and zone codes. However, if you're working with classic infrastructure or Power Virtual Server resources, the specific data center codes are the pertinent information for you.

For example, if you have resources that are deployed in the London 2 (eu-gb-2) zone, you can set filters to display only those resources in your resource list. Expand the London metro option, and the London (eu-gb) region option. Within that region, you can select from the list of available zones, such as London 2 (eu-gb-2).

If you have a classic infrastructure resource that is deployed in a specific data center, you can identify the data center by the specific metro location and alphanumeric code. For example, use Dallas for the metro location and then Dallas 10 (dal10) for the data center.

You can also view resources that are deployed in Satellite locations, which are managed by an IBM Cloud metro or region and determines where the master of your Satellite control plane runs. For example, you might have a Satellite location that's managed by the Dallas metro. Expand the Dallas metro option, which includes your Satellite location, like my-satellite-dal. For more information about the metros and regions that manage Satellite locations, see Regions.

You might also want to display your resources that are located globally. The Global option means that only one logical, globally accessible instance of the service, independent of any region or zone, is published to customer workloads. These types of resources are accessible from a global endpoint.

As illustrated in the following graphic, a data center is a physical building that represents a zone that is located within a multizone region (MZR). An MZR is organized by its metro location. For example, London can encompass more than one grouping of data centers within an MZR. The graphic shows three zones in one MZR that work together in the instance that one of the data centers becomes unavailable. Zones are connected directly to each or through low latency links.

Classic data centers

In addition to selecting a region for your resource, you can select from a list of the IBM Cloud data centers, if you're working with classic infrastructure or Power Virtual Server resources.

Data centers host the power, cooling, compute, network, and storage resources used for services and apps. They don't provide isolation from multizones in a location.

Data centers are based on a POD architecture where each data center can have more than one POD, depending on the on-demand build out. Each POD consists of racks, servers, networks, and storage, along with backup power generators. Placing workload servers across PODs improves the availability.

See the following table for the specific code for each data center.

The table includes certain data centers that are set to close soon. For the list of data centers that are closing, see Data center closures.