Lesson 1: How AWS Is Organised and How to Use This Course

Why start with the org chart, not the service list

Say you are choosing between three clouds and someone asks: "Where does this workload live, who pays for it, and who can switch it off?" On AWS the answer is almost always an account. Every resource, bill line, quota and permission boundary attaches to an account, and accounts are grouped above that. Get this model clear and the next twelve category lessons are much easier to read, because every service sits inside it.

This level covers four things: the account hierarchy, where things physically run, how you get charged and supported, and how to read the dated tables that make up the rest of the course.

The account hierarchy: Organizations, OUs, accounts

AWS Organizations groups many accounts under one management account, which pays the consolidated bill. You arrange member accounts into organizational units (OUs) and attach policies such as service control policies (SCPs) to the root, an OU or an account. Policies are inherited down the tree.

Root  (management account: billing, org-wide policy)
├── OU: Security
│   ├── account: log-archive        # central logs, locked down
│   └── account: security-tooling
├── OU: Workloads
│   ├── OU: Prod                    # SCP: deny leaving approved Regions
│   │   └── account: payments-prod
│   └── OU: Non-prod
│       └── account: payments-dev
└── OU: Sandbox                     # SCP: cap expensive services

The limits to know: OUs nest at most five levels below the root, and the default quota is 10 accounts per organisation, which you can raise through Service Quotas.

Practitioner note: In AWS, the account is the hard isolation unit, so mature teams run dozens or hundreds of them, often one per workload per environment. A single shared account for everything is the most common early mistake and the hardest one to undo.

The same idea on the other two clouds

The match is close but not exact. An Azure subscription is a billing and management boundary, but the identity boundary is the Entra tenant above it. In AWS each account has its own IAM. Google Cloud projects are lighter and cheaper to create than either, so teams make many more of them.

Regions, Availability Zones and edge locations

• Region: a separate geographic area such as eu-west-2 (London). Most services are regional, and your data stays in the Region you pick unless you move it. As of October 2026 AWS lists about 39 Regions, with more announced.
• Availability Zone (AZ): one or more data centres with their own power and networking. Each Region has at least three. To survive a data-centre failure, you spread a workload across AZs.
• Edge locations: points of presence used by CloudFront, Route 53 and similar services to serve users nearby. You do not run general workloads there.

Region eu-west-2
├── AZ eu-west-2a  ─┐
├── AZ eu-west-2b  ─┼─ spread instances here for high availability
└── AZ eu-west-2c  ─┘
Gotcha: "eu-west-2a" in your account may be a different physical AZ
from "eu-west-2a" in mine. Use AZ IDs (e.g. euw2-az1) to line up across accounts.

Not every service or instance type is offered in every Region. Before you pick a Region, check whether the services you need are available there and whether the location meets your data-residency rules.

How AWS charges you

There are three main ways to pay:

1. On-demand: pay per second or hour with no commitment.
2. Commitments: Savings Plans (up to 72% off on-demand) or Reserved Instances, for one or three years. Spot capacity can be up to 90% cheaper, but AWS can take it back.
3. Data transfer: data coming in is generally free. Data going out to the internet is charged after 100 GB a month free, and that allowance is shared across all Regions. Traffic between AZs and between Regions is also billed.

Here is a worked example:

Workload: 2 VMs on-demand + 2 TB/month served to the internet
  compute       -> priced per hour, no commitment
  egress        -> (2,048 GB - 100 GB free) x per-GB rate
  cross-AZ sync -> charged both ways, often forgotten
Lesson: in multi-cloud designs, egress is often the line that
makes or breaks a plan. Model it before choosing.

Support plans (changing now)

AWS announced new plans on 2 December 2025. Basic support is free for everyone. The paid tiers are now:

Developer, Business (classic) and Enterprise On-Ramp keep their current coverage until 1 January 2027, after which customers must have moved to a new plan. Check what plan your accounts are on.

How to read this course's tables

Every category lesson has two tables: a list of AWS services, and a three-column equivalence table with one row per job. Each table is dated, and each row is one of three kinds:

[Tables checked: 2026-10]
Job              | AWS        | Azure              | Google Cloud
Workload unit    | Account    | Subscription       | Project        <- direct
Guardrails       | SCPs       | Azure Policy       | Org Policy     <- judgement*
X                | Service A  | no direct equivalent | Service C    <- gap
* SCPs cap what identities may do; Azure Policy mainly
  governs resource properties. Same job, different behaviour.

• Direct: the services do the same job in broadly the same way.
• Judgement (marked *): the services overlap, but a note explains where they differ in limits, pricing or behaviour. Read the note before you rely on the mapping.
• No direct equivalent: you would have to build it, combine several services or accept the gap.

Best practice: Treat the date as an expiry date. Services get renamed and retired often, so check every row you intend to act on against current provider documentation.

Key takeaways

• On AWS, the account is the unit of isolation and billing. Organizations, OUs and SCPs sit above accounts, and the closest peers are Azure management groups and subscriptions, and Google Cloud folders and projects.
• Regions decide where data sits. Spreading a workload across AZs protects it against a data-centre failure. Edge locations serve users and do not host general workloads.
• You pay for compute on demand or through commitments, and for data going out. Data transfer is easy to underestimate.
• The support tiers are now Business Support+, Enterprise Support and Unified Operations. The older plans end on 1 January 2027.
• Each table row is direct, judgement or no direct equivalent. Check the date and the provider's documentation before you act on a row.
• For more depth: Cloud Pro: AWS Fundamentals and Governance.