The region names and identifiers for the US Defense 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 US Defense Cloud regions, you can subscribe to the other regions in the US Defense Cloud. These tenancies can't subscribe to any Oracle Cloud Infrastructure regions not belonging to the OC3 realm . For information about subscribing to a region, see Managing Regions.
Oracle US Defense Cloud
Console Sign-in URLs 🔗
To sign in to the US Defense Cloud, enter one of the following URLs in a supported browser:
When you're signed in to the Console for
one of the US Defense Cloud regions, the browser times out
after 15 minutes of inactivity, and you need to sign in again to use the Console.
Oracle US Defense Cloud API Reference and Endpoints 🔗
This section includes the APIs and corresponding regional endpoints with the US Defense Cloud.
Use the Endpoint of Your Home Region for All IAM API Calls
When you sign up for Oracle Cloud Infrastructure, Oracle creates a tenancy for you in one region. This is your home region. Your home region is where your IAM resources are defined. When you subscribe to a new region, your IAM resources are replicated in the new region, however, the master definitions reside in your home region and can only be changed there. Make all IAM API calls against your home region endpoint. The changes automatically replicate to all regions. If you try to make an IAM API call against a region that is not your home region, you will receive an error. See What is the tenancy home region? How do I find my tenancy home region?
In addition to these endpoints, each vault has a unique endpoint for create, update, and list operations for keys. This endpoint is referred to as the control plane URL or management endpoint. Each vault also has a unique endpoint for cryptographic operations. This endpoint is known as the data plane URL or the cryptographic endpoint.
The source service must be available in US Defense Cloud regions for messages to be
successfully sent through the Notifications service. If
the source service isn't available in these regions, then the message isn't sent. For a
list of unavailable services, see Services Not Supported in Oracle US Defense Cloud.
Email Delivery only supports the AUTH PLAIN command when
using SMTP authentication. If the sending application is not flexible with the AUTH
command, an SMTP proxy/relay can be used. For more information about the AUTH command,
see AUTH Command and its Mechanisms.
An SPF record is a TXT record on your sending domain that authorizes Email Delivery IP addresses to send on your behalf. SPF
is required for subdomains of oraclegovcloud.com and recommended in
other cases. The SPF record syntax for each sending region is shown in the following
table:
The Realm Key is applicable for any sending regions in that realm.
Oracle Database Releases That Support Recovery Service in Oracle US Defense Cloud 🔗
In the US Defense Cloud you can use Oracle Database
Autonomous Recovery Service as the backup destination for Oracle Cloud databases
provisioned with the following Oracle Database releases.
Database Service in US Defense Cloud
Oracle Database Edition and Version
Exadata Database Service
Oracle Database 19c Release 26 (19.26) and later
Oracle Base Database service
Oracle Database 19c Release 26 (19.26) and later
Oracle Database 23ai (23.4) and later
Services Not Supported in Oracle US Defense Cloud 🔗
Currently, the following services and features aren't available or aren't supported for
tenancies in the US Defense Cloud.
Note
This list isn't exhaustive. Full Stack Disaster Recovery services and features are not available. Other services and features might also be unavailable or unsupported.
Networking services and features not
available:
FastConnect with a provider (FastConnect in a colocation model is
supported)
DNS Zone Management - public DNS zones (private DNS
zones are supported). If you require this service, contact your sales team.
Traffic Management
Network Visualizer - export map data
Oracle Database services not
available:
Data Catalog - Data asset type of MySQL.
Storage services and features not available:
The Ultra High Performance level for block volumes and boot volumes.
Analytics & AI services not
available:
Fusion Data Intelligence
Identity & Security services not
available:
Compliance Documents
SMS-based notifications
Observability & Management services
and features not available:
Health Checks
Logging Analytics - Sample Log Data
Management Agent - Enabling Management Agent from Compute instances. As an
alternative, you can manually install the Management Agent. See Install Management Agents for more information.
Oracle Cloud Infrastructure
Free Tier, including promotional trial and Always Free offers aren't available in US Defense Cloud regions.
Access to Multiple Oracle US Defense Cloud Regions 🔗
This section shows how to give the on-premises resources that are part of NIPRNet access to multiple US Defense Cloud regions over a single FastConnect connection. This is important if one of the regions doesn't 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 US Defense Cloud regions have a direct connection to a NIPRNet BCAP, but others don't. You can use the Networking service to give on-premises resources that are part of NIPRNet access to a US Defense Cloud region that's not directly connected to the NIPRNet's BCAP. You might do this to extend on-premises workloads into a particular US Defense Cloud region that you're interested in, or to use that region for disaster recovery (DR).
This scenario is illustrated in the following diagram.
Callout 1: Route Table for VCN-1's Subnets
Destination CIDR
Route Target
172.16.1.0/24
DRG-1
10.0.3.0/24
DRG-1
Callout 2: Route Table for VCN-2's Subnets
Destination CIDR
Route Target
172.16.1.0/24
DRG-2
10.0.1.0/24
DRG-2
Callout 3: BGP at BCAP Edge
Advertises
Receives
172.16.1.0/24
10.0.1.0/24
10.0.3.0/24
Callout 4: BGP at DRG-1
Advertises
Receives
10.0.1.0/24
172.16.1.0/24
10.0.3.0/24
In the diagram, US Defense Cloud region 1 has a direct connection to the NIPRNet's BCAP, but US Defense Cloud region 2 doesn't. Imagine that on-premises resources in NIPRNet (in subnet 172.16.1.0/24) need access to a 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 isn't 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:
FastConnect between the NIPRNet BCAP and region 1.
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 the BCAP edge router accordingly.
The subnets in both VCN-1 and VCN-2 are advertised to the 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.
Summary: In this task, you set up the FastConnect between the NIPRNet BCAP and region 1. FastConnect has three connectivity models, and you generally follow the colocate with Oracle model. In this case, colocation occurs in the BCAP (the meet me point). The connection consists of both a physical connection (at least one cross-connect) and logical connection (private virtual circuit).
For instructions, follow the flow chart and tasks listed in Getting Started with FastConnect, and notice these specific variations:
In task 2, the instructions assume that you have a VCN (in region 1), but it's
optional.
In task 8, create a private virtual circuit (not a public one).
Summary: If you don't yet have a VCN in region 2 (VCN-2 in the preceding diagram), you set it up in this task. You also create a DRG in region 2 and attach it to the VCN. Then, for each VCN-2 subnet that needs to communicate with the on-premises network, you update that subnet's route table to include a route rule for the on-premises subnet of interest. If there are multiple on-premises subnets that you want to route to, set up a route rule for each one.
In step 4 in the preceding list, add a route rule with the following settings:
Destination CIDR = the on-premises subnet of interest
Target = the VCN's DRG
In the preceding diagram, it's the rule with 172.16.1.0/24 as the destination CIDR, and target as DRG-2. The second rule in the diagram (for 10.0.1.0/24 and DRG-2) is necessary only if resources in VCN-2 need to communicate with resources in VCN-1.
Summary: In this task, you set up a remote peering to enable private traffic between DRG-1 and DRG-2. The term remote peering typically means that resources in one VCN can communicate privately with resources in a VCN in a different region. In this case, the remote peering also enables private communication between the on-premises network and VCN-2.
Optional region 1 VCN: The instructions assume that each region has a VCN, but in this situation, it is optional for region 1.
Single VCN administrator: The instructions assume that there are two different VCN administrators: one for the VCN in region 1 and another for the VCN in region 2. In this situation, there might be only a single VCN administrator (you) who handles both regions and configures the remote peering connection.
Unnecessary IAM policies: The instructions include a task for each VCN administrator to set up particular IAM policies to enable the remote peering connection. One policy is for the VCN administrator who is designated as the requestor, and one is for the VCN administrator who is designated as the acceptor. Those terms are further defined in Important Remote Peering Concepts. However, if there's only a single VCN administrator with comprehensive networking permissions across the tenancy, those IAM policies aren't necessary. For more information, read the tip that appears at the end of the task.
RPC anchor points and connection: The remote peering actually consists of multiple components that you must set up. There's an anchor point on each DRG (shown as RPC-1 and RPC-2 in the preceding diagram), plus a connection between those two RPC anchor points. The instructions include steps for creating those RPCs and the connection between them. Ensure that you create all the components.
More Information for Oracle US Defense Cloud Customers 🔗