StackScopes
StackScopes connects an infrastructure failure or proposed change to the workloads and capabilities that may depend on it. Blast Radius Analysis evaluates typed paths, redundancy, time-to-impact, operational criticality, and evidence so teams can distinguish a directly affected resource from the broader system consequences.
Problem
Cloud alerts usually name a resource. Incident and change decisions require more context:
- Which workloads require this resource?
- Which effects are direct and which are transitive?
- Do independent alternatives remain?
- How long before customers notice?
- Is impact limited to one tenant group or shared across a Region?
- Which owners and recovery steps are involved?
Counting connected nodes cannot answer those questions. An IAM policy may permit 100 workloads to access a key while only a few use it. A queue failure may delay processing rather than stop a synchronous request. A logging destination can receive traffic from every service without sitting on the customer request path.
Blast-radius analysis also risks overconfidence. Unknown application behavior, missing telemetry, stale topology, and external services can create gaps. A responsible result must show its evidence and limits.
What We Built
We built an impact engine that starts from a defined failure or change and follows relevant dependency edges toward affected resources, workloads, capabilities, owners, and tenant scopes.
The engine represents several impact states:
- Unavailable
- Degraded
- Delayed
- At risk
- Unaffected through a verified path
- Unknown because coverage is incomplete
Direct and transitive effects remain separate. A service that cannot write to a database is directly affected. A downstream fulfillment process that receives no new events is indirectly delayed.
Results are path-based. Every impact conclusion points back to the initiating condition through typed relationships. Users can inspect configuration, runtime evidence, observation time, criticality, and confidence instead of relying on one opaque risk score.
How It Works
Define the initiating condition
The input can be a failed resource, degraded property, security finding, infrastructure diff, or historical event. Property-level analysis prevents a small rule change from being modeled as total node loss.
Find structural reachability
The engine follows dependency edges in the impact direction. Edge types determine whether a connection is relevant to the changed capability. Cycles are handled without endless traversal.
Evaluate behavior
Each path is evaluated as required, optional, degradable, buffered, redundant, fallback, or unknown. This changes the result from “connected” to an operational impact state.
For asynchronous paths, queues and retention can create delay. For synchronous paths, timeouts and retries can create fast impact. Caches, credentials, circuit breakers, and manual fallback can move a workload through different states over time.
Check alternatives and shared dependencies
The engine identifies remaining paths and tests whether they share the same endpoint, key, route, identity provider, or data store. A Multi-AZ compute deployment may still contain a regional or shared single point of failure.
Fallback readiness includes activation method, capacity, data consistency, and validation status. Existence alone is not treated as proof.
Project into operational context
Resources connect to workloads, services, customer capabilities, owners, and controlled tenant groups where reliable mappings exist. Tenant projection uses routing or partition rules and avoids unnecessary personal data.
Prioritize results
Impact is prioritized using criticality, time-to-impact, affected capability, confidence, and recovery complexity—not graph degree alone.
Output and Evidence
Blast-radius output can include:
- Directly affected resources
- Transitive impact paths
- Workload and capability states
- Tenant scope where known
- Time-to-impact progression
- Critical and shared dependencies
- Alternative paths considered
- Recovery prerequisites
- Confidence and coverage gaps
- Evidence for every important edge
Illustrative scenario: An Aurora writer becomes unavailable. Checkout cannot commit orders and is directly unavailable after retry. Fulfillment remains technically healthy but receives no new messages, so it is delayed. Reporting reads a replica and remains available while freshness begins to degrade. Login uses a different identity and session path and remains unaffected. The result communicates four different operational states rather than declaring every connected resource down.
Evidence can include the database endpoint referenced by a secret, recent trace paths, queue configuration, workload ownership, replica relationships, and owner-reviewed fallback. If tenant routing shows the database serves one regional shard, the result can limit scope to that controlled tenant group without inventing customer counts.
Why It Matters
During incidents, a prioritized blast radius helps teams identify owners, choose containment, and communicate what is known versus suspected. It reduces the need to manually assemble a dependency story from separate consoles while the system is changing.
Before deployment, the same engine can evaluate a Terraform plan, CloudFormation change set, route update, IAM policy, or security-group diff against current topology. A reviewer can see which critical paths may change and request validation before production.
Blast radius also supports architecture work. Repeated analysis can reveal growing shared dependencies, unverified fallback, difficult recovery sequences, and resources whose operational importance is not visible from cost or health metrics.
The goal is not to produce a larger impact number. It is to produce a defensible explanation that helps engineers make the next decision.
Recovery complexity is part of that explanation. Two scenarios can affect the same number of services while requiring very different responses. StackScopes considers prerequisites, data-consistency concerns, required permissions, cross-team ownership, rollback, and validation. A path with modest immediate impact but an untested, multi-team recovery sequence may deserve attention before a broader issue with a verified automatic fallback.
Time-based results support more precise communication. An immediate synchronous failure, a queue backlog approaching its deadline, and a backup path that increases future recovery risk are different operational states. The analysis can show how scope changes as caches expire, retries exhaust, fallback activates, or capacity is consumed.
Operational Guardrails
Customer and tenant context is sensitive. StackScopes uses minimal controlled identifiers, tenant-aware authorization, retention controls, encryption, and auditability. Personal data is not required for topology analysis.
Results distinguish potential from observed impact. Permission paths are not treated as runtime use, and historical traffic is not automatically treated as current criticality.
Model freshness and collection gaps remain visible. High-risk decisions should refresh relevant topology and confirm important assumptions with workload owners.
Blast-radius conclusions do not initiate unrestricted production actions. Any recovery execution uses separate permissions, policy constraints, approval, and verification.
The engine does not convert affected infrastructure into unsupported revenue estimates or customer counts. Business impact requires verified business data and an explicit model.
Confidence is multidimensional. A dependency path can have strong topology evidence while application response remains uncertain. Scenario assumptions and fallback readiness are reported separately so a polished result does not imply more certainty than the sources support.
Historical state is preserved when available. During an incident, responders can evaluate the topology that existed before rollback or automatic replacement rather than relying only on the current healthy graph.
FAQ
Is blast radius just the number of connected resources?
No. The engine evaluates dependency type, criticality, fallback, timing, capability context, and confidence. Resource count is only one summary.
Can analysis run before a change?
Yes. A proposed infrastructure or configuration diff can be projected onto current topology to identify affected paths and review questions.
How does StackScopes identify tenant impact?
Where available, it uses controlled workload, routing, shard, or partition mappings. Unknown scope remains unknown, and unnecessary personal data is not collected.
Does redundancy guarantee a workload is unaffected?
No. Alternative paths may share dependencies, lack capacity, require manual activation, or introduce data-consistency constraints. These conditions remain part of the result.
Related StackScopes links
StackScopes keeps operational evidence, timestamps, assumptions, and confidence visible. Production-impacting recovery remains subject to policy and human approval.