eraldoaws — My Personal AWS Learning Journey

01

Regions, availability zones, account security, and identity management.

Click to see the full curriculum →

MODULE CURRICULUM

Shared Responsibility Model — AWS defines this as the split between what AWS secures ("security of the cloud" — hardware, facilities, networking) and what you secure ("security in the cloud" — data, IAM, configuration). Used to know exactly where your job starts. Example: AWS patches the physical host, but you're responsible for patching the OS on your EC2 instance.
Regions & Availability Zones (AZs) — A Region is a physical location with multiple, isolated data centers called AZs. Used to place resources close to users and to build fault tolerance. Example: deploying your app across 3 AZs in eu-central-1 so one data center outage doesn't take your site down.
Edge Locations & global infrastructure — Smaller sites AWS uses to cache and deliver content closer to end users. Used by CloudFront to reduce latency. Example: a user in Tirana loads your S3-hosted images from a nearby edge location instead of a far-away Region.
IAM Users, Groups & Roles — Users represent people, Groups bundle permissions for multiple users, Roles are temporary identities assumed by people or services. Used to control who/what can do what. Example: an EC2 instance assumes a Role to read from an S3 bucket, instead of storing long-term credentials on the instance.
IAM Policies in JSON — Documents that define permissions using Effect, Action, Resource, and optional Condition fields. Used to grant precise, least-privilege access. Example: a policy that allows s3:GetObject only on a specific bucket, only from a specific IP range.
Multi-Factor Authentication (MFA) — A second verification step (e.g. a one-time code) beyond username/password. Used to protect accounts even if a password leaks. Example: enabling MFA on the root account so a leaked password alone can't compromise it.
Protecting the Root Account — The root user has unrestricted access to the entire account. Used only for tasks that truly require it. Example: creating an admin IAM user on day one and locking the root credentials away, never using root for daily work.
AWS Organizations basics — A service to centrally manage multiple AWS accounts. Used by companies to separate environments (dev/prod) or teams under one billing umbrella. Example: a "Production" account and a "Sandbox" account under one Organization, with Service Control Policies restricting what Sandbox can do.
Billing, Budgets & Cost Explorer — Tools to track spend and get alerted before costs spiral. Used to avoid surprise bills. Example: setting a Budget alarm to email you if monthly spend exceeds $10.
Navigating the AWS CLI & Console — The command-line and web interfaces used to manage every AWS service. Used for both quick console changes and scriptable, repeatable actions. Example: running aws s3 ls in the terminal instead of clicking through the S3 console.

🎯 WHAT YOU'LL BE ABLE TO DO AFTER THIS MODULE

Set up a secure AWS account, configure IAM users with least-privilege permissions, and read or write a JSON policy without help.

02

Choosing the right storage service for every practical scenario.

Click to see the full curriculum →

MODULE CURRICULUM

S3 Buckets, Objects & Storage Classes — S3 stores data as objects inside buckets, with classes like Standard, Infrequent Access, and Glacier priced by how often you access the data. Used to balance cost against retrieval speed. Example: moving old log files to Glacier where storage is cheap but retrieval takes hours.
S3 Versioning & Lifecycle Policies — Versioning keeps every version of an object; Lifecycle rules automate moving or deleting objects over time. Used to protect against accidental deletion and cut storage costs automatically. Example: a rule that moves objects to Infrequent Access after 30 days and deletes them after 365.
S3 Bucket Policies & access control — JSON-based policies attached to a bucket that define who can read or write to it. Used to grant access without touching IAM. Example: a bucket policy that allows only CloudFront to read objects, blocking direct public access.
S3 Static Website Hosting — An S3 feature that serves objects as a website over HTTP. Used for simple static sites, though it has no built-in HTTPS. Example: quickly previewing a static site before putting CloudFront in front of it for SSL.
EBS Volume Types (gp3, io2, etc.) — Block storage volumes attached to a single EC2 instance, with types optimized for different IOPS and throughput needs. Used as the "hard drive" for a virtual server. Example: choosing io2 for a database that needs consistent, high IOPS.
EBS Snapshots & backup strategy — Point-in-time, incremental backups of an EBS volume stored in S3 behind the scenes. Used to recover data or migrate volumes across AZs. Example: taking a nightly snapshot of a volume so you can restore it if an instance is corrupted.
EFS for shared storage — A managed, elastic file system that many EC2 instances can mount and access at the same time. Used when multiple servers need the same files. Example: a fleet of web servers behind a load balancer all mounting the same EFS volume for shared uploaded content.
S3 vs EBS vs EFS — which to use — S3 for objects (files accessed via API), EBS for a single instance's block storage, EFS for shared file access across instances. Used to make the right architectural call. Example: user-uploaded images → S3; a database's data files → EBS; a shared config directory across 10 servers → EFS.
Storage Gateway — the basics — A hybrid service that connects on-premises infrastructure to AWS storage. Used when a company wants cloud backup without fully moving off-premises. Example: an on-prem file server that transparently backs up to S3 through a Storage Gateway appliance.
Cross-Region Replication — Automatic, asynchronous copying of S3 objects from a bucket in one Region to a bucket in another. Used for disaster recovery and compliance. Example: replicating a bucket from eu-central-1 to us-east-1 so data survives a full Region outage.

🎯 WHAT YOU'LL BE ABLE TO DO AFTER THIS MODULE

Set up an S3 bucket with lifecycle rules that cut costs automatically, and correctly choose between S3, EBS, or EFS for any scenario you're given.

03

Build private virtual networks, subnets, and firewall rules like a real company would.

Click to see the full curriculum →

MODULE CURRICULUM

VPC Design & CIDR blocks — A VPC is an isolated virtual network you define with an IP address range (CIDR block), which you then split into subnets. Used to fully control your network's layout. Example: a VPC with CIDR 10.0.0.0/16, split into 10.0.1.0/24 and 10.0.2.0/24 subnets.
Public vs Private Subnets — A subnet is "public" if its route table sends internet traffic to an Internet Gateway; otherwise it's "private." Used to separate internet-facing resources from internal ones. Example: a web server in a public subnet, a database in a private subnet it talks to internally.
Internet Gateway & NAT Gateway — An Internet Gateway is a VPC component that lets resources in public subnets communicate directly with the internet, both inbound and outbound. A NAT Gateway sits in a public subnet and lets resources in private subnets make outbound connections (e.g. software updates) without being reachable from the internet. Used together to give public resources direct internet access while keeping private resources hidden but still able to reach out. Example: a private database instance uses a NAT Gateway to download a security patch, but no one on the internet can initiate a connection to it.
Route Tables & traffic routing — Sets of rules that determine where network traffic from a subnet is directed. Used to control exactly how packets flow inside and outside the VPC. Example: a route table entry sending 0.0.0.0/0 traffic to the Internet Gateway for a public subnet.
Security Groups vs Network ACLs — Security Groups are stateful, instance-level firewalls (return traffic is automatically allowed); Network ACLs are stateless, subnet-level firewalls (you must allow both directions explicitly). Used as layered defenses. Example: a Security Group allowing inbound port 443 on a web server, plus a Network ACL blocking a known malicious IP range at the subnet level.
VPC Peering — A network connection between two VPCs that lets them communicate using private IP addresses, as if they were one network. Used to connect separate environments without routing through the public internet. Example: peering a "shared services" VPC with a "production" VPC so both can reach a central logging server.
VPN & Direct Connect basics — Site-to-Site VPN creates an encrypted tunnel over the internet between your network and AWS; Direct Connect is a dedicated physical network connection. Used to link on-premises infrastructure to AWS. Example: a company office connecting to its AWS VPC over a Site-to-Site VPN instead of the public internet.
Load Balancers: ALB & NLB — An Application Load Balancer (ALB) routes HTTP/HTTPS traffic based on content (like URL path); a Network Load Balancer (NLB) handles raw TCP/UDP traffic at very high performance. Used to distribute traffic and add resilience. Example: an ALB routing "/api" requests to one set of servers and "/images" to another.
Bastion Hosts for secure access — A hardened, publicly reachable instance used as the single entry point to reach instances in private subnets. Used so private resources never need a public IP. Example: SSH-ing into a bastion host first, then hopping to a private database server from there.
VPC Flow Logs & traffic monitoring — A feature that captures information about the IP traffic going to and from network interfaces in a VPC. Used to troubleshoot connectivity issues and detect suspicious activity. Example: using Flow Logs to discover that a security group is silently blocking traffic from a partner's IP range.

🎯 WHAT YOU'LL BE ABLE TO DO AFTER THIS MODULE

Build a VPC from scratch with public/private subnets, a working NAT Gateway, and Security Groups that allow only the traffic that's actually needed.

04

From virtual servers to serverless architecture.

Click to see the full curriculum →

MODULE CURRICULUM

EC2 Instance Types & sizing — Families like T (burstable, general purpose), M (balanced), C (compute-optimized), and R (memory-optimized) trade off CPU, memory, and cost differently. Used to match compute resources to workload. Example: choosing a C-family instance for a CPU-heavy video encoding job instead of a general-purpose T instance.
AMIs (Amazon Machine Images) — A template containing an OS, application server, and applications, used to launch new EC2 instances. Used for fast, consistent deployment. Example: baking a custom AMI with your app pre-installed so new instances boot up ready in seconds.
Auto Scaling Groups — A group of EC2 instances that automatically adds or removes capacity based on demand or schedules. Used to handle variable traffic without manual intervention. Example: scaling from 2 to 10 instances automatically during a traffic spike, then back down overnight.
Integration with Elastic Load Balancing — Load balancers distribute incoming traffic across the instances in an Auto Scaling Group. Used to keep traffic evenly spread as capacity changes. Example: new instances launched by Auto Scaling are automatically registered with the ALB and start receiving traffic.
Lambda Functions & triggers — Serverless functions that run code in response to events, without provisioning servers. Used for event-driven, short-lived tasks. Example: a Lambda function that automatically resizes an image the moment it's uploaded to an S3 bucket.
API Gateway + Lambda — API Gateway exposes HTTP endpoints that trigger backend logic, commonly Lambda functions. Used to build a fully serverless API with no servers to manage. Example: a POST /orders endpoint in API Gateway that invokes a Lambda function to write the order to DynamoDB.
Containers: ECS & Fargate basics — ECS orchestrates Docker containers; Fargate is a launch type that runs containers without you managing the underlying EC2 instances. Used to deploy containerized apps without server management. Example: running a containerized web app on ECS with Fargate, so you only think about the container, not the host.
ECR — Elastic Container Registry — A managed Docker container registry for storing and versioning container images. Used as the source ECS/EKS pull images from. Example: pushing a new app version as myapp:v2 to ECR, then updating the ECS service to deploy it.
Spot Instances vs Reserved Instances — Spot Instances use spare AWS capacity at steep discounts but can be reclaimed with short notice; Reserved Instances commit to 1-3 years for a lower fixed price. Used for cost optimization based on workload flexibility. Example: running batch data processing on Spot Instances (interruption-tolerant) but a production database on Reserved Instances (needs to stay up).
Systems Manager (SSM) — A service for managing, patching, and running commands on instances without opening SSH access. Used to administer fleets of servers securely. Example: running a patch update across 50 instances at once via SSM, with no SSH keys involved.

🎯 WHAT YOU'LL BE ABLE TO DO AFTER THIS MODULE

Deploy an app behind an Auto Scaling Group, and confidently decide whether a given scenario calls for EC2, Lambda, or containers.

05

RDS, DynamoDB, and how to migrate existing systems into the cloud.

Click to see the full curriculum →

MODULE CURRICULUM

RDS: MySQL, PostgreSQL & other engines — A managed relational database service that handles patching, backups, and provisioning. Used when you need SQL without administering the server yourself. Example: launching a PostgreSQL RDS instance for an app instead of installing and maintaining Postgres on an EC2 server.
RDS Multi-AZ & Read Replicas — Multi-AZ keeps a synchronized standby copy in another AZ for automatic failover; Read Replicas are separate copies used to scale read traffic. Used for high availability and performance respectively. Example: Multi-AZ fails over automatically if the primary database crashes; a Read Replica handles reporting queries so they don't slow down the main database.
DynamoDB: tables, items & partition keys — A fully managed NoSQL database where data is organized into tables of items, distributed across partitions based on a partition key. Used for apps needing massive, predictable-latency scale. Example: choosing userId as the partition key so a user's data is always retrieved with single-digit millisecond latency.
DynamoDB vs RDS — which to use — RDS suits structured, relational data with complex queries and joins; DynamoDB suits simple access patterns at very high scale. Used to make the right database choice upfront. Example: an e-commerce order history with complex reporting → RDS; a session store handling millions of reads/sec → DynamoDB.
Database Migration Service (DMS) — A service that migrates databases to AWS with minimal downtime, including continuous replication during the cutover. Used to move existing databases without a long outage. Example: using DMS to replicate an on-premises MySQL database into RDS in real time, then switching over with only seconds of downtime.
Backup & Restore strategy — Automated or manual snapshots of a database, combined with a tested restore process. Used to guarantee data can actually be recovered, not just backed up. Example: scheduling nightly automated RDS backups and periodically restoring one to verify the backup actually works.
ElastiCache: Redis & Memcached — A managed in-memory caching service used to reduce load on a primary database by serving frequent reads from memory. Used to speed up applications and cut database costs. Example: caching a frequently-viewed product page in Redis so it doesn't hit RDS on every request.
Aurora basics — AWS's own MySQL/PostgreSQL-compatible database engine, built for higher performance and availability than standard RDS. Used when you need RDS-like ease with better throughput. Example: migrating a high-traffic app from standard RDS MySQL to Aurora MySQL for better performance at a similar price.

🎯 WHAT YOU'LL BE ABLE TO DO AFTER THIS MODULE

Deploy a Multi-AZ RDS database, design a DynamoDB table with a good partition key, and plan a migration with no downtime.

06

A deep review of every module, tying the concepts together into one complete picture.

Click to see the full curriculum →

MODULE CURRICULUM

The 5 pillars of the AWS Well-Architected Framework — Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization; a structured way AWS recommends evaluating any architecture. Used to review a design objectively instead of by gut feeling. Example: reviewing your project and realizing it's optimized for cost but has no monitoring — a gap in Operational Excellence.
Building architecture diagrams — Visually representing how services connect and interact. Used to communicate a design clearly to others (or your future self). Example: diagramming your S3 + CloudFront + Route 53 project the way you'd present it in a job interview.
Practical review of every module — Connecting IAM, storage, networking, compute, and databases into a single working system. Used to see the full picture instead of isolated services. Example: tracing exactly how a request flows from Route 53 → CloudFront → ALB → EC2 → RDS.
Real troubleshooting scenarios — Debugging common issues like 403 errors, connectivity failures, and performance bottlenecks. Used to build the diagnostic instincts that only come from hands-on debugging. Example: a 403 from CloudFront traced back to a missing permission in the S3 bucket policy.
Cost optimization review — Identifying unused or oversized resources and right-sizing them. Used to keep a project's monthly bill under control. Example: finding an idle NAT Gateway racking up hourly charges with nothing using it.
Security checklist before deploying — A final pass to confirm least-privilege IAM, encrypted storage, and no unintentionally public resources. Used as a safety net before anything goes live. Example: catching an S3 bucket that was accidentally left publicly readable before it becomes a real incident.
Consolidating projects into a portfolio — Packaging what you've built (with diagrams and explanations) into something presentable. Used to turn hands-on practice into something you can show. Example: writing a short README for each project explaining the architecture and the decisions behind it.

🎯 WHAT YOU'LL BE ABLE TO DO AFTER THIS MODULE

Explain and defend every architectural decision made across Modules 1-5, with a portfolio of projects ready to show.

Learn AWS through real projects, not just the theory.

From the first IAM account to a complete architecture

Cloud Foundations & IAM

Storage: S3, EBS & EFS

Networking: VPC & Security

Compute: EC2, Lambda & ECS

Databases & Migration

Review & Consolidation

Building real things, not just exercises

Static site on S3 & CloudFront

Serverless API with Lambda

Auto-scaling infrastructure

Everything you need, organized in one place

Service-by-service summaries

Service comparisons

Hands-on question bank

AWS terminology

My AWS journey continues every week.