OCI Government Cloud and FedRAMP: Regions and Controls

Government cloud is the part of OCI where the architecture conversation and the legal conversation become the same conversation. The question is never just which region has the lowest latency. It is which realm your contract, your data classification, and your personnel obligations permit you to use at all, and what evidence you will owe an assessor when you get there. Teams that treat the government realms as commercial OCI with a flag on it lose months to rework. This article is part of our complete guide to OCI compliance and sovereignty, and it covers the regions, the authorizations, the impact levels, and the division of responsibility that determines how much compliance work is actually yours.

One framing point before the detail. OCI, like every major cloud, separates its government offerings into distinct realms, complete and isolated instances of the cloud with their own identity systems, consoles, and operations. Realm choice is a one way door in practice. Moving a workload between realms later is a migration project, so the goal of this article is to help you pick correctly the first time.

The OCI US Government Cloud regions

The US Government Cloud is a separate realm with two regions, one in Ashburn, Virginia and one in Phoenix, Arizona. Two regions in one realm means you can build a proper disaster recovery posture, with replication and failover, without ever leaving the authorized boundary. The realm is operated under US jurisdiction with screened US persons handling operations and support, and it exists to serve federal agencies, state and local government, and the contractors and software vendors that sell to them.

The realm carries a FedRAMP High authorization, the most demanding of the FedRAMP baselines, built on the NIST 800 53 control catalog at its largest scope. FedRAMP High is calibrated for systems where a breach would have severe or catastrophic effects, which in practice covers law enforcement data, emergency services, financial systems, and health records held by federal bodies. An agency that needs High has a short list of places it can go, and the OCI government realm is on it. The realm also supports Criminal Justice Information Services requirements and IRS publication 1075 style obligations for tax data, the usual companions of FedRAMP High in state and federal work. Where OCI's broader certification portfolio fits around this, SOC reports, ISO certificates, PCI and the rest, is mapped in our companion article on OCI compliance certifications.

DoD regions and DISA impact levels

Above the civilian government realm sit dedicated US Defense Cloud regions built for the Department of Defense. These are assessed under the DISA Cloud Computing Security Requirements Guide, which defines impact levels for DoD data. The levels that matter for most programs are IL4, covering controlled unclassified information, and IL5, covering higher sensitivity controlled unclassified information and national security systems. IL5 brings the strictest requirements in the unclassified space: dedicated infrastructure separation from non DoD tenants and access restricted to screened US persons. Oracle also operates air gapped classified capability for national security customers beyond IL5, but if you are reading a public blog post to find out about that tier, you are not its buyer.

The practical point for contractors is that the impact level is assigned to the data by the mission owner, not chosen by the vendor. If your contract says IL5, no amount of compensating control design in a commercial region substitutes. Confirm the level in writing early, because the gap between IL4 and IL5 hosting can change your architecture, your staffing, and your bid price.

UK Government Cloud

The UK has its own pair of dedicated OCI government regions, in London and Newport in Wales, serving UK public sector bodies and defence. The realm is operated in country with security cleared UK based personnel, and it aligns with UK government security classifications for official data. The logic is identical to the US realms, jurisdiction, personnel, and isolation, applied to a different sovereign. Organizations weighing UK government regions against EU jurisdiction options should read this alongside our guide to the OCI EU Sovereign Cloud, because multinationals with both UK public sector and EU regulated workloads often end up running in more than one realm, and the boundaries between them need to be designed deliberately.

Who must use government regions, and who can stay commercial

Not every public sector adjacent workload belongs in a government realm, and putting one there unnecessarily costs you money and service availability. The sorting logic is reasonably clean.

You must use government regions when the authorization demands it: federal systems categorized at FedRAMP High, DoD workloads at IL4 and IL5, CJIS data in most state configurations, and contracts that explicitly name an authorized government cloud boundary. The contract and the system security plan, not preference, make this call.

You can often stay commercial when your obligation sits at FedRAMP Moderate or below. Many federal civilian systems are categorized at Moderate, and a large share of the defense industrial base holds contractor data subject to NIST 800 171 and CMMC rather than to FedRAMP itself. Commercial cloud regions that implement a FedRAMP Moderate equivalent control baseline can satisfy those obligations, and OCI commercial regions carry the attestations most contractors need for that argument. The trade is favorable when it works: the full commercial service catalog, faster feature delivery, and standard pricing. The risk is scoping error, so have someone who reads authorization boundaries for a living confirm the categorization before you build.

ITAR and export control

Export controlled technical data under ITAR and EAR adds a separate test that is about people, not certifications. ITAR technical data must not be accessible to foreign persons, which means the hosting environment must restrict operational access to US persons and keep the data inside the United States. The US government realm is built for exactly that posture, which is why defense manufacturers and space and aviation suppliers often land there even when no agency ATO requires it. If you handle export controlled data, treat US persons access as a hard requirement in your region selection, and document how the platform satisfies it, because export violations carry penalties that make cloud hosting costs look like rounding.

What changes for architects

Building in a government realm is recognizably OCI, same console patterns, same Terraform provider model, same core services, but four differences shape the work.

Service catalog lag. Services and features reach government regions after commercial regions, sometimes long after, because each addition must pass through the authorization process before agencies may use it. Newer AI services, niche platform offerings, and the latest compute shapes are the usual gaps. Validate your target architecture against the government region service list on day one, and design fallbacks for anything missing rather than assuming it will arrive on your schedule.

Separate realm, console, and endpoints. Government tenancies live in their own identity realm with their own console domains and API endpoints. Nothing federates across from a commercial tenancy, no policy, no group, no peering. Your CLI profiles, SDK configuration, and pipelines all need realm aware settings, and any shared services design that assumed one tenancy now needs a second, fully separate, root.

No cross realm networking. There is no native private path between a government region and a commercial region. Hybrid estates connect through your own network, FastConnect or VPN into each side, with the boundary treated as an external one, including for DNS and monitoring traffic.

Personnel requirements. On the platform side, screened US persons run the government realm, that is Oracle's responsibility. On your side, agencies and primes commonly flow down citizenship, residency, and background investigation requirements to anyone with privileged access to the workload. That constrains which of your engineers, and which of your vendors' engineers, can hold admin credentials, and it is a staffing question to resolve before the project plan exists, not after.

All of this argues for getting the foundation right once, in code. A compartment design, identity model, logging baseline, and network architecture that map cleanly to the control catalog will be inspected repeatedly for the life of the system, and our piece on the regulated workload landing zone goes deep on what that foundation should contain.

The authorization process and inherited controls

Hosting in an authorized region does not make your system authorized. FedRAMP and the DoD process work on inheritance: OCI holds an authorization for the platform, and your system inherits the controls Oracle implements, physical security, infrastructure operations, media handling, and the underlying service hardening. Everything above that line remains yours. The agency, or the contractor operating on its behalf, still takes the system through its own Authority to Operate, the ATO, with a system security plan describing every control, an independent assessment, and a continuous monitoring obligation that never ends.

In practice the split looks like this. Oracle answers for roughly the bottom half of the control catalog and publishes the inheritance documentation your assessor will expect, customer responsibility matrices and the platform security package available under NDA and through the FedRAMP marketplace process. You answer for identity and access design, network segmentation within your tenancy, encryption configuration and key management, configuration baselines on anything you deploy, vulnerability and patch management for your own software, incident response for your system, and above all the evidence. Assessors do not accept architecture diagrams as proof. They want logs, scan results, access reviews, and change records, produced on demand, for years. Audit log retention and evidence pipelines are worth engineering deliberately from the start, and our article on OCI audit logging for compliance covers exactly how to build that on OCI services.

Budget honestly for this. The platform inheritance removes an enormous amount of work, but a first ATO on any cloud is still typically a multi month effort involving security engineering, documentation, and an independent assessor. Where teams go wrong is sequencing: they build the workload first and retrofit the controls, which doubles the work. Building the landing zone to the control baseline before the first application lands is the single highest leverage decision in the whole process, and it is the core of how our OCI implementation practice approaches government and regulated builds, with 20+ years of combined Oracle experience and 24/7/365 operations behind the environments after go live.

A decision framework

Run any government or defense adjacent workload through this sequence before committing to a realm.

The government realms are the least negotiable corner of OCI, and that is their value. The regions, the impact levels, and the inheritance model are all published and stable, so the work is in matching your actual obligations to the right boundary and then engineering the half of the controls that remain yours. Do the classification first, pick the realm once, and put the evidence machinery in the foundation, and a government build on OCI becomes a disciplined project rather than an open ended negotiation with an assessor.