Check Blast Radius Before You Remediate or Stop
One hop of connected resources, classed by what the operation would do to each, in the minute before you click.
A stop or delete is rarely dangerous because of the target itself. It is dangerous because of what is connected to it: the application servers that share a database’s security group, the function whose trigger points at a bucket, the nodes inside a pool. ZopNight’s blast radius view shows those neighbours for the specific operation you are about to run. This guide walks through reading it and cross-checking it with the provider’s own data.
1. Open it from the recommendation
On a recommendation, choose View Blast Radius. The architecture canvas switches to an overlay: the target in blue, affected neighbours in red, warnings in amber, safe neighbours in green, and everything unrelated dimmed. A side panel lists the same resources with their team, group and schedule ownership, and the risk factors behind the score.
Changing or deleting a schedule opens a similar check: a confirmation dialog with a View Blast Radius link listing the attached resources and groups with each one’s monthly cost and savings before and after.
2. Read the classes for this operation
The same neighbour can be safe for a stop and affected for a delete. The rules, per connection type:
| Operation and connection | Class | Why |
|---|---|---|
| Delete, child is a member of the target | Affected | Destroyed with the parent |
| Delete, volume attached to the target | Warning | Detached, data preserved |
| Delete, something the target triggers | Affected | The trigger breaks |
| Delete, database target | Affected | Data is lost |
| Stop, attached storage | Safe | Storage is preserved |
| Stop, database target | Warning | Connections are terminated |
| Delete or stop, cross-region replica | Warning | Promoted or serving stale data |
For a modify, such as a resize, the class depends on the resource type: live-update types leave all connections safe; restart types put load balancers and Auto Scaling groups at warning; node-pool types mark their nodes affected because they are recreated. Any resource type not explicitly mapped defaults to warning, never safe.
3. Read the risk score
The 0 to 100 score adds up three things: how many neighbours are affected or at warning, the environment (production weighs most, then staging, then dev, and this counts only if something is impacted), and how widely ownership spreads across teams and schedules. If everything is safe, the score is 0. Use it to decide who else needs to look, not as an automatic go or no-go.
4. Cross-check with the provider
The graph is built from resource metadata: shared security groups on AWS, shared networks on GCP, shared subnets on Azure, load balancer targets, volume attachments and triggers. It does not read network traffic. For a database or instance on AWS, list every network interface that uses the same security group:
aws ec2 describe-network-interfaces \ --filters Name=group-id,Values=sg-0123456789abcdef0 \ --query "NetworkInterfaces[].[NetworkInterfaceId,InterfaceType,Attachment.InstanceId,Description]" \ --output tableEach row is something sharing that group. If this lists resources the blast radius did not show, ask why before proceeding.
5. Know the limits
- Only direct (one-hop) neighbours appear, not neighbours of neighbours.
- It does not know redundancy: it cannot tell that a load balancer has nine other healthy targets.
- It covers single resources, autoscaler policies and schedules; teams, resource groups and cloud accounts are not blast-radius targets.
Then act
With the neighbours understood, go ahead with the remediation, or hand it to an admin for approval; see approving a destructive remediation. More on the model: blast radius explained and one-hop adjacency.