Define Workload Requirements
Communication Requirements
OCI Communication Gateways
Select the appropriate communication gateways based on your workload's requirements from the following table:
| Feature | Recommended Gateway | Comments |
|---|---|---|
| Traffic in and out of OCI can be initiated from OCI or the internet | Internet Gateway | Need a public subnet and a resource with public IP |
| Resources in OCI access internet securely | NAT Gateway | Only traffic initiated from within the subnet is allowed through the NAT Gateway |
| Access to Oracle Cloud Infrastructure Object Storage or other services in Oracle Service Network | Service Gateway | Examples of services are OS management service, Oracle Linux, or Yum
Service. See the Explore section
for a full list of supported services in OSN
|
| Connection between OCI and on-premises and between VCNs | DRG | A virtual router connects VCNs and on-premises locations through a central connection point and also connects between regions and different tenancies |
Inter-VCN Connectivity
Oracle recommends using DRGs for the inter-VCN connectivity. DRG provides scalable path for connectivity not only between VCNs but also from on-premises and other clouds. Dynamic route importing reduces management complexity. For specific routing needs between two VCNs, use a Local Peering Gateway (LPG). You can use both DRGs and LPGs together depending on your requirements.
The following three examples of inter-VCN connectivity use an LPG or DRG:
Local Peering Gateway (LPG)
The following image shows a region with two VCNs using LPGs for local peering:
Both VCNs must be in the same OCI region and you can have up to 10 LPGs per VCN.
Dynamic Routing Gateway (DRG)
DRGs connect VCNs within or across regions and allow up to 300 attachments per DRG. DRGs provide simple routing options, in addition to static routes. Routes from the attached networks are dynamically imported into DRG route tables using import route distributions.
The following image shows a region with two VCNs connected by a DRG in the same region:
The following image shows a region with two VCNs using the DRG with two VCNs connected between separate regions:
Access Oracle Services Network (OSN)
OSN is a conceptual network in OCI that is reserved for Oracle services.
The following architecture shows a VCN accessing the OSN without the traffic going over the internet through a service gateway:
Consider the following options and decide how you want to route your traffic:
- Use a Service Gateway to route private traffic to OSN without traversing the internet.
- Services (like Object Storage) have public IPs that can be reached over the internet. Use private endpoints (PEs) to keep traffic within the OCI network.
- When adding a route to OSN, decide if you want to enable the network to use all OCI services or just use OCI Object Storage for database backups.
- Consider private endpoints (PE) for direct, private access from VCNs or on-premises data centers. For example, you could configure OCI Object Storage with a PE reachable from within a VCN or from an on-premises region over a private IP address.
Hybrid and Multicloud Connectivity Requirements
Connect OCI to on-premises networks base on your needs using either of these connectivity options:
- OCI FastConnect uses a dedicated connection for fixed bandwidth and latency. Oracle recommends using redundant connections for resiliency.
- OCI Site-to-Site VPN uses the internet as the carrier and can also use FastConnect. Bandwidth, latency, and availability can vary due to public internet circuits. Oracle recommends using redundant tunnels.
The following diagram shows an example architecture of connecting an on-premises environment to OCI using either site-to-site VPN or FastConnect:
Oracle recommends using FastConnect for primary connections with VPN as backup for production workloads. FastConnect is available at varying speeds up to 400 Gbps, depending on region and partners.
To set up your connectivity, do the following:
- Set up a virtual circuit with public peering for only OSN access.
- Use private peering for a private connection to resources in VCNs.
- Use site-to-site VPN (with IPSec) for traffic encryption within FastConnect private peering.
Note:
Oracle recommends using redundant hardware for all connections.Connect to On-Premises Networks Using OCI FastConnect
Oracle recommends using FastConnect with VPN as backup as the primary connections for production workloads. Use site-to-site VPN as a backup connection for FastConnect, so the primary connection is FastConnect and the backup is VPN. The available connection speeds are 1 Gbps, 10 Gbps, or 100 Gbps.
- Set up a virtual circuit with public peering, if you only need access to OSN.
- Use OCI Site-to-Site VPN which uses IPSec for encryption of traffic in addition to FastConnect public peering.
- Use private peering when you need a private connection to resources in OCI VCNs.
Note:
Oracle recommends using twice the equipment for redundancy.Connect to On-Premises Networks Using OCI Site-to-Site VPN
The following diagram shows an architecture with redundant customer-premises equipment (CPE) and an OCI connection using site-to-site VPN:
Site-to-site VPN performance may vary depending on internet traffic. As with FastConnect, configure site-to-site VPN with redundant tunnels and where possible also with redundant CPE devices. Oracle provides two VPN endpoints for every site-to-site VPN connection.
Oracle Interconnect for Microsoft Azure
The following diagram shows an example architecture of an Oracle database in an OCI region and the application in Azure:
Latency is important for a good user experience with better response times. Oracle and Azure have integration points in different locations around the world. This makes it easy to integrate and also reduces latency which makes it possible to have solution that spans between the clouds using FastConnect and Azure ExpressRoute.
You can enable access between the clouds by configuring from both Azure portal—ExpressRoute and OCI console—FastConnect. You only need to set up 1x virtual circuit since Azure interconnect has built-in redundancy using physical diversity of hardware and location where possible. There is no cost of traffic between Azure and OCI (egress cost) if you use a local SKU and select the minimum 1 Gbps Azure ExpressRoute connection speed. The interconnects are built where Azure and OCI are located close to each other to enable low latency between the clouds.
Note:
Not all regions have this capability. Use a network service provider in other regions.If you are looking for connecting to Microsoft Azure, see Access to Microsoft Azure.
Oracle Interconnect for Google Cloud
The following architecture diagram shows you a connection between OCI and Google Cloud.
Connect to AWS and Other Cloud Platforms
The following diagram shows a connection between OCI and AWS using our connection partner Megaport:
You can also consider a direct VPN connection between AWS and OCI.
Resiliency Requirements
Assess your need for regional resiliency from outages and consider a multiregion deployment.
Multiregion Deployment
The following diagram shows data replication between a primary and standby region:
Description of the illustration multi-region-deployment-full-arch.png
Load Balancing
Use a load balancer (public or private) to optimize traffic distribution. several backend servers.
Load Balancer
A standard load balancer for public facing web servers can terminate SSL traffic or pass it through to the backend. Use flexible shapes between the minimum and maximum bandwidth depending on traffic.
You can set up either a public or private load balancer on layer 4/7, TCP/HTTP layer.
Network Load Balancer
Free service that provides a non-proxy, ultra-low latency, pass-through load balancing with high throughput. Network load balancers are optimized for long-running connections over days or months with connections to the same backend server which is optimal for the database.
Network load balancers ensure that your services remain available by directing traffic only to healthy servers based on Layer 3/Layer 4 (IP protocol) data.
To learn more, review the topic Comparing Load Balancer and Network Load Balancer in the OCI Documentation linked in Explore More.
Security Requirements
OCI Web Application Firewall
- Access control
- Bot management
- Protection rules
- Rate limits
- Customer applications
Note:
Use WAF to protect any internet-facing endpoints, and ensure consistent security rule enforcement across applications.To learn more, review both OCI WAF policy (regional solution) and Edge policy (global solution).
OCI Network Firewall
The following diagram shows a supported OCI Network Firewall insertion design that allows for the use of a single OCI Network Firewall to manage both north-south (internet-bound) and east-west (inter-VCN and on-premises) traffic patterns:
In this architecture, an OCI Network Firewall deployed within a central Hub VCN inspects and secures traffic flows inbound from the internet, outbound to the internet, and from an on-premises region.
Zero Trust Packet Routing
The following diagram shows network security policies managed independently from the underlying network architecture to reduce the risk of unauthorized access:
Security administrators can quickly define intent-based access policies. Only explicitly permitted traffic is allowed, making unauthorized access impossible. This approach simplifies network security management and audit processes.