DEV Community

Vipin Vijaykumar
Vipin Vijaykumar

Posted on

SAP BTP Multi-Region Setup with Terraform: A Practical Guide to Disaster Recovery Subaccount Pairing

#btp #terraform #tutorial #sap

From real-world outages to automated resilience — how to protect your SAP BTP workloads across regions using Terraform

When the Cloud Goes Down

In March 2026, physical attacks on data center infrastructure in the Middle East took two of three availability zones in an AWS region completely offline. The damage was not a software bug or a misconfiguration — it was fire and power shutdown from direct physical impact. Engineers could not simply reboot their way out of it. Physical repairs took multiple days.

The cascading effect went further than the directly hit facilities. Ninety-one AWS services were disrupted across two Middle East regions. The control plane degraded — IAM, CloudFormation, and EC2 APIs all throttled — meaning that organizations whose DR strategy relied on deploying infrastructure during the incident found their recovery tooling was itself unreliable.

Analyses published after the incident landed on a blunt conclusion: Multi-AZ is not disaster recovery. One expert put it plainly: "Multi-AZ protects you from hardware failures, not a missile hitting an entire availability zone cluster in the same city."

A financial analysis of the impact illustrated the stakes concretely: for an $80K/hour SaaS platform, total costs from such an outage — revenue loss, SLA penalties, customer churn — would reach $2.77 million. Organizations that had pre-provisioned infrastructure in a secondary region and implemented automated, data-plane-based failover recovered in 28 minutes. Those that did not faced days of downtime.

Network World's post-incident report captured the lesson: "The enterprises that will come through events like this aren't the ones with the thickest DR binders, they're the ones who've actually failed over to another continent."

These are not theoretical scenarios. They happened.

What Is Disaster Recovery?

Disaster recovery (DR) is the practice of designing systems so that when a failure occurs — and failure always occurs eventually — your business can continue operating or recover fast enough that the impact is acceptable.

Two metrics define every DR strategy:

Recovery Time Objective (RTO) — the maximum acceptable time your system can be down after a failure. This is a business decision, not a technical one.

Recovery Point Objective (RPO) — the maximum acceptable data loss measured in time. Can you tolerate losing the last 15 minutes of transactions? The last 24 hours? Nothing at all?

These are defined in the NIST SP 800-34 Contingency Planning Guide and the AWS Well-Architected Reliability Pillar. The lower your RTO and RPO targets, the more investment your DR strategy requires — but according to the Uptime Institute's 2023 Annual Outage Analysis, more than two-thirds of enterprise outages already cost over $100,000. For large enterprises the figure climbs past $1 million per hour. The cost of not investing is often higher than the cost of investing.

Multi-AZ: Necessary but Not Sufficient

Before discussing multi-region, it is worth being precise about what multi-AZ actually protects against — because it is commonly misunderstood.

Cloud providers divide each geographic region into multiple Availability Zones (AZs) — physically separate data centers within the same metropolitan area, connected by low-latency private fiber. Deploying across multiple AZs within the same region protects against:

  • A single data center power failure
  • A single building fire or hardware fault
  • A localized network partition within one facility

What multi-AZ does not protect against:

  • A failure that affects the entire regional network layer (routing misconfiguration, backbone outage)
  • A physical event large enough to affect multiple facilities in the same city simultaneously
  • A regional control plane failure that takes down APIs across all AZs
  • Legal or regulatory action that makes an entire geographic jurisdiction inaccessible
  • A submarine cable cut that severs connectivity to the entire region

The March 2026 Middle East incident demonstrated all of these simultaneously. The AZs were in the same metropolitan area. When two of three were hit, the third experienced cascading degradation from the loss of redundancy. And when the control plane throttled, the customers whose DR plans said "redeploy in a secondary region" discovered they could not reliably execute that plan using the primary region's APIs.

A real-world case study of a multi-region DR implementation shows what proper architecture achieves: after a regional outage caused nearly a full day of downtime with $40,000 in losses, the organization moved to an active/passive architecture across two geographically separate regions. The result was a 2–5 minute RTO and sub-30-second RPO — at 50% of the cost of a full active-active model.

Multi-region is not a luxury for hyperscalers. It is the minimum viable resilience posture for business-critical workloads.

The Physical Internet Is Also a Factor

The Red Sea submarine cable incidents of early 2024 are a useful reminder that cloud regions are not abstract — they depend on physical cables laid on ocean floors. When four major cables connecting Europe, the Middle East, and Asia were damaged, approximately 25% of traffic on those routes was disrupted. Providers rerouted traffic around the Cape of Good Hope, adding latency and reducing throughput. Cloud services in European regions serving users in Asia experienced degraded performance for weeks while repairs were negotiated.

Organizations with active workloads on both sides of the disruption — in both an EU region and an Asia-Pacific region — were insulated. Those with all workloads in a single region were not.

The point is not that these events happen frequently. The point is that they happen unpredictably, they affect entire geographic areas, and multi-AZ provides no protection against them.

SAP BTP Multi-Region: The Platform-Level Response

SAP Business Technology Platform is the cloud foundation for modern SAP applications — the runtime for extensions, integrations, and services that connect to core SAP systems. For enterprises running business-critical SAP workloads on BTP, regional resilience is not optional.

SAP's answer is the BTP Multi-Region Setup, described in the SAP BTP Multi-Region Guide. It provides a native disaster recovery capability at the platform layer, built around the following core ideas:

Basic Concepts

SAP defines specific region pairs — the secondary region for a given primary is prescribed by SAP, ensuring sufficient geographic distance while keeping data within the same jurisdiction. The pairing is not arbitrary; it reflects deliberate decisions about latency, data residency, and regulatory compliance.

The BTP Multi-Region architecture involves:

  • Region Pairs — SAP-defined pairs of regions that are sufficiently distant from each other while remaining within the same country or jurisdiction
  • Subaccount Pairs — two customer subaccounts, one in each region of a pair, linked into a DR relationship
  • Redundant Setup — customers deploy equivalent resources in both subaccounts; SAP BTP handles asynchronous replication between them behind the scenes
  • Instance-level Failover — controlled failover for individual service instances
  • Subaccount-level Failover — controlled failover of an entire subaccount (currently in development)
  • Regional-level Failover — in a catastrophic regional event, SAP can initiate failover after a formal disaster declaration

One important design note from the SAP documentation: customers should segregate DR and non-DR workloads into separate subaccounts.

Currently Supported Region Pairs

SAP maintains a defined and growing set of DR region pairs. The secondary region for a given primary is prescribed by SAP ensuring sufficient geographic distance while keeping data within the same jurisdiction. For the most current list of supported pairs, refer to the SAP BTP Multi-Region Pairs page.

How to Set Up Multi-Region on BTP

According to the SAP setup guide, the process involves:

1. Pair two subaccounts — one in each region of a supported pair. The pairing is symmetric: SAP BTP does not maintain or enforce "primary" and "secondary" roles at the platform level. You define which is primary based on your use case, typically proximity to your users.

2. Configure redundant resources — customers are responsible for deploying equivalent resources in both subaccounts. This includes:

  • Trust configuration (same Identity Provider in both subaccounts for seamless authentication after failover)
  • Entitlements (equivalent service entitlements in both subaccounts)
  • Role collections and assignments
  • Destination and connectivity settings
  • Environment variables and service bindings

3. Pair service instances — for services with built-in multi-region support, create a paired instance using the dr_setup parameter:

cf create-service <service> <plan> <name> \
  -c '{"dr_setup": {"op": "pair", "values": ["<primary_instance_id>"]}}'
Enter fullscreen mode Exit fullscreen mode

After pairing, the primary instance handles traffic while data is asynchronously replicated to the secondary.

For the full list of services with built-in multi-region support (a growing list), refer to SAP BTP Services with Built-in Multi-Region Support.

Triggering a Failover

When a failover is needed, SAP BTP supports two strategies:

Planned failover — zero data loss. The primary service instance becomes read-only, the secondary waits for full replication to complete, then promotes itself. If replication cannot complete within a time window, the failover is aborted. This is for scheduled maintenance or proactive region migration.

Forced failover — used during regional outages where the primary is unreachable. May incur data loss. The customer is responsible for resolving any data inconsistency afterward.

cf update-service <name> \
  -c '{"dr_setup": {"op": "promote", "values": ["forced"]}}'
Enter fullscreen mode Exit fullscreen mode

Why Automate This with Terraform?

Subaccount pairing through the BTP cockpit works for one environment. In practice you have multiple subaccounts in development, staging, and production — each needing its own pairing, each with the same bilateral role assignments, each needing to be documented, audited, and reproducible.

The SAP BTP Terraform provider exposes subaccount pairing as a first-class resource. With it, your DR topology is:

  • Auditable — every pairing change is a git commit with an author and timestamp
  • Repeatable — new environment, same topology, terraform apply
  • Drift-detectable — terraform plan catches manual changes made through the cockpit
  • GitOps-compatible — DR changes go through pull request review like any other infra change

Critically: the March 2026 incident showed that relying on deploying infrastructure during an outage is dangerous — the control plane may be degraded. With Terraform, everything is pre-provisioned and pre-declared. When the incident happens, the infrastructure is already there.

The Terraform Resource: btp_disaster_recovery_subaccount_pair

Refer to the full schema from the Terraform Registry:

Required Arguments

Argument Type Description
subaccount_id String The ID of the first subaccount to pair
paired_subaccount_id String The ID of the second subaccount to pair

Read-Only Attributes

Attribute Type Description
pair_id String Unique identifier of the subaccount pair
globalaccount_id String The Global Account owning both subaccounts
created_by String The user who created the pairing
created_date String Timestamp of creation in RFC3339 format

Step-by-Step Terraform Configuration

1. Provider Setup

provider.tf

terraform {
  required_providers {
    btp = {
      source  = "SAP/btp"
    }
  }
}

provider "btp" {
  globalaccount = var.globalaccount_subdomain
}
Enter fullscreen mode Exit fullscreen mode

2. Variables

variables.tf

variable "globalaccount_subdomain" {
  type        = string
  description = "Your BTP Global Account subdomain"
}

variable "primary_subaccount_id" {
  type        = string
  description = "ID of the subaccount in the primary region (e.g. cf-eu10)"
}

variable "secondary_subaccount_id" {
  type        = string
  description = "ID of the subaccount in the paired secondary region (e.g. cf-eu13)"
}
Enter fullscreen mode Exit fullscreen mode

3. The DR Pair Resource

main.tf

resource "btp_disaster_recovery_subaccount_pair" "dr_pair" {
  subaccount_id        = var.primary_subaccount_id
  paired_subaccount_id = var.secondary_subaccount_id
}
Enter fullscreen mode Exit fullscreen mode

Two arguments. The provider handles the API calls to establish the DR relationship. That is the entire configuration needed to pair the subaccounts.

4. Outputs

outputs.tf

output "dr_pair_id" {
  value       = btp_disaster_recovery_subaccount_pair.dr_pair.pair_id
  description = "The ID of the disaster recovery subaccount pair"
}

output "dr_pair_created_by" {
  value       = btp_disaster_recovery_subaccount_pair.dr_pair.created_by
}

output "dr_pair_created_date" {
  value       = btp_disaster_recovery_subaccount_pair.dr_pair.created_date
}
Enter fullscreen mode Exit fullscreen mode

5. Apply 

terraform init
terraform plan
terraform apply
Enter fullscreen mode Exit fullscreen mode

After apply, the pairing appears in the BTP cockpit under Multi-Region Setup in both subaccounts.

Importing an Existing Pair

If the pairing was created manually through the cockpit, import it without destroying and recreating it.

CLI import:

terraform import btp_disaster_recovery_subaccount_pair.dr_pair \
  'dd005d8b-1fee-4e6b-b6ff-cb9a197b7fe0,2dc1ecf1-786c-4f92-91f2-26650ab3ad28'
Enter fullscreen mode Exit fullscreen mode

Import block (Terraform 1.5+):

import {
  to = btp_disaster_recovery_subaccount_pair.dr_pair
  identity = {
    subaccount_id        = "dd005d8b-1fee-4e6b-b6ff-cb9a197b7fe0"
    paired_subaccount_id = "2dc1ecf1-786c-4f92-91f2-26650ab3ad28"
  }
}
Enter fullscreen mode Exit fullscreen mode

Important Constraints

  • One-to-one only. Each subaccount can be paired with exactly one other subaccount.
  • Bilateral role requirement. The Central Disaster Recovery Administrator role must be assigned in both subaccounts. Assigning it only in one is the most common setup mistake.
  • Destroy unpairs, does not delete. terraform destroy removes the pairing relationship — subaccounts and their resources are untouched.
  • Subaccount pairing is the foundation. It establishes the trust relationship. Individual service instance pairs and subscription pairs must be created on top of it to achieve actual data replication.
  • Separate DR from non-DR workloads. SAP recommends keeping DR-enabled resources in dedicated subaccounts, separate from non-DR workloads.

Summary

The events of the past few years — data center disruptions, undersea cable damage, regional network failures — have made one thing clear: multi-AZ resilience is no longer enough for business-critical workloads. The failure modes that actually cause extended outages operate at a level above individual availability zones.

Multi-region disaster recovery is the architectural response. For SAP BTP workloads, the platform provides this natively through subaccount pairing and service-level replication. Terraform makes the configuration auditable, repeatable, and safe to execute before the incident happens — not during it.

The full setup is genuinely simple:

resource "btp_disaster_recovery_subaccount_pair" "dr_pair" {
  subaccount_id        = var.primary_subaccount_id
  paired_subaccount_id = var.secondary_subaccount_id
}
Enter fullscreen mode Exit fullscreen mode
Step Action
1 Create two subaccounts in a supported SAP BTP region pair
2 Assign Central Disaster Recovery Administrator in both
3 Configure the SAP BTP Terraform provider
4 Declare btp_disaster_recovery_subaccount_pair and apply
5 Mirror entitlements, trust config, roles, and destinations
6 Create service instance pairs for each critical service
7 Test a planned failover — before you need it

References

Top comments (0)