AWS Resource Hierarchy Explained: Organizations, Accounts, Regions, AZs, and ARNs

Simple explanation

From largest to smallest, here is the full hierarchy:

1. Organization: an optional wrapper that groups multiple AWS accounts under one roof
2. Organizational Units (OUs): folders inside an Organization that group accounts by purpose (like “Production” or “Security”)
3. AWS Accounts: the main boundary, where each account has its own users, roles, billing, and resources
4. Regions: geographic locations where you deploy resources (like us-east-1 or eu-west-2)
5. Availability Zones: isolated data centers within a region (like us-east-1a)
6. Individual resources: the actual things you create, such as EC2 instances, S3 buckets, and Lambda functions
7. ARNs: the unique address for every resource, encoding where it sits in this hierarchy

Each layer inherits rules from the layers above it. An account inside an OU inherits the policies applied to that OU. A resource inside a region inherits the account’s billing and IAM boundaries. This nesting is what makes the hierarchy powerful, and what makes it confusing when you skip a layer.

How AWS resource hierarchy works

AWS Organizations

AWS Organizations is an optional service that lets you manage multiple accounts as a group. You create a management account (the root of the Organization), then create or invite member accounts into it.

Organizations is not required. Many individuals and small teams use a single AWS account with no Organization at all. But as soon as you need consolidated billing, centralized access policies, or account-level isolation between workloads, Organizations becomes essential.

From the management account, you can apply Service Control Policies (SCPs) that restrict what member accounts are allowed to do. SCPs set a ceiling on permissions. They do not grant access; they only limit it.

Organizational Units (OUs)

OUs are folders inside an Organization. They let you group accounts by purpose so you can apply policies to many accounts at once instead of one at a time.

A common setup is to have OUs like “Production,” “Development,” “Security,” and “Sandbox.” You apply strict SCPs to the Production OU and more permissive ones to Sandbox. OUs can be nested, so an OU can contain other OUs.

OUs do not own resources. They have no IAM users or roles. They exist only inside AWS Organizations and serve purely as a grouping and policy-attachment mechanism.

AWS Accounts

The AWS account is the most important boundary in the hierarchy. Each account is a hard isolation boundary by default:

• IAM namespace: users, roles, and policies exist within one account and are not visible to other accounts
• Billing boundary: charges are attributed to the account where resources run (even under consolidated billing)
• Network boundary: the default VPC in each account is independent
• Resource boundary: resources in one account cannot be accessed from another account without explicit cross-account configuration

Common patterns include one account per environment (dev, staging, production), one per team, or one per workload. The accounts-as-boundaries model is the foundation of least-privilege architecture at scale.

Regions

Within an account, resources are deployed to specific regions. Each region is an independent cluster of data centers in a geographic area, such as us-east-1 (Northern Virginia), eu-west-1 (Ireland), or ap-southeast-1 (Singapore).

Regions are separate deployment scopes. A Lambda function in us-east-1 does not exist in eu-west-2. When you switch regions in the AWS Console or change the --region flag in the AWS CLI, you see a completely different set of resources.

A few services are global and not tied to a region. Most notably, IAM, Route 53, and CloudFront. The rest are regional or zonal.

Availability Zones

Within a region, AWS operates multiple Availability Zones (AZs). Each AZ is one or more physically separate data centers with independent power, networking, and cooling.

Some resources are tied to a specific AZ. When you launch an EC2 instance, it runs in one AZ. When you create an EBS volume, it exists in one AZ and can only be attached to instances in that same AZ. Subnets in a VPC each belong to exactly one AZ.

Deploying across multiple AZs is how you build high availability on AWS. If one AZ goes down, the resources in other AZs keep running.

Individual resources and ARNs

At the bottom of the hierarchy are the actual resources: an EC2 instance, an S3 bucket, a DynamoDB table, a Lambda function. Every resource belongs to a service, an account, and (for most services) a region.

Every AWS resource has a unique ARN (Amazon Resource Name) that encodes its position in the hierarchy:

arn:partition:service:region:account-id:resource

Real examples:

# An S3 bucket (region is omitted because bucket names are globally unique)
arn:aws:s3:::my-company-assets

# An IAM role (IAM is global, so region is omitted)
arn:aws:iam::123456789012:role/MyAppRole

# An EC2 instance in us-east-1
arn:aws:ec2:us-east-1:123456789012:instance/i-0abc123def456

# A Lambda function in eu-west-1
arn:aws:lambda:eu-west-1:123456789012:function:my-function

# An RDS database instance in us-west-2
arn:aws:rds:us-west-2:123456789012:db:my-postgres-db

ARNs are used in IAM policy statements to specify exactly which resources a permission applies to. Using specific ARNs rather than wildcards is a core part of least-privilege access control.

# Get the ARN of your current IAM identity
aws sts get-caller-identity --query Arn --output text

# List all S3 buckets (ARNs can be inferred from the names)
aws s3api list-buckets --query 'Buckets[*].Name'

Quick reference table

Global vs regional vs zonal services

Not every AWS service works at the same scope. Knowing whether a service is global, regional, or zonal tells you where to find its resources and how to reference them in policies and CLI commands.

How this affects permissions, billing, and architecture

Permissions

IAM permissions are evaluated within an account. When someone makes an API call, AWS checks in this order:

1. Do any SCPs from the Organization deny this action? If so, it is denied regardless of IAM policies.
2. Does the principal have an IAM policy (identity-based or resource-based) that allows this action on this resource?
3. Are there permission boundaries, session policies, or VPC endpoint policies that further restrict access?

An IAM policy that looks correct can still be blocked by an SCP at the Organization level. If you are debugging an AccessDenied error, always check SCPs first when the account is inside an Organization.

Billing

AWS billing follows the account boundary. Each account accumulates its own charges. Under AWS Organizations with consolidated billing, all member accounts roll up into a single invoice on the management account, but the per-account cost breakdown is preserved.

Resource tags let you add further granularity. You can tag resources by team, project, or cost center and use Cost Explorer to break down spending by tag, account, region, or service.

Isolation

Accounts are the strongest isolation boundary in AWS. Resources in one account cannot reach resources in another account by default. This separation applies to IAM, networking, and data. You must explicitly configure cross-account access (using IAM roles, resource policies, or services like AWS RAM) to allow it.

Regions add another layer of isolation. A VPC in us-east-1 is entirely separate from a VPC in eu-west-1, even in the same account. Cross-region communication requires explicit networking configuration.

Troubleshooting

Most “missing resource” confusion comes from being in the wrong region or the wrong account. Before you assume a resource was deleted:

• Check which account you are signed into (aws sts get-caller-identity)
• Check which region your console or CLI is pointing at
• Remember that global services (like IAM roles) appear in all regions, but regional resources do not

When to use this mental model

The resource hierarchy is not abstract theory. It is the mental model you need for everyday AWS work. Use it when you are:

• Designing a multi-account setup: deciding how many accounts to create and how to organize them with OUs. See AWS Organizations for patterns.
• Debugging why a role works in one account but not another: IAM roles are per-account. A role in account A does not exist in account B. Cross-account access requires explicit trust configuration.
• Choosing the right region: consider latency, compliance, and service availability.
• Figuring out why a resource is “missing”: check your account and region first. This solves most cases.
• Understanding a cost spike: billing is per-account. Use tags and Cost Explorer to trace unexpected charges to the right account, region, and service.
• Writing IAM policies: ARNs encode the hierarchy. A well-scoped policy uses specific ARNs, not wildcards. See principle of least privilege.

AWS Organizations vs OUs vs accounts vs regions vs AZs

These five layers serve different purposes. Here is how they compare side by side:

Example scenario

A startup called Acme uses AWS Organizations to manage three accounts:

• Dev account (111111111111), in the “Development” OU
• Staging account (222222222222), in the “Development” OU
• Production account (333333333333), in the “Production” OU

The Production OU has a strict SCP that denies all actions outside us-east-1 and eu-west-1. This prevents anyone from accidentally deploying production workloads to the wrong region, even if their IAM policy allows it.

In the production account, the main web application runs in us-east-1. EC2 instances are spread across us-east-1a and us-east-1b for high availability. An Application Load Balancer distributes traffic between them.

The application stores data in an S3 bucket named acme-prod-assets (globally unique, created in us-east-1) and reads from a DynamoDB table in the same region.

Here is where each part of the hierarchy fits:

• IAM: the WebAppRole role exists in the production account (global within that account). Its policy grants read access to the S3 bucket and DynamoDB table using specific ARNs.
• SCPs: the Production OU’s SCP limits all member accounts to two regions. Even an admin in the production account cannot launch resources in ap-southeast-1.
• Billing: the production account’s charges (EC2, S3, DynamoDB) appear on the consolidated bill under the management account, tagged by resource tags like team:backend and env:production.
• ARNs: the EC2 instance is arn:aws:ec2:us-east-1:333333333333:instance/i-0abc123def456. The S3 bucket is arn:aws:s3:::acme-prod-assets. The IAM role is arn:aws:iam::333333333333:role/WebAppRole.

A developer in the Dev account cannot access the production S3 bucket unless a cross-account bucket policy or IAM role trust is configured. This is the account boundary at work.