# Blast radius

> Before you apply a recommendation, see which connected resources it will impact and at what severity; on the architecture canvas.

Source: https://zop.dev/docs/zopnight/optimization/blast-radius

---

Before you stop, delete, or modify a resource, the question that matters is "what else does this touch?" Blast Radius answers it visually: click a recommendation, and ZopNight highlights the connected resources the action would affect, classifies each by severity, and gives the whole change a risk score; all on the architecture canvas.

![Blast Radius overlay on the architecture canvas: a target resource in the centre with red, amber, and green edges to connected resources, a left panel listing At Risk / Warning / Safe resources, and a right panel with a risk score, connected-resource counts, and category impact](https://storage.googleapis.com/zopdev-blog-resources/1/files/originals/20260707/adc37044-ff8d-428e-994f-85371dc69f97-blastradius.png)

*Blast Radius on the architecture canvas; the target resource, its connected resources coloured by impact, and a risk score with per-category breakdown.*

## How it works

**Open blast radius**

  From a recommendation (or an autoscaler policy, or a schedule change), click **View Blast Radius**. The canvas overlay activates.

**ZopNight builds the impact graph**

  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.

**Read the canvas + side panel**

  The canvas colours the target blue, affected 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.

## Impact classification

Every connected resource is classified **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 affected (nodes recreated) |
| **Pool modify** | gke-nodepool, eks-nodegroup, aks-agentpool, asg, vmss, mig | Child nodes affected (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** → affected (destroyed with parent)
- **delete + attachment** → warning (detached, data preserved)
- **delete + trigger** → affected (trigger breaks, invocations fail)
- **delete + DB access** → database neighbour affected (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 (0 = all safe, higher = riskier), combining impact severity (up to 60), environment (up to 15), and ownership spread (up to 20):

- **Impact severity**: affected 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.

## 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 |

## 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 **View Blast Radius**; shows attached resources and expandable groups with per-resource cost impact (monthly cost, current savings, after savings) |

## Limits

Blast Radius is a decision aid, not a guarantee. Today it looks at **one hop** of neighbours, infers connectivity from resource metadata (not live VPC flow logs), and doesn't reason about redundancy (it won't tell you how many *other* healthy targets a load balancer still has). Treat it as "what could this touch," then confirm with your own knowledge of the system.