Multi-account AWS landing zone for growing SMBs
Separate prod/dev/billing with AWS Organizations without a million-dollar consultancy.
Puerto Rico SMBs starting with single AWS account — prod and dev mixed, root keys in shared .env, opaque billing — scale until incident or audit forces separation. Multi-account landing zone does not require day-one enterprise Control Tower; AWS Organizations with lite OU structure is achievable in weeks. The AWS Security Blog documents multi-account security patterns — adopt SMB version.
Minimum structure: Management account for billing and Organizations only; Production, Development, Security (logs + GuardDuty admin) OUs; separate accounts per critical environment. SSO (IAM Identity Center) with Developers, Admins, ReadOnly groups — MFA enforced. Never operate prod from root.
Service Control Policies: deny root actions, restrict regions if only using us-east-1, prevent disabling CloudTrail. Centralize logs in Security account with restrictive S3 bucket policy. Bruce Schneier recommends fail-safe defaults — SCPs are guardrails when someone attempts "temporary shortcut" lasting years.
Mainland companies with PR operations often inherit shared account with local vendor — landing zone clarifies ownership and access for PCI/HIPAA audits. Cross-account cost allocation tags in Cost Explorer simplify FinOps.
Do not over-engineer: three well-governed accounts beat ten chaotic ones. Quarterly SSO access review; vendor offboarding must revoke in minutes, not when "we agreed in the meeting." Multi-account is maturity investment, not vanity architecture.
Writes about practical cybersecurity for SMBs in Puerto Rico and the Caribbean — no fluff, just what actually needs to get done.
