// Module included in the following assemblies:
//
// * osd_architecture/osd_policy/osd-service-definition.adoc
:_mod-docs-content-type: CONCEPT
[id="regions-availability-zones_{context}"]
= Regions and availability zones

[role="_abstract"]
The following regions are supported by {OCP} 4 and are supported for {product-title}.

[id="aws-regions-availability-zones_{context}"]
== AWS regions and availability zones
The following AWS regions are supported by {OCP} 4 and are supported for {product-title}:

* af-south-1 (Cape Town, AWS opt-in required)
* ap-east-1 (Hong Kong, AWS opt-in required)
* ap-northeast-1 (Tokyo)
* ap-northeast-2 (Seoul)
* ap-northeast-3 (Osaka)
* ap-south-1 (Mumbai)
* ap-south-2 (Hyderabad, AWS opt-in required)
* ap-southeast-1 (Singapore)
* ap-southeast-2 (Sydney)
* ap-southeast-3 (Jakarta, AWS opt-in required)
* ap-southeast-4 (Melbourne, AWS opt-in required)
* ca-central-1 (Central Canada)
* eu-central-1 (Frankfurt)
* eu-central-2 (Zurich, AWS opt-in required)
* eu-north-1 (Stockholm)
* eu-south-1 (Milan, AWS opt-in required)
* eu-south-2 (Spain, AWS opt-in required)
* eu-west-1 (Ireland)
* eu-west-2 (London)
* eu-west-3 (Paris)
* me-central-1 (UAE, AWS opt-in required)
* me-south-1 (Bahrain, AWS opt-in required)
* sa-east-1 (São Paulo)
* us-east-1 (N. Virginia)
* us-east-2 (Ohio)
* us-west-1 (N. California)
* us-west-2 (Oregon)

[id="gcp-regions-availability-zones_{context}"]
== {gcp-full} regions and availability zones
The following {gcp-full} regions are currently supported:

* asia-east1, Changhua County, Taiwan
* asia-east2, Hong Kong
* asia-northeast1, Tokyo, Japan
* asia-northeast2, Osaka, Japan
* asia-south1, Mumbai, India
* asia-south2, Delhi, India
* asia-southeast1, Jurong West, Singapore
* australia-southeast1, Sydney, Australia
* australia-southeast2, Melbourne, Australia
* europe-north1, Hamina, Finland
* europe-west1, St. Ghislain, Belgium
* europe-west2, London, England, UK
* europe-west3, Frankfurt, Germany
* europe-west4, Eemshaven, Netherlands
* europe-west6, Zürich, Switzerland
* europe-west8, Milan, Italy
* europe-west12, Turin, Italy
* europe-southwest1, Madrid, Spain
* northamerica-northeast1, Montréal, Québec, Canada
* southamerica-east1, Osasco (São Paulo), Brazil
* southamerica-west1, Santiago, Chile
* us-central1, Council Bluffs, Iowa, USA
* us-east1, Moncks Corner, South Carolina, USA
* us-east4, Ashburn, Northern Virginia, USA
* us-west1, The Dalles, Oregon, USA
* us-west2, Los Angeles, California, USA
* me-central1, Doha, Qatar
* me-central2, Dammam, Saudi Arabia

Multi-AZ clusters can only be deployed in regions with at least 3 availability zones (see link:https://aws.amazon.com/about-aws/global-infrastructure/regions_az/[AWS] and link:https://cloud.google.com/compute/docs/regions-zones[{gcp-full}]).

Each new {product-title} cluster is installed within a dedicated Virtual Private Cloud (VPC) in a single Region, with the option to deploy into a single Availability Zone (Single-AZ) or across multiple Availability Zones (Multi-AZ). This provides cluster-level network and resource isolation, and enables cloud-provider VPC settings, such as VPN connections and VPC Peering. Persistent volumes are backed by cloud block storage and are specific to the availability zone in which they are provisioned. Persistent volumes do not bind to a volume until the associated pod resource is assigned into a specific availability zone in order to prevent unschedulable pods. Availability zone-specific resources are only usable by resources in the same availability zone.

[WARNING]
====
The region and the choice of single or multi availability zone cannot be changed once a cluster has been deployed.
====