Getting Started with AWS

1. How the AWS Cloud came about

Before touching any individual service, it helps to know that AWS was not a product somebody drew up and then sold. It grew out of Amazon’s own internal needs: the infrastructure that kept their e-commerce site running turned out to be one of the company’s core strengths, and only later did the idea of selling that capability to other people take shape.

The timeline on the slide:

• 2002: internally launched — used inside Amazon only.
• 2003: Amazon’s infrastructure is recognized as a core strength; the idea to take it to market appears.
• 2004: first public launch, with SQS.
• 2006: re-launched publicly with SQS, S3 and EC2 — the three foundational services.
• 2007: launched in Europe.

Why bother remembering this? Because it explains why SQS (message queuing), S3 (object storage) and EC2 (virtual servers) sit at the center of almost every AWS architecture you will meet in the exam. They were the first bricks, and everything else was built around them.

A few numbers

The deck offers some figures purely to convey scale:

• In 2023, AWS had $90 billion in annual revenue.
• AWS accounted for 31% of the market in Q1 2024 (Microsoft second, with 25%).
• AWS has been pioneer and leader of the cloud market for the 13th consecutive year, per the Gartner Magic Quadrant.
• Over 1,000,000 active users.

Not exam material

These revenue and market-share numbers are context, not content. The part you genuinely have to internalise starts with Regions and Availability Zones below.

2. What AWS is used for

AWS lets you build sophisticated, scalable applications, and it applies to a diverse set of industries — not just technology companies. The use cases the slide lists:

• Enterprise IT — a company’s internal IT infrastructure.
• Backup & Storage — keeping and protecting data.
• Big Data analytics — processing data at scale.
• Website hosting — running web sites.
• Mobile & Social Apps — the backends behind apps.
• Gaming — the systems that serve games.

The list is worth remembering because it mirrors the shape of SAA-C03 questions: the stem describes a concrete system (a web site, an analytics pipeline, a game backend) and asks you which services to compose into it.

3. The AWS global infrastructure

Everything in AWS sits on physical infrastructure spread around the world, and AWS divides that infrastructure into four conceptual layers. Getting these four straight is mandatory, because nearly every architectural decision you make — availability, latency, legal compliance — turns on them:

Layer	What it is
AWS Regions	A cluster of data centers inside one geographic area
AWS Availability Zones	Independent zones inside a Region
AWS Data Centers	The actual physical data centers
AWS Edge Locations / Points of Presence	Presence points at the edge of the network, close to end users

AWS publishes the map of all this at infrastructure.aws.

4. AWS Regions

A Region is the largest unit you work with day to day. AWS has Regions all around the world, and their names look like us-east-1 or eu-west-3 — a geographic code, a direction, and an index.

Physically, a Region is a cluster of data centers. Logically, the point to carry into the exam is this: most AWS services are region-scoped. When you create a resource it lives in that Region and does not appear anywhere else on its own. Launch an EC2 instance in us-east-1 and the eu-west-3 console will show you nothing.

Exam tip

“Region-scoped” is the root of a lot of trick questions. If a stem says a resource is “not visible” or “not usable” somewhere, the first suspicion should always be that you are looking at the wrong Region.

5. Choosing a Region for a new application

When you have to deploy something new, “which Region?” has no default answer. The deck gives four criteria, and exam questions usually lean on exactly one of them:

• Compliance with data governance and legal requirements: whatever you store in a Region stays there unless you yourself authorise a move out of it. This criterion tends to be absolute — if the law says the data must stay inside a country’s borders, none of the other three matter.
• Proximity to customers: placing workloads near users means reduced latency.
• Available services within a Region: a freshly released service or feature does not land in every Region at once, so check that the one you need exists where you want to deploy.
• Pricing: prices vary from Region to Region, and are stated transparently on each service’s pricing page.

Real-world example

You are building for users in Australia. Proximity says pick ap-southeast-2 (Sydney). But if the application needs a brand-new feature that exists only in us-east-1, you have a genuine trade-off: accept the higher latency, wait for the feature to reach Sydney, or split the architecture across two Regions.

6. Availability Zones

Each Region is divided into several Availability Zones (AZs). This is the layer you actually design fault tolerance around.

What the slide says about AZs:

• Each Region has many AZs — usually 3, minimum 3, maximum 6. For Sydney (ap-southeast-2) they are ap-southeast-2a, ap-southeast-2b, ap-southeast-2c.
• An AZ is built from one or several separate data centers, each carrying its own duplicated power, network links and connectivity.
• AZs are separate from each other, so that they are isolated from disasters — a fire, flood or power failure in one does not travel to the next.
• They are connected with high bandwidth, ultra-low latency networking.

Those last two properties together are why the standard AWS architecture is always “spread the application across several AZs”: separated enough that they do not fail together, connected fast enough that they still behave as one system.

Exam tip

Do not blur the two layers. Multiple AZs inside one Region solve the problem of one data center failing; multiple Regions solve the problem of a whole geography failing or a legal requirement about where data sits. Questions signal the difference with phrases like “an AZ becomes unavailable” versus “the entire Region is lost”.

7. Points of Presence (Edge Locations)

Beyond Regions and AZs, AWS runs an edge network whose whole job is getting content close to users:

• Amazon has 400+ Points of Presence — 400+ Edge Locations and 10+ Regional Caches.
• They sit in 90+ cities across 40+ countries.
• The purpose: content is delivered to end users with lower latency.

The distinction to keep: Regions and AZs are where your application runs; Edge Locations are where copies of content are cached so users fetch them faster. This network is the substrate CloudFront runs on — see CloudFront & Global Accelerator.

8. Global services versus Region-scoped services

Open the AWS Console and you will see a Region selector in the top right. For some services that selector reads “Global” instead — those services belong to no Region at all.

Global services:

• Identity and Access Management (IAM) — users and permissions; see AWS IAM.
• Route 53 — the DNS service.
• CloudFront — the Content Delivery Network.
• WAF (Web Application Firewall) — the firewall for web applications.

Most other services are Region-scoped, and the slide uses them to illustrate the cloud service models at the same time:

Service	Model
Amazon EC2	Infrastructure as a Service
Elastic Beanstalk	Platform as a Service
Lambda	Function as a Service
Rekognition	Software as a Service

AWS maintains a Region Table so you can check which service exists in which Region.

Exam tip

Memorize the four Global services exactly as listed (IAM, Route 53, CloudFront, WAF). An IAM user you create works in every Region — there is no need to recreate it per Region. An EC2 instance, by contrast, exists only in the Region where you launched it.

Quick recap

Item	What to remember for the exam
History	Internal launch in 2002, public launch in 2004 with SQS, re-launch in 2006 with SQS + S3 + EC2
Global infrastructure	Four layers: Region, Availability Zone, Data Center, and Edge Locations / Points of Presence
Region	A cluster of data centers, named like us-east-1; most AWS services are region-scoped
Choosing a Region	Compliance and legal (your data leaves a Region only if you permit it), proximity to customers (latency), which services exist there, and pricing
Availability Zones	Usually 3 per Region, minimum 3, maximum 6; one or several separate data centers with their own duplicated power and networking, isolated from disasters, joined by high-bandwidth ultra-low-latency links
Points of Presence	400+ (400+ Edge Locations, 10+ Regional Caches) in 90+ cities across 40+ countries, serving content at lower latency
Global services	IAM, Route 53, CloudFront, WAF
Service models	EC2 = IaaS, Elastic Beanstalk = PaaS, Lambda = FaaS, Rekognition = SaaS