Skip to main content

Command Palette

Search for a command to run...

End-to-End DR Testing on Azure: AKS, PostgreSQL, Front Door, App Gateway, and Cloudflare

Updated
2 min read

Introduction

In this blog, I walk through how I set up and validated a Disaster Recovery (DR) architecture using Azure Kubernetes Service (AKS), PostgreSQL (EDB/PGD), Azure Front Door, Application Gateway, and Cloudflare.

The goal was simple:
👉 Validate multi-region failover before the real application is ready

Architecture Overview

User → Cloudflare → Azure Front Door → Application Gateway → AKS → PostgreSQL

  • Cloudflare → DNS + WAF

  • Front Door → Global routing + failover

  • App Gateway → Regional entry

  • AKS → Application

  • PostgreSQL → Shared backend (multi-region capable)

Step 1 – Create a Test Application

Instead of waiting for the real app, I built a simple Flask app:

  • UI to submit messages

  • Stores data in PostgreSQL

  • Helps validate connectivity + failover

Step 2 – Containerize and Deploy to AKS

  • Built Docker image

  • Used Azure Container Registry (ACR)

  • Deployed to AKS in a separate namespace (dr-test)

Step 3 – Database Connectivity

Used PostgreSQL connection string:

  • Stored securely in Kubernetes Secret

  • Injected via environment variable

Key learning:
👉 Special characters like @ must be URL encoded (%40)

Step 4 – Expose Application

Initially exposed via:

  • Kubernetes LoadBalancer

  • Got public IPs for both regions

Step 5 – Application Gateway Setup

Created one App Gateway per region:

  • Backend → AKS LoadBalancer IP

  • Health probe → /

  • Fixed issue: Backend must use port 80 (not 443)

Step 6 – Azure Front Door

Configured:

  • Origin group (Italy + Sweden)

  • Health probe /

  • Routing rule with failover

Step 7 – Cloudflare Integration

  • Added custom domain

  • Created TXT record for validation

  • Added CNAME → Front Door

Step 8 – DR Testing

Simulated failure:

kubectl scale deployment dr-test-app --replicas=0 -n dr-test

Result:
👉 Traffic automatically failed over to secondary region

Conclusion

This setup provides a production-like DR validation environment:

  • Multi-region

  • Layered routing

  • Real failover testing

And the best part:
👉 You don’t need the real app to validate DR