Blast radius
Before you apply a recommendation, change an autoscaler policy, or edit a schedule, see which connected resources it would affect and how risky the change is.
Before you stop, delete, or modify a resource, check what else it touches. Blast Radius shows this on the architecture canvas (Cloud Estate → Inventory → Architecture): ZopNight highlights the connected resources the action would affect, classifies each as At Risk, Warning, or Safe (At Risk means the resource is affected), and gives the whole change a risk score.

Cloud Estate → Inventory → Architecture with Blast Radius open: the target, its connected resources coloured by impact, and the risk score with per-category breakdown.
Before you start
- A discovered resource with something to change: an open recommendation, an autoscaler policy, or a schedule. Blast radius launches from each of these; see Where you can launch it.
- Connected cloud accounts for the neighbours. Edges are inferred from discovered resource metadata, so resources ZopNight has not discovered cannot appear.
How it works
A server-side adjacency graph, built from resource metadata (shared security groups, routing targets, attachments, triggers, parent links), identifies the resources one hop away from the target. Each neighbour is then classified by what the operation does to it, and the results roll up into a single risk score.
How ZopNight detects the edges
| Edge | Detected from |
|---|---|
| DB access | AWS: shared security group · GCP: shared network · Azure: shared subnet |
| Routes to | Load balancer target metadata |
| Attached to | Volume/disk attachment metadata |
| Triggers | Lambda trigger UIDs, Cloud Run event sources |
| Member of | Resource parent link |
| Cross-region | Connection resources with a source and target resource |
Open blast radius
Open blast radius
From a recommendation drawer, click Blast radius (autoscaler policies and schedule changes offer the same view). The Inventory Architecture tab opens with the overlay active; Exit Blast Radius or Back to Recommendations returns you.
Read the canvas and side panel
The canvas colours the target blue, At Risk resources red, warnings amber, and safe resources green, dimming everything unrelated. The side panel lists the impact summary, per-resource detail, ownership (team / group / schedule), and the risk factors that drove the score.
Decide
Apply the change, or go back and adjust it. Treat the result as “what could this touch”, then confirm with your own knowledge of the system (see FAQ).
Impact classification
Every connected resource is classified At Risk (the resource is affected), Warning, or Safe. The classification is resource-type-aware and operation-aware; the default for anything unmapped is Warning (Safe must be positively proven).
Modify operations
| Behaviour class | Example types | What happens to connections |
|---|---|---|
| Online modify | lambda, ebs, s3, ecs-service, K8s deployments, managed services | All connections Safe: live update, no interruption |
| Restart modify | ec2, vm, rds, cloudsql, elasticache | Attached storage Safe; load balancer Warning (briefly offline); ASG Warning (auto-replaces); DB Safe; K8s pool parent At Risk (nodes recreated) |
| Pool modify | gke-nodepool, eks-nodegroup, aks-agentpool, asg, vmss, mig | Child nodes At Risk (recreated); cluster Safe; storage Warning (brief detach); services Safe (endpoints auto-update) |
Delete / stop operations
Classified by the edge type between the target and its neighbour, and (for database edges) whether the neighbour is a database or a compute node:
- delete + parent link → At Risk (destroyed with parent)
- delete + attachment → Warning (detached, data preserved)
- delete + trigger → At Risk (trigger breaks, invocations fail)
- delete + DB access → database neighbour At Risk (data lost); compute neighbour Safe (DB is independent)
- stop + attachment → Safe (storage preserved on all clouds)
- stop + DB access → database neighbour Warning (connections terminated); compute neighbour Safe
- cross-region + delete/stop → Warning (replica promoted / serves stale data)
Risk score
Each analysis produces a risk score on a 0 to 100 scale (0 = all Safe, higher = riskier). Three parts feed it:
- Impact severity: At Risk counts full, Warning counts half (up to 60 points)
- Environment: prod 15, staging 8, dev 3 (zeroed when nothing is impacted)
- Ownership spread: how many teams and schedules are touched (up to 20 points)
An all-Safe blast radius scores 0.
Where you can launch it
| Entity | Behaviour |
|---|---|
| Resource | A single resource targeted by a recommendation |
| Autoscaler policy | The policy’s scaling target is the root; applying / removing / tuning shows the same connected set and risk score |
| Schedule | Update/delete pops a confirmation with a View Blast Radius link; shows attached resources and expandable groups with per-resource cost impact (monthly cost, current savings, after savings) |
FAQ
Why is a resource I know is connected not shown?
Blast Radius looks at one hop of neighbours and infers connectivity from resource metadata, not live VPC flow logs. A dependency that is two hops away, or that no metadata records, does not appear.
Why are so many neighbours marked Warning?
Warning is the default for any resource type or operation that is not mapped. Safe has to be positively proven.
Does a low risk score mean the change is safe?
No. Blast Radius does not reason about redundancy (it won’t tell you how many other healthy targets a load balancer still has). It is a decision aid, not a guarantee.