OCI Autonomous Database Terraform Tutorial

In this guide, we’ll walk through how to set up OCI Autonomous Database Terraform, enabling cross-region disaster recovery with Autonomous Data Guard (ADG). When your OLTP workloads can’t afford regional outages, Autonomous Data Guard (ADG) is the safest path: a remote standby in another OCI region that’s continuously kept in sync. With Terraform, you can codify the whole flow—repeatable and auditable.

This post shows a minimal, production-flavored setup: primary ADB in a primary region and a remote standby ADB in a standby region—both with Private Endpoint enabled. We’ll use a reusable module to keep the code small, readable, and consistent.

Architecture Overview: Deploying OCI Autonomous Database Terraform with ADG

Region A (primary): Autonomous Database (ATP/OLTP) with Private Endpoint.
Region B (standby): Remote standby created via Autonomous Data Guard (ADG), cross-region.
Traffic: Application talks to the primary PE; in DR you can promote the standby.
Networking: PE rides OCI backbone. For complex/multi-VCN topologies, you’ll likely add Remote Peering—out of scope here, covered in my flagship training.

💡 Note: This walkthrough focuses on ADB + ADG. We don’t dive into VCN design here. Both DBs are created with module-managed networking (use_existing_vcn = false) for simplicity.

Figure 1. Cross-region deployment of OCI Autonomous Database with Autonomous Data Guard.

Step 1 – Providers (primary & standby aliases)

Use two provider aliases so Terraform knows which region to target for each resource. Example:


provider "oci" {
  alias            = "primary"
  region           = var.primary_region
  tenancy_ocid     = var.tenancy_ocid
  user_ocid        = var.user_ocid
  fingerprint      = var.fingerprint
  private_key_path = var.private_key_path
}

provider "oci" {
  alias            = "secondary"
  region           = var.secondary_region
  tenancy_ocid     = var.tenancy_ocid
  user_ocid        = var.user_ocid
  fingerprint      = var.fingerprint
  private_key_path = var.private_key_path
}

Step 2 – Primary Autonomous Database (Serverless, OLTP)

Create the source ADB in the primary region. Private Endpoint keeps it off the public internet.


module "oci-fk-adb-primary" {
  providers = {
    oci = oci.primary
  }
  source                                = "github.com/mlinxfeld/terraform-oci-fk-adb"

  compartment_ocid                      = var.compartment_ocid
  adb_database_db_name                  = "FoggyKitchenADB"
  adb_database_display_name             = "FoggyKitchenADB_Source"
  adb_password                          = var.adb_password

  adb_database_db_workload              = "OLTP"   # ATP
  adb_free_tier                         = false
  adb_database_cpu_core_count           = 1
  adb_database_data_storage_size_in_tbs = 1

  # networking kept simple: module provisions what’s needed
  use_existing_vcn                      = false
  adb_private_endpoint                  = true
}

Step 3 – Remote Standby via Autonomous Data Guard (cross-region)

Now create the standby in the secondary region. The key is setting the source and remote DR type:


module "oci-fk-adb-remote-standby" {
  providers = {
    oci = oci.standby
  }
  source                                = "github.com/mlinxfeld/terraform-oci-fk-adb"

  compartment_ocid                      = var.compartment_ocid
  adb_database_db_name                  = "FoggyKitchenADB"
  adb_database_display_name             = "FoggyKitchenADB_Standby"

  adb_database_db_workload              = "OLTP"   # ATP
  adb_free_tier                         = false
  adb_database_cpu_core_count           = 1
  adb_database_data_storage_size_in_tbs = 1

  use_existing_vcn                      = false
  adb_private_endpoint                  = true
  adb_private_endpoint_label            = "fkadbpes"

  # *** ADG remote standby linkage ***
  source_id                             = module.oci-fk-adb-primary.adb_database.adb_database_id
  source_type                           = "CROSS_REGION_DISASTER_RECOVERY"
  remote_disaster_recovery_type         = "ADG"
}

What happens here:

source_id points to the primary ADB OCID.
source_type = "CROSS_REGION_DISASTER_RECOVERY" tells OCI we’re building a remote DR peer.
remote_disaster_recovery_type = "ADG" selects Autonomous Data Guard as the replication mechanism.

💡 Note on using a custom Terraform module:

In this example, I’m using my custom Terraform module for Autonomous Database. Why does this matter?

The module encapsulates all the boilerplate around ADB provisioning, ADG association, and networking.
It can operate in two modes:
- Self-contained networking – when use_existing_vcn = false, the module automatically provisions a VCN and subnets for the database.
- Plug-in mode – when use_existing_vcn = true, you can inject your own existing VCN/subnet IDs, making it easy to integrate with enterprise-grade network topologies.
This dual-mode flexibility is valuable: you can spin up a quick PoC in minutes, or drop the module into a production multicloud landscape where networking is centrally managed.

While you could always use the raw Terraform resources (oci_database_autonomous_database, ADG configs, VCN, subnets), the module reduces boilerplate, enforces best practices, and makes your IaC cleaner and easier to maintain.

Why this matters (business view)

Why should you care about setting up Autonomous Data Guard across regions? Beyond the technical implementation, the business impact is critical. Using OCI Autonomous Database Terraform setup with ADG ensures:

Real DR, not backups: ADG keeps a warm standby in another region—shorter RTO/RPO, faster recovery than snapshot-restore.
Repeatable & auditable: Terraform codifies DR; you can review, peer-review, and re-apply safely.
Private by default: With Private Endpoints, the database isn’t exposed publicly—reduced attack surface.
Scale later: Increase cores/storage independently on primary/standby as workloads evolve.
By codifying your DR setup with OCI Autonomous Database Terraform, you ensure repeatability and easier audits.

What’s next?

These steps are just the beginning. In real enterprise setups, DR involves more than just spinning up a standby database. You’ll often need to:

Add connection strings and application failover logic.
Wire notifications/alarms for role changes (primary/standby).
Promote standby for DR tests; then reinstate ADG to rehearse recovery.
Evolve networking (Remote Peering, shared services VCN, DNS failover).

In this walkthrough, we’ve successfully deployed an Autonomous Database with cross-region disaster recovery using Autonomous Data Guard and Terraform. You’ve seen how modular code can make DR setups repeatable, auditable, and easy to extend.

If you want to explore more advanced OCI Autonomous Database Terraform scenarios — from connection failover to network peering — check out my dedicated course on OCI Autonomous Database. It expands on what we covered here with real labs and step-by-step guidance.

🚀 Take Your OCI Autonomous Database Skills Further

Master Autonomous Database in real-world scenarios. In the full FoggyKitchen course, you’ll learn not only cross-region disaster recovery with Autonomous Data Guard, but also how to integrate with applications, manage private endpoints, and rehearse failover/fallback like in enterprise-grade environments.

🔒 Lifetime • ⏱️ Self-paced • 🧪 Real labs