Regional Outage Rehearsal
Import cloud configurations and critical user paths to simulate a data-center region outage and identify the business functions that would actually fail.
Teams often believe they have deployed across multiple regions, only to discover after an outage in a popular cloud region that login, DNS, queues, or identity services are still single points of failure. They import Terraform and Kubernetes configurations along with a few critical user paths, such as logging in, placing an order, reading a file, or submitting a form.
The product maps resources, networks, identities, databases, and third-party services into a dependency graph, then temporarily simulates the complete loss of a selected region. Rather than merely flagging disconnected resources, it replays each user path to show where the request breaks, which functions can still be completed, and which customer actions are affected.
Results are ranked by user impact and remediation priority, highlighting components that appear multi-region but retain cross-region dependencies. After changing the configuration, teams can rerun the same exercise and compare whether the failure surface for paths such as login and checkout has narrowed. The first version focuses on cloud configuration and a small set of predefined user paths; it neither replaces an actual disaster-recovery failover nor changes production environments automatically.
Why now
On July 22, a Northern Virginia transmission-line outage prompted data centers to switch to backup power. S1 Related searches exceeded 20,000, up 500%; they were still continuing when observed on July 25. S1
Target user
The core users are SREs, platform engineers, and cloud architects responsible for multi-region systems. It is most valuable before launching a new region or entering a disaster-recovery review, when configurations look complete but a real failover is too costly. Teams need to confirm whether login, checkout, and file reads still work and turn the risks into schedulable fixes.
Minimal entry point
Start with AWS, Terraform, and Kubernetes. Read resource references from `terraform show -json`, then parse service relationships from Kubernetes YAML. Limit the dependency graph to networking, DNS, identity, queues, and databases. Define user paths as declarative HTTP steps that can extract tokens and validate responses. During simulation, remove only the target region from the graph and never call the production account. Report each path’s first break point, remaining capabilities, and remediation order. Retests compare break-point changes in the same paths; do not perform live fault injection yet.
Punching above its weight
Release an open-source CLI and GitHub Action that checks pull requests for cross-region single points of failure. Build reproducible Terraform examples around public incidents to show how login and checkout paths can break. Publish short checklists for common architectures, then use them to encourage uploads of sanitized configurations. Early distribution should focus on SRE, platform engineering, and cloud architecture communities.
Competitors & gaps
- AWS Resilience HubGoogle
- AWS Resilience Hub can already import Terraform state, EKS, and CloudFormation. It provides resilience assessments, failure modes, and AWS FIS experiment recommendations. S2 Its next-generation API also includes user journeys, dependency lists, and topology edges. S2 These capabilities closely overlap with the product’s core. Its advantage is native knowledge of AWS resource semantics and the ability to connect to live fault injection. The opening is a lighter offline workflow: teams can rehearse quickly in code review without connecting a cloud account. Results can also be expressed directly as blocked logins or purchases rather than resource scores alone. If the product supports only AWS, that differentiation could narrow quickly. To remain viable, cross-cloud dependencies and path replay need to be the core product.
- GremlinGoogle
- Gremlin already covers multicloud, Kubernetes, and on-premises environments. It can discover network dependencies and test dependency loss and regional evacuation. S3 It also provides stop conditions and blast-radius controls. For mature SRE teams, this comes closer to a real answer than a static rehearsal. The opening is mainly lower setup cost and clearer presentation of results. Many teams are not ready to install agents or run chaos experiments. A regional-disconnect rehearsal can first read the code repository and produce an explanatory report without sending traffic. It can also organize findings around a small set of user paths, making joint product-and-engineering review easier. Still, static analysis is only useful as pre-exercise screening. If reports cannot lead smoothly into live exercises, users will ultimately turn to existing platforms.
How it makes money
Charge a monthly subscription per application environment for continuous configuration scanning, user-path rehearsals, and before-and-after comparisons. Live fault injection and compliance reporting can be enterprise-tier features.
The case against
The largest risk is that AWS is already closing the gap. The next-generation Resilience Hub includes user journeys and dependency topology. S2 Static configuration cannot reveal runtime traffic, dynamic DNS, or implicit SaaS dependencies. False negatives create misplaced confidence, while false positives erode engineering trust. As cloud-service semantics keep changing, rule maintenance costs can accumulate quickly. Sensitive configurations may also prevent hosted uploads. Unless it can prove that path-level explanations are materially faster and easier to use, teams may choose their cloud provider or Gremlin instead.