Identify VCN Topology and Specifications
Decide which VCN topology and what VCN specifications address your business needs.
Single Network Architecture
The following diagram shows an example of a single network architecture:
Hub-and-Spoke Network Architecture
The Hub-and-Spoke Network architecture is Oracle's recommended approach for deployments that require scaling in future.
This architecture allows for deployments like firewalls, traffic inspections management nodes, and so on, and enables you to implement a firewall software between on-premises and OCI or between VCNs. The following diagram shows an example of using a hub-and-spoke network architecture:
Choose a hub-and-spoke architecture if your business requires one or more of the following:
- Expand to include more VCNs in future
- Span several separate VCNs due to local regulatory requirements
- Separate customers on separate VCNs
- Require virtual network separation for production, test, and development environments
- Require transit routing capabilities with firewall in hub VCN
Virtual Cloud Network Specifications
Oracle recommends use of all the available capabilities to make the architecture as resilient as possible. In regions where there are three availability domains, make use of them and allow subnets to span across all the availability domains.
The following image shows how you can maximize the use of availability domains for high availability designs.
Oracle recommends using regional subnets that span all availability domains in a region and separate VCNs for different workloads.
Note:
If you plan to use the architecture in a region with a single availability domain, then use fault domains to build better resiliency within one availability domain.
Size Your VCN or Subnets
Size your VCNs to allow for future expansion and choose an IP address range that doesn't overlap with on-premises or other networks you might connect to.
The following table helps you decide how to size your VCNs based on your need.
| VCN Size | Netmask | Subnet Size | Number of Subnets in VCN | Usable IPs per Subnet |
|---|---|---|---|---|
| Small | /24 | /27 | 8 | 30 |
| Medium | /20 | /24 | 16 | 254 |
| Large | /18 | /22 | 16 | 1022 |
| Extra Large | /16 | /20 | 8 | 4094 |
Security Lists and Network Security Groups
Security lists provide comprehensive security to applications with security rules applied at every subnet. But if you have multiple resources that require different security postures within a given subnet and you need to control traffic at a more granular application level, an NSG lets you create these granular rules and add multiple resources to them.
The following graphic shows an example of how you can separate the VCN's subnet architecture from the security requirements using NSGs.
You can use Security Lists or Network Security Groups (NSG) to control access to your resources in both private and public subnets. You can use them together or separately.
Oracle recommends using NSGs over security lists because NSGs enable you to separate the VCNs subnet architecture from the security requirements of your application. Use NSGs to define a set of ingress and egress rules that apply to specific VNICs.
Security lists let you define a set of security rules that apply to all the VNICs in a subnet. In the following example security list which includes three subnets, the rules will apply to all three of the subnets contained within the security list:
- Subnet 1 10.0.0/24
- Subnet 2 10.0.1.0/24
- Subnet 3 10.0.2.0/24
Consider an example where the NSG includes VNICs and security rules. NSG group rules apply to VNICs that are added to the NSG.
Note:
Oracle recommends using private subnets with individual route tables to control the flow of traffic within and outside of VCN.