Who We Worked With
Our client was a Tamil Nadu-based energy & utilities company running a grid monitoring and load-analytics platform on Amazon EKS — the system operations teams relied on to track distribution-network health, meter data, and load patterns in near real time. The platform's stateful services held recent telemetry and configuration data that couldn't simply be re-created from scratch after an outage. We're keeping their identity anonymous at their request; we'll just call them "the client" here.
The Problem: Multi-AZ Wasn't the Whole Answer
The client's EKS cluster was already spread across multiple Availability Zones, which covered the everyday failure modes — a bad node, a lost AZ, routine maintenance. What it didn't cover was a full regional disruption, and for a utilities operator, that gap wasn't academic. Grid monitoring is the kind of system regulators and internal continuity policies expect to have a real answer for when someone asks, "what happens if the whole region goes down?"
The client didn't have that answer yet. They had backups of individual pieces — EBS snapshots here, config exports there — but no single, tested path from "us-east-1 is gone" to "the platform is back up in another region, with the data intact." They came to us wanting exactly that: a cross-region recovery process they could point to, not just assume would work.
What We Did: Built the Recovery Path, Then Proved It
We used AWS Backup as the coordination layer across both regions, rather than stitching together region-specific scripts by hand.
The approach, in practice:
- Stood up a pre-provisioned DR cluster in the recovery region ahead of time. This was a deliberate choice — restoring into an already-running EKS cluster removes cluster bring-up from the recovery-time clock entirely, instead of provisioning infrastructure during an actual incident.
- Created backup vaults in both regions and an IAM role scoped specifically to AWS Backup's cross-region operations.
- Backed up the full application state, not just the database — EKS cluster configuration, Kubernetes resources (Deployments, StatefulSets, Services, ConfigMaps, Secrets), storage classes, RBAC configuration, and the underlying EBS volumes for the platform's stateful services.
- Configured cross-region copy jobs so every backup in the source vault replicated automatically to the DR region's vault, and confirmed each copy job completed before treating a backup as "safe."
- Wrote the restore metadata explicitly — mapping each EBS snapshot to its target availability zone, volume type, and encryption setting in the DR region, so a restore didn't depend on someone making the right call under pressure.
- Ran a full restore into the existing DR cluster end to end, targeting the pre-provisioned cluster rather than standing up a new one.
What We Verified — Not Just What We Assumed
A restore that completes without error isn't the same as a restore that actually worked. We treated those as two separate questions.
Once the restore job reported success, we checked that every pod in the application's namespace came up healthy, that persistent volume claims bound correctly to the restored EBS volumes, and — the part that actually matters to the client — that the data itself was intact. We queried the restored database for record counts and checked the cache layer's key counts against what the source region held at backup time. Only after both matched did we call the recovery path proven, and we brought the platform up behind a load balancer in the DR region to confirm it was actually reachable and functional, not just technically "restored."
Where We Left Things
A one-time successful restore isn't a disaster recovery plan — it's a demonstration that one is possible. We made sure the client left with the former, not just the latter:
- A documented, repeatable restore runbook, built from the exact steps and restore metadata we used — not a generic AWS Backup tutorial, but the client's own cluster, storage classes, and application topology.
- A recommendation to schedule backups, not rely on on-demand jobs, so cross-region copies happen automatically on a cadence tied to their actual RPO target.
- Amazon EventBridge alerting on backup and copy job status, so a failed job gets caught the same day, not discovered during the next real incident.
- A standing recommendation to re-run the DR drill periodically — an untested recovery path degrades quietly as the application changes underneath it, and the only way to know it still works is to actually run it again.
Why This Approach Worked
The client didn't need a bespoke disaster-recovery platform built from scratch — they needed AWS Backup's existing cross-region capabilities applied correctly to their specific cluster, storage, and application state, with the restore actually tested rather than assumed. Pre-provisioning the DR cluster ahead of time meant the recovery-time clock started on data, not infrastructure. And verifying record counts instead of just restore-job status meant "recovered" was a checked fact, not a hope.
That's the standard we hold every engagement to: prove the thing works before calling it done, not after.
Wondering whether your Kubernetes workloads would actually survive a full regional outage — or just assume they would? Metasips helps engineering teams design and test real cross-region recovery paths for EKS, using AWS-native tooling instead of custom scripting. Get in touch and let's find out before an incident does.
This case study is based on the approach described in AWS's "Cross-Region disaster recovery for Amazon EKS using AWS Backup" — referenced here for readers who want the full technical walkthrough.