When you work with Oracle Cloud Infrastructure, one of the first steps is to set up a virtual cloud network (VCN) for your cloud resources. This topic gives you an overview of Oracle Cloud Infrastructure Networking components and typical scenarios for using a VCN.
The Networking service uses virtual versions of traditional network components you might already be familiar with:
- virtual cloud network (vcn)
- A private network that you set up in the Oracle data centers, with firewall rules and specific types of communication gateways that you can choose to use. A VCN covers a single, contiguous IPv4 CIDR block of your choice. See Default Components that Come With Your VCN. The terms virtual cloud network, VCN, and cloud network are used interchangeably in this documentation. For more information, see VCNs and Subnets.
- Subdivisions you define in a VCN (for example, 10.0.0.0/24 and 10.0.1.0/24). Subnets contain virtual network interface cards (VNICs), which attach to instances. Each subnet exists in a single availability domainOne or more isolated, fault-tolerant Oracle data centers that host cloud resources such as instances, volumes, and subnets. A region contains several availability domains. and consists of a contiguous range of IP addresses that do not overlap with other subnets in the VCN. Subnets act as a unit of configuration within the VCN: All VNICs in a given subnet use the same route table, security lists, and DHCP options (see the definitions that follow). You can designate a subnet as private when you create it, which means VNICs in the subnet can't have public IP addresses. See Internet Access.
- A virtual network interface card (VNIC), which attaches to an instance and resides in a subnet to enable a connection to the subnet's VCN. The VNIC determines how the instance connects with endpoints inside and outside the VCN. Each instance has a primary VNIC that's created during instance launch and cannot be removed. You can add secondary VNICs to an existing instance (in the same availability domain as the primary VNIC), and remove them as you like. For more information, see Virtual Network Interface Cards (VNICs).
- private ip
- A private IP address and related information for addressing an instance (for example, a hostname for DNS). Each VNIC has a primary private IP, and you can add and remove secondary private IPs. For more information, see Private IP Addresses.
- public ip
- A public IP address and related information. You can optionally assign a public IP to your instances or other resources that have a private IP. Public IPs can be either ephemeral or reserved. For more information, see Public IP Addresses.
- internet gateway
- An optional virtual router that you can add to your VCN. It provides a path for network traffic between your VCN and the internet. For more information, see Internet Access and also Typical Networking Scenarios.
- dynamic routing gateway (drg)
- Another optional virtual router that you can add to your VCN. It provides a path for private network traffic between your VCN and on-premises network. You can use it with other Networking components and a router in your on-premises network to establish a connection via IPSec VPN or Oracle Cloud Infrastructure FastConnect. For more information, see Connection to Your On-Premises Network and also Dynamic Routing Gateways (DRGs).
- local peering gateway (LPG)
- Another optional virtual router that you can add to your VCN. It provides a path for private network traffic between your VCN and another VCN in the same region. For more information, see VCN Peering.
- route tables
- Virtual route tables for your VCN. Your VCN comes with a default route table, and you can add more. These route tables provide mapping for the traffic from subnets via gateways or specially configured instances to destinations outside the VCN. For more information, see Route Tables.
- security lists
- Virtual firewall rules for your VCN. Your VCN comes with a default security list, and you can add more. These security lists provide ingress and egress rules that specify the types of traffic allowed in and out of the instances. You can choose whether a given rule is stateful or stateless. For more information, see Security Lists.
- dhcp options
- Configuration information that is automatically provided to the instances when they boot up. For more information, see DHCP Options.
A VCN covers a single, contiguous IPv4 CIDR block of your choice. The allowable VCN size range is /16 to /30. Example: 10.0.0.0/16. The Networking service reserves the first two IP addresses and the last one in each subnet's CIDR. After you've created a VCN or subnet, you can't change its size, so it's important to think about the size of VCN and subnets you need before creating them.
For your VCN, Oracle recommends using one of the private IP address ranges specified in RFC 1918 (10.0.0.0/8, 172.16/12, and 192.168/16). However, you can use a publicly routable range. Regardless, this documentation uses the term private IP address when referring to IP addresses in your VCN's CIDR.
Your VCN automatically comes with some default components (default route table, default security list, default set of DHCP options). You can’t delete these default components; however, you can change their contents (for example, the individual route rules). And you can create more of each kind of component in your cloud network (additional route tables).
When you create a new subnet, you can associate a route table with it. If you don’t, the default route table is automatically associated with the subnet. The same is true for security lists and sets of DHCP options. After you associate a particular route table, security list, or set of DHCP options with a subnet (whether it’s the default or not), you can’t change that association. But as mentioned before, you can change the contents of the component.
You can set up your VCN to have access to the internet if you like. You can also privately connect your VCN to your on-premises network and to another VCN.
For an instance in a given subnet to have direct access to the internet:
- The VCN must have an internet gateway that is enabled.
- The subnet must be public.
The subnet must have a route rule that directs traffic to the internet gateway.
- The subnet must have security list rules that allow the traffic (and each instance's firewall must allow the traffic).
The instance must have a public IP address.
For your instances to have access to any public IP addresses outside the VCN, an internet gateway and the other components mentioned above are required. However, when an internet gateway receives traffic from your VCN destined for a public IP address that is part of Oracle Cloud Infrastructure (such as Object Storage), the internet gateway routes the traffic to the destination without sending the traffic over the internet.
Instances without public IP addresses or access to an internet gateway cannot access the internet directly. However, you can configure a subnet to access the internet indirectly by either:
- Setting up an instance in your VCN to perform Network Address Translation (NAT). For information about routing subnet traffic to an instance, see Using a Private IP as a Route Target.
- Connecting your VCN to your on-premises network via a DRG and then routing your internet traffic to your on-premises network. Your on-premises network must be configured to route traffic to the internet. For more information, see Connection to Your On-Premises Network.
When you create a subnet, by default it's considered public, which means instances in that subnet are allowed to have public IP addresses. Whoever launches the instance chooses whether it will have a public IP address. You can override that behavior when creating the subnet and request that it be private, which means instances launched in the subnet are prohibited from having public IP addresses. Network administrators can therefore ensure that instances in the subnet have no internet access, even if the VCN has a working internet gateway, and security lists and firewall rules allow the traffic.
Each instance has a primary VNIC that's created during instance launch and cannot be removed. You can add secondary VNICs to an existing instance (in the same availability domain as the primary VNIC) and remove them as you like.
Every VNIC has a private IP address from the associated subnet's CIDR. You can choose the particular IP address (during instance launch or secondary VNIC creation), or Oracle can choose it for you. You can also add secondary private IPs to a VNIC.
If the VNIC is in a public subnet, then each private IP on that VNIC can have a public IP assigned to it at your discretion. Oracle chooses the particular IP address. There are two types of public IPs: ephemeral and reserved. An ephemeral public IP exists only for the lifetime of the private IP it's assigned to. In contrast, a reserved public IP exists as long as you want it to. You maintain a pool of reserved public IPs and allocate them to your instances at your discretion. You can move them from resource to resource in a region as you need to.
There are two ways to connect your on-premises network to Oracle Cloud Infrastructure:
- IPSec VPN: Offers multiple IPSec tunnels between your existing network's edge and your VCN, by way of a DRG that you create and attach to your VCN.
- Oracle Cloud Infrastructure FastConnect: Offers a private connection between your existing network's edge and Oracle Cloud Infrastructure. Traffic does not traverse the internet. Both private peering and public peering are supported. That means you can access private IPv4 addresses in your VCN as well as regional public IPv4 addresses in Oracle Cloud Infrastructure (for example, Object Storage or public load balancers in your VCN).
You can use one or both types of the preceding connections. If using both, you can use them simultaneously, or in a redundant configuration.
Connection to Another VCN
You can connect your VCN to another VCN in the same region and tenancy over a private connection that doesn't require the traffic to traverse the internet. In general, this type of connection is referred to as local VCN peering. Each VCN must have a local peering gateway, as well as specific IAM policies, route rules, and security lists that permit the connection to be made and the desired network traffic to flow over the connection. For more information, see VCN Peering.
This section describes several typical scenarios for using a VCN.
Scenario A: Public Subnets
This is the fastest way to try out Networking. The following figure illustrates the scenario. You set up a VCN with:
- One public subnet per availability domain
- An internet gateway
- A corresponding route rule in the default route table
- The default security list
- The default set of DHCP options
You then launch one or more compute instances A Bare Metal Cloud compute host. The image used to launch the instance determines its operating system and other software. The shape specified during the launch process determines the number of CPUs and memory allocated to the instance.in one of the subnets. In this scenario, each instance gets both a public and private IP address. You can then communicate with the instances via the public IP address over the internet from your on-premises network.
For instructions on using the Console or API to set up a VCN with public subnets, see Scenario A: Public Subnets.
Scenario B: Private Subnets with an IPSec VPN
In this scenario you set up a VCN with:
- Two private subnets in separate availability domains (to illustrate redundancy)
- A virtual private network connection (IPSec VPN) to provide private communication with your on-premises network
- A corresponding route rule in the default route table
- A modified default security list, with additional rules to allow these additional types of traffic:
- Stateful ingress rule for traffic from anywhere on TCP port 80 (HTTP)
- Stateful ingress rule for traffic from anywhere on TCP port 443 (HTTPS)
- Stateful ingress rule for traffic from anywhere on TCP port 1521 (for Oracle databases)
- The default set of DHCP options
For additional security, you could modify all the security list ingress rules to allow traffic only from within your VCN and your on-premises network.
The following figure illustrates the general layout. To use this scenario, you must have a network administrator configure the router at your end of the IPSec VPN. You can then launch an instance in your VCN and communicate with it using its private IP address from your on-premises network.
You might use this scenario, for example, if you want to extend your private database servers in your on-premises network into the cloud.
For instructions on using the Console or API to set up a VCN with private subnets and IPSec VPN, see Scenario B: Private Subnets with a VPN.
Scenario C: Public and Private Subnets
In this scenario you set up a VCN with:
- Both a public subnet and a private subnet in a single availability domain
- Similar subnets in a second availability domain for redundancy
- An internet gateway so the instances in the public subnets can communicate with the internet using their public IP addresses
- An IPSec VPN so the instances in the private subnets can communicate securely with your on-premises network using their private IP addresses
- Two route tables to direct traffic out of the VCN—one for traffic to the internet and one for traffic to your on-premises network
- A modified default security list, where you change all the existing stateful ingress rules to allow traffic only from your on-premises network's CIDR block
- A separate security list just for the public subnets, with these rules:
- Stateful ingress rule for traffic from anywhere, on TCP ports 80 (HTTP) and 443 (HTTPS)
- Stateful egress rule for any traffic to the private subnets on TCP port 1521 (for Oracle databases)
- A separate security list just for the private subnets, with these rules:
- Stateful ingress rule for any traffic from the public subnets, on TCP port 1521 (for Oracle databases)
- Stateful ingress rule for any traffic in the private subnets, on TCP port 1521 (for Oracle databases)
- Stateful egress rule for any traffic in the private subnets on TCP port 1521 (for Oracle databases)
- The default set of DHCP options
Notice that the public subnet would use both the default security list and the public subnet security list. Likewise, the private subnet would use both the default security list and the private subnet security list. The default security list contains a core set of stateful rules that all subnets in the scenario need to use.
The following figure illustrates the general layout. To use this scenario, you must have a network administrator configure the router at your end of the IPSec VPN.
You might use this scenario to host a cloud-based website that's connected to a database. The web servers reside in the public subnet and are thus reachable from the internet. The database servers reside in the private subnet.
For instructions on using the Console or API to set up a VCN with public and private subnets, see Scenario C: Public and Private Subnets with a VPN.
Regions and Availability Domains
Your VCN resides in a single Oracle Cloud Infrastructure region. Each subnet resides in a single availability domain (AD). Availability domains are designed to provide isolation and redundancy in your VCN, as illustrated in Scenario B and C earlier. For example, you could set up your primary set of subnets in a single AD, and then set up a duplicate set of subnets in a secondary AD. The two ADs are isolated from each other in the Oracle data centers, so if one fails, you can easily switch over to the other AD. For more information, see Regions and Availability Domains.
Public IP Addresses for Oracle Data Centers
The Oracle Cloud Infrastructure data centers use the following CIDR blocks for public IP addresses. You should whitelist these on your on-premises network.
Ashburn (IAD) region:
Frankfurt (FRA) region:
Phoenix (PHX) region:
The following IP addresses are reserved for Oracle Cloud Infrastructure use:
Each Oracle Cloud Infrastructure resource has a unique, Oracle-assigned identifier called an Oracle Cloud ID (OCID). For information about the OCID format and other ways to identify your resources, see Resource Identifiers.
You can access Oracle Cloud Infrastructure using the Console (a browser-based interface) or the REST API. Instructions for the Console and API are included in topics throughout this guide. For a list of available SDKs, see SDKs and Other Tools.
To access the Console, you must use a supported browser. You can use the Console link at the top of this page to go to the sign-in page. You will be prompted to enter your cloud tenant, your user name, and your password.
For general information about using the API, see About the API.
Authentication and Authorization
Each service in Oracle Cloud Infrastructure integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API).
An administrator in your organization needs to set up groupsA collection of users who all need a particular type of access to a set of resources or compartment., compartmentsA collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization., and policiesA document in the IAM that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. that control which users can access which services, which resources, and the type of access. For example, the policies control who can create new users, create and manage the cloud network, launch instances, create buckets, download objects, etc. For more information, see Getting Started with Policies. For specific details about writing policies for each of the different services, see Policy Reference.
If you’re a regular user (not an administrator) who needs to use the Oracle Cloud Infrastructure resources that your company owns, contact your administrator to set up a user ID for you. The administrator can confirm which compartment or compartments you should be using.
See Service Limits for a list of applicable limits and instructions for requesting a limit increase.