Overview of VCNs and Subnets
Learn about virtual cloud networks (VCNs) and subnets in OCI.
This topic describes virtual cloud networks (VCNs) and the subnets in them. This topic uses the terms virtual cloud network, VCN, and cloud network interchangeably. The Console uses the term Virtual Cloud Network, whereas for brevity the API uses VCN.
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 Networking Overview.
A VCN can have multiple non-overlapping IPv4 CIDR blocks that you can change after you create the VCN. Regardless of the number of CIDR blocks, the max number of private IPs you can create within the VCN is 64,000. A VCN can optionally be enabled for IPv6 and Oracle will allocate a /56 prefix. You can also can import a BYOIP IPv6 prefix and assign it to an existing VCN or create a new VCN with a BYOIP or ULA IPv6 prefix.
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 Transit Routing inside a hub VCN.
Each subnet in a VCN consists of a contiguous range of IPv4 addresses and optionally IPv6 addresses that do not overlap with other subnets in the VCN. Example: 172.16.1.0/24. With IPv4 addresses as well as IPv6 addresses, the first two addresses and the last in the subnet's CIDR are reserved by the Networking service. You can change the size of the subnet after creation. IPv6-enabled subnets will always be /64.
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). The choice of public or private happens 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 attached to a virtual network interface card (VNIC), which in turn resides in the subnet and enables a network connection for that instance.
IPv6 addressing is supported for all commercial and government regions. For more information, see IPv6 Addresses.
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.
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 subnets release note.
VCN and Subnet Limits
|
Resource |
Scope |
Oracle Universal Credits |
Pay As You Go or Trial |
|---|---|---|---|
| VCN | Region | 50 | 10 |
| Subnets | VCN | 300 | 300 |
| IPv4 CIDRs | VCN | 5 | 5 |
| IPv6 Prefixes | VCN | 5 | 5 |
| IPv4 CIDRs | Subnet | 1 | 1 |
| IPv6 Prefixes | Subnet | 3* | 3* |
| Oracle allocated IPv6 prefix | Subnet | 1 | 1 |
| * Limit for this resource can be increased to a maximum of five. | |||
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.
You may optionally assign descriptive 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 rules are enforced at the instance level, even though the list is associated at the subnet level. Network security groups are an alternative to security lists and let you apply a set of security rules to a set of resources that all have the same security posture, instead of all the resources in a particular subnet.
You may optionally specify a set of DHCP options for the subnet to use. All instances in the subnet 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, OCI database 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 Deleting a VCN.
See Service Limits for a list of applicable limits and instructions for requesting a limit increase.
Required IAM Policy
To use Oracle Cloud Infrastructure, you must be granted security access in a policy by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don't have permission or are unauthorized, verify with your administrator what type of access you have and which compartment to work in.
For administrators: see IAM Policies for Networking.
Security Zones
Security Zones ensure that your cloud resources comply with Oracle security principles. If any operation on a resource in a security zone compartment violates a policy for that security zone, then the operation is denied.
The following security zone policies affect your ability to manage VCNs and subnets:
- Subnets in a security zone can't be public. All subnets must be private.
- You can't move a subnet from a security zone to a standard compartment.