AWS Introduction

What AWS is#

Amazon Web Services (AWS) is a cloud platform: a huge catalog of on-demand computing services — servers, storage, databases, networking, machine learning, and hundreds more — that you rent by usage instead of buying and operating physical hardware yourself. Instead of provisioning a physical server in a data center you own or lease, you request a virtual server from AWS and it exists within minutes, billed for exactly as long as you use it.

The core mental model#

Pay for what you use, not what you provision for peak. Traditional infrastructure means buying enough hardware to handle your busiest expected moment — Black Friday traffic, a viral spike — and having that capacity sit mostly idle the rest of the time. Cloud computing flips this: you can scale resources up during a spike and back down afterward, paying only for what you actually consumed. This is the foundational economic argument for cloud computing, and it's also the source of its biggest operational risk — it's just as easy to forget to scale something down and pay for idle capacity indefinitely.

Managed services vs. self-hosted. For almost every piece of infrastructure, AWS offers both a raw building block you fully operate yourself and a "managed" version where AWS handles the operational burden:

The trade-off is consistent across all of these: a managed service costs more per unit and gives you less low-level control, in exchange for offloading operational work (patching, backups, high availability, scaling) onto AWS. Most real-world architectures mix both — using managed services for things you don't want to babysit (databases, message queues) and raw compute for the parts of your system where you need full control.

Regions and Availability Zones#

AWS infrastructure is physically organized into a hierarchy:

• A Region is a distinct geographic area (e.g. us-east-1 in Northern Virginia, eu-west-1 in Ireland). Regions are fully independent of each other — data doesn't move between them unless you explicitly configure it to.
• Each Region contains multiple Availability Zones (AZs) — physically separate data centers within that region, each with independent power, cooling, and networking, but connected by low-latency links.

Region: us-east-1
 ├── Availability Zone: us-east-1a
 ├── Availability Zone: us-east-1b
 └── Availability Zone: us-east-1c

The reason this hierarchy matters practically: deploying redundant infrastructure across multiple AZs within a region protects you against a single data center failure (power outage, hardware fault) without the latency cost of spreading across distant regions. Choosing which Region to deploy in is mostly driven by where your users are (latency) and data residency/compliance requirements; spreading across AZs within that region is a baseline reliability practice almost every production system should do.

The console and the CLI#

The AWS Management Console is the web UI — useful for exploring services, one-off tasks, and learning, but it doesn't scale to repeatable, reviewable infrastructure changes (a problem the Terraform track covers in depth).

The AWS CLI lets you interact with every AWS service from the command line, which is what scripts, CI/CD pipelines, and most day-to-day operational work actually use:

# configure credentials once
aws configure

# example: list your S3 buckets
aws s3 ls

# example: list running EC2 instances
aws ec2 describe-instances --query "Reservations[].Instances[].InstanceId"

Common mistakes#

• Leaving unused resources (idle EC2 instances, unattached storage volumes, forgotten load balancers) running — this is the single most common cause of surprise AWS bills.
• Doing everything through the console with no record of what was clicked — this is exactly the problem Infrastructure as Code tools like Terraform exist to solve.
• Deploying a "highly available" system entirely within a single Availability Zone — a single data center outage takes the whole thing down.
• Using your AWS account's root credentials for everyday work instead of creating scoped IAM users/roles — the root account should be locked away and used only for account-level tasks.