Outcome
By the end of this lesson, you will be able to explain how each of the six edge types is detected from resource metadata, and name the four limits that bound what a blast radius result can tell you.
| Tier | Engineer |
| JTBD | ”Know what the graph can see, so I know what I still have to check myself.” |
| Personas | Platform Engineer · SRE · Security/Compliance |
| Prerequisites | M2.15.L3 |
| Time | 9 minutes |
| Bloom verb | Explain (Understand), Name (Remember) |
1. Concept
Every edge in the adjacency graph is inferred from resource metadata that discovery already collected. Nothing is instrumented, and no traffic is observed.
The six edge types
EDGE DETECTED FROM─────────────────────────────────────────────────────────────db_access AWS: a shared security group GCP: a shared network Azure: a shared subnet
routes_to a load balancer's targets[] metadata
attached_to a volume or disk's attachedTo metadata
triggers Lambda triggerUids[] Cloud Run eventSource
member_of a resource's parentUID
cross_region connection resources carrying both a sourceResourceId and a targetResourceIddb_access is the one to be careful with
Look at how it is detected: a shared security group, network or subnet. That is a possibility of access, not a fact of it.
WHAT IT ACTUALLY MEANS "These two things are on the same network segment, so one COULD reach the other."
WHAT IT DOES NOT MEAN "These two things talk to each other."
CONSEQUENCE, BOTH DIRECTIONS FALSE EDGES a flat security group produces a db_access edge between every instance and every database in it, including pairs that have never exchanged a packet.
MISSED EDGES an app reaching a database through a different security group, a VPC peering, a proxy or a public endpoint may produce no edge at all.A flat network architecture makes blast radius noisy; a well-segmented one makes it sharp. That is worth knowing when you interpret a result on an estate you did not design.
The other five are stronger
attached_to, member_of, routes_to Read from authoritative provider fields. A volume's attachedTo IS the attachment. A parentUID IS the parentage. These are facts.
triggers Read from the function's own trigger list. Strong for the trigger mechanisms it covers, and blind to application-level invocation: one service calling another over HTTP is not a trigger edge.
cross_region Requires a connection resource carrying both ends, so it sees explicit replication relationships and not ad-hoc ones.The practical hierarchy: trust attached_to and member_of almost completely, trust routes_to and triggers for what they cover, and read db_access as “possible” rather than “actual”.
The four limits
Stated plainly, because relying on the tool means knowing where it stops.
1. ONE HOP ONLY Direct neighbours. The service two hops away that depends on this one is invisible.
2. NO ENTITY TYPES BEYOND THE THREE resource, autoscaler_policy and schedule are supported roots. Team, resource group and cloud account are not. "What breaks if I delete this whole resource group" is not a question v1 answers.
3. INFERRED, NOT OBSERVED Edges come from resource metadata, never from VPC flow logs or traces. An application dependency that leaves no metadata trace does not exist to the graph.
4. NO REDUNDANCY AWARENESS The graph does not know how many OTHER healthy targets an ALB has. Removing the only target and one of forty are indistinguishable to it.Limit 4 is the one most likely to matter in a real decision, and the manual check it implies is cheap: look at how many healthy targets the load balancer has before treating an amber as acceptable.
Freshness
The graph is cached per organisation with a short TTL, and invalidated on resource-discovered and resource-deleted events. So it is as current as discovery, which means:
A resource created five minutes ago may not be in thegraph yet, and therefore may not appear as a neighbour.
If you have just provisioned something, refresh discoverybefore trusting a blast radius result that ought toinclude it.How to use it honestly
WHAT TO SAY IN A CHANGE REVIEW "Blast radius shows two directly-connected resources affected, both owned by our team. It traverses one hop and infers edges from metadata, so I have separately checked that the ALB has three other healthy targets and that no downstream service calls this one."
WHAT NOT TO SAY "Blast radius says it's safe."The first sentence is defensible and the second is not, and the difference is entirely in naming what the tool did not check.
2. Demo
A result read correctly, including what it could not see:
ACTION: delete rds-legacy-reporting (RC-169 idle RDS, no connections in 30 days)
BLAST RADIUS, operation = delete neighbours 7 i-report-01 AFFECTED db_access, DB target i-report-02 AFFECTED db_access, DB target i-etl-03 AFFECTED db_access, DB target i-web-01 AFFECTED db_access, DB target i-web-02 AFFECTED db_access, DB target vol-rds-data WARNING attached_to rds-replica-eu WARNING cross_region
risk score 78
FIRST READING: "five instances break. Do not delete."
SECOND READING, checking HOW the edges were found: All five db_access edges came from a SHARED SECURITY GROUP. The estate has one flat `app-tier` SG containing every instance and every database.
So the edge says these five COULD reach the database, not that they DO.
THE MANUAL CHECK THE TOOL CANNOT DO Query logs on rds-legacy-reporting: 30 days, zero connections from any of the five. The rule that raised the recommendation had already established this.
Two of the five (i-report-01, i-report-02) were built for this database and are themselves idle. The other three have never connected to it.
WHAT BLAST RADIUS GOT RIGHT vol-rds-data WARNING and rds-replica-eu WARNING are both real and both authoritative edges. The cross-region replica WOULD be promoted to standalone, and that is a genuine consequence nobody had considered.
OUTCOME Deleted the database and the two idle report instances. Handled the EU replica deliberately rather than discovering it afterwards.
The five red nodes were noise from a flat network. The two ambers were the real finding.That inversion is the lesson: on a flat network, the reds can be the noise and the ambers the signal.
3. Hands-on (6 min)
1. Find a db_access edge in your estate. What produced it? [ ] shared security group (AWS) [ ] shared network (GCP) [ ] shared subnet (Azure) How many resources share that segment? ______ Over about 20 means your db_access edges are noisy.
2. Find an attached_to and a member_of edge. Are they consistent with what you know? Y / N These should be reliable; if one is wrong, discovery metadata is stale.
3. Take a load-balanced service. Run blast radius for a stop, then check MANUALLY: healthy targets on that LB: ______ Does the risk score reflect that? Y / N (It does not. Limit 4.)
4. Try to run blast radius on a RESOURCE GROUP. Can you? Y / N Which of the four limits is this? ______
5. Write the change-review sentence for your next action, including what you checked outside the tool: ______________________________________________4. Knowledge check
Q1
A db_access edge between an instance and a database means:
A. The instance connects to that database
B. They share a security group (AWS), network (GCP) or subnet (Azure), so one could reach the other
C. Traffic between them was observed in flow logs
D. The database appears somewhere in the instance’s own connection string configuration block
Show answer
Correct: B. It is a possibility of access inferred from network placement, not an observed connection, so a flat network produces edges between pairs that have never exchanged a packet. The error runs both ways: a flat security group creates false edges, and an app reaching a database through a peering, a proxy or a public endpoint may produce no edge at all. Read db_access as “possible” and attached_to / member_of as “factual”.
Q2
An engineer says “blast radius says this change is safe” in a change review. The accurate version is:
A. Correct as stated, if the risk score is 0
Three things are packed into that. It looks one hop out. It infers connections from how resources are configured, not from traffic anybody watched. And it does not know what is redundant. Each of those implies a manual check, named separately below.
B. Correct, provided that all of the neighbours are green, since a green neighbour by definition cannot be disrupted by the change and the risk score already accounts for every edge that the graph knows anything about already today
C. “Nothing directly connected will break, as far as the metadata shows.”
D. Correct only for delete operations
Show answer
Correct: C. The defensible sentence names what the tool did not check: hops beyond the first, dependencies that leave no metadata trace, and how many other healthy targets a load balancer has.
Q3
Which question can blast radius v1 not answer at all?
A. What happens if I delete this volume
B. What breaks if I delete this entire resource group
C. What happens if I tune this autoscaler policy
D. What happens if I edit this schedule
Show answer
Correct: B. Only resource, autoscaler_policy and schedule are supported roots; team, resource group and cloud account entity types are not in v1. C and D are both supported: an autoscaler policy uses its scaling target as the root, and a schedule shows attached resources plus expandable resource groups with per-resource cost impact.
5. Apply
Before trusting a db_access-heavy result, check how many resources share the segment that produced the edges. On a flat network those edges are noise, and the authoritative edges (attached_to, member_of, cross_region) are where the real findings usually are.
Pair every blast radius check with the one manual check the tool cannot do: how much redundancy exists behind the thing you are about to disrupt.
Related lessons
- L3: The risk score
- L1: What blast radius answers
- T1.M1.2.L2: Parent-child hierarchies
- T5.M5.4.L3: Network architecture and egress cost
Glossary terms touched
Edge type · attached_to · member_of · cross_region