1. Configure cross-region private connectivity between tenancies
  2. Configure Cross-Region Private Connectivity Between Tenancies

Configure Cross-Region Private Connectivity Between Tenancies

For business and technical reasons, you might need to enable private connectivity between your virtual networks in the cloud, and ensure that traffic between the networks never traverses the public internet. For example, you might need private connectivity between networks in two regions within your tenancy, or between networks in your tenancy and those in the tenancy of a cooperating organization.

Oracle Cloud Infrastructure supports two network-peering models:

  • Local VCN peering

    Virtual cloud networks (VCNs) within a region can be peered by using local peering gateways (LPG). The resources attached to such peered VCNs can communicate by using private IP addresses without routing the traffic over the public internet. The VCNs can be in the same tenancy or in different tenancies.

  • Remote VCN peering

    VCNs in different regions can communicate by using private IP addresses without routing the traffic over the public internet. You can set up peering between two VCNs in different regions by configuring a remote peering connection (RPC) on each of the dynamic routing gateways (DRG) attached to the VCNs in the peering relationship. Remote VCN peering is generally used to connect two VCNs across regions in the same tenancy. In certain scenarios, you might need to connect VCNs in two different tenancies across regions.

Architecture

In this architecture, private network connectivity is configured between two tenancies and across two regions.

Description of xregion-private-connectivity-oci.png follows
Description of the illustration xregion-private-connectivity-oci.png

The architecture has the following components:

  • Tenancy

    A tenancy is a secure and isolated partition that Oracle sets up within Oracle Cloud when you sign up for Oracle Cloud Infrastructure. You can create, organize, and administer your resources in Oracle Cloud within your tenancy.

    This architecture has two tenancies, one for company A and the other for company B.

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

    This architecture has two regions. Company A has its cloud resources in a single region, US East (Ashburn). The resources of Company B are distributed across two regions: US East (Ashburn) and India West (Mumbai).

  • Virtual cloud network (VCN)

    A VCN is a customizable, private network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. You can segment VCNs into subnets, which can be scoped to a region or to an availability domain. Both regional subnets and availability domain-specific subnets can coexist in the same VCN. A subnet can be public or private.

    In this architecture, company A has VCN 10.0.0.0/16 in the US East (Ashburn) region. Company B has two VCNs, each in a different region: VCN B 172.16.0.0/16 in US East (Ashburn) and VCN C 192.168.0.0/16 in India West (Mumbai). Note that each VCN in this peering architecture has a unique CIDR prefix.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.

    In this architecture, VCN B in Ashburn and VCN C in Mumbai are peered remotely using DRGs.

  • Local peering gateway (LPG)

    An LPG enables you to peer one VCN with another VCN in the same region. Peering means the VCNs communicate using private IP addresses, without the traffic traversing the internet or routing through your on-premises network.

    In this architecture, VCN A and VCN B (both within the Ashburn region) are peered locally using LPGs.

  • Route tables

    Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

    This architecture includes route tables to direct traffic across the VCNs.
    • VCN A has route rules to direct traffic to VCNs B and C through the LPG.
    • VCN B has route rules to direct traffic to VCN A through the LPG and to VCN C through the DRG.
    • VCN C has route rules to direct traffic to VCNs A and C through the DRG.

Recommendations

Use the following recommendations as a starting point. Your requirements might differ from the architecture described here.

  • Identity and access management (IAM)

    You can configure an IAM policy to allow users in only a specific group to initiate connections from any LPG in the requestor's compartment (Company A compartment) to a specific tenancy. Attach the policy to the requestor's tenancy (that is, the root compartment), and not to the requestor's compartment.

  • VCN

    When you create the VCN, determine how many IP addresses your cloud resources in each subnet require. Using the Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range that's large enough for the required IP addresses. Use an address range that's within the standard private IP address space.

    Select an address range that doesn’t overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or in another cloud provider) that you intend to set up private connections to.

  • Security rules

    To control network traffic, you can use security lists or network security groups (NSGs). The rules that you specify in a security list apply to all the VNICs in the subnet to which you attach the security list. If you need firewalls at a more granular level, use network security groups (NSGs). The rules in an NSG apply to only the VNICs that you specify. Oracle recommends that you use NSGs, because they enable you to separate the subnet architecture from your workload's security requirements.

Considerations

When implementing this architecture, consider the following factors:

  • Scalability

    Consider the service limits for VCNs and subnets for your tenancy. If you need more networks, request an increase in the limits.

  • Security

    Use appropriate security mechanisms to protect your topology.

    In the architecture that you deploy by using the provided Terraform code, the default security list of the VCN allows SSH traffic from 0.0.0.0/0 and ICMP only from both the tenancies. Adjust the security list to allow only the hosts and networks that should have SSH access (or access to other required service ports) to your infrastructure.

  • Performance

    Within a region, the number of VCNs doesn’t affect performance. When you peer VCNs in different regions, consider latency.

Deploy

The Terraform code to deploy this architecture is available in GitHub.

  1. Go to GitHub.
  2. Clone or download the repository to your local computer.
  3. Follow the instructions in the README document.

Explore More

Change Log

This log lists significant changes: