Amazon Web Services services
24 / 24
Amazon Web Services

Account Security — Organizations, SCPs, WAF & GuardDuty

Separate workloads across accounts, set guardrails nobody can escape, and detect what IAM cannot prevent.

Security at the account level, above individual IAM policies.

Separate buildings rather than separate desks. Site rules apply to everyone including the manager, a doorman turns away known troublemakers, and cameras record what the rules did not anticipate.

Key Concepts

1
Multiple accounts are the strongest boundary AWS offers.
    Organization
      +-- Security OU     log-archive, audit
      +-- Workloads OU    prod, staging, dev
      +-- Sandbox OU      experiments, capped spend
2
A mistake in dev cannot reach prod's resources, because they are different accounts. That is a harder boundary than any IAM policy within one account.
3
Service Control Policies set a ceiling.
    an SCP does not GRANT anything -- it limits what IAM may grant
    effective permission = SCP ∩ IAM policy
4
So even an account's root user cannot exceed the SCP. Typical guardrails: deny leaving the organisation, deny disabling CloudTrail, deny regions you do not operate in.
5
That last one is a real control. Denying unused regions removes a large part of the crypto-mining blast radius from a leaked key.
6
WAF filters HTTP before it reaches you. Attached to CloudFront, an ALB or API Gateway:
7
    managed rule groups  OWASP top 10, bad inputs, known bad IPs
    rate-based rule      block an IP over N requests in 5 minutes
    geo match            block or allow by country
8
Shield Standard is automatic and covers common network floods. Shield Advanced adds higher-layer protection, a response team and billing protection, at a serious monthly cost.
9
GuardDuty detects rather than prevents. It reads CloudTrail, VPC Flow Logs and DNS logs and flags cryptomining, credential exfiltration, calls from Tor and unusual API patterns. It needs no agent — turning it on is a checkbox.
10
The detection layer, assembled.
    CloudTrail     every API call, to an immutable log archive account
    Config         resource configuration over time, and compliance
    GuardDuty      threat detection from those logs
    Security Hub   one place for the findings
11
Root accounts get MFA and nothing else. No access keys, used only for the few tasks that require it.
12
What the interviewer is probing.1. "What does an SCP do that IAM cannot?" Probing: the ceiling. Stalls: "It grants permissions." Moves up: it grants nothing — it caps what IAM may grant, so even the account root cannot exceed it.
13
2. "Why deny unused regions?" Probing: blast radius. Stalls: "Tidiness." Moves up: it removes most of the crypto-mining blast radius from a leaked key, which would otherwise spin up instances anywhere.
14
3. "Why separate accounts rather than separate IAM policies?" Probing: the strength of the boundary. Stalls: "Policies are enough." Moves up: an account is a harder boundary with its own quotas and billing; a mistake in development cannot reach production resources at all.
15
4. "What does GuardDuty catch that policy cannot prevent?" Probing: detection versus prevention. Stalls: "It blocks attacks." Moves up: it only detects — cryptomining, credential exfiltration, calls from Tor — from CloudTrail, flow and DNS logs, and someone must own the findings.
Use cases:organizationsscpwafguarddutycloudtrail