Identity, accounts, and governance

Good enterprise architecture starts with boundaries, not servers.

Identity in simple terms

An identity says who is asking. A policy says what they may do. A role is a temporary set of permissions. Prefer temporary credentials and federation through IAM Identity Center. Avoid long-lived access keys.

The permission decision

AWS starts with implicit deny. An applicable allow is required. An explicit deny wins. Identity policies, resource policies, permission boundaries, session policies, and Organizations controls can all limit the final permission.

Multi-account landing zone

Use AWS Organizations to group accounts into organizational units (OUs). Use AWS Control Tower to establish and govern a landing zone. A practical layout:

management account: organization administration only;
security OU: audit and centralized log archive accounts;
infrastructure OU: network and shared services;
workloads OU: separate production and non-production accounts;
sandbox OU: experimentation with spending and access limits.

Service control policies (SCPs) set the maximum available permissions. They do not grant permission. Controls can prevent, detect, or proactively reject unwanted configurations.

Security foundations

Require MFA for people and protect the root user.
Centralize workforce access with short-lived roles.
Separate workloads and environments by account.
Log organization activity centrally.
Encrypt with KMS keys and control who can use each key.
Store secrets in Secrets Manager or Parameter Store, never source code.
Automate accounts and guardrails; do not handcraft each environment.

Architect trade-off

Too few accounts create a large blast radius and tangled billing. Too many accounts without automation create operational friction. Choose boundaries around ownership, environment, sensitivity, and failure containment.

Official source: AWS Control Tower.