AWS Identity, Accounts and Governance

Regions, AZs and edge locations

AWS infrastructure is organised in layers. A Region is a geographic area that contains several isolated Availability Zones (AZs); each AZ is one or more data centers with independent power and networking, connected to its siblings by low-latency links. Most services are regional, so a resource created in one Region is invisible in another unless you replicate it deliberately.

When choosing a Region, weigh four things: legal and data-residency requirements, latency to your users, which services are offered there, and cost. Spread critical workloads across at least two AZs so the loss of one facility does not take you down. Edge locations are separate points of presence used by content delivery and DNS services to serve users close to where they are; they are not places you deploy servers into.

The shared responsibility model

The provider is responsible for security of the cloud: physical sites, hardware, the virtualisation layer and the managed-service software. You are responsible for security in the cloud: identities, permissions, data classification, encryption choices, network rules and guest operating-system patching on services where you manage the OS. The more managed the service, the less you operate, but identity and data protection always remain yours.

IAM users, groups, roles and policies

Identity and Access Management is global and free to use. Its building blocks are:

• Users represent a person or application with long-lived credentials.
• Groups collect users so permissions are attached once. Groups hold only users, never other groups.
• Roles are identities with no permanent credentials. A trusted principal (a service, another account or a federated user) assumes the role and receives temporary credentials.
• Policies are JSON documents that grant or deny actions.

Prefer roles over users for anything that runs in AWS: attach a role to a compute instance or function and the SDK fetches rotating credentials automatically, so nothing needs to be stored on disk.

Anatomy of a policy

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ReadReportsBucket",
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::example-reports",
      "arn:aws:s3:::example-reports/*"
    ],
    "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
  }]
}

Each statement has an effect, actions, resources and optional conditions. Evaluation follows a few rules: everything is denied by default, an explicit Allow grants access, and an explicit Deny always wins. Identity-based policies attach to users, groups and roles; resource-based policies (such as bucket policies) attach to the resource and can grant access across accounts.

Permission boundaries set the maximum permissions an identity can ever receive, which is useful when delegating the ability to create roles without letting delegates escalate privilege. Start from least privilege, then widen only when a real need appears; the access analysis and credential report tools help find unused permissions and stale keys.

MFA and credential hygiene

Protect the account root user above everything: enable multi-factor authentication, remove any access keys it has, and use it only for the few tasks that truly require it. Enforce MFA for all human users with an authenticator app, a hardware token or a passkey. Password policies (length, rotation, reuse) add a second layer. For command-line access, prefer short-lived credentials from single sign-on or a browser-based shell over long-lived access keys, and rotate or delete any keys you must keep.

Organizations and service control policies

A single account is a poor boundary for growing teams. AWS Organizations lets you create and group accounts in a hierarchy of organizational units (OUs) under a management account, with consolidated billing so usage is aggregated across the whole tree. Separate accounts per environment or team limit blast radius and make cost attribution straightforward.

Service control policies (SCPs) attach to the root, OUs or accounts and define the maximum permissions available there. They never grant access by themselves; an action must be allowed by both the SCP and the identity's own policy. Typical uses are denying unused Regions, blocking the disabling of logging, and preventing member accounts from leaving the organization. SCPs do not restrict the management account, so keep workloads out of it.

Identity Center and directories

IAM Identity Center provides single sign-on across all accounts in an organization. You define permission sets (reusable bundles of policies), then assign users or groups to accounts with a chosen permission set. Users sign in once to a portal and receive temporary credentials for whichever account and role they pick. It can use its own built-in user store or connect to an external identity provider or a directory such as Active Directory through AWS Directory Service, so existing corporate groups map directly onto cloud access.

Control Tower and controls

Control Tower automates the setup of a well-architected multi-account environment, called a landing zone. It creates a security OU with log-archive and audit accounts, turns on organization-wide logging, and provides an account factory for vending new accounts with consistent baselines. Controls (originally called guardrails) are the governance rules it applies. Preventive controls are implemented with SCPs and block disallowed actions; detective controls use AWS Config rules to flag non-compliant resources. Some are mandatory, others strongly recommended or elective.

Budgets, monitoring and logging

Cost surprises are an operational risk, so configure AWS Budgets early. Set a monthly budget with threshold alerts on actual and forecasted spend, and notify an email list or a messaging topic. Cost allocation tags and cost-exploration tools then show which team or workload drives usage.

For visibility into behavior, three services cover most needs:

Enable an organization-wide trail that writes to a protected, central log bucket, and create alarms on sensitive events such as root sign-ins or policy changes. Combine this with tagging standards and periodic permission reviews and you have a baseline that scales from one account to hundreds.