Scenario A: Public Subnet

This topic explains how to set up Scenario A, which consists of a virtual cloud network (VCN) and a regional public subnet . There are public servers in separate availability domains  for redundancy. The VCN is directly connected to the internet by way of an internet gateway . The gateway is also used for connectivity to your on-premises network. Any resource in the on-premises network that needs to communicate with resources in the VCN must have a public IP address and access to the internet.

The subnet uses the default security list, which has default rules that are designed to make it easy to get started with Oracle Cloud Infrastructure. The rules enable typical required access (for example, inbound SSH connections and any type of outbound connections). Remember that security list rules only allow traffic. Any traffic not explicitly covered by a security list rule is implicitly denied.

In this scenario, you add additional rules to the default security list. You could instead create a custom security list for those rules. You would then set up the subnet to use both the default security list and the custom security list.

Tip

Security lists are one way to control traffic in and out of the VCN's resources. You can also use network security groups, which let you apply a set of security rules to a set of resources that all have the same security posture.

The subnet uses the default route table, which starts out with no rules when the VCN is created. In this scenario, the table has only a single rule for the internet gateway.

See the following figure.

This image shows Scenario A: a VCN with a regional public subnet and internet gateway.

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.

If you're a member of the Administrators group, you already have the required access to execute Scenario A. Otherwise, you need access to Networking, and you need the ability to launch instances. See IAM Policies for Networking.

Setting Up Scenario A in the Console

Setup is easy in the Console.

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.
Task 1: Create the VCN
  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:
    • Name: A descriptive 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.
    • Create in Compartment: Leave as is.
    • 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.
    • Enable IPv6 Address Assignment: This option is available only if the VCN is in the Government Cloud. For more information, see IPv6 Addresses.
    • Use DNS Hostnames in this VCN: Required for assignment of DNS hostnames to hosts in the VCN, and required if you plan to use the VCN's default DNS feature (called the Internet and VCN Resolver). If the check box is selected, 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.
    • 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.

Task 2: Create the regional public subnet
  1. While still viewing the VCN, click Create Subnet.
  2. Enter the following:

    • Name: A friendly name for the subnet (for example, Regional Public 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 Availability Domain-Specific: Select Regional (recommended), which means the subnet spans all availability domains in the region. Later when you launch an instance, you can create it in any availability domain in the region. For more information, see Overview of VCNs and Subnets.
    • CIDR Block: A single, contiguous CIDR block within the VCN's CIDR block. For example: 172.16.0.0/24. You cannot change this value later. For reference, here's a CIDR calculator.
    • Enable IPv6 Address Assignment: This option is available only if the VCN is in the US Government Cloud. For more information, see IPv6 Addresses.
    • Route Table: Select the default route table.
    • Private or public subnet: Select Public Subnet, which means instances in the subnet can optionally 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. The option is required for assignment of DNS hostnames to hosts in the subnet, and required if you plan to use the VCN's default DNS feature (called the Internet and VCN Resolver). If the check box is selected, you can specify a DNS label for the subnet, or the Console will generate one for you. The dialog box automatically displays 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: Select the default set of DHCP options.
    • Security Lists: Make sure the default security list is selected (the default).
    • Tags: Leave as is. You can add tags later if you want. For more information, see Resource Tags.
  3. Click Create Subnet.

    The subnet is then created and displayed on the Subnets page.

Task 3: Create the internet gateway
  1. Under Resources, click Internet Gateways.
  2. Click Create Internet Gateway.
  3. Enter the following:

    • Name: A friendly name for the internet gateway. 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.
    • Create in Compartment: Leave as is.
    • Tags: Leave as is. You can add tags later if you want. For more information, see Resource Tags.
  4. Click Create Internet Gateway.

    Your internet gateway is created and displayed on the Internet Gateways page. It's already enabled, but you must add a route rule that allows traffic to flow to the gateway.

Task 4: Update the default route table to use the internet gateway

The default route table starts out with no rules. Here you add a rule that routes all traffic destined for addresses outside the VCN to the internet gateway. The existence of this rule also enables inbound connections to come from the internet to the subnet, through the internet gateway. You use security list rules to control the types of traffic that are allowed in and out of the instances in the subnet (see the next task).

No route rule is required in order to route traffic within the VCN itself.

  1. Under Resources, click Route Tables.
  2. Click the default route table to view its details.
  3. Click Add Route Rule.
  4. Enter the following:

    • Target Type: Internet Gateway
    • Destination CIDR block: 0.0.0.0/0 (which means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule)
    • Compartment: The compartment where the internet gateway is located.
    • Target: The internet gateway you created.
    • Description: An optional description of the rule.
  5. Click Add Route Rule.

The default route table now has a rule for the internet gateway. Because the subnet was set up to use the default route table, the resources in the subnet can now use the internet gateway. The next step is to specify the types of traffic you want to allow in and out of the instances you later create in the subnet.

Task 5: Update the default security list

Earlier you set up the subnet to use the VCN's default security list. Now you add security list rules that allow the types of connections that the instances in the VCN will need.

For example: This is a public subnet with an internet gateway, so the instances your launch might need to receive inbound HTTPS connections from the internet (if they're web servers). Here's how to add another rule to the default security list to enable that traffic:

  1. Under Resources, click Security Lists.
  2. Click the default security list to view its details. By default, you land on the Ingress Rules page.
  3. Click Add Ingress Rule.
  4. To enable inbound connections for HTTPS (TCP port 443), enter the following:

    • Stateless: Unselected (this is a stateful rule)
    • Source Type: CIDR
    • Source CIDR: 0.0.0.0/0
    • IP Protocol: TCP
    • Source Port Range: All
    • Destination Port Range: 443
    • Description: An optional description of the rule.
  5. Click Add Ingress Rule.
Important

Security List Rule for Windows Instances

If you're going to launch Windows instances, you need to add a security list rule to enable Remote Desktop Protocol (RDP) access. Specifically, you need a stateful ingress rule for TCP traffic on destination port 3389 from source 0.0.0.0/0 and any source port. For more information, see Security Lists.

For a production VCN, you typically set up one or more custom security lists for each subnet. If you like, you can edit the subnet to use different security lists. If you choose not to use the default security list, do so only after carefully assessing which of its default rules you want to duplicate in your custom security list. For example: the default ICMP rules in the default security list are important for receiving connectivity messages.

Task 6: Create instances in separate availability domains

Your next step is to create one or more instances in the subnet. The scenario's diagram shows instances in two different availability domains. When you create the instance, you choose the AD, which VCN and subnet to use, and several other characteristics.

Each instance automatically gets a private IP address. When you create an instance in a public subnet, you choose whether the instance gets a public IP address. With this network setup in Scenario A, you must give each instance a public IP address, or else you can't access them through the internet gateway. The default (for a public subnet) is for the instance to get a public IP address.

After creating an instance in this scenario, you can connect to it over the internet with SSH or RDP from your on-premises network or other location on the internet. For more information and instructions, see Launching an Instance.

Setting Up Scenario A with the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use the following operations:

  1. CreateVcn: Make sure to include a DNS label for the VCN if you want the instances to have hostnames (see DNS in Your Virtual Cloud Network).
  2. CreateSubnet: Create one regional public subnet. Include a DNS label for the subnet if you want the instances to have hostnames. Use the default route table, default security list, and default set of DHCP options.
  3. CreateInternetGateway
  4. UpdateRouteTable: To enable communication with the internet gateway, update the default route table to include a route rule with destination = 0.0.0.0/0, and destination target = the internet gateway. This rule routes all traffic destined for addresses outside the VCN to the internet gateway. No route rule is required in order to route traffic within the VCN itself.
  5. UpdateSecurityList: To allow specific types of connections to and from the instances in the subnet.
Important

Security List Rule for Windows Instances

If you're going to launch Windows instances, you need to add a security list rule to enable Remote Desktop Protocol (RDP) access. Specifically, you need a stateful ingress rule for TCP traffic on destination port 3389 from source 0.0.0.0/0 and any source port. For more information, see Security Lists.

Your next step is to create one or more instances in the subnet. The scenario's diagram shows instances in two different availability domains. When you create the instance, you choose the AD, which VCN and subnet to use, and several other characteristics.

Each instance automatically gets a private IP address. When you create an instance in a public subnet, you choose whether the instance gets a public IP address. With this network setup in Scenario A, you must give each instance a public IP address, or else you can't access them through the internet gateway. The default (for a public subnet) is for the instance to get a public IP address.

After creating an instance in this scenario, you can connect to it over the internet with SSH or RDP from your on-premises network or other location on the internet. For more information and instructions, see Launching an Instance.