Course
AWS for Developers
219 lessons across 14 modules
Build, deploy, secure, and operate production applications - the services developers actually use, not every service AWS sells. IAM, compute, S3, VPC networking, RDS and DynamoDB, Lambda, queues and events, CloudWatch, ECS, CI/CD, and architecture and cost - ending in a production learning platform. The road is laid out in full; lessons are being written one at a time.
AWS Fundamentals
The cloud, the AWS map, and the tools you drive it with
What is Cloud Computing?
1Renting infrastructure on demand instead of owning it.
A server running in minutes rather than weeks
What is AWS?
2The largest cloud provider, and the handful of services that matter most.
The dozen services behind a typical web application
AWS Global Infrastructure
3Regions, zones, and edge locations as one physical picture.
Where your data physically lives, and why that matters
Regions
4Independent geographic areas - choosing one for latency, law, and cost.
The same instance priced differently in two regions
Availability Zones
5Separate data centres within a region, the unit of resilience.
An app that survives a whole zone going dark
Edge Locations
6Points of presence close to users, for caching and DNS.
A static asset served from a city near the user
AWS Management Console
7The web console - good for exploring, poor for repeating.
A setup clicked together that nobody can reproduce
AWS CLI
8Every console action as a command you can script.
Listing every bucket in one command
AWS SDK
9Calling AWS from application code.
Uploading a file to S3 from a Node.js service
Shared Responsibility Model
10What AWS secures and what remains your job.
A public bucket that AWS did not leak - you did
AWS Free Tier
11What is free, for how long, and how people still get billed.
A forgotten NAT gateway on a free-tier account
Creating an AWS Account
12Securing the root user first, then never using it.
Root with MFA, and an admin user for daily work
AWS Resource Naming
13Names and conventions that keep an account navigable.
env-app-resource names that sort sensibly
AWS Service Categories
14Compute, storage, database, networking, integration - the map.
Placing every service in this course on the map
IAM and Security
Who and what can do which things, and where secrets live
What is IAM?
15Identity and access management - every AWS call is checked against it.
An access denied error read correctly
Users
16Identities for people - and why applications should never be users.
An application running on a personal access key
Groups
17Granting permissions to a role in the team, not to each person.
A developers group with one policy attached
Roles
18The concept - temporary credentials assumed by whoever is trusted.
A role assumed for an hour, then expired
Policies
19JSON documents of effect, action, resource, and condition.
A policy read line by line
Permissions
20How allows and denies combine - an explicit deny always wins.
A permission granted by one policy and denied by another
Managed Policies
21AWS-managed and customer-managed, reusable across identities.
The broad AWS-managed policy you should replace
Inline Policies
22Policies embedded in one identity, and when that is justified.
A one-off exception kept tied to its role
Least Privilege
23Granting exactly what is needed, and narrowing it over time.
A wildcard policy reduced to three actions on one bucket
MFA
24A second factor on every human login, root above all.
A leaked password that was useless on its own
IAM Roles for Applications
25Giving an application a role instead of keys.
An EC2 instance reading S3 with no credentials in its code
Access Keys
26Long-lived keys, the risk they carry, and rotating them.
A key committed to a public repository, found in minutes
Secrets Manager
27Storing and rotating secrets, fetched at runtime.
A database password rotated with no redeploy
Parameter Store
28Configuration and secrets, cheaper and simpler than Secrets Manager.
Choosing between the two for one application
KMS
29Managed encryption keys, and who is allowed to use them.
Encrypted data that an admin still cannot read
AWS Security Best Practices
30The account-level checklist worth running on day one.
A new account hardened in under an hour
Compute
Running your code - servers, platforms, and functions
What is EC2?
31Virtual servers you rent by the second.
A Linux server launched and reached over SSH
EC2 Instances
32Launching, stopping, and terminating - and what each keeps.
Data lost on terminate that survived a stop
Instance Types
33Families and sizes, and choosing by the workload.
A memory-bound service on a compute-optimised instance
AMIs
34Machine images you launch from, and baking your own.
A pre-configured image that boots ready to serve
Key Pairs
35SSH keys for instances, and Session Manager instead.
Reaching an instance with no open SSH port at all
Security Groups
36Opening a port on an instance, and only to whom it needs.
SSH open to the world, then narrowed to one address
EBS
37Attaching a persistent disk to an instance.
A data volume moved from one instance to another
Elastic IP
38A fixed public address, and why you rarely want one.
A load balancer that removed the need for a fixed IP
User Data
39A script that runs when an instance first boots.
An instance that installs and starts the app on launch
Auto Scaling
40Adding and removing instances with demand.
Capacity that doubles at noon and halves at midnight
Elastic Beanstalk
41A platform that manages the servers for you.
An app deployed with no instance configuration at all
Lambda Introduction
42Functions that run on demand, with no server to manage.
A function that runs only when a file arrives
When to Use EC2 vs Lambda
43Long-running against event-driven, and the cost curves of each.
The traffic level at which Lambda stops being cheaper
Storage
S3 in depth, and the block and file storage beside it
What is S3?
44Object storage - effectively unlimited, highly durable, and simple.
User uploads stored without a single disk to manage
Buckets
45Containers for objects, with globally unique names.
A bucket name already taken by someone else in the world
Objects
46A file plus its metadata, stored whole and replaced whole.
Why there is no appending to an S3 object
Object Keys
47Keys that look like folders but are really just prefixes.
A folder that disappears when its last file is deleted
Uploading Files
48Single uploads, and multipart uploads for large files.
A 5 GB upload resumed after a dropped connection
Downloading Files
49Reading objects, ranges, and streaming them through.
Streaming a large file without holding it in memory
Bucket Policies
50Resource policies attached to the bucket itself.
A bucket readable by one role and nobody else
Access Control
51Block Public Access, and why ACLs are now switched off.
The setting that prevents an accidental public bucket
Versioning
52Keeping every version of an object.
An overwritten file recovered in seconds
Lifecycle Rules
53Moving or deleting objects automatically as they age.
Logs moved to cheap storage after thirty days, deleted after a year
Storage Classes
54Paying less for data you read less often.
Archive storage at a fraction of the standard price
Encryption
55Encryption at rest - S3-managed keys against KMS keys.
An object nobody can read without the KMS key permission
Static Website Hosting
56Serving a static site from a bucket.
A React build served straight from S3
Presigned URLs
57Time-limited access to one object without making it public.
A browser uploading directly to S3, bypassing your API
EBS
58Block storage as a storage choice - volume types and snapshots.
A snapshot restored as a new volume in another zone
EFS
59A shared file system mounted by many instances at once.
Several servers reading the same uploaded files
S3 vs EBS vs EFS
60Object, block, and file storage, and choosing between them.
Uploads, a database disk, and shared files, each placed correctly
AWS Networking
VPCs, subnets, routing, DNS, and load balancing
Networking Fundamentals
61IP addresses, ranges, routing, and ports - the minimum you need.
Following one packet from a browser to a server
VPC
62Your own isolated network inside AWS.
A VPC with nothing reachable until you allow it
CIDR
63Describing address ranges, and sizing them so they do not run out.
A /24 subnet that ran out of addresses
Subnets
64Slices of a VPC, each in one availability zone.
The same tier spread across three zones
Public vs Private Subnets
65The route table decides - not the name.
A database moved into a subnet the internet cannot reach
Route Tables
66Where traffic from a subnet is sent.
A route that made a subnet public by accident
Internet Gateway
67The door between a VPC and the internet.
An instance with a public IP and still no internet access
NAT Gateway
68Outbound internet for private subnets, and its cost.
A private server installing updates, and the bill for it
Security Groups
69Stateful firewalls on each resource, referencing each other.
The app security group allowed into the database group
Network ACLs
70Stateless subnet-level rules, and why most teams leave them open.
A NACL blocking return traffic the security group allowed
VPC Peering
71Connecting two VPCs privately.
Two accounts talking without touching the internet
VPC Endpoints
72Reaching AWS services privately, without a NAT gateway.
S3 traffic that no longer pays for NAT
DNS
73Names, records, and resolution inside and outside a VPC.
A private hostname only resolvable inside the VPC
Route 53
74Managed DNS, domains, and health-checked routing.
A domain pointed at a load balancer with an alias record
Load Balancers
75Spreading traffic across healthy targets.
One unhealthy instance taken out of rotation automatically
Application Load Balancer
76HTTP-aware routing by path and host, with TLS.
/api to one service and everything else to another
Network Load Balancer
77Layer 4 load balancing for raw TCP and static IPs.
A non-HTTP protocol that an ALB cannot route
AWS Databases
Managed relational, DynamoDB, and caching
SQL in depth →What is RDS?
78Managed relational databases - what AWS runs and what you still own.
Patching and backups you no longer do by hand
PostgreSQL on RDS
79Running PostgreSQL managed, and what is not allowed.
An extension that RDS does not permit
MySQL on RDS
80The same service with a different engine.
The settings that differ between the two engines
Database Configuration
81Instance size, storage, and parameter groups.
A parameter change that needed a reboot to apply
Security Groups
82A database reachable only from the application that uses it.
An RDS instance with no public access at all
Backups
83Automated backups, point-in-time restore, and manual snapshots.
Restoring the database to the minute before a bad migration
Multi-AZ
84A standby in another zone, failed over to automatically.
A zone outage with a minute of database downtime
Read Replicas
85Scaling reads, and the replication lag that comes with it.
A read just after a write returning stale data
Monitoring
86Database metrics, slow queries, and Performance Insights.
Finding the one query using most of the database
What is DynamoDB?
87A serverless key-value database with predictable performance.
Millisecond reads at any scale, for a price in flexibility
Tables
88Tables with no fixed schema beyond their keys.
Two items in one table with different attributes
Items
89Items and attributes, and the size limit on each item.
An item that grew past the limit and stopped saving
Partition Keys
90How data is spread, and the hot partition that follows a bad choice.
Every write hitting one partition because of a date key
Sort Keys
91Ordering items within a partition and querying ranges.
A user and all their orders sorted by date
Queries
92Efficient reads by key - the only kind you should rely on.
One partition read, fast and cheap
Scans
93Reading the whole table, and why that is almost always wrong.
A scan that cost more than the rest of the month
Indexes
94Global and local secondary indexes for other access patterns.
Looking up users by email without a scan
DynamoDB Design
95Designing from access patterns, not from entities.
Listing every query first, then designing the keys
ElastiCache
96Managed in-memory caching - the service itself.
A cache cluster placed in private subnets
Redis
97Using Redis on ElastiCache for caching, sessions, and rate limits.
A slow endpoint served from cache in two milliseconds
RDS vs DynamoDB
98Relational flexibility against predictable scale.
The same feature designed for each, and the trade-offs
Serverless
Lambda, API Gateway, and functions triggered by events
What is Serverless?
99Servers still exist - you just stop managing and paying for idle ones.
A function that costs nothing when nobody uses it
Lambda
100The service in depth - invocation, the execution environment, and reuse.
A connection opened once and reused across invocations
Lambda Functions
101Writing, packaging, and deploying a function.
A function deployed from a zip and from a container image
Runtime
102Managed runtimes, versions, and when they are retired.
A deprecated runtime that stopped accepting updates
Handler
103The entry point, its event and context arguments.
Reading the event shape for each kind of trigger
Environment Variables
104Configuring a function, and keeping secrets elsewhere.
A table name in an environment variable, a password in Secrets Manager
IAM Roles
105The execution role - what the function itself may do.
A function that can read one table and nothing else
Lambda Layers
106Sharing libraries and dependencies between functions.
One layer used by twelve functions
Lambda Timeout
107The maximum duration, and choosing a sensible limit.
A default three-second timeout killing a slow call
Memory Configuration
108Memory also buys CPU - and sometimes lowers the bill.
A function made faster and cheaper by giving it more memory
Concurrency
109Parallel executions, limits, cold starts, and provisioned concurrency.
A burst that overwhelmed the database behind the function
Error Handling
110Retries by invocation type, and where failures end up.
An async failure retried twice and then lost
Lambda and API Gateway
111Putting an HTTP front door on a function.
A serverless API endpoint in one deployment
REST APIs
112The fuller API Gateway type - more features, higher cost.
Request validation and API keys done at the gateway
HTTP APIs
113The simpler, cheaper type, and when it is enough.
The same API at a fraction of the price
Routes
114Mapping methods and paths to integrations.
Four routes served by two functions
Stages
115Deployment stages, and separating dev from production.
A dev stage and a prod stage with different settings
Authentication
116JWT authorizers, Lambda authorizers, and IAM auth.
A token validated before the function is ever invoked
Throttling
117Rate limits and bursts protecting the backend.
A misbehaving client capped at the gateway
S3 to Lambda
118Running code whenever an object is created.
Thumbnails generated for every uploaded image
SQS to Lambda
119Processing queue messages in batches, with partial failures.
One bad message no longer failing the whole batch
EventBridge to Lambda
120Reacting to events and running on a schedule.
A nightly cleanup job with no server running
Application Integration
Queues, topics, events, and workflows between services
Messaging patterns in depth →SQS
121The managed queue service - standard against FIFO queues.
Order processing that needs FIFO and logging that does not
SNS
122Topics that push one message to many subscribers.
One order event sent to email, a queue, and a function
EventBridge
123An event bus with content-based routing rules.
Only high-value orders routed to the fraud service
SQS vs SNS
124Pull against push, one consumer against many.
SNS fanning out to several SQS queues
Pub/Sub
125Publishers that do not know who is listening.
A new subscriber added without touching the publisher
Message Queues
126Queue semantics - at-least-once delivery and visibility timeouts.
A message processed twice, and handling that safely
Dead Letter Queues
127Where messages go after repeated failure.
A poison message parked instead of retried forever
Retry Strategies
128Backoff, jitter, and knowing when to stop retrying.
Retries that hammered a recovering service back down
Event-Driven Architecture
129Services reacting to events instead of calling each other.
A synchronous chain of calls replaced by events
Step Functions
130Orchestrating multi-step workflows with state and retries.
An order workflow with a compensation step when payment fails
Asynchronous Processing
131Moving slow work out of the request path.
An upload acknowledged instantly and processed afterwards
Monitoring and Logging
Seeing what is happening, and who changed what
CloudWatch
132The monitoring service behind nearly everything on AWS.
Where every service already sends its metrics
Metrics
133Built-in metrics, custom metrics, and dimensions.
A business metric published alongside the system ones
Logs
134Collecting application logs, and querying them with Logs Insights.
Every error in the last hour found with one query
Log Groups
135One group per application, with a retention setting.
Logs kept forever by default, and the bill that followed
Log Streams
136The individual sources within a group.
Finding the stream from one misbehaving container
Alarms
137Acting on a metric crossing a threshold.
An alarm that fired at 3am, and one that should have
Dashboards
138The handful of graphs worth looking at during an incident.
A dashboard built for on-call, not for show
CloudTrail
139A record of every API call made in the account.
Finding who deleted a security group, and when
AWS X-Ray
140Tracing a request across services.
The one slow downstream call behind a slow endpoint
Application Monitoring
141Monitoring what users experience, not just the servers.
Healthy servers and a broken checkout
Alerting
142Alerts that are actionable, routed to the right people.
Alert fatigue cured by deleting half the alarms
Troubleshooting AWS Applications
143A method - metrics, then logs, then traces, then changes.
An outage traced to a configuration change in CloudTrail
Containers on AWS
Running the images from the Docker course
Prerequisite: the Docker course →Docker on AWS
144The options for running containers, and choosing between them.
ECS, EKS, App Runner, and plain EC2 compared
ECR
145The registry - repositories, lifecycle policies, and scanning.
Old images expired automatically to cap storage cost
ECS
146The AWS container orchestrator and its core concepts.
Clusters, services, and tasks on one diagram
ECS Cluster
147The logical grouping that tasks run in.
One cluster per environment
ECS Task
148Task definitions - image, CPU, memory, ports, and roles.
A task role and an execution role, and why there are two
ECS Service
149Keeping the desired number of tasks running.
A crashed task replaced without intervention
Fargate
150Running tasks without managing any instances.
A service with no EC2 instances to patch
Load Balancer and ECS
151Target groups, health checks, and dynamic ports.
New tasks registering with the ALB on their own
ECS Networking
152awsvpc mode, and tasks in private subnets.
A task with its own security group
ECS Security
153Task roles, secrets injection, and read-only root filesystems.
A database password injected from Secrets Manager at start
EKS Introduction
154Managed Kubernetes, and what you still operate yourself.
What changes when the same app moves to EKS
ECS vs EKS
155Simplicity against portability and ecosystem.
A small team choosing ECS, and a platform team choosing EKS
Deploying a Docker Application
156An image from the registry running behind a load balancer.
A containerised API reachable on a real domain
CI/CD and Deployment
From a git push to a running service, safely
CI/CD in depth →CI/CD Fundamentals
157Continuous integration and delivery on AWS.
Every merge built, tested, and deployable
CodeCommit Concepts
158The AWS Git service, and why most teams stay on GitHub or GitLab.
A pipeline triggered from a repository hosted elsewhere
CodeBuild
159Managed build containers driven by a buildspec.
A buildspec that tests and builds an image
CodeDeploy
160Deploying to EC2, Lambda, and ECS with traffic shifting.
A deployment rolled back automatically on an alarm
CodePipeline
161Chaining source, build, and deploy into one pipeline.
A pipeline with a manual approval before production
GitHub Actions and AWS
162Deploying from GitHub using OIDC, with no stored keys.
A workflow that assumes a role instead of holding secrets
Docker and AWS
163Where the image fits in an AWS delivery pipeline.
One image built once and promoted through every stage
Build Docker Image
164Building in the pipeline, with layer caching.
A build that reuses the cache from the last run
Push to ECR
165Authenticating to ECR from a pipeline and pushing.
An image tagged with the commit SHA and pushed
Deploy to ECS
166Registering a new task definition and updating the service.
A new version rolling out task by task
Deployment Strategies
167Rolling, blue-green, and canary - and what each risks.
Choosing a strategy for a database-backed API
Blue-Green Deployment
168A full second environment, and switching traffic at once.
An instant switch back when the new version misbehaved
Rolling Deployment
169Replacing instances gradually, with health checks gating each step.
A rollout that paused itself on failing health checks
Rollback
170Returning to the last known-good version quickly.
A bad release reverted in under two minutes
AWS Architecture
The Well-Architected pillars, and designing for failure
Architecture patterns in depth →AWS Well-Architected Framework
171Six pillars for reviewing a design, and using them in practice.
A design review structured by pillar
Reliability
172Recovering from failure, and scaling to meet demand.
A single point of failure found and removed
Security
173Identity, detection, protection, and incident response.
Every layer of one application secured in turn
Performance Efficiency
174Choosing the right resources, and revisiting the choice.
A newer instance generation, faster and cheaper
Cost Optimization
175The principle - paying only for the value you actually get.
Cost treated as a design input, not an afterthought
Operational Excellence
176Running and improving systems - automation and learning from failure.
A post-incident review that changed the runbook
Sustainability
177Reducing the resources a workload consumes.
Idle capacity removed for cost and energy alike
High Availability
178Staying up through the failure of any single component.
Every tier spread across at least two zones
Fault Tolerance
179Continuing correctly while something is broken.
A dependency outage absorbed by a cache and a fallback
Scalability
180Handling more load by adding resources, not by rewriting.
A stateless tier that scales out without a code change
Horizontal Scaling
181More instances - and keeping the application stateless to allow it.
Session state moved out so any instance can serve any user
Vertical Scaling
182Bigger instances - simple, limited, and sometimes the right call.
A database scaled up because it could not scale out
Multi-AZ Architecture
183Load balancer, compute, and database each spread across zones.
The reference architecture drawn and costed
Disaster Recovery
184The four strategies - backup and restore, pilot light, warm standby, active-active.
The same app designed for each strategy, and what each costs
Backup Strategy
185What to back up, how often, where to keep it, and for how long.
Backups copied to another region and another account
Cost and Reliability
Understanding the bill, and proving you can recover
AWS Pricing Fundamentals
186Paying for compute, storage, requests, and data transfer.
Data transfer turning out to be the largest line on the bill
Understanding AWS Billing
187Reading a bill and tracing each charge back to a resource.
A mystery charge traced to a forgotten load balancer
Cost Explorer
188Breaking spend down by service, account, and tag.
The service whose cost doubled last month, found in a minute
Budgets
189Alerts before spend becomes a surprise.
An alert at half the monthly budget, not after the invoice
Cost Optimization
190The practical levers - rightsizing, idle resources, and scheduling.
Development environments switched off overnight and at weekends
Reserved Instances
191Committing to capacity for a large discount.
A steady database committed for a year at a much lower rate
Savings Plans
192A spend commitment that is more flexible than reservations.
Discounts that follow workloads across instance types
Spot Instances
193Spare capacity at deep discounts, reclaimable with little warning.
Batch jobs that tolerate interruption running on spot
Resource Tagging
194Tags that make cost and ownership visible.
Every resource tagged with its team, app, and environment
Backup
195AWS Backup - one policy across many services.
Databases, volumes, and file systems backed up from one plan
Disaster Recovery
196Choosing a DR plan against its cost, then testing it for real.
A game day that found the restore took ten times longer than assumed
Recovery Point Objective
197How much data you can afford to lose.
An RPO of five minutes and the backup frequency it demands
Recovery Time Objective
198How long you can afford to be down.
An RTO of one hour ruling out a restore from cold backups
AWS Reliability Best Practices
199The reliability checklist for any production workload.
A real system reviewed against the list
Real-World AWS Project
A production learning platform, from VPC to review
The API this deploys: the Node.js course →AWS Architecture Design
200Route 53, CloudFront, S3, ALB, ECS, RDS, and ElastiCache, designed first.
The full architecture on one page, with a cost estimate
Create VPC
201The network the whole platform runs in.
A VPC spanning three availability zones
Create Subnets
202Public subnets for the load balancer, private for everything else.
Six subnets across three zones
Configure Security Groups
203Each tier allowed to reach only the tier behind it.
ALB to API to database, and nothing else open
Deploy PostgreSQL
204RDS PostgreSQL, Multi-AZ, in private subnets.
A database with automated backups and no public access
Deploy Redis
205ElastiCache Redis for caching and sessions.
A cache reachable only by the API tasks
Build Docker Image
206The Node.js API image, production-ready.
A small, non-root image built from the project
Push Image to ECR
207The project image stored in its repository.
A tagged image ready for ECS to pull
Deploy Node.js to ECS
208Fargate tasks running the API across zones.
Two tasks in two zones, replaced automatically on failure
Configure ALB
209Listeners, target groups, TLS, and health checks.
HTTPS terminated at the load balancer
Deploy React to S3
210The built frontend uploaded to a private bucket.
Static assets uploaded with long cache headers
Configure CloudFront
211A CDN in front of S3 and the API, with origin access control.
A bucket readable only through CloudFront
Configure Route 53
212The domain pointed at CloudFront and the API.
Alias records for the apex domain and the API subdomain
Configure IAM
213Task roles, pipeline roles, and human access, each scoped tightly.
An API allowed to read one bucket and nothing more
Configure CloudWatch
214Logs and metrics wired up for every component.
Every service logging into its own log group
Configure CI/CD
215A pipeline from push to production for both frontend and API.
A merge to main deployed with no manual steps
Configure Monitoring
216The alarms and dashboards that act on those logs and metrics.
An on-call dashboard and alarms that page for real problems
Cost Optimization
217The finished platform costed and trimmed.
A monthly bill cut by removing idle capacity
Production Security
218A security review of the running platform.
Findings fixed from a Well-Architected security review
Final Architecture Review
219The platform reviewed against all six pillars.
The finished architecture, and what you would change next time