AWS Structure and Core Vocabulary

Account, service, and resource

Three nouns do most of the work in AWS, and they sit at different layers. Mixing them up is the fastest way to misread a scenario, so pin them down before anything else.

An AWS account is the basic container for AWS resources created by a customer. It represents a formal business relationship established with AWS: resources are created and managed inside it, and it is what a bill and a set of permissions attach to.

Amazon S3 buckets, Amazon RDS databases, and Amazon EC2 instances are examples of AWS resources. Each of them is something a customer created; the service is the offer, the resource is the object.

The distinction matters because scenarios describe resources, not catalogues. "The bucket holding the audit logs" is one object, in one account, with its own permissions. "Amazon S3" is the service that made such objects possible, and the AWS Management Console is neither — it is a way of reaching them.

Naming exactly one resource

Identity comes in two layers, and both are unique.

Each AWS account has a unique ID that differentiates it from other accounts. Every AWS resource is uniquely identified by an Amazon Resource Name that includes the owning account ID.

An Amazon Resource Name (ARN) therefore does two jobs at once: it points at a single object, and it carries the identity of the account that contains — that is, owns — that object. Read one as a fingerprint for one thing, never as the label of a service or of a group of resources.

The account as a security boundary

An account is not merely a billing registration. An AWS account is a resource container and a security boundary, and the second job is the one that shapes architecture.

An account provides identity management capabilities for access and billing. Among the resources created in an account are identities such as users and roles. Identities carry credentials, which are used to sign in — authentication — and permission policies, which state what the holder may do with the resources of that account — authorization.

The account is also the unit of isolation. All resources provisioned in an account are logically isolated from resources in other accounts, even inside the same company, and an account provides security, access, and billing boundaries for what it contains.

That isolation is what limits damage. If an application problem, a misconfiguration, or a malicious action occurs inside one account, the effect on workloads in other accounts is reduced or eliminated.

Nothing is shared between accounts by default

Access between two accounts must be explicitly allowed because no cross-account access is allowed by default. Sharing resources and data across the boundary is a deliberate act, never a side effect of common ownership, a shared Region, or similar naming.

The documented example is the one most teams meet first. If production resources and non-production resources are placed in different accounts, no access is allowed between those environments until someone allows it. That is a feature: the separation is what makes the split worth doing.

Why teams run more than one account

Using multiple AWS accounts can provide billing boundaries and resource isolation. Running several accounts is a recognized best practice for scaling an environment: it gives a natural billing boundary for costs, isolates resources for security, and leaves individuals and teams room to work without colliding.

Costs are allocated by account by default, so separate accounts for different business units or groups of workloads make expenditure easier to track, control, forecast, budget, and report.

Accounts can also mirror the shape of the business. Grouping workloads with a common business purpose into distinct accounts aligns ownership and decision making, and avoids dependencies with how workloads elsewhere are secured and managed.

Note what this does not require: the environments may sit in the very same Region. Isolation here comes from the account, not from geography.

Regions: separate geographic areas

Placement introduces a second hierarchy, and it is independent of the first. An AWS Region is a separate geographic area that contains multiple isolated Availability Zones.

Each Region is designed to be isolated from the other Regions, which is what achieves the greatest possible fault tolerance and stability. A Region is chosen deliberately: to put resources close to particular customers, or to meet legal and other requirements that apply to the workload.

Isolation has a consequence that surprises people. Resources tied to one Region are not automatically replicated to another Region. When resources are listed, only those tied to the selected Region appear — there is no hidden second copy elsewhere.

So a workload can run in several Regions, but each deployment is its own set of resources, created on purpose. Two Regions holding identically named resources hold two independent things, not one thing seen twice.

Availability Zones inside a Region

Within a Region, the ground is divided again. Each Region has multiple isolated locations known as Availability Zones, and an Availability Zone consists of one or more discrete data centers with redundant power, networking, and connectivity.

Their names follow a rule worth memorizing, because it appears constantly in scenarios: an Availability Zone code combines its Region code with a letter identifier, such as us-east-1a. Read us-east-1a as "the a zone of the us-east-1 Region" — a location inside a Region, not an account and not a resource name.

AWS operates highly available data centers, but failures that affect one location, though rare, do occur. If every instance sits in the location that fails, none of them is available.

Multiple Availability Zones can protect an application from the failure of one location within a Region. Distribute the components across zones, and the design can be built so that a component in another Availability Zone serves requests when one fails — all without leaving the Region, which keeps the deployment inside a single geographic area.

Reading a deployment in the right order

Put the two hierarchies together and any deployment statement becomes easy to parse. Each AWS resource is owned by an AWS account. A Regional resource can be placed in a selected Region and Availability Zone.

Trace it in this order: account, then resource identity, then Region, then Availability Zone.

Ownership and placement are independent. One account can hold resources in many Regions, and many accounts can hold resources in the same zone.

Key takeaways

• An AWS account is both a resource container and a security boundary, and it supplies identity management for access and billing.
• An ARN uniquely identifies a resource and includes its owning account ID, so identity always carries ownership with it.
• No access is allowed between accounts by default, which is why multiple accounts give real billing boundaries and resource isolation.
• A Region contains multiple isolated Availability Zones, and a zone code is the Region code plus a letter, such as us-east-1a.
• Resources are not automatically replicated between Regions, while spreading components across Availability Zones protects an application from the failure of one location.