Azure Deployment Guide

Here you'll get instructions and learn best practices for deploying Highflame within your Azure environment.

HA Setup across Azure

High Availability (HA) / Disaster Recovery (DR) Mode

The Highflame HA/DR Mode is designed for enterprise-grade applications where continuous operation is paramount. This mode ensures resilience against regional failures.

Characteristic	Description
Configuration	Active-Passive deployment architecture spanning two distinct geographical regions.
Suitable For	Production and mission-critical systems requiring maximum uptime and fault tolerance.
Redundancy	Built-in redundancy with mechanisms for automatic cross-region failover.
Implication	Enables seamless business continuity by rerouting traffic to the passive region during disasters or major outages in the active region.

This model focuses around two key regions: a Primary (Active) region that handles all live production traffic, and a Secondary (Passive) region that remains on standby, ready to take over in case of failure.

• Primary Region (Active): This region is responsible for handling all live, incoming production traffic.

• Secondary Region (Passive/Warm Standby): This region remains ready on standby. It typically runs minimal compute resources (or scaled-down instances) but maintains up-to-date state data via replication.

Example: Deploying across East US and West US regions.

Essential Prerequisites for the setup

A successful HA/DR deployment hinges on symmetry and operational readiness across both cloud regions. Two foundational pillars ensure seamless failover and minimal disruption:

1. Symmetrical Infrastructure: Both the Primary and Secondary regions must be configured to support identical resources.

2. State Replication: Robust replication mechanisms are mandatory to ensure that all stateful components (e.g., persistent databases) are synchronized between the Active and Passive regions. This minimizes data loss (low RPO).

Active-Passive Environment Setup

This setup is driven by two primary phases: Build for deployment, and Operate for failover execution.

Deployment: Active-Passive Environment Setup (Build Phase)

This phase focuses on provisioning symmetrical infrastructure across two Azure regions

Step 1: Define Target Regions

• Select two geographically distinct Azure regions, for example: East US (R1) and West US (R2).

• Ensure all required Azure services and SKUs are supported in both regions.

Step 2: Prepare Scripts for Resource Creation

• Prepare custom scripts to provision required infrastructure components across both regions.

• If applicable, reuse or adapt existing terraform modules from highflame-iac repository to ensure consistency and reduce duplication.

• Path: highflame-iac/azure

Step 3: Provision Core Resources in Both Regions

Provision the following infrastructure components uniformly in Region 1 (R1) and Region 2 (R2) to maintain symmetry and enable seamless failover.

• Azure Kubernetes service

• Azure Key vault

• Azure virtual network

• Azure Application Gateway

• Azure Cache for Redis

Step 4: Validate Configuration Parity

Ensure all resource parameters match across both regions, including:

• VM sizes and node pool configuration

• Subnet CIDR ranges

• Network Security Groups (NSGs)

• Kubernetes versions and add-ons

Step 5: Tag and Document Resource s

• Apply consistent tagging for auditability and environment identification.

• Document all the region-specific endpoints and failover readiness.

DR Runbook: Failover Execution (The Operate Phase)

Failover can be triggered manually or automatically, depending on your setup. Below are the operational steps to execute a successful failover:

Step 1: Trigger Database Failover (Azure PostgreSQL)

• Initiate a manual failover on the Azure PostgreSQL read replica.

• This action:

  • Promotes the read replica in Region 2 to a standalone primary (READ/WRITE).

  • Permanently detaches it from the original primary database in Region 1.

After failover, the original Region 1 database cannot be reattached to the promoted primary.

Step 2: Reconfigure Read Replica (Post-Failover)

• To restore redundancy:

  • Manually create a new read replica in Region 1.

  • Use the new primary database in Region 2 as the replication source.

• Post-failover database topology:

  • Primary Database: Region 2

  • Read Replica: Region 1

Step 3: Update Traffic Manager Endpoints

• Update Azure Traffic Manager to route traffic to the new active region (Region 2).

• Update the endpoint target with:

  • Application Gateway FQDN(Fully-qualified domain name)

  • Private Link FQDN(Fully-qualified domain name)

  • Public or Private IP address, as applicable.

Step 4: Validate Application Health

Confirm that health checks (e.g., /healthz endpoint) return a healthy status in Region R2.

• Verify that:

  • Global traffic is flowing through Azure Traffic Manager.

  • Requests are reaching the Application Gateway endpoint in Region 2 (R2).

  • End-to-end application functionality is intact.

What's Next?

• Learn next steps, like how to configure your platform, in the Quick Start Guide for Administrators.

• Get answers to common deployment-related questions in the FAQ.