VCNs and Subnets

This topic describes how to manage virtual cloud networks (VCNs) and the subnets in them. This
topic uses the terms virtual cloud network, VCN, and cloud network interchangeably.
The Consoleuses the term Virtual Cloud Network, whereas for brevity the API uses VCN.
Warning

Avoid entering confidential information when assigning descriptions, tags, or friendly names to
your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

Overview of VCNs and Subnets

A VCN is a software-defined network that you set up in the Oracle Cloud Infrastructure data
centers in a particular region . A subnet is a subdivision of a VCN. For an overview of VCNs,
allowed size, default VCN components, and scenarios for using a VCN, see Overview of
Networking.

You can privately connect a VCN to another VCN so that the traffic does not traverse the internet.
The CIDRs for the two VCNs must not overlap. For more information, see Access to Other VCNs:
Peering. For an example of an advanced routing scenario that involves the peering of multiple
VCNs, see Advanced Scenario: Transit Routing.

Each subnet in a VCN consists of a contiguous range of IP addresses that do not overlap with
other subnets in the VCN. Example: 172.16.1.0/24. The first two IP addresses and the last in the
subnet's CIDR are reserved by the Networking service. You can't change the size of the subnet
after creation, so it's important to think about the size of subnets you need before creating them.

Subnets act as a unit of configuration: all instances in a given subnet use the same route table,
security lists, and DHCP options. For more information, see Default Components that Come With
Your VCN.

Subnets can be either public or private (see Public vs. Private Subnets). You choose this during
subnet creation, and you can't change it later.

You can think of each Compute instance as residing in a subnet. But to be precise, each instance is
actually attached to a virtual network interface card (VNIC), which in turn resides in the subnet and
enables a network connection for that instance.

About Regional Subnets

Originally subnets were designed to cover only one availability domain (AD) in a region. They were
all AD-specific, which means the subnet's resources were required to reside in a
particular availability domain. Now subnets can be either AD-specific or regional. You choose the
type when you create the subnet. Both types of subnets can co-exist in the same VCN. In the
following diagram, subnets 1-3 are AD-specific, and subnet 4 is regional.

Aside from the removal of the AD constraint, regional subnets behave the same as AD-specific
subnets. Oracle recommends using regional subnets because they're more flexible. They make it
easier to efficiently divide your VCN into subnets while also designing for availability
domain failure.

When you create a resource such as a Compute instance, you choose which availability domain the
resource will be in. From a virtual networking standpoint, you must also choose which VCN and
subnet the instance will be in. You can either choose a regional subnet, or choose an AD-specific
subnet that matches the AD you chose for the instance.

Warning

If anyone in your organization implements a regional subnet, be aware that you may need to
update any client code that works with Networking service subnets and private IPs. There are
possible breaking API changes. For more information, see the regional subnet release note.

Working with VCNs and Subnets

One of the first things you do when working with Oracle Cloud Infrastructure resources is create a
VCN with one or more subnets. You can easily get started in the Console with a simple VCN and
some related resources that enable you to launch and connect to an instance. See Tutorial -
Launching Your First Linux Instance or Tutorial - Launching Your First Windows Instance.

For the purposes of access control, when you create a VCN or subnet, you must specify the
compartment where you want the resource to reside. Consult an administrator in your
organization if you're not sure which compartment to use. For more information, see Access
Control.

You may optionally assign friendly names to the VCN and its subnets. The names don't have to be
unique, and you can change them later. Oracle automatically assigns each resource a unique
identifier called an Oracle Cloud ID (OCID). For more information, see Resource Identifiers.

You can also add a DNS label for the VCN and each subnet, which are required if you want the
instances to use the Internet and VCN Resolver feature for DNS in the VCN. For more information,
see DNS in Your Virtual Cloud Network.

When you create a subnet, you may optionally specify a route table for the subnet to use. If you
don't, the subnet uses the cloud network's default route table. You can change which route table
the subnet uses at any time.

Also, you may optionally specify one or more security lists for the subnet to use (up to five). If you
don't specify any, the subnet uses the cloud network's default security list. You can change which
security list the subnet uses at any time. Remember that the security list rules are enforced at the
instance level, even though the list is associated at the subnet level.

Similarly, you may optionally specify a set of DHCP options for the subnet to use. All instances in
the subnet will receive the configuration specified in that set of DHCP options. If you don't specify
a set, the subnet uses the cloud network's default set of DHCP options. You can change which set
of DHCP options the subnet uses at any time.

To delete a subnet, it must contain no resources (no instances, load balancers, DB systems,
and orphaned mount targets). For more details, see Subnet or VCN Deletion.

To delete a VCN, its subnets must contain no resources. Also, the VCN must have no attached
gateways. If you're using the Console, there's a "Delete All" process you can use after first ensuring
the subnets are empty. See To delete a VCN.
 For information about the number of VCNs and subnets you can have, see Service Limits.

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be given the required type of access in
a policy written by an administrator, whether you're using the Console or the REST API with an
SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have
permission or are unauthorized, confirm with your administrator the type of access you've been
granted and which compartment you should work in.

For administrators: see IAM Policies for Networking.

Using the Console

To create a VCN
Note

The following procedure creates a VCN without any subnets or gateways for access. You must
manually create the subnets and other resources before you can use the VCN. For a quick
procedure that creates a VCN that you can try out immediately (that is, with subnets and an
internet gateway), see Scenario A: Public Subnet.

1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual
Cloud Networks.
2. Choose a compartment you have permission to work in (on the left side of the page). The page
updates to display only the resources in that compartment. If you're not sure which compartment
to use, contact an administrator. For more information, see Access Control.

3. Click Create Virtual Cloud Network.

4. Enter the following:

a. Name: A friendly name for the VCN. It doesn't have to be unique, and it cannot be changed later
in the Console (but you can change it with the API). Avoid entering confidential information.

b. Create in Compartment: Leave as is.

c. Create Virtual Cloud Network Only: Make sure this radio button is selected (the default).

d. CIDR Block: A single, contiguous CIDR block for the VCN. For example: 172.16.0.0/16.
You cannot change this value later. See Allowed VCN Size and Address Ranges. For reference,
here's a CIDR calculator.
e. Use DNS Hostnames in this VCN: If you want the instances in the VCN to have DNS hostnames
(which can be used with the built-in DNS capability in the VCN), select the Use DNS Hostnames
in this VCN check box. Then you can specify a DNS label for the VCN, or the Console will generate
one for you. The dialog box automatically displays the corresponding DNS Domain Name for the
VCN (<VCN DNS label>.oraclevcn.com). For more information, see DNS in Your Virtual Cloud
Network.

f. Tags: Optionally, you can apply tags. If you have permissions to create a resource, you also have
permissions to apply free-form tags to that resource. To apply a defined tag, you must have
permissions to use the tag namespace. For more information about tagging, see Resource Tags. If
you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your
administrator.

5. Click Create Virtual Cloud Network.

The VCN is then created and displayed on the Virtual Cloud Networks page in the compartment
you chose.

Next you'll typically want to create one or more subnets in the cloud network.
To create a subnet
1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual
Cloud Networks.
2. Click the VCN you're interested in.

3. Click Create Subnet.

4. In the Create Subnet dialog box, you specify the resources to associate with the subnet (for
example, a route table, and so on). By default, the subnet will be created in the current
compartment, and you'll choose the resources from the same compartment. Click the click
here link in the dialog box if you want to enable compartment selection for the subnet and each
of those resources.
Enter the following:

 Create in Compartment: If you've enabled compartment selection, specify the compartment

where you want to put the subnet.

 Name: A friendly name for the subnet. It doesn't have to be unique, and it cannot be changed
later in the Console (but you can change it with the API). Avoid entering confidential information.

 Regional or AD-specific subnet: Oracle recommends creating only regional subnets, which
means that the subnet can contain resources in any of the region's availability domains. If you
instead choose Availability Domain-Specific (the only kind of subnet that Oracle originally
offered), you must also specify an availability domain. This choice means that any instances or
other resources later created in this subnet must also be in that availability domain.
 CIDR Block: A single, contiguous CIDR block for the subnet (for example, 172.16.0.0/24). Make
sure it's within the cloud network's CIDR block and doesn't overlap with any other subnets.
You cannot change this value later. See Allowed VCN Size and Address Ranges. For reference,
here's a CIDR calculator.

 Route Table: The route table to associate with the subnet. If you've enabled compartment
selection, under Route Table Compartment, you must specify the compartment that contains the
route table.

 Private or public subnet: This controls whether VNICs in the subnet can have public IP addresses.
For more information, see Access to the Internet.

 Use DNS Hostnames in this Subnet:This option is available only if you provided a DNS label for
the VCN during creation. If you want this subnet's instances to have DNS hostnames (which can be
used with the built-in DNS capability in the VCN), select the check box for Use DNS Hostnames in
this Subnet. Then you may specify a DNS label for the subnet, or the Console will generate one
for you. The dialog box will automatically display the corresponding DNS Domain Name for the
subnet (<subnet DNS label>.<VCN DNS label>.oraclevcn.com). For more information, see DNS in Your
Virtual Cloud Network.

 DHCP Options: The set of DHCP options to associate with the subnet. If you've enabled
compartment selection, under DHCP Options Compartment, you must specify the compartment
that contains the set of DHCP options.

 Security Lists: One or more security lists to associate with the subnet. If you've enabled
compartment selection, you must specify the compartment that contains the security list.

 Tags: Optionally, you can apply tags. If you have permissions to create a resource, you also have
permissions to apply free-form tags to that resource. To apply a defined tag, you must have
permissions to use the tag namespace. For more information about tagging, see Resource Tags. If
you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your
administrator.

5. Click Create.
The subnet is then created and displayed on the Subnets page in the compartment you chose.

To edit a subnet
You can change these characteristics of a subnet:

 Name

 Which set of DHCP options the subnet uses

 Which route table the subnet uses

 Which security lists the subnet uses

1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual
Cloud Networks.
2. Click the VCN you're interested in.

3. Click Subnets.

4. Click the subnet you're interested in.

5. Click Edit.

6. Make your changes.

7. Click Save Changes.

The changes take effect within a few seconds.
To delete a subnet
Prerequisite: The subnet must have no instances, load balancers, DB systems, and orphaned mount
targets in it. For more information, see Subnet or VCN Deletion.

1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual
Cloud Networks.
2. Click the VCN you're interested in.

3. Click Subnets.

4. Click the subnet you're interested in.

5. Click Terminate.

6. Confirm when prompted.

If the subnet is empty, its state changes to TERMINATING briefly and then TERMINATED. If the
subnet is not empty, you get an error indicating that there are still instances or other resources in
it that you must delete first.
To delete a VCN
Important

The Console has an easy "Delete all" process that deletes a VCN and its
related Networkingresources (subnets, route tables, security lists, sets of DHCP options, internet
gateway, and so on). If the VCN is attached to a dynamic routing gateway (DRG), the attachment is
deleted, but the DRG remains.
 The "Delete All" process deletes one resource at a time and takes a minute or two. A progress
report is displayed to show you what's been deleted so far.

Before using the "Delete All" process, make sure there are no instances, load balancers, DB
systems, or orphaned mount targets in any of the subnets. For more information, see Subnet or
VCN Deletion.

If there are still resources in any subnet, or if you don't have permission to delete a
particular Networking resource, the "Delete All" process stops and an error message is displayed.
Any resources deleted up to that point cannot be restored. You might need to contact your
tenancy administrator to help you delete any remaining resources.

1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual
Cloud Networks.
2. Click the VCN you're interested in.

3. Click Terminate.
The resulting dialog box displays a list of the resources to be deleted. The list doesn't include
the default components that come with the VCN, but they will be deleted along with the VCN.
4. Click Delete All.
The process begins. The progress is displayed as each resource is deleted.
5. When the process is complete, click Close.

To manage tags for a VCN

1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual
Cloud Networks.
2. Click the VCN you're interested in.

3. Click the Tags tab to view or edit the existing tags. Or click Apply tag(s) to add new ones.

For more information, see Resource Tags.

To manage tags for a subnet
1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual
Cloud Networks.
2. Click the VCN you're interested in.

3. Click the subnet you're interested in.

4. Click the Tags tab to view or edit the existing tags. Or click Apply tag(s) to add new ones.

For more information, see Resource Tags.