StackScopes
StackScopes explores cloud failure against a modeled representation rather than intentionally damaging production. The Production-Safe Failure Simulation Engine applies precise scenarios to the infrastructure digital twin, evaluates typed dependencies, alternative paths, and timing, then explains which resources and capabilities could become unavailable, degraded, delayed, or uncertain.
Problem
Teams need answers to questions that are difficult or unsafe to test directly:
- What depends on this database endpoint?
- What happens if a shared KMS key becomes inaccessible?
- Which workloads lose a route through this VPC endpoint?
- Does a queue buffer impact or merely postpone it?
- Would an Availability Zone assumption expose a shared dependency?
- What could a proposed resource replacement affect?
Staging environments help, but they often differ from production in topology, account boundaries, data volume, shared services, and fallback capacity. Production chaos experiments can provide strong behavioral evidence, yet require mature observability, safeguards, rollback, and controlled scope.
A simple graph traversal is not enough. Every reachable node is not automatically down. A cache can degrade gracefully, a queue can delay work, redundant paths may remain, and application retries can change time-to-impact. Failure analysis needs dependency behavior and explicit assumptions.
What We Built
We built a scenario engine that operates on the StackScopes resource graph and temporal state. It can model a node becoming unavailable, a dependency degrading, a permission disappearing, a route changing, or a proposed infrastructure diff altering topology.
Scenarios are structured rather than vague. They identify the target, affected capability, failure mode, scope, duration, reference state, and exclusions. “Database failure” can therefore be refined into writer unavailability, authentication failure, connection exhaustion, or elevated latency.
The engine distinguishes impact states:
- Unavailable
- Degraded
- Delayed
- At risk
- Unaffected through a verified alternative
- Unknown because evidence is incomplete
Every conclusion retains its dependency path, evidence, confidence, and assumptions. The output is an explainable model result, not a guarantee of production behavior.
How It Works
Select the reference topology
A scenario can use current discovered state, a historical point-in-time graph, or a proposed state derived from a change plan. Resource and edge freshness are checked before analysis, and coverage gaps remain attached to the result.
Apply a capability-level failure
The engine changes a specific modeled property. A failed database writer removes write capability but may preserve reads. A narrowed security-group rule affects matching paths rather than deleting the entire group. An inaccessible KMS key affects encryption or decryption edges relevant to the principal and resource.
This property-level approach avoids overstating impact.
Propagate through typed dependencies
Relationship semantics determine propagation. A required synchronous dependency can produce immediate unavailability. An optional analytics event may produce partial degradation. A queue can buffer, while a cache can delay impact until expiration.
The engine records the causal path for each transition and detects cycles. Multiple paths to the same capability are evaluated together rather than defaulting to the worst result.
Evaluate redundancy
Alternative paths are checked for shared dependencies, activation method, capacity assumptions, and data consistency. Two compute instances do not provide end-to-end redundancy if both use one endpoint, key, route, or database writer.
Fallback can be automatic, application-controlled, operator-initiated, a manual workaround, or unverified. The distinction appears in results.
Advance time
Temporal simulation can include client retries, cache expiration, queue backlog thresholds, circuit-breaker behavior, credential lifetime, and recovery steps. Timing inputs retain provenance. Unknown timing is shown as a range or uncertainty rather than a precise prediction.
Project operational impact
Affected resources are mapped to workloads, capabilities, owners, and controlled tenant groups where those relationships exist. StackScopes avoids invented customer counts or financial outcomes.
Output and Evidence
Simulation output can include:
- Scenario definition and reference time
- Directly affected resources
- Transitive dependency paths
- Workload and capability states
- Blast-radius progression
- Time-to-impact timeline
- Alternative paths considered
- Shared-dependency findings
- Coverage and confidence
- Recovery prerequisites and validation steps
Illustrative scenario: A Redis endpoint is modeled as unreachable for 20 minutes. One workload uses it for required session state, another caches product configuration locally for 15 minutes, and a third uses it for distributed rate limiting with a limited local fallback. The engine projects immediate session errors, delayed configuration risk, and partial API degradation. It does not label all three workloads identically simply because they share the same Redis resource.
For every result, engineers can inspect why the dependency was considered required or optional, which source supplied the relationship, whether fallback was validated, and which timing assumptions shaped the outcome.
Simulation results can be compared across topology versions. A team can run the same database, endpoint, or Availability Zone scenario before and after an architecture change and inspect which paths were removed, introduced, or left uncertain. Historical comparison is especially useful after remediation: it tests whether the modeled critical dependency was actually eliminated instead of assuming that a completed ticket reduced risk.
The engine can also surface preparation gaps alongside impact. A critical workload without an owner, an unverified fallback, missing telemetry, or an undefined recovery prerequisite becomes an explicit finding. These findings are not presented as customer outcomes; they are concrete areas for architecture review, instrumentation, or tabletop exercises.
Why It Matters
Model-based simulation creates a low-risk way to ask broad resilience questions early. Teams can uncover shared dependencies, missing owners, untested fallback, and incomplete telemetry before planning a more expensive experiment.
It also supports change review. A Terraform plan, route update, security policy, or resource replacement can be evaluated against current topology before deployment. The result can suggest owner review, staged rollout, additional observability, or a safer alternative.
Simulation complements chaos engineering. Simulation offers breadth, repeatability, and safety; controlled experiments provide stronger behavioral validation. Observed results can update timeouts, dependency classifications, and fallback confidence in the model.
The engine turns resilience assumptions into inspectable hypotheses rather than leaving them inside diagrams and runbooks.
Operational Guardrails
Simulation operates on the model and does not require write access to intentionally disrupt AWS resources. Discovery remains read-only. Any separate controlled remediation path requires narrow permissions, policy checks, auditability, human approval, and post-action verification.
Results always show model freshness, evidence, assumptions, and gaps. StackScopes does not claim to reproduce proprietary managed-service internals, application code paths, or external-provider behavior that it cannot observe.
High-consequence scenarios need human review. Recommendations involving data recovery, identity, network access, or customer impact are presented as evidence-backed options, not automatic commands.
Simulation rules are versioned because a change in propagation logic can alter conclusions across many workloads. Historical results retain their rule and topology context.
External dependencies and managed-service behavior are bounded honestly. A scenario can represent documented configuration and observed endpoints, but it cannot reproduce undisclosed provider internals or a third party’s recovery process. Those boundaries appear in the result.
Customer and tenant projections use minimal, controlled context. They do not require personal information, and unsupported financial impact is not inferred from resource reachability.
FAQ
Does the simulation touch production resources?
No. Model-based scenarios run against the StackScopes representation and do not intentionally stop or corrupt production resources.
Does it replace chaos engineering?
No. Simulation safely explores many hypotheses; controlled experiments validate real behavior. The two methods can improve each other.
How accurate are time-to-impact estimates?
Accuracy depends on evidence for retries, caches, queues, failover, and application behavior. StackScopes shows the source and uses uncertainty ranges when precision is not justified.
Can a simulation execute recovery?
The engine can organize recovery options and prerequisites. Production execution is a separate controlled workflow requiring authorization and human approval.
Related StackScopes links
StackScopes keeps operational evidence, timestamps, assumptions, and confidence visible. Production-impacting recovery remains subject to policy and human approval.