Learn About Setting Up the Basic Infrastructure for a Cloud Environment

Any cloud deployment requires a basic set of networking resources. You also need to control how your resources can be accessed and managed from outside the cloud. To deploy and manage your topology efficiently, define your cloud infrastructure as code (IaC) in Terraform configuration files.

To change the topology, version the appropriate Terraform modules, update the resource definitions, and apply the revised configuration. When necessary, you can roll back to a previous version of the infrastructure easily.

Use the Terraform building blocks provided in this solution to deploy the basic infrastructure required for a cloud environment. By creating this basic topology and then tuning it to suit your business requirements, you save significant time and effort.


The sample topology that this solution provides Terraform code for contains a single virtual cloud network (VCN) with the required gateways and networking resources, all in a single Oracle Cloud Infrastructure region.

Sample cloud topology
The architecture consists of the following components:


The Terraform code includes input variables, which you can use to tune the architecture to suit your technical and business requirements.
  • Virtual cloud network (VCN)

    All the resources in the topology are in a single network. You define the CIDR prefix for the network (default:

  • Subnets
    The VCN in the sample topology contains the following subnets. You define the sizes of the subnets.
    Subnet Default CIDR Prefix Description
    Bastion subnet A public subnet for the optional bastion host.
    Admin subnet A private subnet for the optional admin host, which contains tools to manage the resources, such as the Oracle Cloud Infrastructure CLI.


    Besides the bastion and admin subnets, the architecture diagram includes subnets for the load balancer nodes and application hosts. Those subnets are not defined in the Terraform code that this solution provides. The additional subnets in the diagram show the flow of traffic when you extend the architecture to deploy applications in a private subnet with a public-facing load balancer.

    All the subnets defined in the sample topology are regional; that is, they span all the availability domains in the region. So they are protected against availability-domain failure. You can use a regional subnet for resources that you deploy to any availability domain in the region.

  • Network gateways
    • Service gateway (optional)

      The service gateway enables resources in the VCN to access Oracle services such as Oracle Cloud Infrastructure Object Storage, Oracle Cloud Infrastructure File Storage, and Oracle Cloud Infrastructure Database privately; that is, without exposing the traffic to the public internet. Connections over the service gateway can be initiated from the resources within the VCN, and not from the services that the resources communicate with.

    • NAT gateway (optional)

      The NAT gateway enables compute instances that are attached to private subnets in the VCN to access the public internet. Connections through the NAT gateway can be initiated from the resources within the VCN, and not from the public internet.

    • Internet gateway

      The internet gateway enables connectivity between the public internet and any resources in public subnets within the VCN.

  • Bastion host (optional)

    The bastion host is a compute instance that serves as the entry point to the topology from outside the cloud.

    The bastion host is provisioned typically in a DMZ. It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. You expose a single, known entry point that you can audit regularly. So you avoid exposing the more sensitive components of the topology, without compromising access to them.

    The bastion host in the sample topology is attached to a public subnet and has a public IP address. An ingress security rule is configured to allow SSH connections to the bastion host from the public internet. To provide an additional level of security, you can limit SSH access to the bastion host from only a specific block of IP addresses.

    You can access Oracle Cloud Infrastructure instances in private subnets through the bastion host. To do this, enable ssh-agent forwarding, which allows you to connect to the bastion host, and then access the next server by forwarding the credentials from your computer. You can also access the instances in the private subnet by using dynamic SSH tunneling. The dynamic tunnel provides a SOCKS proxy on the local port; but the connections originate from the remote host.

  • Admin host (optional)

    By using an admin host, you can avoid installing and running infrastructure-management tools such as the Oracle Cloud Infrastructure CLI outside the cloud. The admin host in the sample topology is in a private subnet, and can be accessed through the bastion host. To be able to run the Oracle Cloud Infrastructure CLI on the admin host, you must designate it as an instance principal.

About Required Services and Permissions

This solution requires the following services and permissions:

Service Required Permissions
Oracle Cloud Infrastructure Identity and Access Management Manage dynamic groups and policies.
Oracle Cloud Infrastructure Networking Manage VCNs, subnets, internet gateways, NAT gateways, service gateways, route tables, and security lists.
Oracle Cloud Infrastructure Compute Manage compute instances.