AWS Fundamentals for DevOps

AWS has hundreds of services and that number is the first thing that scares people off. Ignore it. You do not learn AWS by learning every service - you learn a small set of building blocks and how they fit together, and the rest are variations you look up when a specific problem demands them. This guide builds that mental model: what the cloud gives you, how AWS is laid out around the world, who is responsible for what, and the core dozen services that cover the overwhelming majority of real work. Get these and you can read any architecture diagram, follow any runbook, and know which service to reach for.

What the cloud actually gives you

Strip away the marketing and a cloud provider gives you three things that a rack of servers in a closet does not.

• On-demand - you ask for a server, a database, or a terabyte of storage and it exists seconds later, through an API. No purchase order, no waiting for hardware. Just as important, you can hand it back when you are done and stop paying for it. Capacity becomes something you request and release, not something you own.
• Pay-per-use - you pay for what you consume - instance-hours, gigabytes stored, requests served - and nothing when it sits idle (with the important exception of resources that keep running because you forgot to delete them). This is the source of both the cloud's flexibility and its surprise bills.
• Managed services - AWS runs the hard parts for you. Instead of installing and patching a database, you rent one (RDS) and AWS handles backups, failover, and the operating system underneath. Instead of building a queue, you use one (SQS). The trade is control for operational burden: you give up some knobs, you stop being paged at 3am for a disk that filled up.

The mental shift is from "I own and maintain machines" to "I compose services through an API and pay for what runs." Everything below is a service you rent and wire together.

The global structure: Regions and Availability Zones

AWS is not one giant data center. It is a hierarchy, and the two levels you must understand are Regions and Availability Zones, because they determine where your data lives and how resilient your system is.

• Region - a geographic area, like us-east-1 (N. Virginia), eu-west-1 (Ireland), or ap-southeast-2 (Sydney). A Region is a big deal: most services are Region-scoped, meaning a resource you create in eu-west-1 does not exist in us-east-1. You pick a Region for latency (close to your users), for compliance (data residency laws), and for cost (prices vary by Region). Some services are global (IAM, Route 53, CloudFront), but assume Region-scoped until you know otherwise.
• Availability Zone (AZ) - one or more discrete data centers within a Region, with independent power, cooling, and networking. A Region has multiple AZs (usually three or more), named us-east-1a, us-east-1b, and so on. AZs in a Region are close enough for fast, low-latency links but far enough apart that one failing - a power outage, a flood - does not take the others down.

This is why multi-AZ matters for resilience. A single AZ can fail. If your whole application runs in one AZ, that failure is your outage. If you spread across two or three AZs - web servers in each, a database with a standby replica in a second AZ - a lost AZ costs you some capacity but not the service. Nearly every production pattern on AWS is really "do this, but across at least two AZs." When you configure a load balancer, an Auto Scaling group, or an RDS instance, spreading across AZs is the single most important reliability choice you make.

# Which Region is my CLI pointed at right now?
aws configure get region

# List the Availability Zones in the current Region
aws ec2 describe-availability-zones --query 'AvailabilityZones[].ZoneName' --output table

The shared responsibility model

Before you build anything, internalize who secures what, because getting this wrong is how data breaches happen. AWS splits security into two halves.

• AWS secures the cloud - the physical data centers, the hardware, the networking backbone, and the software that runs the managed services. You never patch the hypervisor or guard the building. This is "security of the cloud."
• You secure what you put in the cloud - your data, your access controls, your network rules, your operating system patches on the servers you run, and how your applications are configured. This is "security in the cloud."

The line moves depending on how managed the service is. With EC2 (a raw virtual machine) you own the OS, the patches, the firewall rules, and the app - a lot of responsibility. With a fully managed service like S3 or DynamoDB, AWS handles the OS and the machine, and your job shrinks to access control and data configuration. But it never shrinks to zero: the most common real-world breach is not AWS being hacked, it is someone leaving an S3 bucket public or an IAM policy too permissive. AWS gave you the tools to lock it down; using them is on you.

The core service categories

Here is the set worth carrying in your head. For each category, there is a flagship service you will meet constantly and reach for by default. Learn these dozen and you can operate.

Compute - running your code

• EC2 (Elastic Compute Cloud) - virtual machines. You pick a size (CPU, memory), an image (the OS), and you get a server you fully control. The classic building block; still the answer when you need a real machine you own end to end.
• Lambda - serverless functions. You upload code, it runs in response to an event (an HTTP request, a file upload, a schedule), and you pay per invocation and runtime. No servers to manage at all. Great for glue, event handlers, and spiky workloads.
• ECS / EKS - running containers. ECS is AWS's own container orchestrator; EKS is managed Kubernetes. Both run your Docker containers across a fleet without you placing each one by hand.

The rough decision: full control and long-running processes -> EC2; event-driven and small -> Lambda; containerized services -> ECS or EKS.

Storage - keeping data

• S3 (Simple Storage Service) - object storage. A near-infinite bucket you put files (objects) into and get back by key, over HTTP, at very low cost with very high durability. This is where static assets, backups, logs, data lakes, and build artifacts live. S3 is one of the most-used services on all of AWS - you will touch it constantly.
• EBS (Elastic Block Store) - block storage, the virtual hard disks you attach to EC2 instances. Where an EC2's operating system and its databases actually store bytes. EBS is AZ-scoped and lives independently of the instance, so a volume survives an instance being stopped.

The distinction: S3 is for objects you access over the network by key; EBS is a disk attached to one machine.

Networking - connecting things

• VPC (Virtual Private Cloud) - your own isolated private network inside AWS. Every EC2 instance, database, and load balancer lives in a VPC. You carve it into subnets (some public, facing the internet; some private, hidden), control traffic with security groups and route tables, and decide what can reach what. The VPC is the foundation everything else is placed into; understanding it is what separates people who can debug "why can't this server reach that one" from people who can't.

Databases - structured data

• RDS (Relational Database Service) - managed relational databases (PostgreSQL, MySQL, MariaDB, SQL Server, Oracle). You get a real SQL database with AWS handling backups, patching, and multi-AZ failover. Reach for this when your data is relational and you want SQL without babysitting a server.
• DynamoDB - a managed NoSQL key-value and document database. Serverless, single-digit-millisecond latency at any scale, priced per request or capacity. Great for high-scale, simple-access-pattern workloads (sessions, carts, event data); a poor fit for complex ad-hoc queries.

The rough split: relational and query-flexible -> RDS; massive scale with known access patterns -> DynamoDB.

Identity - who can do what

• IAM (Identity and Access Management) - controls who (users, roles, services) can do what to which resources. This is the security spine of your whole account. IAM is global, it is free, and it underpins every other service - every API call is authorized against an IAM policy. Roles (temporary credentials assumed by services and instances) are how you avoid hard-coding long-lived keys. Nearly every "access denied" you hit is an IAM policy telling you no.

Observability - seeing what happens

• CloudWatch - metrics, logs, and alarms. Every service ships metrics here (CPU, request counts, error rates); your applications ship logs here; and you set alarms that fire when a metric crosses a threshold (page someone when errors spike, scale out when CPU is high). When something is wrong, CloudWatch is usually where you look first.

That is the core dozen: EC2, Lambda, ECS/EKS, S3, EBS, VPC, RDS, DynamoDB, IAM, and CloudWatch. Almost every architecture is these composed together - servers in a VPC, storing data in S3 and RDS, permissioned by IAM, watched by CloudWatch.

How you interact with AWS

There are four ways to touch AWS, and mature teams lean hard on the last one.

• Console - the web UI. Good for exploring, learning what a service offers, and one-off inspection. Bad for anything you need to repeat or review, because clicking is not reproducible and leaves no record of why.
• AWS CLI - the command line. Scriptable, greppable, and the fastest way to check or change one thing. This is what you use in day-to-day operations and in shell scripts.
• SDKs - libraries for your language (Python's boto3, the JavaScript SDK, Go, Java, and more) so your application code can call AWS APIs directly - upload to S3, read from DynamoDB, invoke a Lambda.
• Infrastructure as Code (IaC) - the professional default for anything that persists. Instead of clicking or running one-off commands, you declare your infrastructure in files and apply them. Terraform (cloud-agnostic, HashiCorp) and CloudFormation (AWS-native) are the two you will meet. The infrastructure lives in git, changes go through review, and you can recreate an entire environment from code. If you take one habit from this guide: describe infrastructure in code, do not click it into existence.

# The CLI follows a consistent shape: aws <service> <action> [options]
aws s3 ls                                   # list your S3 buckets
aws ec2 describe-instances                  # list EC2 instances (verbose)
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId,State.Name]' \
  --output table                            # trim to just id + state

aws sts get-caller-identity                 # who am I authenticated as?

That last command, aws sts get-caller-identity, is worth remembering: it answers "which account and identity is this CLI actually using," which is the first question when a command mysteriously fails or you fear you are pointed at the wrong account.

What underpins everything: IAM and cost

Two concerns run underneath every service, and both are easy to ignore until they bite.

IAM is not optional and not a side topic. Every single API call - by you, by an EC2 instance, by a Lambda - is authorized against IAM. Get in the habit of least privilege (grant only what is needed), use roles instead of long-lived access keys, and never, ever commit credentials to git. The most common and most damaging AWS mistakes are IAM mistakes: over-broad permissions, leaked keys, a public bucket. It is worth a guide of its own, and it is the first thing to get right.

Cost awareness is a daily discipline, not a monthly surprise. Pay-per-use cuts both ways: idle resources you forgot about keep charging, an oversized instance quietly wastes money every hour, and data transfer out of AWS has real per-gigabyte cost that catches people off guard. Set a billing alarm on day one, tag resources so you can see what a project costs, and get reflexive about deleting things you are done with. The engineers who are trusted with production access are the ones who treat someone else's money as if it were their own.

Where to go next

You now have the map: the cloud gives you on-demand, pay-per-use, managed services; AWS is organized into Regions and AZs, and you spread across AZs for resilience; AWS secures the cloud while you secure what you put in it; and a core dozen services - EC2, Lambda, containers, S3, EBS, VPC, RDS, DynamoDB, IAM, CloudWatch - cover most of what you will build, composed together and permissioned by IAM, watched by CloudWatch, and (ideally) defined in code. From here, go deeper on the pieces that underpin the most:

• IAM - identity and permissions, the security spine of your account.
• EC2 - virtual machines, instance types, and how you actually run servers.
• VPC and networking - the private network everything lives inside.
• S3 - object storage, the service you will touch most.

Learn those four well and the rest of AWS becomes a matter of looking up the specific service when a specific problem asks for it - which is exactly how the pros use it.