Before you can assess an AWS security issue, you need to know where the resource lives, which account owns it, what scope it has, and how AWS identifies it.

If someone gives you an AWS resource and says, "Check whether this is secure," the first mistake is to start testing the resource immediately.

Before asking whether an EC2 instance is exposed, whether an S3 bucket is public, or whether an IAM role is overly privileged, you need to answer a simpler question:

Where does this resource actually exist?

In AWS, that question has several parts.

Which AWS account owns it? Which Region is it in? Does it belong to a specific Availability Zone? Is the resource Regional or global? What service owns it? How is the resource uniquely identified?

These details are not just infrastructure concepts. They directly affect security testing, authorization, visibility, logging, attack-surface discovery, and the interpretation of AWS findings.

— -

The Basic AWS Hierarchy

A useful simplified model is:

AWS |

• — Account |
• — Region |
• — Availability Zone |
• — Resources

The first diagram is only a beginner-friendly visualization, not a literal containment hierarchy.

Not every AWS resource belongs to an Availability Zone, and not every resource is Regional. Some AWS services provide global resources.

A more useful security model is:

AWS partition |

• — AWS account |
• — Global resources |
• — Regional resources |
• — Availability Zone resources |
• — Other Regional resources

Understanding this distinction prevents many mistakes during cloud reconnaissance.

— -

What Is an AWS Account?

An AWS account is a fundamental administrative, resource, and security boundary. An account contains AWS resources and identities and has its own account identifier.

Example:

123456789012

The value above is illustrative. An AWS account ID is an identifier, not a credential.

That distinction matters during reconnaissance.

Discovering an account ID does not automatically give an attacker access to the account. The interesting security questions come afterward:

• Who owns the account?
• What resources belong to it?
• Which identities exist?
• Which resources are publicly reachable?
• Which resources trust other accounts?
• Which principals can access resources in the account?
• Can identities move between accounts?

These questions become increasingly important as the series progresses toward IAM and cross-account access.

An account is an important security boundary, but access can be intentionally delegated across account boundaries.

— -

The Root User Is Associated With the Account

When an AWS account is created, it begins with an AWS account root user. AWS documents the root user as having complete access to all AWS services and resources in the account and recommends not using it for everyday tasks.

This is important for understanding the account boundary.

Think of the account as a security domain:

AWS Account |

• — Root user
• — IAM identities
• — IAM roles
• — AWS resources

Later, when we study IAM, we will break down how identities interact with those resources.

For this article, the important idea is:

An AWS account is not simply a billing container. It is also an important administrative and security boundary, while authorized relationships can provide access across accounts.

— -

One Account Can Use Multiple Regions

An AWS account can use multiple AWS Regions. A Region represents a separate geographic area in AWS infrastructure.

Examples include:

us-east-1 us-west-2 eu-west-1 ap-south-1

The exact list of available Regions changes over time, and not every Region is automatically enabled for every account. AWS distinguishes between Regions enabled by default and Regions that require opt-in.

This matters to security researchers because the following assumption is dangerous:

"I checked the account in one Region, so I checked the account."

That is not necessarily true.

For example:

AWS Account |

• — us-east-1 | + — EC2 | + — Lambda |
• — eu-west-1 | + — EC2 | + — Lambda |
• — ap-south-1
• — EC2
• — RDS

A resource discovery process that checks only one Region can miss resources in other Regions.

— -

Region Is Part of the Security Context

Region selection is not just about geography. It can affect:

• Resource visibility
• Service availability
• API endpoints
• Resource identifiers
• Logging behavior
• Data location
• Regulatory requirements
• Network latency
• Disaster recovery
• Cross-Region architecture

AWS states that most services support Regional resources, and a Regional resource is specific to the Region in which it was created.

If you switch the Region in the AWS console or CLI, you can see a different set of Regional resources.

This creates an important security-research rule:

Always establish the Region before interpreting a resource.

— -

Availability Zones Are Inside Regions

A Region contains multiple Availability Zones (AZs). AWS describes Availability Zones as isolated locations within a Region.

For example:

Region: us-east-2

Availability Zones: us-east-2a us-east-2b us-east-2c

The simplified relationship is:

Region |

• — AZ-A
• — AZ-B
• — AZ-C

Availability Zones are designed to provide fault isolation. They are connected within a Region using high-bandwidth, low-latency networking while being physically separated.

This is primarily an availability concept, but it also matters for security architecture.

For example, an application may distribute components across multiple AZs:

Internet | v Load Balancer |

• — — — — — — + | | v v AZ-A AZ-B | | v v Application Application | |
• — — — v — — -+ | Database

A failure affecting one AZ does not necessarily have to take down the entire architecture.

— -

Availability Zone Codes Versus AZ IDs

There is a subtle AWS detail that security researchers should know.

An Availability Zone has a human-readable code such as:

us-east-1a

AWS also provides an AZ ID such as:

use1-az1

AZ IDs identify the physical Availability Zone consistently across AWS accounts.

Historically, AWS independently mapped Availability Zone names in several Regions for different accounts. This means that, for affected Regions and older accounts, us-east-1a in one account could refer to a different physical location than us-east-1a in another account.

AWS has since changed this behavior for newer accounts. Accounts created starting November 2025 receive consistent Availability Zone name mappings, while older accounts in the affected Regions can retain the historical independent mapping.

Because of this, researchers should not rely on an AZ name alone when comparing infrastructure across accounts.

Use the AZ ID when the physical Availability Zone needs to be compared across accounts.

For example:

use1-az1

represents the same physical Availability Zone across AWS accounts.

This becomes particularly useful when analyzing shared infrastructure or resources involving multiple AWS accounts.

— -

Not Every Resource Belongs to an Availability Zone

This is a common beginner mistake.

An EC2 instance can be associated with an Availability Zone. A VPC is Regional.

The distinction is:

Regional resource |

• — Exists within a Region

Zonal resource |

• — Exists within a specific Availability Zone

For example:

VPC |

• — Region: us-east-1 |
• — Subnet A -> us-east-1a
• — Subnet B -> us-east-1b
• — Subnet C -> us-east-1c

The VPC is Regional. The subnets are associated with specific Availability Zones.

This becomes useful later when we study VPCs, security groups, subnets, routing, and network exposure.

— -

Regional Resources Versus Global Resources

This is one of the most important concepts in this article.

Some AWS resources are Regional. Others are global.

A Regional resource belongs to a specific AWS Region.

A global resource is not tied to a specific AWS Region in the same way Regional resources are. Its service operations can generally be accessed without selecting a resource Region.

AWS documents that Regional resources include the Region in their ARN.

For example:

arn:aws:ec2:us-east-1:123456789012:instance/i-0example

The important portion is:

us-east-1

That tells you the Region associated with the resource.

A global resource can have no Region value in its ARN. The exact ARN format depends on the service.

— -

Why Global Versus Regional Matters for Security

Imagine you are performing AWS reconnaissance.

If you discover a Regional resource such as an EC2 instance in us-east-1, you need to consider the Region as part of the investigation.

If you discover a global resource, changing the AWS CLI Region does not create another independent copy of that same global resource.

This changes how you enumerate resources.

A simplistic approach might be:

for every Region: enumerate everything

That can work for Regional services, but it does not mean every AWS service should be treated as if it were Regional.

A better approach is:

1. Identify the AWS service.
2. Determine whether the relevant resource is Regional or global.
3. Identify the appropriate endpoint or Region.
4. Enumerate resources within the correct scope.

This becomes especially important when building automated cloud-recon tooling.

— -

Amazon Resource Names (ARNs)

AWS provides Amazon Resource Names, commonly called ARNs, to identify resources.

Depending on the service, an ARN can contain information such as:

• Partition
• Service
• Region
• Account ID
• Resource identifier

A simplified ARN structure is:

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

The exact format varies by service.

For example:

arn:aws:ec2:us-east-1:123456789012:instance/i-0example

Breaking it down:

arn |

• — aws |
• — ec2 |
• — us-east-1 |
• — 123456789012 |
• — instance/i-0example

This tells you:

Partition = aws Service = ec2 Region = us-east-1 Account = 123456789012 Resource = instance/i-0example

ARNS become extremely important later when we work with IAM policies.

— -

An ARN Is Not a Credential

This distinction is worth making early.

An ARN identifies a resource. It does not authenticate you.

For example:

arn:aws:ec2:us-east-1:123456789012:instance/i-0example

does not provide permission to access that instance.

Similarly, knowing an account ID, Region, EC2 instance ID, bucket name, or ARN does not automatically grant access.

The security question is always:

What authorization mechanism controls access to this resource?

— -

AWS Partitions

AWS Regions are grouped into partitions.

AWS documents these major partitions:

aws aws-cn aws-us-gov

The standard commercial AWS Regions use:

aws

China Regions use:

aws-cn

AWS GovCloud (US) Regions use:

aws-us-gov

Partitions provide a stronger boundary than simply switching Regions. AWS documents that partitions have independent IAM instances and form a boundary between Regions in different partitions.

This matters when interpreting ARNs.

For example:

arn:aws:…

is different in scope from:

arn:aws-cn:…

and:

arn:aws-us-gov:…

Do not assume that an AWS account in one partition can be treated exactly like an account in another partition.

— -

Region Selection and Security Research

Suppose you are investigating a company and discover:

api.example.com

You identify that the backend uses AWS.

That still tells you very little.

You may eventually discover:

API Gateway | v Lambda | v DynamoDB

But where is the workload?

Perhaps ap-south-1. Perhaps us-east-1. Perhaps another Region. And there may be resources in multiple Regions.

A useful cloud-recon workflow therefore becomes:

Application | v AWS fingerprint | v AWS service identification | v Account / resource clues | v Region identification | v Regional resource enumeration | v Global resource enumeration | v Security analysis

This is much more reliable than assuming that one discovered AWS hostname represents the entire environment.

— -

Region Mistakes Can Create False Conclusions

Consider this situation.

A researcher looks for an EC2 instance in us-east-1 and finds nothing.

They conclude:

"There is no EC2 instance."

That conclusion is too strong.

The correct statement is:

"No matching EC2 instance was found in the scope that was checked."

The environment could contain:

us-east-1 -> no matching instance

eu-west-1 -> instance found

ap-south-1 -> another instance

Cloud reconnaissance must therefore keep track of scope.

There is another important distinction:

Region enabled + No matching resource

No matching resource found in the checked scope

Region not enabled + No resource visibility

Scope not fully evaluated

A reconnaissance tool should distinguish between "no resource found" and "the Region could not be evaluated."

— -

AWS CLI and Region Context

When using the AWS CLI, Region context matters for Regional services.

For example:

aws ec2 describe-instances — region us-east-1

This asks the EC2 API for resources in us-east-1.

Changing the Region changes the scope of the query.

For example:

aws ec2 describe-instances — region ap-south-1

is asking a different Regional endpoint for EC2 resources.

A small example illustrates why the result must be interpreted carefully:

$ aws ec2 describe-instances — region us-east-1

Possible result:

{ "Reservations": [] }

Interpretation:

No EC2 instances were returned in the queried scope.

This does not prove that the account contains no EC2 instances anywhere. Another Region may contain resources, or the current identity may not have visibility into the relevant resources.

This is one reason automated AWS reconnaissance tools should explicitly track Region rather than silently relying on a default.

Example workflow:

for region in discovered_regions: enumerate regional resources

The exact implementation depends on the tooling and authorization available.

These commands are examples only; no AWS account testing is claimed for this article.

— -

Example: Investigating a Discovered EC2 Instance

Suppose you discover an EC2 instance ID in an application artifact.

Do not immediately treat the discovery as a vulnerability.

Work through the scope first.

Step 1 — Identify the account

Determine which AWS account the resource belongs to, if that information is available.

Step 2 — Identify the Region

Determine which Region the instance belongs to.

Step 3 — Confirm the resource

Check whether the instance exists in the authorized scope being investigated.

Step 4 — Identify the Availability Zone

Determine the AZ associated with the instance, where applicable.

Step 5 — Resolve the ARN

Record the resource's ARN and associated identifiers.

Step 6 — Determine exposure

Determine whether the instance is publicly reachable or only accessible through private network paths.

Step 7 — Continue into identity and authorization

Only after establishing the resource scope should you investigate:

• Who can access it?
• What identity does the application use?
• What permissions apply?
• What network controls exist?
• What data or capabilities are exposed?

The important distinction is:

Discovery evidence: Instance ID + Region

does not automatically equal:

Security finding: Unauthorized access

This is the practical meaning of:

Discovery is not exploitation.

— -

What Should a Security Researcher Record?

When discovering an AWS resource, don't save only the hostname.

A useful inventory record can include:

• Account ID
• Partition
• Region
• Availability Zone
• Service
• Resource type
• Resource ID
• ARN
• Public/private exposure
• Authentication context
• Associated identity
• Relevant permissions
• Trust relationships
• Network location
• Data sensitivity
• Evidence source
• Discovery timestamp
• Scope/authorization used for the observation

Example:

Account: 123456789012

Partition: aws

Region: ap-south-1

Service: EC2

Resource: Instance

Resource ID: i-0example

AZ: ap-south-1a

ARN: arn:aws:ec2:ap-south-1:123456789012:instance/i-0example

Authentication context: Authorized IAM role

This structure becomes much more useful later when we start connecting cloud reconnaissance with IAM and attack paths.

— -

Resource Discovery Is Not Vulnerability Discovery

Suppose you discover:

arn:aws:ec2:us-east-1:123456789012:instance/i-0example

You have learned that a resource exists.

You have not yet demonstrated:

• Unauthenticated access
• Authorization failure
• Sensitive data exposure
• Privilege escalation
• Remote code execution
• Or another security impact

Likewise:

Finding an AWS account ID does not mean the account is compromised.

Finding an AWS Region does not mean the Region is vulnerable.

Finding an ARN does not mean the resource is accessible.

Finding a public hostname does not mean the application is vulnerable.

This is the same precision principle introduced in Article 1:

Discovery is not exploitation.

— -

The Security Boundaries and Scopes to Remember

At this point, you should have several different scopes in mind.

Partition scope

aws |

• — commercial AWS Regions

aws-cn |

• — China Regions

aws-us-gov |

• — GovCloud Regions

Account boundary

AWS Organization |

• — Account A
• — Account B
• — Account C

Authorized relationships can allow identities or resources to interact across account boundaries.

Region scope

Account |

• — us-east-1
• — eu-west-1
• — ap-south-1

Availability Zone / failure-isolation scope

Region |

• — AZ-A
• — AZ-B
• — AZ-C

Resource scope

Region |

• — VPC
• — EC2
• — Lambda
• — RDS
• — Other resources

These scopes are not interchangeable.

A security researcher should always know which scope they are currently analyzing.

— -

How This Connects to the Next Articles

Article 1 gave us the general AWS security model.

This article gives us the physical and logical scope in which AWS resources exist.

The next article introduces one of the most important ideas in cloud security: the AWS Shared Responsibility Model.

The progression is:

Article 1 AWS Security Fundamentals | v Article 2 Accounts, Regions, Availability Zones & Resources | v Article 3 Shared Responsibility Model | v Article 4 AWS Attack Surface | v Article 5 AWS CLI Security Researcher Workflow | v IAM

This order matters.

Before asking:

"Can I access this resource?"

you need to know:

"What resource is it, which account owns it, which Region contains it, and what security scope am I actually testing?"

— -

Lab Validation Candidate

This article can be understood without an AWS account.

The following behaviors would be useful to validate later in an authorized AWS lab:

• Enumerating Regions available to an account
• Comparing Regional resource visibility
• Identifying Availability Zones and AZ IDs
• Comparing Regional and global resource identifiers
• Inspecting ARNs
• Using AWS CLI Region selection
• Observing how resource discovery changes between Regions

No such lab testing is claimed in this article.

— -

What This Article Intentionally Does Not Cover

This article does not go deeply into:

• Shared Responsibility Model
• IAM policy evaluation
• IAM roles and trust policies
• S3 public access
• EC2 security groups
• VPC routing
• Cross-account IAM
• CloudTrail
• Attack-chain construction

Those topics appear later in the series.

— -

Final Takeaway

AWS security research starts with understanding scope.

An AWS environment is not one flat collection of resources.

You need to think in layers:

Partition ↓ Account ↓ Region ↓ Availability Zone where applicable ↓ Resource ↓ Identity and authorization ↓ Network and data exposure

When you discover an AWS resource, record where it belongs.

Ask:

Which account? Which partition? Which Region? Which Availability Zone, if applicable? Is the resource Regional or global? What is its ARN? Who can access it?

Only after answering those questions should you start deciding whether the resource represents a security weakness.

That discipline becomes increasingly important as we move from AWS fundamentals into IAM, cloud reconnaissance, and eventually multi-step AWS attack paths.

The goal is not to collect as many AWS resources as possible.

The goal is to understand what each resource represents, which security scope controls it, and how it fits into the larger architecture.

— -

PRIMARY AWS SOURCES USED FOR RESEARCH

AWS Regions and Availability Zones: https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions-availability-zones.html

AWS Regions: https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html

AWS Availability Zones: https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-availability-zones.html

AWS AZ IDs: https://docs.aws.amazon.com/global-infrastructure/latest/regions/az-ids.html

AWS Regional vs global resources: https://docs.aws.amazon.com/ram/latest/userguide/working-with-regional-vs-global.html

AWS Regions and partitions: https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html

AWS root user: https://docs.aws.amazon.com/accounts/latest/reference/root-user.html