Expanding into a second OCI region: a checklist for identity, limits, keys, images, networking and observability

#Goal

You are adding a region for DR, data residency or latency, and the tenancy has only ever run in its home region. Some OCI constructs are global, some are regional, and some can only be written in the home region. Teams find out which is which during the first failover. Work through this checklist before any workload lands in the new region.

#1. Subscribe and verify

• Subscribe the region from a tenancy administrator account. You can't undo a region subscription.

oci iam region-subscription list --tenancy-id <tenancy-ocid> --output table
oci iam region-subscription create --tenancy-id <tenancy-ocid> --region-key <KEY>

• Wait for the status to change to READY before you create resources.
• Confirm that every automation sends IAM writes to the home region. Scripts that create policies or compartments with --region <new-region> fail or behave inconsistently. Pin those calls with --region <home-region>.

#2. Identity

• Replicate each identity domain that users or workloads sign in through to the new region. This matters during a home-region outage, when you need sign-in to work in the DR region.
• Check that break-glass accounts can sign in through the new region's Console endpoint.
• Check policies for region-specific statements, such as where request.region = 'xxx' conditions written when there was only one region.
• Dynamic groups match by compartment or tag, not by region. Check that the matching rules don't accidentally include DR instances in a production group, or leave them out.

#3. Service limits and quotas

Limits are per region and often per AD. A new region starts with default limits, which are usually far below what you run at home.

for svc in compute block-storage database load-balancer vcn; do
  oci limits value list -c <tenancy-ocid> --service-name $svc --region <new-region> --all \
    --query 'data[?value>`0`].{name:name,scope:"scope-type",ad:"availability-domain",value:value}' --output table
done

oci limits resource-availability get -c <compartment-ocid> --service-name compute \
  --limit-name standard-e5-core-count --availability-domain <AD-name> --region <new-region>

• Compare the limits with the full DR footprint, not the pilot. Raise service limit requests early, because approval is not instant.
• Add or update compartment quotas. Quota statements are global, so scope them with the region condition:

set compute-core quota standard-e5-core-count to 64 in compartment prod-dr where request.region = 'eu-amsterdam-1'
zero compute-core quotas in compartment sandbox where request.region = 'eu-amsterdam-1'

• Think about capacity reservations for DR shapes. Limits give you permission to launch, not guaranteed capacity.

#4. Keys and secrets

• For virtual private vaults, create a replica. Each source vault can have only one replica, and the replica must be in the same realm.

oci kms management vault create-vault-replica --vault-id <vault-ocid> --replica-region <new-region>
oci kms management vault list-vault-replicas --vault-id <vault-ocid>

• For default (shared) vaults, which can't be replicated, create separate keys in the new region and record which key protects which resource.
• Replicate secrets or recreate them in the new region. Applications must resolve the secret OCID that belongs to their region.

Warning

Cross-region copies of volume backups, boot volume backups and Object Storage replicas that use customer-managed keys need a key in the destination region. If you schedule a copy without that key, it fails, or produces a backup you can't restore with the key you expect.

#5. Images and data

• Custom images are regional. Export them to Object Storage and import them into the new region, or rebuild them from your image pipeline. Record the new image OCIDs in your Terraform variables per region.
• Copy backups or set up replication:

oci bv boot-volume-backup copy --boot-volume-backup-id <ocid> --destination-region <new-region>
oci bv backup copy --volume-backup-id <ocid> --destination-region <new-region>
oci os replication create-replication-policy --bucket-name <src> --name to-dr \
  --destination-region <new-region> --destination-bucket <dst>

• The Object Storage service in the source region needs a policy that lets it manage objects for replication (Allow service objectstorage-<region> to manage object-family in ...). Grant it for each source region.
• Check that the Object Storage namespace is the same in both regions (it is per tenancy). Then update hard-coded regional endpoints in your applications.

#6. Networking

• Allocate non-overlapping CIDRs. Overlapping ranges block RPC routing and on-prem reachability later.
• Create the DRG in the new region, and peer it with remote peering connections:

oci network remote-peering-connection create -c <c> --drg-id <drg-home> --display-name to-dr --region <home>
oci network remote-peering-connection create -c <c> --drg-id <drg-dr> --display-name to-home --region <new-region>
oci network remote-peering-connection connect --remote-peering-connection-id <rpc-home> \
  --peer-id <rpc-dr> --peer-region-name <new-region> --region <home>

• If the regions are in different tenancies, the acceptor side needs IAM policies before connect succeeds.
• Update the DRG route tables and import distributions in both regions. Then confirm the path with Network Path Analyzer.
• Hybrid connectivity: if DR has to work while the home region is down, the new region needs its own FastConnect or VPN to on-prem. Don't route it through the home region.
• DNS: recreate the private views and resolver endpoints in the new region, and decide how clients switch between regions (steering policy, record change or both).

#7. Observability and security

Nothing below is copied automatically:

• Log groups, service logs (VCN flow logs, load balancer, Object Storage) and agent configurations
• Monitoring alarms and their Notifications topics and subscriptions. Confirm each subscription in the new region.
• Events rules and the Functions or Streams they target
• Connector Hub connectors, if you ship logs to a SIEM or archive bucket
• Budgets and cost tracking tags. Tags are global, but check that tag defaults apply in the new compartments.
• Cloud Guard: add targets that cover the new region's resources, and know which region is your reporting region. Problems from every region are collected there.
• Audit retention is a tenancy-wide setting (oci audit config update), but you query audit events per region. Update your incident queries to loop over regions.

for r in $(oci iam region-subscription list --query 'data[]."region-name"' --raw-output | jq -r '.[]'); do
  echo "== $r"; oci monitoring alarm list -c <c> --region $r --all --query 'length(data)'
done

#8. Automation and runbooks

• Terraform: one provider alias per region, and separate state per region. A failed apply in the home region must not block DR changes.
• Hard-coded --region values, regional endpoints, AD names (xxxx:EU-AMSTERDAM-1-AD-1) and image OCIDs. Search the repository for each of them.
• Runbooks that point to home-region Console URLs.
• Rehearse once: launch a full workload in the new region using only automation, with no Console fixes. Whatever breaks is your remaining checklist.

Caution

Test a scenario where the home region is unavailable. IAM writes, such as policy changes and new users, only work in the home region. Prepare the DR policies, groups and dynamic groups in advance, because you can't create them during the outage.