OCI (Oracle Cloud Infrastructure) Functions are regional resources. If you need the same serverless workload to run in another region, whether for a planned migration, regional expansion, or disaster recovery, you should first choose a recovery approach that matches your business continuity requirements. OCI disaster recovery guidance describes multiple approaches, including backup and restore, pilot light, warm standby, and active/active, and the right choice depends on factors such as recovery time objective (RTO), recovery point objective (RPO), acceptable cost, and operational complexity. This guide focuses on a cold-standby / recreate-in-destination-region approach for OCI Functions, in which the workload can be recreated in another approved region using maintained artifacts, prepared dependencies, and a repeatable recovery process. 

For OCI Functions, a cross-region recovery strategy should account for both the function code and the surrounding OCI resources required to restore equivalent behavior in the destination region. Functions applications are created in a specific region, use specified subnets, and functions run from container images stored in OCI Container Registry (OCIR). In practice, that means a successful cross-region recovery strategy includes not only the function code, but also the application definition, image availability, IAM, networking, secrets, triggering and routing integrations, security controls, and operational settings required for production parity in the destination region.

If you already maintain a standby environment, validate it periodically with a controlled exercise: deploy/redeploy the workload, re-create or repoint integrations, and run end-to-end tests in the destination region. Also review destination-region service limits and headroom before an event forces you to rely on them.

This guide focuses on cross-region recreation and failover readiness for OCI Functions workloads. It does not attempt to fully describe warm-standby or continuously active multi-region deployment architectures, which may require broader data replication, routing, and cross-region design decisions.

Recovery at a Glance

A complete recreation is successful only when the destination region can (1) deploy the required function images, (2) invoke the functions through equivalent trigger paths and client-facing access patterns, and (3) allow the functions to reach their dependencies (databases, Vault, Object Storage, external endpoints) with equivalent security controls and observability. In many cases, the destination region will use different regional endpoints than the source region, so external callers and upstream systems might require updated configuration, DNS/routing changes, or other cutover steps to reach the destination-region deployment. We’ll refer to the region where your function currently runs as the source region, and the region where you will recreate it as the destination region.

A function rarely stands alone. A complete recreation typically includes:

  • The Functions application (including VCN/subnet attachment and app-level config)
  • Each function definition (memory/timeout/config) plus the function image in OCIR
  • The surrounding service integrations/”wiring”: API Gateway routes, Events rules, Service Connector targets, schedules, etc.
  • Runtime dependencies: networking, IAM, Vault secrets/keys, logs/alarms, and whatever the function calls (databases, buckets, streams)
Diagram of Functions Cross Region Recovery High Level Components

Step 1: Prepare an Inventory of Source Region

Start by documenting everything required to reproduce the workload in another region.

Capture Platform Prerequisites

  • IAM setup: policies, groups, dynamic groups, and any resource-principal-based access patterns
  • Limits and capacity: whether the destination region needs raised service limits. See Viewing Current Limit Values for OCI Functions
  • Networking: VCNs, subnets, route rules, gateways, NSGs, security lists, and DNS dependencies
  • Secrets and keys: Vault secrets, key references, and how the functions authenticate to OCI services
  • Downstream services: databases, Object Storage buckets, streams, queues, and external endpoints

Capture Function and Application Details 

For each application and function, capture the full configuration required to reproduce its production behavior in the destination region, including:

  • Application definition: compartment, subnet attachment, app-level configuration, and any application-level security attributes or policies
  • Function definition: memory, timeout, config/environment variables, logging/tracing settings, and provisioned concurrency if used
  • Image and deployment configuration: OCIR image references, image build process (source code, Dockerfile, build commands), and any image signing or verification requirements
  • Security and secrets dependencies: KMS/Vault usage, secret references, dynamic groups, IAM policies, and any ZPR-related configuration if used
  • Operational controls: logging configuration, alarms, metrics, notifications, image scanning settings, and failure/success destinations if configured
  • Runtime integrations: any configuration that affects how the function is invoked or interacts with other OCI services or external systems

The goal is to reproduce the full production-relevant configuration of the source workload in the destination region, not just the code package. If the source workload uses provisioned concurrency, signed-image enforcement, repository image scanning, or ZPR/security attributes, equivalent controls should also exist in the destination region before the workload is considered recovery-ready.

Where possible, capture the Functions application, function definitions, networking, IAM, repository configuration, and related dependencies as infrastructure as code and deployment automation, rather than relying only on manual documentation. A written inventory remains useful, but automation typically provides a more reliable and repeatable way to recreate the workload in a destination region. OCI Functions resource creation flows can also be saved as Terraform stacks, which can help turn a inventory into a reusable recovery mechanism.

Identify what relies on your functions

List every system or integration that invokes, routes to, or otherwise depends on your functions so you can recreate or cut over those paths in the destination region. Common examples include:

  • API Gateway deployments and routes
  • OCI Events rules
  • Connector Hub connectors
  • Resource Scheduler schedules
  • Any external applications, clients, or custom services that invoke the function directly or indirectly

Step 2. Prepare Destination-Region Dependencies

Use the inventory from Step 1 to recreate the prerequisites in the destination region. This typically includes:

  • Networking and subnet layout
  • IAM permissions and dynamic groups
  • Vault secrets and keys
  • Log groups, service logs, and alarms
  • Any downstream services the function depends on
  • Any security, compliance, or operational controls required for production parity

Step 3. Recreate applications

For each application in the source region, create a corresponding Functions application in the destination region.

Make sure the destination application matches the source in the areas that affect runtime behavior:

  • Correct compartment placement
  • Correct subnet attachment, especially for private applications
  • Equivalent application configuration
  • Expected logging and tracing settings where applicable
  • Equivalent application-level security and policy configuration, including security attributes / ZPR where used

OCI Functions applications are defined with subnets and logging-related behavior, so recreating the application correctly is a foundational step before recreating the functions inside it.

Step 4. Recreate functions

Each OCI Function runs from a container image stored in OCIR. Because the image location and deployment configuration matter, decide how you will make the image available in the destination region.

Two common approaches are:

  • Retag and push an existing image into the destination region’s OCIR repository
  • Rebuild the image and push the newly built image into destination-region OCIR

If the function is straightforward and doesn’t rely on region-specific build inputs, retagging and pushing can be sufficient. If the build depends on region-specific configuration or you want to reproduce the release more explicitly, rebuilding may be the better choice. See Pushing Images Using the Docker CLI for details. 

Once the image is available in the destination region:

  • Create the function in the destination application
  • Point it to the destination-region OCIR image
  • Reapply the same memory, timeout, and configuration values
  • Reapply any provisioned concurrency, image verification, image scanning expectations, and other production operational settings used in the source region
  • Re-enable any logging, tracing, and related settings needed for production operations

Step 5. Recreate Integrations and Invocation Paths

After the functions are deployed, recreate the integrations and invocation paths that invoke or route to them.

This includes:

  • API Gateway routes and deployments
  • OCI Events rules
  • Connector Hub connectors
  • Any external or scheduled invocation mechanism

For API Gateway specifically, functions referenced by an API deployment must already exist and be routable from the gateway’s VCN path. For Events and Connector Hub, you’ll want to recreate equivalent rules or connectors and update them to target the destination-region functions. External callers may need configuration, endpoint, DNS, or routing updates during cutover.

Step 6. Test

Validate the destination-region environment before you rely on it. 

Recommended checks include:

  • Invoke each function directly for a basic smoke test
  • Invoke functions through their real trigger paths
  • Confirm access to secrets, databases, Object Storage, streams, queues, and external endpoints
  • Verify that logs, metrics, and alarms appear in the expected destination-region operational views

Conclusion

Cross-region recovery for OCI Functions is successful only when you can recreate the full workload, not just the code: the Functions application, container images in OCIR, invocation paths (API Gateway, Events, Connector Hub), and the networking/IAM/Vault/observability controls needed for production parity. The most reliable way to achieve repeatable recovery is to maintain an up-to-date inventory and automate recreation via infrastructure as code, then validate readiness with periodic deploy + invoke + end-to-end tests in the destination region.

As a best practice:

  • Keep source artifacts and image build processes current
  • Maintain a documented runbook for cross-region recreation
  • Pre-provision destination-region dependencies where needed
  • Prefer infrastructure as code and automated deployment pipelines for repeatable resource provisioningover manual recreation alone
  • Periodically test redeployment and invocation flows
  • Review service limits and regional prerequisites ahead of time
  • Maintain a cutover plan for external callers, including endpoint, DNS, routing, or configuration changes where required

If your business continuity requirements extend beyond a nearby region, consider planning for a geographically distant destination region as well, subject to your data residency, compliance, and latency requirements. OCI service limits, networking, IAM, and workload dependencies should all be reviewed as part of that decision.

If you have questions about your OCI Functions architecture or recovery design, contact Oracle Support through a My Oracle Support (MOS) service request