Regional subnets

Historically, subnets in your VCN have been specific to a particular availability domain (AD). When you create an AD-specific subnet, you specify which AD in the region you want the subnet to be in. Later when you create a Compute instance or other resource in the VCN, you specify a subnet, and the resource must reside in the same AD as the subnet.

Now, you can create regional subnets, which span all ADs in the region. Regional subnets have a null availability domain attribute. You choose whether the subnet is regional or AD-specific during creation. Aside from the removal of the AD constraint, regional subnets behave the same as AD-specific subnets. Your existing AD-specific subnets continue to work as designed. A VCN can have both AD-specific and regional subnets.

Use of regional subnets means:

• You have flexibility to choose any AD in the region when you create an instance or other resource. The choice is no longer tied to which AD the subnet is in.
• It's easier to implement failover across ADs. With a regional subnet, you can easily move a secondary private IP from an instance in one AD to another instance in another AD.

To use regional subnets, you must:

1. Create one or more regional subnets in the VCN. Note: The Console has a handy "Create a VCN" wizard that quickly sets up a VCN with related resources such as subnets and an internet gateway. The behavior of that wizard has not changed. At this time, it still creates one subnet in each AD in the region. It does not create any regional subnets in the VCN.
2. Choose a regional subnet when you create a new resource such as a Compute instance.

For example, when you create an instance in a VCN, you must first specify an AD for the instance. Then when you choose the VCN and subnet to hold the instance, you can choose from any of the applicable subnets. This includes the ones specific to the AD you chose, and the regional ones, which are flagged with "regional" in parentheses at the end of the name.

Resources That Can Be Created in Regional Subnets

The majority of the resources that you create in a particular subnet can be created in regional subnets. These reseources are supported:

• Compute instances
• DB systems
• Load balancers
• Mount targets for file systems

You cannot yet use Container Engine for Kubernetes to create Kubernetes clusters in a regional subnet. At the time of this release, clusters must still use AD-specific subnets.

Also, Oracle Cloud Infrastructure services that are currently in limited availability (LA) might support only AD-specific subnets when the service becomes generally available (GA). However, support for regional subnets will come later.

Availability Domain for a Private IP

The availability domain attribute for the primary private IP for any VNIC on the instance will always be set to the instance's availability domain and never be null (blank), even if the instance is in a regional subnet. However, if the instance is in a regional subnet, any secondary private IPs that you create for that instance will have a null availability domain.

Possible Breaking API Changes If Your Organization Uses a Regional Subnet

Important: This is applicable ONLY if you or other users with appropriate access in your organization create a regional subnet in a VCN. If this is not the case, you are not affected.

If your organization creates a regional subnet in a VCN, you must update the code for all your clients that work with the Networking service subnets and private IPs. The APIs for these resources have changed as part of the regional subnet release. See the following details.

Subnets

• Subnet object: The availabilityDomain attribute can now be null, which indicates that the subnet is regional. If you're using the CLI, this is the availability-domain parameter in the JSON.
• CreateSubnetDetails object: The availabilityDomain attribute is no longer required. If you don't provide a value, that indicates that you want the subnet to be regional. If you're using the CLI and want to create a regional subnet, omit the availability-domain option in the oci network subnet create command.

Private IPs

• PrivateIp object: For secondary private IPs only, the availabilityDomain attribute can now be null, which indicates the private IP is in a regional subnet. If you're using the CLI, this is the availability-domain parameter in the JSON.
• For primary private IPs, there's no change to the PrivateIp object. The primary private IP on any VNIC always has the availabilityDomain attribute set to the instance's availability domain, regardless of whether the VNIC is in a regional subnet.

IMPORTANT: Be aware that the preceding changes to the Subnet object and PrivateIp object may cause problems for your existing code if it assumes the availabilityDomain attribute of these objects cannot be null. Before creating any regional subnets or private IPs, make sure to update any code to handle the possibility of these objects having a null availabilityDomain.