Oracle Cloud Infrastructure Documentation

Federal Government Cloud with Impact Level 5 Authorization

This topic contains information specific to Oracle Cloud Infrastructure Federal Government Cloud.

Compliance with Defense Cloud Security Requirements

Oracle Cloud Infrastructure Federal Government Cloud supports applications that require Impact Level 5 (IL5) data, as defined in the Department of Defense Cloud Computing Security Requirements Guide (SRG).

Federal Government Cloud Regions

The region names and identifiers for the Oracle Cloud Infrastructure Federal Government Cloud regions are shown in the following table:

Region Name Region Identifier Region Key Realm Key Availability Domains
US DoD East (Ashburn) us-gov-ashburn-1 ric OC3 1
US DoD North (Chicago) us-gov-chicago-1 pia OC3 1
US DoD West (Phoenix) us-gov-phoenix-1 tus OC3 1

After your tenancy is created in one of the Federal Government Cloud regions, you can subscribe to the other regions in the Federal Government Cloud. Federal Government Cloud tenancies cannot subscribe to any Oracle Cloud Infrastructure regions not belonging to the OC3 realm . For information about subscribing to a region, see Managing Regions.

Federal Government Cloud Console Sign-in URLs

To sign in to the Oracle Cloud Infrastructure Federal Government Cloud, enter one of the following URLs in a supported browser:

Note

When you're logged in to the Console for one of the Government Cloud regions, the browser times out after 15 minutes of inactivity, and you need to sign in again to use the Console.

Government Cloud API Reference and Endpoints

Oracle Cloud InfrastructureGovernment Cloud has these APIs and corresponding regional endpoints:

Core Services (covering Networking, Compute, and Block Volume)
Database API
IAM API
Key Management API
Object Storage and Archive Storage APIs
Work Requests API (for Compute and Database work requests)

Services Not Supported in Oracle Cloud Infrastructure Federal Government Cloud

Currently, the following services are not available for tenancies in the Federal Government Cloud:

Core Infrastructure services and features not available:

  • Compute service features:
    • Autoscaling
  • FastConnect with a provider (FastConnect in a colocation model is supported)
  • Data Transfer service
  • File Storage service

Database services not available:

  • Autonomous Data Warehouse
  • Autonomous Transaction Processing
  • Data Safe

Data and AI services not available:

  • Digital Assistant

Solutions and Platform services not available:

  • Analytics Cloud
  • Analytics for Applications
  • Container Engine for Kubernetes
  • Content and Experience
  • DNS Zone Management
  • Email Delivery
  • Events
  • Functions
  • Health Checks
  • Integration
  • Marketplace
  • Monitoring
  • Notifications
  • Registry
  • Resource Manager
  • Streaming
  • Traffic Management Steering Policies

Governance and Administration features not supported

  • Auto-federation with Oracle Identity Cloud Service
  • WAF service

Infrastructure Tools

  • Oracle Cloud Infrastructure Terraform Provider

Integration with Oracle SaaS and PaaS services, including those listed here: Getting Started with Oracle Platform Services.

Access to Multiple Federal Government Cloud Regions

This section shows how to give the on-premises resources that are part of NIPRNet access to multiple Federal Government Cloud regions over a single FastConnect connection. This is important if one of the regions does not have a direct connection to the NIPRNet's border cloud access point (BCAP). The BCAP is also referred to as the meet me point.

Overview

Some Federal Government Cloud regions have a direct connection to a NIPRNet BCAP, but others do not. You can use the Networking service to give on-premises resources that are part of NIPRNet access to a Federal Government Cloud region that is not directly connected to the NIPRNet's BCAP. You might do this to extend your on-premises workloads into a particular Federal Government Cloud region that you're interested in, or to use that region for disaster recovery (DR).

This scenario is illustrated in the following diagram.

This image shows the layout of the NIPRNet connected to two different Oracle regions by way of FastConnect and remote peering.

In the diagram, Federal Government Cloud region 1 has a direct connection to the NIPRNet's BCAP, but Federal Government Cloud region 2 does not. Imagine that on-premises resources in NIPRNet (in subnet 172.16.1.0/24) need access to your virtual cloud network (VCN) in region 2 (with CIDR 10.0.3.0/24).

Optionally, there could also be a VCN with cloud resources in region 1 (with CIDR 10.0.1.0/24), but a VCN in region 1 is not required for this scenario. The intent of this scenario is for the on-premises resources to get access to resources in region 2.

In general, you set up two types of connections:

Here are some details about the connections:

  • That FastConnect has at least one physical connection, or cross-connect . You set up a private virtual circuit that runs on the FastConnect. The private virtual circuit enables communication that uses private IP addresses between the on-premises resources and the cloud resources.
  • The remote peering connection is between a dynamic routing gateway (DRG) in region 1, and a DRG in region 2. A DRG is a virtual router that you typically attach to a VCN to give that VCN access to resources outside its Oracle region.
  • You can control which on-premises subnets are advertised to the VCNs by configuring your BCAP edge router accordingly.
  • The subnets in both VCN-1 and VCN-2 are advertised to your BCAP edge router over the FastConnect connection.
  • You can optionally configure VCN security rules and other firewalls that you maintain to allow only certain types of traffic (such as SSH or SQL*NET) between the on-premises resources and VCNs.

Here are some basic requirements:

  • The VCNs and DRGs in region 1 and region 2 must belong to the same tenancy, but they can be in different compartments  within the tenancy.
  • For accurate routing, the CIDR blocks of the on-premises subnets of interest and the VCNs must not overlap.
  • To enable traffic to flow from a VCN to the on-premises subnets of interest, you must add a route rule to the VCN subnet route tables for each of the on-premises subnets. The preceding diagram shows the route rule for 172.16.1.0/24 in each VCN's route table.

General Setup Process

Task 1: Set up FastConnect to region 1
Task 2: Set up a VCN and DRG in region 2
Task 3: Set up remote peering between region 1 and region 2