Field notes · Cloud Security & Compliance
The security and compliance backbone I build into every AWS Organization
Security and compliance aren't a separate track from account structure — they're built into it. This is the delegated-admin Security account, the frameworks, and the DevSecOps habits I put in place, and how they connect back to the multi-account landing zone itself.
This overlaps with how I structure a multi-account AWS Organization on purpose — security and compliance aren't bolted on after the account structure exists, they're part of how the landing zone gets built in the first place. This page is that same material, viewed from the compliance side.
01The account-level foundation
- Log Archive and Audit accounts, created as part of the initial Control Tower landing zone — not added later.
- A dedicated Security account, set as the delegated administrator for the org's security services, so every account's findings roll up to one place instead of being checked account by account.
02What runs in the Security account
GuardDuty
Org-wide threat detection, including patterns like DDoS activity.
Inspector
Continuous vulnerability scanning across Lambda, EC2, and containers, in every account, from one view.
AWS Config + conformance packs
Config enabled org-wide, with conformance packs deployed out to every account to catch compliance drift. The resource inventory it builds doubles as a cost-visibility signal — new or changed resources show up before they show up on a bill.
Security Hub
Frameworks turned on to match the actual business and regulatory need — NIST CSF, CIS Benchmarks, SOC 2 — so the compliance score reflects standards that matter, not a generic default.
Trusted Advisor + CloudWatch
Trusted Advisor for ongoing best-practice checks; CloudWatch centralizing logs and metrics from every account as the base layer for incident management and alerting.
03DevSecOps in delivery, not after it
- Security checks run inside the CI/CD pipeline itself, not as a separate gate bolted on after deployment.
- IAM policies scoped to least privilege as a default, not a cleanup pass.
- The same discipline that governs infrastructure changes (IaC + CI/CD) applies to security policy changes — reviewed, versioned, promoted through environments.
Security and compliance is the Security account acting as delegated admin over GuardDuty, Inspector, Config conformance packs, and Security Hub — with frameworks matched to the actual business, Trusted Advisor and CloudWatch underneath it, and DevSecOps practices built into delivery rather than checked after the fact. It's the same landing zone as the account-structure page, just read through a compliance lens.
Security and compliance isn't really a separate thing from how I structure accounts — it's built into the same landing zone from day one. If you've read how I approach the multi-account structure itself, this is the same story, just told from the security side.
Control Tower requires a Log Archive account and an Audit account, so those get stood up as part of the initial build. Then I create a dedicated Security account, and I use it as the delegated administrator for every security service across the org — so instead of checking each account one at a time, everything rolls up to one place.
What actually runs there
GuardDuty is what catches threat activity — including patterns like DDoS — across the whole organization. Inspector scans everything: Lambda functions, EC2 instances, containers, in every account, consolidated into one view instead of account-by-account checking.
AWS Config runs org-wide, with conformance packs deployed out to every account to catch compliance drift — a rule silently disabled, a resource that fell out of policy. The inventory Config builds turns out to be useful for more than compliance too; it's one of the better signals I've had for catching cost anomalies early, since you already know what exists and when it changed.
Trusted Advisor stays on for ongoing best-practice checks, and CloudWatch centralizes logs and metrics from every account, which is what makes real incident management and alerting possible in the first place.
Where DevSecOps fits
None of this works if security is a step that happens after deployment. Security checks need to run inside the CI/CD pipeline itself, IAM policy needs to default to least privilege instead of getting tightened later, and security-policy changes go through the same review-and-promote discipline as any other infrastructure change.
Read on its own, this can look like a duplicate of the account-structure story — and it is, deliberately. Security and compliance was never a bolt-on step for me; it's the same landing zone, just described from the angle of what protects it.