Impact classification · ZopDev University

Outcome

By the end of this lesson, you will be able to predict the impact severity for a modify, delete or stop, using the three modify behaviour families and the edge-type matrix.


Tier	Engineer
JTBD	”Know why this neighbour is red and that one is green, without guessing.”
Personas	Platform Engineer · SRE
Prerequisites	M2.15.L1
Time	9 minutes
Bloom verb	Predict (Analyze)

1. Concept

Classification runs on two different axes depending on the operation, and knowing which axis is in play is most of the skill.

MODIFY      classified by the TARGET'S RESOURCE TYPE
            "what does changing a thing of this kind do
             to its neighbours?"

DELETE/STOP classified by the EDGE TYPE
            "what does this relationship mean when one
             end goes away?"

Modify: three behaviour families

The behaviour map covers 152 resource types, grouped into three families by what a change to them actually does.

onlineModify        94 types
  lambda, ebs, s3, ecs-service, k8s deployments, most
  managed services

  ALL connections SAFE. A live update with no service
  interruption: the resource changes underneath its
  neighbours without going away.

restartModify       52 types
  ec2, vm, rds, cloudsql, elasticache

  attached storage   SAFE     survives the restart
  load balancer      WARNING  target offline briefly
  ASG                WARNING  may auto-replace the
                              instance during the change
  database           SAFE     independent lifecycle
  K8s pool parent    AFFECTED all nodes recreated

poolModify           6 types
  gke-nodepool, eks-nodegroup, aks-agentpool,
  asg, vmss, mig

  child nodes        AFFECTED recreated
  cluster            SAFE     survives
  storage            WARNING  brief detach
  services           SAFE     endpoints auto-update
  db_access,         SAFE     pods reconnect
  triggers

The distinction that catches people: an EC2 modify is not the same kind of event as a Lambda modify. One reboots and one does not, and the classification reflects that rather than treating “modify” as one thing.

Delete and stop: the edge matrix

OPERATION  EDGE                     RESULT
─────────────────────────────────────────────────────────────
delete     member_of (incoming)     AFFECTED
                                    destroyed with the parent

delete     attached_to (incoming)   WARNING
                                    detached, data preserved

delete     triggers (incoming)      AFFECTED
                                    the trigger breaks,
                                    invocations fail

delete     db_access                TARGET-TYPE AWARE
                                      database target -> AFFECTED
                                        (data lost)
                                      compute target  -> SAFE
                                        (the DB is independent)

stop       attached_to              SAFE
                                    storage is preserved on
                                    all three clouds

stop       db_access                TARGET-TYPE AWARE
                                      database target -> WARNING
                                        (connections terminated)
                                      compute target  -> SAFE

delete or  cross_region             WARNING
stop                                replica promoted to
                                    standalone, or serving
                                    stale data

Why db_access needs a target-type override

This is the subtlety worth internalising.

A db_access EDGE IS SYMMETRIC IN THE GRAPH.
An app instance and a database share a security group;
the edge exists between them with no inherent direction.

BUT THE CONSEQUENCE IS NOT SYMMETRIC.

  Delete the DATABASE  -> the app loses its data store.
                          AFFECTED.
  Delete the APP       -> the database is completely
                          unaffected. It has its own
                          lifecycle. SAFE.

Without the target-type override, one of those two directions would always be wrong. The classifier checks whether the neighbour on the other end is a database or a compute resource and answers accordingly.

The same asymmetry applies to stop, one severity lower: stopping a database terminates its connections (warning), stopping an app touches the database not at all (safe).

attached_to: delete versus stop

DELETE the instance   -> volume WARNING
                         It detaches. The DATA IS
                         PRESERVED, which is why this is
                         amber rather than red.

STOP the instance     -> volume SAFE
                         Storage is preserved on all
                         three clouds. Nothing happens
                         to it at all.

People routinely expect stopping an instance to endanger its disk, and on none of AWS, GCP or Azure does it. That expectation is exactly what the green is there to correct.

The default, restated

Anything not explicitly mapped -> WARNING

Including modify. Safe is never inferred; it is proven
through the behaviour map or the edge matrix.

So the classification carries two different kinds of amber: “this will be briefly disrupted”, and “this type is unmapped and we will not claim it is safe”. The side panel’s prose is what tells them apart.

2. Demo

Predicting three results before opening the canvas, then checking:

SETUP: a standard three-tier stack
  alb-prod            -> routes_to -> i-web-01, i-web-02
  i-web-01            -> db_access -> rds-orders
  i-web-01            -> attached_to <- vol-web-01
  asg-web             -> member_of  <- i-web-01, i-web-02

─────────────────────────────────────────────────────────
CASE 1: resize i-web-01  (modify, ec2)

  PREDICTION
    ec2 is restartModify.
      vol-web-01  attached storage -> SAFE
      alb-prod    load balancer    -> WARNING
      asg-web     ASG              -> WARNING
      rds-orders  database         -> SAFE

  ACTUAL: matched. Risk score low, driven by two ambers
  and a prod environment weight.

─────────────────────────────────────────────────────────
CASE 2: delete rds-orders  (delete, db_access edge)

  PREDICTION
    db_access with a DATABASE target -> AFFECTED
      i-web-01  AFFECTED
      i-web-02  AFFECTED

  ACTUAL: matched. Two red nodes, high risk score.
  Nobody was going to do this, but it is the case that
  demonstrates why the target-type override exists.

─────────────────────────────────────────────────────────
CASE 3: stop i-web-01  (stop)

  PREDICTION
    attached_to  -> vol-web-01 SAFE  (storage preserved)
    db_access with a COMPUTE target on the other end
                 -> rds-orders SAFE
    routes_to    -> alb-prod WARNING (target goes away)
    member_of    -> asg-web WARNING

  ACTUAL: matched, and the one that surprised the
  engineer was vol-web-01 being GREEN. They expected
  amber, on the instinct that stopping an instance
  endangers its disk. It does not, on any of the three
  clouds.

─────────────────────────────────────────────────────────
THE CASE THAT DID NOT MATCH

CASE 4: modify a `datasync-task`
  PREDICTION: safe, it is a managed service
  ACTUAL:     WARNING on all three neighbours

  The type is not in the 152-entry behaviour map, so the
  default applied. That amber is a coverage statement,
  not a hazard assessment, and reading the side panel
  prose is what distinguishes the two.

3. Hands-on (6 min)

1. Pick an EC2 or VM instance with a volume, a load
   balancer and a database neighbour. PREDICT a modify:
   volume ______  LB ______  DB ______  ASG ______
   Then check. Score yourself: ____/4

2. Same resource, predict a STOP:
   volume ______  LB ______  DB ______
   Which one did you get wrong, if any?  __________
   (The volume is the usual one.)

3. Find a db_access edge in your estate. Run blast radius
   from BOTH ends:
   from the database side, neighbour severity: ______
   from the compute side,  neighbour severity: ______
   Explain the asymmetry in one line:
   ______________________________________________

4. Find a node pool or ASG. Predict a modify:
   child nodes ______  cluster ______  storage ______

5. Find any result where a neighbour is amber and the
   panel prose does NOT describe a disruption. That is
   an unmapped type. Which one?
   ______________________________________________

4. Knowledge check

Q1

An engineer stops an EC2 instance that has an attached EBS volume. Blast radius shows the volume as:

A. Warning, because the volume is detached during the stop
B. Affected, because the instance can no longer reach it
C. Dimmed, because it is not a true neighbour
D. Safe

Show answer

Correct: D. Storage is preserved through a stop on all three clouds, so nothing happens to the volume at all. It is a delete of the instance that shows the volume as warning, because it detaches although the data survives. This is the most commonly mis-predicted case. The expectation that stopping an instance endangers its disk is widespread and wrong, and the green is there precisely to correct it.

Q2

Why does the db_access edge need a target-type-aware override rather than a single severity?

A. Because databases are much more expensive than the compute around them
B. Because the edge is symmetric in the graph but the consequence is not
C. Because databases may be multi-AZ
D. Because security groups can span regions

Show answer

Correct: B. Deleting the database costs the app its data store (affected); deleting the app leaves the database entirely unaffected (safe). Without the override, one of the two directions would always be wrong. The same asymmetry applies to stop, one severity lower: stopping a database terminates connections (warning), stopping an app touches the database not at all (safe).

Q3

Modifying a Lambda function and modifying an EC2 instance produce different neighbour classifications because:

A. Lambda has fewer neighbours
B. Lambda modifications are not tracked
C. EC2 modifications always require a stop
D. They are in different behaviour families

Show answer

Correct: D. Lambda is onlineModify, where a live update interrupts nothing so all connections are safe; EC2 is restartModify, where the resource reboots, so a load balancer target goes briefly offline and an ASG may auto-replace it. The third family, poolModify (node pools, ASGs, VMSS, MIGs), is different again: child nodes are affected because they are recreated, while the cluster itself is safe. Treating “modify” as one operation is the mistake the three families exist to prevent.

5. Apply

Before opening a blast radius result, predict it. Ask which axis applies (resource type for modify, edge type for delete and stop), then predict each neighbour. Your mis-predictions are the useful output: they are the places your mental model of the estate is wrong.

When a neighbour is amber, read the panel prose before treating it as a hazard. Amber carries two meanings, and only one of them is a real disruption.

Glossary terms touched

onlineModify · restartModify · poolModify · db_access edge

Outcome

1. Concept

Modify: three behaviour families

Delete and stop: the edge matrix

Why db_access needs a target-type override

attached_to: delete versus stop

The default, restated

2. Demo

3. Hands-on (6 min)

4. Knowledge check

Q1

Q2

Q3

5. Apply

Related lessons

Glossary terms touched

Start with the bill.