01 — AWS Foundations: Cloud, Shared Responsibility, and the Well-Architected Lens

"Just rent a server somewhere" was my entire model of AWS, and it fell apart the first time I had to decide who was responsible for what. The line the rest of the roadmap hangs off: *AWS is not one product, it is a catalog of rented building blocks, and AWS is only responsible for security of the cloud while I stay responsible for security in it* [1][5]. Once that line was clear, every later service (EC2, S3, IAM, Lambda) stopped feeling like disconnected tools and started feeling like different points on the same rented-foundation curve.

What cloud computing actually is

The framing that landed: cloud computing is delivering computing services over the internet instead of from a box under my desk [2]. Storage, databases, virtual machines, analytics — all rented, on-demand, priced by what I use. The shift isn't technological magic; it's economic. I stop buying hardware upfront and start buying capacity in seconds, which is why a startup can stand up global infrastructure in an afternoon that would have taken a procurement cycle a decade ago.

The catalog is genuinely huge — over 200 services. The trick I keep reminding myself: I do not need to learn all of them. The roadmap walks the ~15 that carry 90% of real workloads, and the rest are look-it-up-when-you-need-it.

The three service models: IaaS, PaaS, SaaS

This was the first distinction I had to stop blurring. The three models differ by how much of the stack the provider manages versus how much I manage [3]:

• IaaS (Infrastructure as a Service) — the provider rents me raw compute, network, and storage. I manage the OS, the runtime, my app, the data. EC2 is the canonical example: AWS hands me a virtual machine; everything above the hypervisor (the software that slices one physical server into several virtual machines) is mine.
• PaaS (Platform as a Service) — the provider runs the runtime and the OS. I bring code and data, they bring the platform. Elastic Beanstalk, Lambda, RDS all sit on this rung.
• SaaS (Software as a Service) — the provider runs the whole finished application; I just use it. Gmail, Salesforce, anything I consume without writing code against its internals.

The rule I use: the further "up" the stack a service sits, the less I manage — and the less I can change. IaaS gives me the most control and the most chores. SaaS gives me the fewest chores and the fewest levers.

Public, private, hybrid

Clouds also differ by who they're built for [4]:

• Public cloud — resources owned by a provider (AWS, Azure, GCP) and shared across many tenants over the public internet. Cheapest, most elastic, least control over the physical layer.
• Private cloud — cloud-style architecture dedicated to one organization, whether on-prem or hosted. More control, more compliance leverage, less elasticity.
• Hybrid — the two connected, with workloads moving between them. The realistic shape for most enterprises: keep regulated data in a private cloud, burst compute into the public one.

AWS is overwhelmingly a public-cloud provider, but its Outposts and private-link offerings exist precisely to fill the hybrid gap. The distinction matters because "cloud" is not one deployment shape, and the right answer depends on data sensitivity, compliance, and burst patterns.

The global infrastructure: regions, AZs, edge

This is the part I had to draw to keep straight. AWS's physical footprint is layered [6]:

• Regions — geographical areas (us-east-1, ap-southeast-1). Each is fully isolated and independent. I pick a region for data sovereignty, latency to users, and service availability (not every service is in every region).
• Availability Zones (AZs) — each region contains two or more AZs, each a discrete data center cluster with independent power, cooling, and networking. AZs are close enough for low-latency links but far enough apart that a flood or fire in one usually misses the others.
• Edge locations — a much larger fleet of smaller sites used by CloudFront (and Route 53) to cache content and serve DNS close to users. There are far more edge locations than regions.

The way of thinking: regions are for data residency and rough latency, AZs are for high availability, edge locations are for delivery. A resilient app runs across at least two AZs in a region; a globally fast app fronts itself with edge locations.

Shared responsibility: who secures what

This is the line every AWS certification hammers, and for good reason. Under the shared responsibility model, AWS secures the cloud itself — the hardware, networking, facilities, virtualization — and I secure everything I put in the cloud [5]. AWS runs the data center; I run the firewall rules, the IAM keys, the patching of my EC2 OS, and the encryption of my S3 objects.

The confusion I had to clear up: the boundary moves with the service. On a raw EC2 instance, I patch the OS and the runtime — that's "in the cloud." On Lambda, AWS manages the runtime; my responsibility shrinks to my code and its IAM execution role. On a managed service like DynamoDB, my responsibility shrinks further still — to data, access policy, and nothing else. The more managed the service, the less of the wall I own.

The Well-Architected Framework

The framework is AWS's own rubric for "is this design any good" — six pillars that I now use as a checklist before I call an architecture done [7]:

• Operational excellence — will this run and evolve without heroics? (Runbooks, IaC — infrastructure defined as code — small frequent changes.)
• Security — is every layer defended, every action least-privileged, every secret encrypted?
• Reliability — does it recover from failure automatically, and scale without breaking?
• Performance efficiency — am I using the right resource type for the workload, not just the one I know?
• Cost optimization — am I paying for what I use and nothing more? (The easiest pillar to ignore, the most painful on the bill.)
• Sustainability — what's the environmental impact, and can I reduce it by right-sizing?

I do not run every workload through all six formally. But when a design feels off, asking which pillar it violates almost always names the problem.

How I use this

The foundations are a decision frame, not a feature list. When I start a new workload I ask, in order: which service model fits (do I need a VM, or will a managed runtime do?), which region satisfies data residency and latency, how many AZs does my availability target need, and which Well-Architected pillar is the binding constraint (usually cost or reliability). The shared responsibility line is the one I revisit whenever I assume "AWS handles that" — most of the time, they handle it down to the hypervisor, and everything above is mine.

References

[1] Amazon Web Services, "Overview of Amazon Web Services," AWS Whitepapers, 2024. [Online]. Available: https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html

[2] Amazon Web Services, "What is cloud computing?," 2024. [Online]. Available: https://aws.amazon.com/what-is-cloud-computing/

[3] Amazon Web Services, "Types of cloud computing," 2024. [Online]. Available: https://aws.amazon.com/types-of-cloud-computing/?nc1=h_ls

[4] Red Hat, "Public cloud vs. private cloud and hybrid cloud," 2024. [Online]. Available: https://www.redhat.com/en/topics/cloud-computing/public-cloud-vs-private-cloud-and-hybrid-cloud

[5] Amazon Web Services, "Shared responsibility model," 2024. [Online]. Available: https://aws.amazon.com/compliance/shared-responsibility-model/

[6] Amazon Web Services, "AWS global infrastructure," 2024. [Online]. Available: https://aws.amazon.com/about-aws/global-infrastructure/?p=ngi&loc=0

[7] Amazon Web Services, "AWS Well-Architected," 2024. [Online]. Available: https://aws.amazon.com/architecture/well-architected