Deployment models
| Model | What it is | Typical driver |
|---|---|---|
| Public commercial region | Standard OCI regions | Most workloads |
| Sovereign / government realm | Separate realm with its own identity, operations and legal controls | Regulatory sovereignty, public sector |
| Dedicated Region | A full OCI region in your data centre | Data must stay on-premises, but you want cloud services |
| Exadata Cloud@Customer | Exadata Database Service on hardware in your data centre | Databases on-prem for residency/latency with cloud operations |
| Compute Cloud@Customer | OCI compute/storage rack on-premises | Edge or on-prem apps with OCI tooling |
| Database@Azure/AWS/Google | Oracle databases in other clouds' data centres | Apps in those clouds |
Realms are separate: tenancies, identity and APIs don't span realms. Plan this upfront; moving between realms is a migration.
Criteria
| Criterion | Questions |
|---|---|
| Residency and sovereignty | Country/geography requirements? Need a sovereign realm or on-prem deployment? |
| Latency | Users, on-prem systems, partners: measured round trips to candidate regions |
| Availability domains | Multi-AD region or single-AD region (fault domains only)? Affects HA design |
| Service availability | Required services, shapes (GPU, Ampere, dense I/O), Autonomous/Exadata options in the region |
| Capacity | Can you get the limits/capacity you need now and in two years? |
| DR | A second region in the same country/realm? Same services there? |
| Connectivity | FastConnect locations, providers, interconnects to other clouds |
| Operations | Who operates Cloud@Customer hardware space, power, network? |
Single-AD vs multi-AD regions
Many regions have one availability domain with three fault domains. HA then relies on fault domains (separate hardware/power within the AD), and AD-level failures need cross-region DR. Multi-AD regions allow cross-AD HA. Design accordingly (see the AD vs FD post).
Check availability early
oci iam region list --output table # regions in your realm
oci iam region-subscription list # regions your tenancy subscribes to
oci limits value list --compartment-id $TENANCY --service-name compute --all --output table | grep -i -E "gpu|a1|e5"
Subscribe to the DR region early so limits and services can be validated, and request limit increases there too.
Record the decision
One page: candidates, scoring, chosen primary and DR, accepted constraints (e.g. "GPU shapes unavailable in DR region; AI workload DR degraded"), review triggers.
Review triggers
- New regulatory requirement or customer contract terms.
- New region opening closer to users or in-country.
- Persistent capacity constraints.
- Services needed that the region lacks.
Tip
Treat the DR region with the same rigour as the primary: services, shapes, limits and connectivity. Most DR surprises come from a region nobody checked until the drill.
Checklist
- Residency and sovereignty requirements confirmed
- Deployment model chosen (public, sovereign, Dedicated Region, Cloud@Customer, multicloud)
- Latency measured
- AD/FD layout understood
- Services, shapes and limits verified in primary and DR
- Connectivity options checked
- Decision recorded with constraints and review triggers