This topic describes the physical and logical organization of Oracle Cloud Infrastructure resources.
About Regions and Availability Domains
Oracle Cloud Infrastructure is hosted in regions and availability domains. A region is a localized geographic area, and an availability domain is one or more data centers located within a region. A region is composed of one or more availability domains. Most Oracle Cloud Infrastructure resources are either region-specific, such as a virtual cloud network, or availability domain-specific, such as a compute instance. Traffic between availability domains and between regions is encrypted.
Availability domains are isolated from each other, fault tolerant, and very unlikely to fail simultaneously. Because availability domains do not share infrastructure such as power or cooling, or the internal availability domain network, a failure at one availability domain within a region is unlikely to impact the availability of the others within the same region.
The availability domains within the same region are connected to each other by a low latency, high bandwidth network, which makes it possible for you to provide high-availability connectivity to the internet and on-premises, and to build replicated systems in multiple availability domains for both high-availability and disaster recovery.
Oracle is adding multiple cloud regions around the world to provide local access to cloud resources for our customers. To accomplish this quickly, we’ve chosen to launch regions in new geographies with one availability domain.
As regions require expansion, we have the option to add capacity to existing availability domains, to add additional availability domains to an existing region, or to build a new region. The expansion approach in a particular scenario is based on customer requirements as well as considerations of regional demand patterns and resource availability.
For any region with one availability domain, a second availability domain or region in the same country or geo-political area will be made available within a year to enable further options for disaster recovery that support customer requirements for data residency where they exist.
Regions are independent of other regions and can be separated by vast distances—across countries or even continents. Generally, you would deploy an application in the region where it is most heavily used, because using nearby resources is faster than using distant resources. However, you can also deploy applications in different regions for these reasons:
- To mitigate the risk of region-wide events such as large weather systems or earthquakes.
- To meet varying requirements for legal jurisdictions, tax domains, and other business or social criteria.
Regions are grouped into A logical collection of regions. Realms are isolated from each other and do not share any data. Your tenancy exists in a single realm and can access the regions that belong to that realm.. Your tenancy exists in a single realm and can access all regions that belong to that realm. You can't access regions that are not in your realm. Currently, Oracle Cloud Infrastructure has two realms: the commercial realm and the Government Cloud realm.
The following table lists the regions in the Oracle Cloud Infrastructure commercial A logical collection of regions. Realms are isolated from each other and do not share any data. Your tenancy exists in a single realm and can access the regions that belong to that realm.:
|Region Name||Region Identifier||Region Location||Region Key||Realm Key||Availability Domains|
|Australia East (Sydney)||ap-sydney-1||Sydney, Australia||SYD||OC1||1|
|Brazil East (Sao Paulo)||sa-saopaulo-1||Sao Paulo, Brazil||GRU||OC1||1|
|Canada Southeast (Toronto)||ca-toronto-1||Toronto, Canada||YYZ||OC1||1|
|Germany Central (Frankfurt)||eu-frankfurt-1||Frankfurt, Germany||FRA||OC1||3|
|India West (Mumbai)||ap-mumbai-1||Mumbai, India||BOM||OC1||1|
|Japan East (Tokyo)||ap-tokyo-1||Tokyo, Japan||NRT||OC1||1|
|South Korea Central (Seoul)||ap-seoul-1||Seoul, South Korea||ICN||OC1||1|
|Switzerland North (Zurich)||eu-zurich-1||Zurich, Switzerland||ZRH||OC1||1|
|UK South (London)||uk-london-1||London, United Kingdom||LHR||OC1||3|
|US East (Ashburn)||us-ashburn-1||Ashburn, VA||IAD||OC1||3|
|US West (Phoenix)||us-phoenix-1||Phoenix, AZ||PHX||OC1||3|
To subscribe to a region, see Managing Regions.
For a list of the Oracle Government Cloud regions, see Information for Oracle Cloud Infrastructure Government Cloud Customers.
Your Tenancy's Availability Domain Names
Oracle Cloud Infrastructure randomizes the availability domains by The root compartment that contains all of your organization's compartments and other Oracle Cloud Infrastructure cloud resources. to help balance capacity in the data centers. For example, the availability domain labeled PHX-AD-1 for tenancyA may be a different data center than the one labeled PHX-AD-1 for tenancyB. To keep track of which availability domain corresponds to which data center for each tenancy, Oracle Cloud Infrastructure uses tenancy-specific prefixes for the availability domain names. For example: the availability domains for your tenancy are something like Uocm:PHX-AD-1, Uocm:PHX-AD-2, and so on.
To get the specific names of your tenancy's availability domains, use the ListAvailabilityDomains operation, which is available in the IAM API. You can also see the names when you use the Console to launch an instance and choose which availability domain to launch the instance into.
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain contains three fault domains. Fault domains let you distribute your instances so that they are not on the same physical hardware within a single availability domain. A hardware failure or Compute hardware maintenance that affects one fault domain does not affect instances in other fault domains.
To control the placement of your compute, bare metal DB system, or virtual machine DB system instances, you can optionally specify the fault domain for a new instance at launch time. If you do not specify the fault domain, the system selects one for you. To change the fault domain for an instance, terminate it and launch a new instance in the preferred fault domain.
Use fault domains to:
- Protect against unexpected hardware failures.
- Protect against planned outages due to Compute hardware maintenance.
- See Fault Domains in Best Practices for Your Compute Instance for recommendations on using fault domains when provisioning application and database servers.
- See Fault Domain Considerations for 2-node Virtual Machine DB Systems and Availability Domain and Fault Domain Considerations for Data Guard for more information on using fault domains when provisioning Oracle bare metal and virtual machine DB systems.
Service Availability Across Regions
All Oracle Cloud Infrastructure regions offer core infrastructure services, including the following:
- Compute: Compute (Intel based Bare Metal & VM, DenseIO & Standard), Container Engine for Kubernetes, Registry
- Storage: Block Volume, File Storage, Object Storage, Archive Storage
- Networking: Virtual Cloud Network, Load Balancing, FastConnect (specific partners as available and requested)
- Database: Database, Exadata Cloud Service, Autonomous Data Warehouse, Autonomous Transaction Processing
- Edge: DNS
- Platform: Identity and Access Management, Tagging, Audit, Work Requests
Generally available cloud services beyond those in the preceding list are made available based on regional customer demand. Any service can be made available within a maximum of three months, with many services deploying more quickly. New cloud services are made available in regions as quickly as possible based on a variety of considerations including regional customer demand, ability to achieve regulatory compliance where applicable, resource availability, and other factors. Because of our low latency interconnect backbone, customers can use cloud services in other geographic regions with effective results when they are not available in their home region, provided that data residency requirements do not prevent them from doing so. We regularly work with customers to help ensure effective access to required services.
The following sections list the resource types based on their availability: global across regions, within a single region, or within a single availability domain.
In general: IAM resources are global. DB Systems, instances, and volumes are specific to an availability domain. Everything else is regional. Exception: Subnets were originally designed to be specific to an availability domain. Now, you can create regional subnets, which is what Oracle recommends.
- API signing keys
- dynamic groups
- federation resources
- tag namespaces
- tag keys
- buckets: Although buckets are regional resources, they can be accessed from any location if you use the correct region-specific Object Storage URL for the API calls.
- customer-premises equipment (CPE)
- DHCP options sets
- dynamic routing gateways (DRGs)
- encryption keys
- internet gateways
- key vaults
- load balancers
- local peering gateways (LPGs)
- NAT gateways
- network security groups
- node pools
- reserved public IPs
- route tables
- security lists
- service gateways
- subnets: When you create a subnet, you choose whether it's regional or specific to an availability domain. Oracle recommends using regional subnets.
- virtual cloud networks (VCNs)
- volume backups: They can be restored as new volumes to any availability domain within the same region in which they are stored.
Availability Domain-Specific Resources
- DB Systems
- ephemeral public IPs
- instances: They can be attached only to volumes in the same availability domain.
- subnets: When you create a subnet, you choose whether it is regional or specific to an availability domain. Oracle recommends using regional subnets.
- volumes: They can be attached only to an instance in the same availability domain.