Why AWS? Ecosystem, Regions & the Shared Responsibility Model

AWS Fundamentals

Chapter 1 · Why AWS? Ecosystem, Regions & the Shared Responsibility Model

Cloud Platform Fundamentals (cloud1) covered cloud computing generically — IaaS/PaaS/SaaS, elasticity, the shared-responsibility idea in the abstract, without committing to any one provider's own real services or console. This course goes deep on one specific provider instead: Amazon Web Services, in genuine, hands-on depth — real services, real console/CLI workflows, real architecture decisions.

AWS's Real Origin

Amazon began offering web services as early as July 2002, but the real cloud-computing platform known today as AWS launched in March 2006. Its first real, generally available service was S3 (Simple Storage Service, launched 14 March 2006) — object storage, not compute. EC2, the virtual-machine service most people associate with "the cloud," followed as a limited public beta on 25 August 2006, and didn't leave beta until October 2008. AWS's own real infrastructure, in other words, grew out of Amazon's own internal need to run its retail business at scale — Amazon itself started running its own retail platform on EC2 in November 2010, once the service had matured enough for that internal use.

Regions, Availability Zones & Edge Locations

AWS's own global infrastructure is organized in three real, distinct layers:

Region — a real, distinct geographical area (e.g. us-east-1, eu-west-2), wholly contained within a single country, where your data stays unless you explicitly configure otherwise.
Availability Zone (AZ) — each Region contains multiple AZs, and each AZ is one or more real, physically discrete data centers with their own independent power, networking, and connectivity — deliberately isolated from each other so a failure in one AZ doesn't take down another.
Edge Location — a much larger number of smaller, real caching/content-delivery points (used by CloudFront and other services) positioned close to end users, distinct from a full Region or AZ.

As of a real, documented count from October 2025, AWS operates 38 geographical Regions containing 120 Availability Zones between them, plus over 700 real Edge Locations worldwide — a genuinely global footprint most single applications never come close to needing in full.

Why This Structure Matters Immediately

Choosing a Region isn't just about latency to your users — it also determines which specific AWS services are available (not every service ships to every Region on day one) and, for regulated data, which country's own legal jurisdiction your data sits under. Deploying across multiple AZs within one Region, not multiple Regions, is the real, standard way to survive a single data-center failure without meaningfully increasing latency.

The Shared Responsibility Model

AWS draws a real, explicit line between what it secures and what you, the customer, are responsible for securing — commonly summarized as security of the cloud versus security in the cloud.

AWS's Responsibility ("of" the cloud)	Your Responsibility ("in" the cloud)
Physical data-center security	Your own IAM users, roles & permissions (Chapter 2)
The underlying hardware, networking, and virtualization layer	Your own operating-system patches, on any EC2 instance you run
The managed-service software itself (e.g. RDS's own database engine patching)	Your own data — encryption, access control, backups
Global infrastructure availability (Regions, AZs)	Your own network configuration — security groups, VPC design (Chapter 5)

This split shifts depending on the specific service: for EC2 (an unmanaged VM), you own the entire guest operating system and everything on it; for a fully managed service like Lambda, AWS takes on far more, and you're mostly responsible only for your own code and its permissions.

A Real, Common Misunderstanding

"AWS is secure" does not mean "my application on AWS is automatically secure." An S3 bucket accidentally left publicly readable, or an EC2 instance with an overly permissive security group, is a real, well-documented, and entirely real-world common cause of data breaches — and squarely the customer's own side of this model, not AWS's.

AWS's Real Market Position

Per real, documented Synergy Research Group data (Q1 2023), AWS held roughly 31% of the global cloud infrastructure market, ahead of Microsoft Azure's real 25% and Google Cloud's real 11% — the same three providers this bucket of courses covers, in the same real relative order they hold in the market today.

Hands-On Exercises

Exercise 1

Explain, in your own words, why deploying an application across multiple Availability Zones within a single Region is usually a better first step for high availability than deploying across two entirely separate Regions.

📄 View solution

Exercise 2

A company deploys an EC2 instance, leaves its operating system unpatched for a year, and is later compromised through a known OS vulnerability. Using the shared responsibility model, explain whose real responsibility this failure was, and why.

📄 View solution

Exercise 3

Explain, in your own words, why the shared responsibility split for a fully managed service like Lambda is genuinely different from the split for an unmanaged EC2 instance, and give one real, concrete example of a responsibility that shifts from you to AWS between the two.

📄 View solution

Chapter 1 Quick Reference

AWS launched — real cloud platform from March 2006, S3 first, EC2 beta later that year
Region — a distinct geographical area; Availability Zone — an isolated data center (or group of them) within a Region; Edge Location — a smaller, latency-focused caching point
Real current scale — 38 Regions, 120 Availability Zones, 700+ Edge Locations (as of October 2025)
Shared responsibility model — AWS secures "of" the cloud (infrastructure); you secure "in" the cloud (your own data, access, configuration)
Real market position — AWS ~31%, Azure ~25%, GCP ~11% (Synergy Research, Q1 2023)