AWS Cloud Fundamentals: Global Infrastructure, Account Model & Pricing

Every cloud journey starts with the same handful of ideas, and Amazon Web Services — the largest cloud provider on the planet — is no exception. Before you can launch a server, secure a workload, or design a resilient architecture, you need a clear mental model of what AWS actually is, where it physically runs, how your account is organised, who is responsible for what, and how you pay for it. Get these foundations right and everything else in the AWS catalogue — and there are now well over two hundred services — clicks into place. Get them wrong and you will spend months confused about why your application is slow in one part of the world, why you got an unexpected bill, or why a security incident was “your fault” when “it’s the cloud”.

This is the very first lesson of the AWS Zero-to-Hero course, so we assume zero prior knowledge of cloud computing and define every term the first time it appears. We still go deeper than a typical introduction: by the end you will be able to reason about Region selection like an architect, explain the difference between a Savings Plan and a Reserved Instance, and draw the shared-responsibility line on a whiteboard. Everything here maps directly to the AWS Certified Cloud Practitioner (CLF-C02) exam, where global infrastructure, billing and pricing, and the cloud value proposition together account for a large share of the marks.

Learning objectives

By the end of this lesson you can:

• Explain in plain English what cloud computing and AWS are, and distinguish IaaS, PaaS and SaaS with AWS examples of each.
• Describe the AWS global infrastructure — Regions, Availability Zones, Local Zones, Wavelength Zones and edge locations — and apply sensible Region-selection criteria.
• Lay out the account and organisation model: the root user, IAM, AWS accounts as a billing and security boundary, and AWS Organizations with organizational units (OUs).
• Draw the shared-responsibility model and correctly place security duties on either the AWS or the customer side of the line.
• Compare every core pricing model — On-Demand, Reserved Instances, Savings Plans, Spot, and the Free Tier — and name the levers that drive a bill.
• Use the billing and cost-management tools (Billing console, Cost Explorer, AWS Budgets, Cost and Usage Report) and choose an appropriate AWS Support plan.
• Recognise the core services across compute, storage, networking, database and identity so the rest of the course has a scaffold to hang on.

Prerequisites & where this fits

You need only basic IT literacy — comfort with the idea of a server, a network and a file — and an email address and payment card if you want to follow the optional hands-on lab in a real account. No programming and no prior cloud experience is assumed; we build the vocabulary from the ground up. This is the foundation lesson of the Fundamentals module in the AWS Zero-to-Hero course, and every later lesson — identity, networking, compute, storage, architecture and the certification kit — leans on the concepts established here. The natural next step after this lesson is AWS IAM Fundamentals: Users, Groups, Roles, Policies & the Evaluation Logic, because identity is the foundation of everything you secure on AWS.

What is cloud computing, and what is AWS?

Cloud computing is the on-demand delivery of IT resources — compute power, storage, databases, networking, and higher-level services — over the internet, with pay-as-you-go pricing. Instead of buying servers, racking them in a data centre you own, and paying for that capacity whether you use it or not, you rent exactly what you need, when you need it, and hand it back when you are done. The provider owns and operates the physical infrastructure; you consume it as a service.

The economic shift this represents is worth stating precisely, because the exam tests it directly. Running your own data centre is a capital expenditure (CapEx) model: you spend a large sum up front on hardware that then depreciates. The cloud turns this into an operational expenditure (OpEx) model: you pay a variable, ongoing fee for consumption. Alongside that, the cloud gives you elasticity (scale capacity up and down to match demand), agility (provision a server in minutes, not months), economies of scale (AWS buys hardware by the warehouse, so its costs — and therefore your prices — fall over time), and global reach (deploy close to users worldwide without building anything).

Amazon Web Services (AWS) is Amazon’s cloud platform: the market-leading provider, launched in 2006, offering a vast catalogue of services you assemble like building blocks. You interact with AWS through four main surfaces, and you will use all of them across your career:

A subtle but important point for beginners: the Console is the friendliest way to learn, but production environments are almost never built by clicking. Professionals define infrastructure as code so it is reviewable, repeatable and auditable. We will use the Console and CLI in early labs and graduate to infrastructure as code later in the course.

IaaS, PaaS and SaaS — the three service models

Cloud services sit on a spectrum of how much the provider manages versus how much you manage. Three labels capture the main points on that spectrum, and the CLF-C02 exam expects you to classify a service correctly.

The trade-off runs in one direction: as you move from IaaS towards SaaS you gain convenience and lose control. IaaS such as EC2 gives you a bare virtual machine — total flexibility, but you patch the OS and manage scaling yourself. PaaS such as Lambda or RDS hands those operational chores to AWS so you focus on code or data. SaaS is a finished product you simply consume. There is no “best” model; senior architects choose the highest level of abstraction that still meets the requirement, because every layer you hand to AWS is a layer you no longer have to operate.

A fourth term you will hear is serverless, which is not a separate model but a way of consuming PaaS where you never see or manage a server at all and you pay only for actual execution — Lambda, DynamoDB on-demand, S3 and EventBridge are the canonical examples.

The AWS global infrastructure

AWS does not run from one giant building; it runs from a deliberately layered, globally distributed physical footprint. Understanding this layering is the single most useful thing a beginner can learn, because it underpins availability, latency, durability, data residency and cost.

Regions

A Region is a separate geographical area — for example eu-west-1 (Ireland), us-east-1 (N. Virginia), or ap-south-1 (Mumbai). Each Region is fully isolated from the others: it has its own infrastructure and its own set of services, and (with rare, explicit exceptions) your data stays in the Region you put it in. This isolation is a feature — a problem in one Region does not spill into another — and it is also the basis of data sovereignty: if regulation says European personal data must remain in Europe, you choose a European Region and the data physically lives there.

Two consequences trip up newcomers constantly:

• Most services are Regional. When you create an S3 bucket or an EC2 instance, you create it in a Region. If you cannot find a resource you “definitely created”, you are almost always looking in the wrong Region in the Console.
• A few services are global. IAM, Amazon Route 53 (DNS), Amazon CloudFront (CDN), and AWS Organizations are global — they are not tied to one Region. Knowing which services are global versus Regional is a recurring exam theme.

Availability Zones

Inside every Region are multiple Availability Zones (AZs) — at least three in most Regions. An AZ is one or more discrete data centres with independent power, cooling and physical security, housed in separate facilities far enough apart to avoid a single local disaster yet close enough (connected by low-latency, high-bandwidth private fibre) to support synchronous replication. AZs within a Region are written with a letter suffix, such as us-east-1a, us-east-1b, us-east-1c.

The reason AZs exist is high availability. By spreading your servers across two or three AZs and putting a load balancer in front, your application survives the loss of an entire data centre with no downtime. This “deploy across multiple AZs” pattern is the most fundamental resilience technique on AWS, and many managed services (such as Amazon RDS in Multi-AZ mode) automate it for you.

Local Zones, Wavelength, edge locations and more

Beyond Regions and AZs, AWS extends its footprint closer to users and devices through several specialised location types. The table summarises the layers from broadest to most edge-ward.

You do not need to deploy to the exotic layers on day one — most workloads live happily in Regions and AZs — but you must recognise them. The two that recur in exams are edge locations (the CloudFront content-delivery network that caches content near users to cut latency) and Local Zones / Wavelength (for latency-sensitive and 5G edge use cases). Outposts is the answer whenever a question describes needing AWS services running physically on-premises for latency or data-residency reasons.

Choosing a Region

Region selection is a genuine architectural decision, not a default, and the CLF-C02 exam asks about it. Weigh five criteria:

A practical rule of thumb: start from your users (latency) and your legal obligations (residency), then check the service is offered there and compare price. Do not blindly default to us-east-1 just because tutorials do — it is often cheapest and has the newest services, but it may be the wrong choice for compliance or latency.

The AWS account and organisation model

An AWS account is the fundamental container for your resources, and — crucially — it is both a billing boundary and a security/isolation boundary. Everything you create lives inside an account, and everything that account consumes appears on one bill. Understanding the account model prevents two of the most common and expensive beginner mistakes: using the all-powerful root user for daily work, and cramming production and experimentation into a single account.

The root user

When you first create an AWS account you sign up with an email address and password; this creates the root user, which has complete, unrestricted access to everything in the account, including the ability to close the account and change billing details. Because it is so powerful, the root user is dangerous: the universal best practice is to use it only for the handful of tasks that genuinely require it (such as the initial account setup and a few account-level settings), enable multi-factor authentication (MFA) on it immediately, and then never use it for day-to-day work. For everyday tasks you create separate identities — covered next.

IAM identities

AWS Identity and Access Management (IAM) is the (global) service that controls who can do what in your account. You create IAM users for people or IAM roles for workloads and federated/temporary access, attach policies that grant specific permissions, and grant the least privilege necessary. The next lesson covers IAM in depth; for now, the foundational takeaway is simple: the root user is for emergencies; everyone and everything else uses IAM identities with scoped permissions and MFA.

Multiple accounts and AWS Organizations

Serious AWS estates are almost never a single account. Because the account is a hard isolation boundary, organisations create multiple accounts — for example separate accounts for production, staging, development, security tooling and logging — so that a mistake or a breach in one is contained and so that billing and access are cleanly separated. AWS Organizations is the (global) service that lets you centrally create and manage many accounts as one tree. Its building blocks:

A few benefits to internalise: consolidated billing rolls every account into one invoice and pools usage so you reach volume-discount tiers faster; SCPs let you enforce organisation-wide guardrails (for example, “no account may disable CloudTrail” or “only these Regions are allowed”); and AWS Control Tower is a higher-level service that sets up a well-architected multi-account “landing zone” with sensible defaults on top of Organizations. You will build exactly this in the course capstone — for now, simply know that the mature pattern is many accounts under one organization, not one big account.

The shared-responsibility model

Security in the cloud is a partnership, and the shared-responsibility model is the framework that draws the line between what AWS secures and what you secure. Misplacing this line is the root cause of a large fraction of real-world cloud breaches, so memorise it: AWS is responsible for the security of the cloud; you are responsible for security in the cloud.

• AWS — security of the cloud: the physical data centres, the hardware, the host operating system and virtualisation layer, and the global network — the infrastructure that runs all the services.
• You — security in the cloud: your data, the configuration of the services you use, identity and access management, network and firewall configuration, client- and server-side encryption, and (for IaaS) the guest operating system and its patches.

The exact split shifts with the service model, which is the nuance the exam loves. For IaaS such as EC2 you shoulder more — including patching the guest OS. For managed/PaaS services such as RDS or Lambda, AWS additionally takes on the OS and runtime, so your responsibilities shrink towards data, access and configuration. For SaaS you are mostly responsible only for your data and who can access it. The table makes the constants explicit.

A useful one-liner for the exam: “AWS secures the infrastructure; you secure your data, your identities, and your configuration.” If a breach happened because an S3 bucket was left public or an IAM key was leaked, that sits squarely on the customer side of the line.

The diagram above ties the picture together: Regions containing multiple Availability Zones, the edge and Local/Wavelength layers reaching closer to users, and — overlaid on that physical footprint — the logical account model of an AWS Organization with OUs and member accounts, all consolidated under one payer and one shared-responsibility line.

AWS pricing models

AWS pricing rests on three principles that the exam states almost verbatim: pay-as-you-go (pay only for what you use, with no long-term commitment required), save when you commit (commit to consistent usage and pay less), and pay less as AWS grows (economies of scale push prices down over time). On top of those principles sit the specific purchasing options for compute, which differ chiefly in the commitment you make and the discount and flexibility you get in return.

A few distinctions are worth labouring because they are classic exam traps:

• Reserved Instances vs Savings Plans. Both reward a 1- or 3-year commitment with similar discounts. RIs commit you to a fairly specific configuration; Savings Plans instead commit you to a steady dollar-per-hour and automatically apply that discount across whatever you run — Compute Savings Plans are the most flexible, covering EC2, Fargate and Lambda across families and Regions, while EC2 Instance Savings Plans trade some flexibility for a slightly bigger discount within a family in a Region. For most teams today, Savings Plans are the simpler choice.
• Spot. You get up to ~90% off by using AWS’s spare capacity, but AWS can reclaim the instance with a two-minute warning when it needs the capacity back. Spot is brilliant for anything that can tolerate interruption and terrible for a single, stateful database.
• Free Tier. AWS offers a Free Tier so you can learn without a bill, in three flavours: 12-months-free (e.g. 750 hours/month of a t2.micro/t3.micro EC2 instance for the first year), always-free (e.g. 1 million AWS Lambda requests per month, 25 GB of DynamoDB, forever), and trials (short-term free access to specific services). The Free Tier is how you will run the labs in this course — but watch the limits, because exceeding them quietly starts charging you.

What drives a bill

Whatever purchasing option you choose, three fundamental factors determine the cost of nearly everything on AWS — the exam phrases them as the “three drivers of cost”:

1. Compute — how much processing you consume (instance hours, Lambda invocations and duration, Fargate vCPU/memory-seconds).
2. Storage — how much data you store, and in which storage class (e.g. S3 Standard vs S3 Glacier).
3. Data transfer — moving data out of AWS to the internet, and sometimes between Regions/AZs.

Two cost truths that save real money: data transfer into AWS is generally free, while data transfer out to the internet is charged (so “egress” is the line item that surprises people), and you keep paying for provisioned resources you forget about — an idle EC2 instance, an unattached EBS volume, or an unused Elastic IP all cost money whether or not you use them. Cloud cost discipline is mostly the habit of turning things off.

Billing and cost-management tools

AWS gives you a suite of (mostly free) tools to see, understand, forecast and control spend. Knowing which tool does what is examinable and operationally essential.

The pattern to adopt from day one: set an AWS Budget with an alert the moment you create an account (so a runaway resource cannot silently rack up a bill), tag everything so cost can be attributed, and use Cost Explorer monthly to spot trends. The Pricing Calculator is your friend before you build; Cost Explorer and Budgets are your friends after.

AWS Support plans

When something breaks or you need guidance, AWS Support is your channel — and there are tiers, which the exam expects you to differentiate by who they suit and how fast they respond.

Two exam anchors: AWS Trusted Advisor (which inspects your account against best practices across cost, performance, security, fault tolerance and service limits) is limited on Basic/Developer and full on Business and above; and the Technical Account Manager (TAM) — a named human who proactively helps optimise your environment — is the signature benefit of Enterprise On-Ramp and Enterprise only.

Core AWS services overview

You will meet these services properly throughout the course, but it helps to have a scaffold now. AWS organises hundreds of services into categories; here are the foundational ones a CLF-C02 candidate is expected to recognise, grouped by the role they play.

Do not try to memorise every service today. The goal is recognition: when a later lesson says “put the static assets in S3 and serve them via CloudFront”, you already know those are object storage and a CDN.

Hands-on lab

In this lab you will create a free AWS account safely, lock down the root user, set a budget so you can never be surprised by a bill, and confirm your default Region — the exact first-day hygiene every professional performs. It uses only the AWS Free Tier and incurs no charge if you follow the steps.

Step 1 — Create the account and secure the root user. Go to the AWS sign-up page and create an account (you will need an email address and a payment card for verification; Free-Tier usage will not be charged). Once in, open the account menu (top-right) → Security credentials, and enable MFA on the root user using an authenticator app. Then create an IAM admin user for daily work (IAM console → Users → Create user → attach the AdministratorAccess policy → enable console access) and sign out of root, signing back in as the IAM user. You should now never use the root user again except for the rare account-level tasks that require it.

Step 2 — Confirm your Region. Look at the Region selector in the top-right of the Console. Pick the Region nearest you (for India, ap-south-1 Mumbai). Remember: resources you create live in the selected Region.

Step 3 — Install and configure the AWS CLI (optional but recommended). On your machine, install the AWS CLI, then run:

aws configure
# Paste an access key/secret from your IAM user, set the default Region (e.g. ap-south-1)

# Validate that the CLI is authenticated and see which identity you are:
aws sts get-caller-identity

Expected output is a small JSON object showing your account ID, user ARN and user ID — confirming the CLI is talking to your account as your IAM user (not root):

{
    "UserId": "AIDA...EXAMPLE",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/admin"
}

Step 4 — Create a zero-dollar budget alert. In the Console, open Billing and Cost Management → Budgets → Create budget → choose the Zero spend budget template (it alerts you the moment your spend exceeds the Free Tier). Enter your email and create it. From now on, any unexpected charge triggers an email.

Step 5 — Explore Cost Explorer. Open Cost Explorer and enable it (data takes up to 24 hours to populate). You now have the panel you will use to watch spend for the rest of the course.

Validation. You have succeeded when: MFA is shown as enabled on the root user; you are signed in as an IAM user (not root); aws sts get-caller-identity returns your IAM user ARN; and your zero-spend Budget appears in the Budgets list.

Cleanup. Nothing in this lab costs money, so there is nothing to delete. If you created the optional CLI access key and will not use it soon, you can deactivate it in IAM → your user → Security credentials. Keep the account, the IAM user, the MFA and the budget — you will use them throughout the course.

Cost note. This lab stays entirely within the Free Tier and costs ₹0 / $0. The single most valuable habit it instils — the zero-spend budget alert — is precisely what stops a forgotten resource from becoming a nasty bill later.

Common mistakes & troubleshooting

Best practices

• Lock down the root user first: enable MFA, create IAM users/roles for everything, and reserve root for the rare tasks that require it.
• Set a budget on day one: a zero-spend or small budget alert is the cheapest insurance against a runaway bill.
• Tag everything with a consistent scheme (Project, Environment, Owner) so cost and ownership are always attributable.
• Choose Regions deliberately by latency, compliance, service availability, cost and sustainability — not by habit.
• Design for multiple AZs from the start; it is the foundational AWS resilience pattern and usually cheap to adopt.
• Plan for multiple accounts as you grow, governed by AWS Organizations and (later) Control Tower, rather than one ever-larger account.
• Prefer the highest level of managed abstraction (PaaS/serverless) that meets the requirement, to minimise what you must operate.
• Estimate before you build with the Pricing Calculator, and review monthly with Cost Explorer.

Security notes

Security on AWS begins with three habits that flow directly from this lesson. First, identity hygiene: protect the root user with MFA, never embed long-lived access keys in code, and grant least privilege through IAM (the entire next lesson). Second, know your side of the shared-responsibility line: AWS secures the infrastructure, but your data, your access controls and your configuration are yours to secure — the overwhelming majority of real cloud incidents (public S3 buckets, leaked keys, over-broad permissions) are customer-side configuration failures, not AWS failures. Third, govern centrally as you scale: AWS Organizations with SCPs lets you set guardrails an individual account cannot override (for example, mandating encryption or restricting Regions), and turning on CloudTrail (the audit log of who did what) and a Budget from the outset means you can both investigate incidents and catch anomalies early. Security is not a later module — it is the posture you adopt the moment the account is created.

Interview & exam questions

1. What is the difference between a Region and an Availability Zone? A Region is an isolated geographic area; an Availability Zone is one or more discrete data centres within a Region, with independent power, cooling and networking. You deploy across multiple AZs in a Region for high availability; you choose a Region for latency, compliance, service availability and cost.

2. Explain the shared-responsibility model in one sentence, then give an example of each side. AWS is responsible for security of the cloud (the physical infrastructure, hardware, host OS and global network); the customer is responsible for security in the cloud (data, IAM, network/firewall configuration, and — for IaaS — the guest OS). Example: AWS secures the data-centre building; you secure your S3 bucket policy.

3. When would you choose Spot Instances, and what is the catch? For fault-tolerant, interruptible workloads (batch jobs, CI, big-data processing, stateless workers), because they offer up to ~90% off On-Demand. The catch is that AWS can reclaim the capacity with a two-minute warning, so Spot is unsuitable for a single stateful instance such as a primary database.

4. Reserved Instances vs Savings Plans — how do they differ? Both give up to ~72% off for a 1- or 3-year commitment. RIs commit you to a fairly specific instance configuration; Savings Plans commit you to a steady dollar-per-hour spend and apply the discount flexibly — Compute Savings Plans even span EC2, Fargate and Lambda across families and Regions. Savings Plans are usually the simpler, more flexible choice.

5. Name three services that are global rather than Regional. IAM, Amazon Route 53, Amazon CloudFront and AWS Organizations are global. Most other services (EC2, S3, RDS, VPC, Lambda) are Regional.

6. What are the three main factors that drive AWS cost? Compute (processing consumed), storage (data stored and its class), and data transfer (especially egress out to the internet). Note that inbound transfer is generally free while outbound is charged.

7. What is the purpose of AWS Organizations and a Service Control Policy? Organizations centrally manages many AWS accounts as one tree with consolidated billing and grouped governance via OUs. A Service Control Policy is a guardrail that sets the maximum permissions accounts may use — it never grants permissions, it only restricts them.

8. A company must keep European customer data inside Europe. Which AWS concept enforces this, and how? Region selection. Because most services and their data are Regional and isolated to the Region you choose, deploying to a European Region keeps the data physically resident there, satisfying data-sovereignty requirements.

9. What does the AWS Free Tier include, and what’s the risk? Three categories: 12-months-free (e.g. 750 hours/month of a micro EC2 instance), always-free (e.g. 1M Lambda requests/month), and short-term trials. The risk is silently exceeding a limit, which starts incurring charges — mitigate with a budget alert.

10. Which AWS Support plan gives you a Technical Account Manager, and what does Trusted Advisor offer at the free tier? A designated TAM comes with Enterprise (and a pooled TAM with Enterprise On-Ramp). On the free Basic plan, Trusted Advisor provides only a limited core set of checks; the full set of cost, performance, security, fault-tolerance and service-limit checks requires Business support or above.

11. What is the difference between an edge location and an Availability Zone? An AZ is a data-centre cluster inside a Region used to run workloads with high availability. An edge location is one of hundreds of points of presence used by CloudFront and Route 53 to cache content and resolve DNS close to end users for low latency — it is not where you run your servers.

12. Why is using the root user for daily tasks discouraged? The root user has unrestricted access to everything, including billing and account closure, so a compromise is catastrophic and its actions cannot be constrained by IAM permissions. Best practice is to secure root with MFA, create scoped IAM identities for all work, and use root only for the few tasks that demand it.

Quick check

1. True or false: Data transfer into AWS from the internet is generally charged.
2. Which service would you reach for to serve images to a global audience with low latency?
3. What is the maximum-permissions guardrail you apply across accounts in an organization called?
4. You need a virtual machine where you control and patch the OS. Which service model and which AWS service is that?
5. Which billing tool lets you set a threshold and receive an alert when forecast spend will exceed it?

Answers

1. False. Inbound data transfer is generally free; it is outbound (egress) to the internet that is charged.
2. Amazon CloudFront (a global CDN using edge locations), typically with content stored in Amazon S3.
3. A Service Control Policy (SCP) in AWS Organizations.
4. IaaS, delivered by Amazon EC2 — you manage and patch the guest OS.
5. AWS Budgets (with Cost Explorer for analysis and forecasting).

Exercise

Design — on paper, no building required — the account and Region strategy for a fictional Indian fintech startup with these requirements: customer financial data must remain in India; it has a small production workload and a separate development environment; the founders want to be alerted before any bill exceeds a small monthly figure; and they want to avoid catastrophic blast radius if a developer makes a mistake. Produce: (a) the Region you would choose and why; (b) how many AWS accounts you would create and what each is for; © which Organizations feature contains a developer mistake to one account; (d) two billing-governance controls you would switch on first; and (e) where on the shared-responsibility line the encryption of the customer data sits, and who owns it. Write two or three sentences for each — this is exactly the reasoning a Cloud Practitioner is expected to articulate.

Certification mapping

This lesson maps to the AWS Certified Cloud Practitioner (CLF-C02) exam, covering material across all four domains: Cloud Concepts (the value proposition, IaaS/PaaS/SaaS, the economics of CapEx→OpEx and elasticity), Security and Compliance (the shared-responsibility model, the root user and IAM basics, Organizations and SCPs as guardrails), Cloud Technology and Services (global infrastructure — Regions, AZs, Local Zones, Wavelength and edge locations — plus the core-services scaffold and the ways to access AWS), and Billing, Pricing and Support (On-Demand/Reserved/Savings Plans/Spot/Free Tier, the cost drivers, the billing and cost-management tools, and the Support plans). The global-infrastructure and account-model concepts also underpin the Associate exams — Solutions Architect Associate (SAA-C03), SysOps Administrator Associate (SOA-C02) and Developer Associate (DVA-C02) — which assume this foundation as a given.

Glossary

• AWS Region — An isolated geographic area containing multiple Availability Zones; the primary place you deploy and the unit of data residency.
• Availability Zone (AZ) — One or more discrete data centres within a Region with independent power, cooling and networking; deploy across multiple AZs for high availability.
• Local Zone / Wavelength Zone — AWS infrastructure placed in a metro (Local Zone) or inside a telco 5G network (Wavelength) for very low latency to users or devices.
• Edge location / Point of Presence (PoP) — One of hundreds of sites used by CloudFront and Route 53 to cache content and resolve DNS close to end users.
• IaaS / PaaS / SaaS — The three service models, from most customer-managed (Infrastructure) to fully provider-managed (Software).
• Root user — The all-powerful identity created with an AWS account; secured with MFA and reserved for the few tasks that require it.
• IAM — Identity and Access Management; the global service controlling who can do what, via users, roles and policies.
• AWS Organizations — The service for centrally managing many AWS accounts as one tree, with consolidated billing and OUs.
• Organizational Unit (OU) — A folder grouping accounts within an organization for shared governance.
• Service Control Policy (SCP) — An organisation-level guardrail that caps the maximum permissions an account/OU may use (it never grants).
• Shared-responsibility model — The framework dividing security duties: AWS secures of the cloud, the customer secures in the cloud.
• On-Demand / Reserved Instance / Savings Plan / Spot — The compute purchasing options, differing by commitment, discount and flexibility.
• Free Tier — The set of free allowances (12-months-free, always-free, trials) for learning and light use.
• Cost Explorer / AWS Budgets / Cost and Usage Report — The tools to analyse, alert on, and export cost and usage data.
• Trusted Advisor — A service that checks your account against best practices across cost, performance, security, fault tolerance and service limits.
• Technical Account Manager (TAM) — A designated AWS support contact, included with Enterprise (and pooled with Enterprise On-Ramp) plans.

Next steps

You now have the foundations: what AWS is, where it runs, how accounts and organisations are structured, who secures what, and how you pay. The natural next move is to go deep on the discipline that underpins every secure thing you will ever build on AWS — identity. Continue with AWS IAM Fundamentals: Users, Groups, Roles, Policies & the Evaluation Logic (aws-iam-fundamentals-users-roles-policies-evaluation), which turns the “use IAM, not root” advice from this lesson into a working command of users, roles, policy documents and the all-important evaluation logic. From there the course builds out networking, compute, storage, architecture and a full certification kit — all resting on the mental model you have just established.