Access OCI Services from AWS with Oracle Interconnect for AWS
Oracle Interconnect for AWS provides private, low-latency and reliable connectivity between Oracle Cloud Infrastructure (OCI) and Amazon Web Services (AWS) over their private backbones, bypassing the public internet and third-party network service providers, to deliver predictable performance, high availability, and resilient cross-cloud networking.
In this reference architecture we showcase two related designs. The first shows how customers can easily access OCI services in the same region as the interconnect by using Oracle Interconnect for AWS, a Dynamic Routing Gateway (DRG), and a Service Gateway. The second design shows how customers can easily access OCI services in a different, remote OCI region from the interconnect by using Oracle Interconnect for AWS, a DRG with a remote peering connection, and a Service Gateway. These two architectures enable OCI and AWS customers to use OCI services in any OCI region over a secure, private, and high-performance network.
Architecture
Oracle has partnered with AWS to provide low-latency, private connectivity between Oracle Cloud Infrastructure and Amazon Web Services. This partnership gives you a highly optimized, secure, and unified cross-cloud experience. Use best-in-class services from Oracle Cloud and AWS, and continue to use existing investments in Oracle and AWS.
Key benefits
- Private Layer 3 Connectivity: Traffic stays on OCI and AWS private backbones and bypasses the public internet or any third-party network service provider.
- High Availability and Resiliency: Oracle Interconnect for AWS follows best practices for maximum resilience. Infrastructure spans multiple network devices across at least two physical facilities with independent power and networking.
- Predictable performance and lower latency versus routing through on-premises environments, third parties, or internet overlays.
- High bandwidth options: Up to 100 Gbps per connection (5/10/20/50/100 Gbps).
- Simplified operations: No physical cross-connect management in colocation facilities is required.
- Cost advantages: You pay port-hour fees; Oracle does not charge FastConnect outbound data transfer fees, and AWS waives data transfer fees for Oracle Interconnect for AWS traffic.
- Collaborative Support Model: Customers can open support tickets with My Oracle Support or AWS Support. Both organizations directly engage to resolve cross-cloud issues.
How it's provisioned (high level)
Oracle and AWS pre-provision backbone capacity between select FastConnect and Direct Connect locations. Provisioning is a streamlined two-step workflow initiated in either cloud:
- Create the interconnect, which generates an activation key, in OCI or AWS.
- Accept the interconnect in the other cloud by using the activation key and attach it to your DRG in OCI and Direct Connect Gateway in AWS.
Connections typically provision in minutes, without long physical provisioning cycles.
Access OCI services from AWS in the same OCI region as Oracle Interconnect for AWS
access-oci-aws-interconnect-arch-oracle.zip#GUID-22558DB2-108F-4921-99E3-6B4AA39DAFC3
Key components
- Amazon Virtual Private Cloud and subnet
Amazon virtual private cloud (VPC) enables you to launch AWS resources into a virtual network you've defined. This virtual network resembles a traditional network that you operate in your own data center, with the benefits of using the scalable infrastructure of AWS. After you create an VPC, you can add subnets.
A subnet is a range of IP addresses in your Amazon VPC. You can create AWS resources, such as Amazon EC2 instances, in specific subnets.
A VPC subnet uses per-subnet route table associations to route cross-cloud traffic towards a Transit Gateway (TGW).
- AWS Transit Gateway (TGW)
An AWS Transit Gateway connects Amazon VPCs and on-premises networks through a central hub. This connection simplifies your network and puts an end to complex peering relationships. A transit gateway acts as a highly scalable cloud router—each new connection is made only once.
A TGW aggregates VPC connectivity to Direct Connect and dynamically imports cross-cloud routes from AWS Direct Connect Gateway. It facilitates routing between VPCs and OCI through the attached Direct Connect Gateway and dynamically learned network prefixes.
- AWS Direct Connect
AWS Direct Connect is a private network circuit between a VPC and a network outside AWS. It offers stable throughput and low latency, bypassing the public Internet. It's the AWS-equivalent of Oracle Cloud Infrastructure FastConnect.
AWS Direct Connect Gateway (DXGW) is an AWS global gateway construct that interconnects Transit Gateway to the interconnect for OCI ↔ AWS private connectivity path. It participates in BGP with OCI to exchange cross-cloud network prefixes.
- Oracle Interconnect for AWS
Oracle Interconnect for AWS is a managed dedicated connectivity service that allows you to provision secure, private cross-cloud connections directly between OCI and AWS in specific regions. This connection lets you set up cloud-to-cloud workloads without the traffic between the clouds going over the internet or through third-party providers.
- OCI FastConnect
Oracle Cloud Infrastructure FastConnect creates a dedicated, private connection between your data center and OCI. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.
OCI FastConnect participates in BGP to exchange cross-cloud network prefixes. The OCI FastConnect logical device terminates the virtual circuit for the OCI-AWS interconnect.
- Dynamic routing gateway
(DRG)
The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider.
- Service
gateway
A service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and does not traverse the internet.
- OCI virtual cloud
network and subnet
A virtual cloud network (VCN) is a customizable, software-defined network that you set up in an OCI region. Like traditional data center networks, VCNs give you control over your network environment. A VCN can have multiple non-overlapping classless inter-domain routing (CIDR) blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Oracle Services Network
The Oracle Services Network (OSN) is a conceptual network on OCI that is reserved for Oracle services. These services have public IP addresses that you can reach over the internet. Hosts outside Oracle Cloud can access the OSN privately by using Oracle Cloud Infrastructure FastConnect or VPN Connect. Hosts in your VCNs can access the OSN privately through a service gateway.
Any Oracle service hosted in OSN and available via Service Gateway can be accessed from Oracle Interconnect for AWS.
- Security controls: To enforce least-privilege traffic flows at the communication endpoints, OCI uses network security groups, security lists, and Zero Trust Packet Routing, and AWS uses security groups and network access control lists.
- Network security group
(NSG)
NSGs act as virtual firewalls for your cloud resources. With the zero-trust security model of OCI you control the network traffic inside a VCN. An NSG consists of a set of ingress and egress security rules that apply to only a specified set of virtual network interface cards (VNICs) in a single VCN.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that is allowed in and out of the subnet.
- Network security group
(NSG)
Workloads in AWS VPC abc or VPC xyz send traffic to the AWS TGW, which forwards it to the AWS DXGW. Traffic then traverses Oracle Interconnect for AWS and enters OCI through OCI FastConnect, terminating on the OCI DRG.
From the DRG, traffic is routed to either:
- VCN
pqrfor application and workload subnet connectivity - VCN
svcwhen the destination is an Oracle service reachable through the Service Gateway
For Oracle Services Network access, transit routing is needed in the upper VCN svc, where the Service Gateway is attached, so that traffic can traverse AWS ↔ DRG-VCN svc ↔ SGW ↔ OSN. Configure the relevant VCN ingress route table on VCN svc and the gateway ingress route table on the Service Gateway. Example Oracle Services Network services are shown, such as Oracle Exadata Database Service and OCI Streaming, but you can access any service hosted in OSN and available via Service Gateway.
Access OCI services from AWS in a different, remote OCI region from the interconnect by using a remote peering connection on a DRG
This architecture is similar to the previous one. The key difference is that it has two OCI regions, US East (Ashburn) and US Phoenix, each with two VCNs and a DRG. The two DRGs are peered by using a remote peering connection over the OCI backbone.
Description of the illustration aws-oci-remote-peering.png
aws-oci-remote-peering-oracle.zip#GUID-2775E07F-CA5D-436B-B59C-BDF0158E6FB2
Key components
- Amazon Virtual Private Cloud and subnet
Amazon virtual private cloud (VPC) enables you to launch AWS resources into a virtual network you've defined. This virtual network resembles a traditional network that you operate in your own data center, with the benefits of using the scalable infrastructure of AWS. After you create an VPC, you can add subnets.
A subnet is a range of IP addresses in your Amazon VPC. You can create AWS resources, such as Amazon EC2 instances, in specific subnets.
A VPC subnet uses per-subnet route table associations to route cross-cloud traffic towards a Transit Gateway (TGW).
- AWS Transit Gateway (TGW)
An AWS Transit Gateway connects Amazon VPCs and on-premises networks through a central hub. This connection simplifies your network and puts an end to complex peering relationships. A transit gateway acts as a highly scalable cloud router—each new connection is made only once.
A TGW aggregates VPC connectivity to Direct Connect and dynamically imports cross-cloud routes from AWS Direct Connect Gateway. It facilitates routing between VPCs and OCI through the attached Direct Connect Gateway and dynamically learned network prefixes.
- AWS Direct Connect
AWS Direct Connect is a private network circuit between a VPC and a network outside AWS. It offers stable throughput and low latency, bypassing the public Internet. It's the AWS-equivalent of Oracle Cloud Infrastructure FastConnect.
AWS Direct Connect Gateway (DXGW) is an AWS global gateway construct that interconnects Transit Gateway to the interconnect for OCI ↔ AWS private connectivity path. It participates in BGP with OCI to exchange cross-cloud network prefixes.
- Oracle Interconnect for AWS
Oracle Interconnect for AWS is a managed dedicated connectivity service that allows you to provision secure, private cross-cloud connections directly between OCI and AWS in specific regions. This connection lets you set up cloud-to-cloud workloads without the traffic between the clouds going over the internet or through third-party providers.
- OCI FastConnect
Oracle Cloud Infrastructure FastConnect creates a dedicated, private connection between your data center and OCI. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.
OCI FastConnect participates in BGP to exchange cross-cloud network prefixes. The OCI FastConnect logical device terminates the virtual circuit for the OCI-AWS interconnect.
- Dynamic routing gateway
(DRG)
The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider.
- Service
gateway
A service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and does not traverse the internet.
- OCI virtual cloud
network and subnet
A virtual cloud network (VCN) is a customizable, software-defined network that you set up in an OCI region. Like traditional data center networks, VCNs give you control over your network environment. A VCN can have multiple non-overlapping classless inter-domain routing (CIDR) blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Oracle Services Network
The Oracle Services Network (OSN) is a conceptual network on OCI that is reserved for Oracle services. These services have public IP addresses that you can reach over the internet. Hosts outside Oracle Cloud can access the OSN privately by using Oracle Cloud Infrastructure FastConnect or VPN Connect. Hosts in your VCNs can access the OSN privately through a service gateway.
Any Oracle service hosted in OSN and available via Service Gateway can be accessed from Oracle Interconnect for AWS.
- Security controls
To enforce least-privilege traffic flows at the communication endpoints, OCI uses network security groups, security lists, and Zero Trust Packet Routing, and AWS uses security groups and network access control lists.
- Network security group
(NSG)
NSGs act as virtual firewalls for your cloud resources. With the zero-trust security model of OCI you control the network traffic inside a VCN. An NSG consists of a set of ingress and egress security rules that apply to only a specified set of virtual network interface cards (VNICs) in a single VCN.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that is allowed in and out of the subnet.
- Network security group
(NSG)
Traffic from AWS EC2 routes to the AWS TGW, then to the AWS DXGW, crosses Oracle Interconnect for AWS, and terminates on the OCI DRG in Ashburn. From the Ashburn DRG, traffic can reach workloads in the Ashburn VCN subnets (10.0.30.0/24, 10.0.40.0/24) and, when the destination is in the remote OCI region, routes over the remote peering connection (Ashburn DRG ↔ Phoenix DRG) across the OCI backbone into US Phoenix.
In Phoenix, the DRG forwards traffic to either VCN pqr, for workloads in 10.1.30.0/24 and 10.1.40.0/24, or VCN svc, for Oracle service access. Because the Service Gateway is attached to VCN svc, transit routing is needed in VCN svc so that traffic entering Phoenix from the remote peering connection can be steered to the Service Gateway ↔ OSN path and return symmetrically. Configure DRG route tables, including remote peering connection import route distribution, and configure the relevant VCN ingress route table on VCN svc and the gateway ingress route table on the Service Gateway.
Example Oracle Services Network services are shown, such as Oracle Exadata Database Service and OCI Streaming, but you can access any service hosted in OSN and available via Service Gateway.
Recommendations
- Services VCN
Consider provisioning a unique VCN just for the Service Gateways that you need to access from AWS to avoid conflicts with other traffic. Use a non overlapping CIDR to avoid having to implement NAT.
- Route tables
Configure VCN route tables (and Security Lists or NSGs) to allow traffic to and from AWS.
- Security lists
Use security lists to define ingress and egress rules that apply to the entire subnet.
- Network security groups (NSGs)
You can use NSGs to define a set of ingress and egress rules that apply to specific VNICs. We recommend using NSGs rather than security lists, because NSGs enable you to separate the VCN's subnet architecture from the security requirements of your application.
- DNS
Consider configuring OCI private DNS if you require name resolution between OCI and AWS. Enable a similar feature in AWS to resolve AWS endpoints.
- Use the service CIDR label
When configuring a route to each Service Gateway from within your OCI tenancy, use the service CIDR label. For example,
All IAD Services in Oracle Services Network. Using the service CIDR label in route tables ensures that all expected Oracle Services Network routes are advertised to AWS. - Cloud Guard
Clone and customize the default recipes provided by Oracle to create custom detector and responder recipes. These recipes enable you to specify what type of security violations generate a warning and what actions are allowed to be performed on them. For example, you might want to detect OCI Object Storage buckets that have visibility set to public.
Apply Oracle Cloud Guard at the tenancy level to cover the broadest scope and to reduce the administrative burden of maintaining multiple configurations.
You can also use the Managed List feature to apply certain configurations to detectors.
- Security Zones
For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, OCI validates the operations against the policies in the recipe, and prevents operations that violate any of the policies.
Considerations
- Service Gateways: All OCI Service Gateways are regional in scope. They can be used only to access services within the Oracle Services Network in the same region. Provision a unique Service Gateway and VCN in each region where you need to access OCI services.
- Dynamic Routing Gateway (DRG): A DRG is required in each region. Attach the VCN with the Service Gateway to the DRG, then configure DRG route tables and import route distributions to propagate routes to Oracle Interconnect for AWS, or cross-region through a remote peering connection to an interconnect in another region.
- Remote peering connections: Although Service Gateways are regional in scope, service-moniker routes that originate from Service Gateways can be propagated to other regions, including to Oracle Interconnect for AWS in another region. Create Dynamic Routing Gateways in each region, then use remote peering connections to propagate OCI service routes across the backbone and to Oracle Interconnect for AWS.
- Non overlapping CIDR blocks: Your network should use non overlapping CIDRs end to end. VCNs in OCI and VPCs in AWS should not use conflicting IP addresses.