AWS has over 200 services. The official documentation is enormous. The certification paths can take months. And if you start on the AWS console without a clear map, you will spend your first two weeks clicking through services that have nothing to do with what you actually need to learn first.
I made that mistake. This post is an attempt to save you from it: a sequenced, practical roadmap to AWS fundamentals aimed at students who want to build real things and understand the core concepts — not just pass a certification.
The mental model before anything else
Before you touch a single AWS service, build a mental model of what cloud computing is actually doing. Cloud infrastructure is rented computing resources — compute (run code), storage (save data), and networking (connect things) — provisioned on-demand and billed by usage. That's the whole idea. Everything else is variation on those three primitives.
AWS's job is to abstract away the physical infrastructure — the servers, the cables, the data center cooling — and give you an API to create, configure, and destroy these resources programmatically. The power isn't in the services individually. It's in the ability to compose them reliably at scale without managing the underlying hardware.
Layer 1: Compute and the execution model
Start here: EC2 (Elastic Compute Cloud)
EC2 is a virtual server. You choose an OS, a CPU/memory configuration (called an instance type), and you get a machine you can SSH into and run whatever you want. It's the closest analog to your laptop. Understanding EC2 gives you intuition for everything else — the concepts of regions, availability zones, security groups, and IAM roles all become concrete when you're managing an actual server.
Spend time on: launching an instance, SSHing in, setting up a simple web server (nginx or Apache), understanding security groups (these are firewalls — what ports are open to whom?), and stopping/terminating instances. Also: understand the pricing model. On-demand vs. reserved vs. spot instances is a concept that will recur throughout AWS.
Then learn: Lambda
Lambda is serverless compute — you upload a function, define what triggers it, and AWS handles the server entirely. No instance to manage. You pay only when the function runs. Lambda is appropriate for event-driven, short-duration tasks: processing an image upload, responding to an API request, reacting to a database change. It's not appropriate for long-running processes.
Understanding both EC2 and Lambda gives you the two ends of the compute spectrum. Most real architectures use a mix.
Layer 2: Storage
S3 (Simple Storage Service)
S3 is object storage. You store files (objects) in buckets. It's infinitely scalable, highly durable, and cheap. It's used for static website hosting, storing images and videos, data lake storage, backup, and distribution through CloudFront. Almost every AWS architecture touches S3.
Learn: creating buckets, uploading and downloading objects, bucket policies and ACLs (access control), static website hosting, versioning, and lifecycle rules (moving objects to cheaper storage tiers over time).
RDS (Relational Database Service)
RDS is managed relational databases — you pick your engine (PostgreSQL, MySQL, Aurora, etc.) and AWS handles backups, patching, failover, and scaling. You connect to it like any database; the difference is you don't manage the server it runs on.
Understanding when to use RDS vs. when to stand up your own database on EC2 vs. when to use DynamoDB (NoSQL) is a key architectural decision skill. The short answer: RDS for most relational workloads where you want managed operations; DynamoDB for high-throughput, key-value workloads where you need single-digit millisecond latency at scale.
Layer 3: Networking
VPC (Virtual Private Cloud)
VPC is how you isolate your resources in AWS. By default, things you create are in a default VPC, but real architectures use custom VPCs to control exactly which resources can talk to which others, what's exposed to the internet, and what's kept private.
Concepts to understand: subnets (public vs. private), internet gateways, NAT gateways, route tables, security groups, and network ACLs. This section is often where students get lost — it requires thinking in network topology, which is unfamiliar. My recommendation: draw the architecture. Literally draw the VPC, the subnets, and the arrows showing what can talk to what. Networking is visual.
Layer 4: Identity and access
IAM (Identity and Access Management)
IAM is how AWS controls who can do what. Users, groups, roles, and policies. This is not optional — it's foundational to everything secure in AWS. The principle of least privilege (give each entity only the permissions it needs, nothing more) is the core idea. Get comfortable reading and writing IAM policies in JSON. Understand the difference between a user (a person), a role (an identity assumed by a service or a person temporarily), and a policy (a document that grants or denies permissions).
A common pattern: an EC2 instance assumes an IAM role that grants it permission to read from S3. The instance doesn't have credentials hardcoded — it assumes the role, gets temporary credentials, and uses them. This is the right way to do it. Hardcoding AWS credentials is a mistake you make exactly once.
The learning path I'd recommend
- Week 1–2: EC2, S3, IAM. Build: a static website hosted on S3. Then: deploy a simple web server on EC2, accessible from the internet.
- Week 3–4: RDS, Lambda, API Gateway. Build: a Lambda function behind an API Gateway endpoint that reads from RDS. This is the serverless API pattern.
- Week 5–6: VPC, CloudFront, Route 53. Build: move your EC2 app into a proper VPC with private subnets, add CloudFront in front of S3, set up a custom domain.
- Week 7–8: CloudWatch, cost management, and the AWS Well-Architected Framework. Build: instrument your existing apps with CloudWatch metrics and alarms. Review your architecture against the five pillars of the Well-Architected Framework.
What to ignore for now
At least 150 of the 200+ AWS services are not relevant to you as a beginner. Ignore ECS, EKS, Step Functions, Glue, Kinesis, SageMaker, and the entire suite of ML/AI services until you have the fundamentals solid. Those are specializations. They make no sense without the core.
The goal in the first two months: feel comfortable building a full-stack application on AWS — a database, a backend API, some compute, and storage. If you can do that and explain how the pieces connect, you're genuinely ahead of most people who claim to "know AWS."
The certifications are a useful forcing function — the AWS Cloud Practitioner and Solutions Architect Associate are both reasonable for students — but don't mistake passing the certification for understanding the platform. Build things. Break things. Read the bills. That's how it actually sticks.