The Shape of AWS: Regions, Accounts, and Who Secures What

Open the AWS console and you meet a directory of hundreds of services with names that mostly do not describe what they do. The instinct is to start learning them one at a time, and it is the slowest possible route.

The faster route is to notice that almost every service is a variation on a handful of primitives: run some code, store some bytes, move packets between things, hold structured data, and control who may do any of it. Once you can place a new service into one of those categories, the specific service becomes a detail you can look up.

What genuinely needs learning first is the scaffolding that every service sits inside, because it is shared, it constrains your design, and getting it wrong is expensive to undo later:

• Where things physically run, which determines latency, resilience and legal exposure.
• The account boundary, which determines what a mistake can reach.
• IAM, which every single API call passes through.
• The responsibility line, which determines what is your job to secure.

Key idea: cloud competence is not knowing what 200 services do. It is knowing the shape of the platform well enough that an unfamiliar service is immediately placeable, and knowing which decisions are hard to reverse.

The physical layer has two levels, and the distinction between them is the single most load-bearing fact in cloud architecture.

A region is a geographic area, such as Ireland or Northern Virginia. Regions are deliberately isolated from each other: they have separate infrastructure, and a failure in one is designed not to propagate to another. Most services are regional, meaning a resource you create exists in one region and is not visible from another unless you arrange it.

An availability zone, or AZ, is one or more discrete data centres within a region, with independent power, cooling and physical security. AZs in a region are close enough for low-latency links between them, and far enough apart that a fire, flood or power event should hit only one.

That two-level design exists to give you a cheap way to survive the most common failures:

• Deploy across multiple AZs and you survive a data centre failure, with millisecond-scale links between them and no meaningful latency cost.
• Deploy across multiple regions and you survive a whole-region event, at real cost: cross-region latency, data transfer charges, and the complexity of keeping state consistent across a distance.

Gotcha: most teams should be multi-AZ and are not, because single-AZ is the default in many setups and nothing looks wrong until an AZ fails. Multi-region is a much bigger commitment and far fewer applications actually need it.

Region choice looks like a dropdown and behaves like an architectural commitment. Four forces pull on it, and they frequently disagree.

The last one surprises people. AWS does not launch everything everywhere simultaneously, so a smaller region can simply not offer the service or hardware your design assumed, and you discover it after the design is settled.

An AWS account is not a login. It is a hard boundary: resources live inside one, and by default nothing in one account can touch anything in another.

That property makes the account the primary tool for containing mistakes. A runaway script, a compromised credential, a misconfigured deletion policy, all of these are bounded by the account they run in. Which is why the mature pattern is many accounts rather than one big one, usually organised as:

• Separate accounts per environment, so a production database cannot be reached from a development credential at all, rather than merely being protected by a policy someone might get wrong.
• Separate accounts per team or workload, so blast radius follows ownership and costs are attributable without tagging discipline nobody sustains.
• A management layer that groups accounts, applies guardrails centrally, and consolidates billing, which AWS provides through its Organizations service.

In practice: the single-account setup is the one that ages worst. It starts as convenience, becomes an IAM policy tangle where everyone has more access than intended because separating them properly is now hard, and every cost question becomes an archaeology exercise. Separating accounts on day one costs an afternoon; separating them in year three is a migration.

Identity and Access Management is not a service you use alongside others. It is the mechanism every AWS API call is evaluated against, including calls services make to each other.

The vocabulary is small and worth getting exactly right. A principal is whoever is making the call: a user, or more often a role. A policy is a JSON document listing which actions are allowed or denied on which resources, under which conditions. A role is a set of permissions that can be assumed temporarily, rather than credentials belonging permanently to a person or machine.

The evaluation rule is simple and strict: access is denied unless a policy explicitly allows it, and an explicit deny always wins over any allow.

Roles are the part worth internalising, because they remove the worst pattern in cloud security. Instead of storing an access key on a server, the server assumes a role and receives temporary credentials that rotate automatically. No long-lived secret exists to be leaked, committed to a repository, or found in a log.

AWS states the division as a shared responsibility model, and the shorthand is precise enough to reason with: AWS is responsible for security of the cloud, and the customer is responsible for security in the cloud.

AWS's side covers the infrastructure running all services: the physical security of buildings, regions, availability zones and data centres, plus the hardware, host operating systems, virtualisation layer and AWS networking components.

Your side covers what you put on it: your data, your applications, identity and access management configuration, and network and firewall configuration. AWS's own framing adds an important nuance, that the split moves with the service, so some services require you to perform all the security configuration, while more abstracted ones leave you only your data and access control.

Key idea: the line moves as you go up the abstraction ladder, and so does the amount of security work you own. That is often the strongest argument for a managed service, and it is why the compute choices in the next lesson are security decisions as much as operational ones.

With the scaffolding in place, the service catalogue becomes navigable, because almost everything is an answer to one of a few questions.

• Run my code: virtual machines, container orchestration, serverless functions, batch jobs.
• Store my bytes: object storage for files and blobs, block storage for disks attached to a machine, file storage for shared mounts.
• Hold structured data: relational databases, key-value and document stores, caches, analytics warehouses.
• Move and control traffic: virtual networks, load balancers, DNS, content delivery, private connectivity.
• Connect things asynchronously: queues, topics, event buses, streams.
• Watch and govern: logging, metrics, tracing, configuration and compliance tooling.

When a new name appears, the useful questions are: which of these does it replace or automate, what does it manage that I would otherwise operate myself, and what does using it prevent me from controlling.

In practice: that last question is the one people skip, and it is where regret lives. Every managed service trades control for operational relief. The trade is usually excellent and it is never free, so the honest evaluation is not "is this service good" but "is the control it removes control I actually needed?"