Pre-Flight Impact Analysis: Blast Radius Before Changes
Before a recommendation changes anything, check what else is wired to the resource it touches.
The question it answers
A recommendation says “delete this” or “stop that”. The resource on the card is rarely alone: it sits behind a load balancer, shares a security group with a database, or triggers a function. Blast radius analysis shows those neighbours before you act, directly on ZopNight’s architecture canvas.
From a recommendation, View Blast Radius opens an overlay. The target turns blue; connected resources are coloured by impact (affected, warning, safe), and everything unrelated dims. A side panel lists the impacted resources with their owning team, group and schedule.
How connections are found
ZopNight builds an adjacency graph from resource metadata it already discovers:
- Database access: a shared security group on AWS, a shared network on GCP, a shared subnet on Azure.
- Routing: load balancer targets.
- Attachments: volumes and disks attached to an instance.
- Triggers: Lambda triggers and Cloud Run event sources.
- Membership: a child resource and its parent, such as nodes in a node pool.
- Cross-region links: replication-style connections between regions.
How impact is classified
Classification depends on the operation, the kind of connection, and the resource type. Deleting a parent marks its members as affected, because they go with it, and breaks any trigger that points at it. Deleting an instance with a disk attached is a warning: the disk is detached, not destroyed. Stopping a resource that a database connection runs through is a warning, because open connections are terminated. Resizing a node pool marks its nodes as affected, because they are recreated. Anything ZopNight cannot prove safe defaults to warning, never to safe.
A risk score from 0 to 100 combines how severe the impacts are, the environment of the resources involved, and how many teams and schedules are spread across them. If nothing is impacted, the score is zero.
Beyond recommendations
The same view works for an autoscaler policy (its scaling target is the root) and for a schedule: editing or deleting a schedule opens a confirmation that lists the attached resources and groups with their monthly cost and the savings before and after the change.
What it does not do
The graph is one hop deep and is inferred from metadata, not from network flow logs. Treat it as a checklist of known neighbours, not as a traffic map.
Use it alongside auto-remediation when approving a change, and read the method in blast radius explained and 1-hop adjacency.
Questions we get a lot.
Does blast radius use network traffic data?
No. Connections are inferred from resource metadata such as security groups, load balancer targets, attachments and triggers. Flow logs are not read.
How far does the analysis reach?
One hop from the target resource. Neighbours of neighbours are not traversed.