Defense in depth and blast radius

Lesson 3 of 3 in Shared Responsibility and the Security Map.

Defense in depth is the assumption that each of your controls will eventually fail, written into the architecture. Not "the WAF will catch it" but "if the WAF misses it, the private subnet has no route; if the route exists, the host is patched; if the host is compromised, its role can read one prefix; if it reads the object, the object is encrypted with a key whose policy does not admit that role."

There is a specific exam behaviour attached to this phrase. A question that asks for defense in depth wants multiple layers, not the single best layer. It is overwhelmingly a multiple-response item, and the correct set is the pair or trio that covers different layers — an identity control plus a network control, say. Two options doing the same job at the same layer are a wrong pair however good each one is, because redundancy without diversity adds nothing: a second WAF with the same rules fails on exactly the same request as the first.

Trace the gauntlet in the order an attacker meets it.

The layers an attacker has to cross — and the rail that notices

  1. The internet

    An unauthenticated request, a scan, a stolen credential, a poisoned dependency. Assume arrival, not absence.

  2. Edge — CloudFront, WAF, Shield

    Layer-7 inspection, managed rule groups, rate limiting, geo matching, bot control; Shield Advanced for volumetric attacks. Catches the generic and the noisy, and misses the targeted.

  3. Network — subnets, security groups, NACLs, Network Firewall

    Private subnets with no inbound route, security groups that reference other security groups rather than CIDRs, stateful inspection for east-west traffic, DNS Firewall against exfiltration, VPC endpoints so nothing needs an internet path.

  4. Host — hardened image, patched, IMDSv2, no open SSH

    A golden AMI from EC2 Image Builder, Patch Manager on a schedule, Inspector finding what you missed, IMDSv2 so an SSRF bug cannot read the role credentials, Session Manager instead of an open port.

  5. Identity — scoped role, short session, conditions

    If code runs, what can it do? A role scoped to one prefix, a short session duration, condition keys on source VPC endpoint and organization id, no wildcards. This is the layer that converts a compromise into a nuisance.

  6. Data — key policy, bucket policy, Object Lock

    The last wall: a KMS key policy that does not admit the role, a bucket policy requiring encryption and your organization id, versioning plus Object Lock so the data cannot be destroyed even with write access.

  7. Did any layer notice?
  8. Automated containment

    GuardDuty finding → EventBridge → Systems Manager Automation: isolate, snapshot, revoke sessions, page a human with the evidence already collected.

  9. Silent compromise

    The outcome when logging had gaps, nothing consumed the findings, or alerts went to a mailbox nobody reads. Detection you do not act on is the same as no detection.

Layers answer "how hard is it to get in". Blast radius answers the question that decides how bad the day is: once one thing is compromised, how much is reachable? The SCS-C03 guide names minimising the blast radius as part of preparing for incidents, and the boundaries are not equally strong. An IAM policy is a rule inside a shared trust domain; an AWS account is a hard wall with its own control plane, its own root, its own limits. That ranking is why "use separate accounts per environment" beats "use separate IAM users per environment" every single time a stem mentions isolation or containment.

Containment boundaries, weakest at the base — how far does a compromise travel?

  1. Tag and resource — softest boundary

    Attribute-based access control on tags is expressive and cheap, and it is only as strong as your control over who may set a tag. If a principal can tag its own resources, a tag-based boundary is advisory. Useful for scale; never the answer to "must not be able to".

  2. Role session — time-boxed

    A session policy narrows a role for one assumption, and a short duration means a leaked credential expires on its own. Revocation works by denying requests issued before a point in time (aws:TokenIssueTime) rather than by deleting the credential. Strong against persistence, weak against what the role may do right now.

  3. Security group and subnet — network reach

    An isolated private subnet with no internet route, security groups that reference other security groups rather than CIDRs, and a NACL for the subnet-wide deny. These stop lateral movement — the classic containment action is swapping an instance into a security group that permits nothing.

  4. VPC — network trust domain

    A separate VPC with deliberate peering or Transit Gateway routes makes east-west movement an explicit decision rather than a default. Network Firewall between VPCs turns that decision into an inspected one.

  5. Organizational unit — policy ceiling

    An OU carries SCPs, RCPs and Control Tower controls, so every account inside it has a ceiling it cannot raise. This is where "even an account administrator cannot do X" becomes true. A sandbox OU with a restrictive SCP contains experiments structurally rather than procedurally.

  6. AWS account — the hardest wall AWS offers

    A separate control plane, separate quotas, separate root, separate billing boundary, and nothing shared unless you share it deliberately with a resource policy or RAM. Log archive, security tooling, production and development belong in different accounts for exactly this reason — and a compromise of one leaves the others needing a second compromise.

Interactive sorting exercise: Sort each control into the layer of the taxonomy it belongs to. The exam picks answers by this classification constantly.

Why “prevent > detect > respond” and not just “prevent”

Because prevention has a cost: every preventive control is also a potential outage, and an estate built only from denials becomes unworkable and gets exceptions carved into it. The exam's preference is ordinal, not absolute — it prefers prevention where a requirement says something must not be possible, and expects detection and response everywhere else. The giveaway words: "ensure", "must not", "prevent", "block" select prevention; "identify", "alert", "report", "continuously assess" select detection; "contain", "remediate", "recover", "investigate" select response.

Why “automate > manual” is a scoring rule, not a style

A documented runbook executed by a tired engineer at 03:00 is a control with a variable success rate. The guide explicitly names using AWS services to automatically remediate incidents — Systems Manager, Step Functions, Lambda — and testing the plan with Fault Injection Service. So when one option is "create a runbook and train the team" and another is "trigger a Systems Manager Automation document from the finding", the second wins unless the stem demands human judgement (a legal hold, a decision to notify regulators, anything irreversible).

Why “central > per-account” decides so many items

Scale. An answer that must be repeated in 400 accounts will drift, and the exam knows it. The central forms worth memorising: organization trail (not per-account trails), delegated administrator for GuardDuty, Security Hub, Macie, Inspector, Detective and Access Analyzer, Config aggregator and conformance packs, Firewall Manager policies, CloudFormation StackSets, Control Tower controls, RAM for shared resources, and IAM Identity Center permission sets. If one option is the central form of the other, it is usually the key.

The layering a multiple-response item is really testing

Take "Select TWO actions that provide defense in depth for data in an S3 bucket." A good pair comes from different layers: a bucket policy requiring aws:PrincipalOrgID (identity perimeter) plus SSE-KMS with a key policy that admits only the application role (data layer). A bad pair stays in one layer: two different bucket-policy conditions, or two different detection services. Ask of each candidate pair: would one failure defeat both? If yes, it is the wrong pair.

Blast radius in the exam’s vocabulary

The phrases that mean "shrink the blast radius": "limit the impact of a compromised credential" (short sessions, scoped roles, no long-lived keys), "isolate the workload" (separate account, separate VPC, isolation security group), "contain the incident" (network containment first, then evidence), "ensure the production environment is unaffected" (separate accounts under separate OUs), "limit which Regions may be used" (an SCP condition on aws:RequestedRegion). All five are structural answers, not procedural ones.

Key terms: Defense in depth, Blast radius, Attack surface, Separation of duties, Explicit deny