JSTAcademy
0 XP
Dashboard
Crash Courses
Cloud Fundamentals & the AWS Mental Model
16 min
Basic+160 XP
Crash Courses · Basic

Cloud Fundamentals & the AWS Mental Model

Regions, AZs, IAM, the shared responsibility model, and how to think about the cloud
16 min read+160 XP on completionCert: AWS Crash Course
Tap any word in the text below to start reading from there.

Cloud Fundamentals & the AWS Mental Model

Why the Cloud Exists

Before cloud, companies bought physical servers, housed them in data centers, and paid for peak capacity that sat idle most of the time. AWS commoditized that infrastructure — you rent compute, storage, and networking by the second or GB, scale instantly, and pay only for what you use.

The mental shift: you are not managing servers, you are composing managed services. Every AWS service abstracts away a hard infrastructure problem.

The Global Infrastructure

AWS operates across 34+ regions worldwide. Each region is a self-contained cluster of data centers identified by a slug like us-east-1 (N. Virginia) or eu-west-1 (Ireland).

Inside each region are Availability Zones — physically separate facilities connected by high-speed, low-latency fiber. AZs are the unit of fault isolation. If one AZ loses power, the others keep running.

Best practice: spread your critical resources across at least 2 AZs. Most managed AWS services (RDS, ECS, ALB) do this automatically.

Region: us-east-1
├── AZ: us-east-1a  (data center cluster A)
├── AZ: us-east-1b  (data center cluster B)
└── AZ: us-east-1c  (data center cluster C)

IAM — The Access Control Plane

Every AWS API call is an IAM call. Whether you click in the console or run aws s3 cp, IAM decides whether you are allowed.

Core concepts:

ConceptWhat it is
UserA person or service with long-lived credentials
GroupA collection of users that share policies
RoleTemporary credentials assumed by a service or user
PolicyA JSON document that grants or denies specific actions on specific resources

The root account (the email used to create the AWS account) has unlimited power. Secure it immediately:

  1. Enable MFA
  2. Create an IAM admin user for daily work
  3. Never create access keys for root

Principle of Least Privilege: grant only the permissions something actually needs. An EC2 instance that reads from S3 needs s3:GetObject on that bucket — not s3:* on all buckets.

A minimal S3 read-only policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

The Shared Responsibility Model

This is the most important mental model for operating on AWS securely.

AWS is responsible for:

  • Physical security of data centers
  • Network hardware and hypervisors
  • Managed service OS patches (e.g., RDS database engine)

You are responsible for:

  • Your application code and its dependencies
  • OS patches on EC2 instances you manage
  • IAM policies and access controls
  • Data encryption in transit and at rest
  • Network configuration (security groups, VPC rules)

A breach caused by a misconfigured S3 bucket is your fault, not AWS's — even though AWS provides the bucket service.

How to Think About AWS Services

Every AWS service answers one question: "What hard infrastructure problem does this solve?"

  • Need to run code? → Lambda (serverless) or EC2 (virtual machine)
  • Need to store files? → S3 (object storage)
  • Need a database? → RDS (relational) or DynamoDB (NoSQL)
  • Need to connect services? → SQS (queue) or SNS (pub/sub)

The services are building blocks. Real architectures compose 5–20 of them. Start with the question, then find the service.

0%