Full Curriculum
A 10-phase progressive program: structured instructor-led training plus ~80 hours of self-study. 74 modules across 10 phases, with hands-on labs, quizzes, and phase exams.
IT Fundamentals
Optional Pre-Bootcamp11 primer modules (~2-3 hours) for those new to IT. Covers computers, command line, networking, APIs, Git, and security basics.
Module 00: How to Use This Bootcamp
Module 01: Computers and Operating Systems
Module 02: The Command Line
Module 03: Networking and the Internet
Module 04: APIs and Programming
Module 05: JSON, YAML, and Configuration Files
Module 06: Version Control with Git
Module 07: Security Fundamentals
Module 08: Databases and Data
Module 09: Cloud and Virtualization Concepts
Module 10: Linux Administration Basics
Create your AWS account, secure it with IAM, and build your first virtual network.
Module 01: Cloud Computing Principles
Every architectural decision you make in cloud starts with the principles in this module. When, three months from now, you are designing a multi-region disaster recovery strategy, or debating whether to use Lambda versus ECS for a workload, or explaining to a security auditor why a data breach is no
Module 02: AWS Global Infrastructure
Every architecture decision you will ever make on AWS begins with one question: where does this run?
Module 03: The AWS Account & Root User
The AWS account is your security boundary. Not the VPC. Not the IAM policy. The account itself.
Module 04: IAM - Users, Groups & Policies
IAM is the most important service in AWS. That is not an opinion. It is the architectural reality.
Module 05: IAM - Roles & Federation
In Module 04 you learned how to write IAM policies and attach them to Users and Groups. That is the foundation. But here is what separates a beginner from a practitioner: if you are creating IAM Users with access keys for your applications, you are doing it wrong.
Phase 2: Networking
7 modulesLaunch your first server (EC2) and store files in the cloud (S3).
Module 06: VPC Fundamentals
The VPC is your data center in the cloud. Every single resource you launch in AWS needs a network address, and the VPC is where those addresses live.
Module 07: Internet Connectivity
Every connection between your VPC and the public internet is a security decision. Not a networking decision. Not a functionality decision. A security decision.
Module 08: Route Tables & Traffic Flow
Route tables are the GPS of your network. Without them, packets go nowhere.
Module 09: Network Security
You have learned how traffic flows through a VPC. Now you learn how to control it.
Module 10: DNS with Amazon Route 53
DNS is the entry point to every internet-facing application you will ever build. If DNS is down, nothing works. If DNS routes to the wrong place, your failover architecture is worthless.
Module 11: Content Delivery with Amazon CloudFront
Latency kills user experience. A user in Singapore requesting content from an origin server in us-east-1 faces 200+ milliseconds of round-trip time just from the speed of light through fiber. Add TLS negotiation, TCP slow start, and origin processing time, and you are looking at full seconds before
Module 12: Advanced Networking
Real enterprise architectures do not live inside a single VPC. A mid-size organization might have 40 VPCs across 3 AWS accounts: production workloads in one, development in another, shared services (Active Directory, DNS, monitoring) in a third. Add a corporate data center connected via dedicated fi
Phase 3: Compute
8 modulesSet up databases (RDS & DynamoDB) and distribute traffic with load balancers and DNS.
Module 13: EC2 Fundamentals
EC2 is the most widely used AWS service. Full stop. It launched in 2006 as the first major AWS offering and remains the foundation for understanding every other compute model on the platform. When you use Lambda, a container runs on EC2 underneath. When you deploy to ECS or EKS, those tasks schedule
Module 14: EC2 Storage
Storage is where your data lives. Every application running on EC2 reads from and writes to some form of storage, whether it is the root volume holding the operating system, a database writing transaction logs, or an analytics engine processing terabytes of event data. Choosing the wrong volume type
Module 15: EC2 Scaling & Availability
A single EC2 instance is a single point of failure. One hardware fault, one kernel panic, one misconfigured deployment, and your application is offline. Manual intervention takes time. The person who can fix it might be asleep.
Module 16: EC2 Pricing & Optimization
Compute is typically the largest line item on an AWS bill. For most organizations, EC2 instances account for 40-60% of total monthly spend. The difference between paying On-Demand rates for everything and applying an intelligent pricing strategy is not 5-10%. It is 40-70%. That gap represents hundre
Module 17: Serverless Compute with AWS Lambda
Lambda changes the economics and operational model of compute entirely. You stop paying for idle. You stop managing servers. You start thinking in events.
Module 18: Container Fundamentals
Every major deployment failure shares a common ancestor: something was different between the developer's machine and the production environment. A library version, an OS patch, a configuration file, a system dependency. The application worked perfectly in development and exploded in production becau
Module 19: Container Orchestration with Amazon ECS
Building a container image and running it locally is straightforward. Running one hundred containers across multiple Availability Zones, replacing failed instances, rolling out new versions without dropping requests, injecting secrets, collecting logs, and scaling in response to demand is a fundamen
Module 20: Kubernetes on AWS with Amazon EKS
Kubernetes is the industry standard for container orchestration beyond any single cloud provider. If your organization operates across multiple clouds, contributes to the CNCF ecosystem, or needs access to the thousands of tools built for Kubernetes (service meshes, GitOps controllers, policy engine
Phase 4: Storage
6 modulesBuild event-driven apps with messaging queues and run code without servers using Lambda.
Module 21: S3 Fundamentals
S3 is arguably the most important service on AWS after IAM. If you think of it as "file storage in the cloud," you are dramatically underestimating what it does and why every architect reaches for it first.
Module 22: S3 Security & Access Control
S3 data breaches have made headlines repeatedly. Capital One. Twitch. US Department of Defense contractors. Municipal voter databases. Every single one of these was a misconfiguration. Not a zero-day exploit. Not a sophisticated attack chain. Someone left a bucket open, wrote an overly permissive po
Module 23: S3 Advanced Features
The difference between using S3 as "dumb storage" and using it as a sophisticated data platform comes down to understanding these advanced features. Most teams stop after learning how to upload and download objects. They leave versioning off, never configure lifecycle policies, pay Standard pricing
Module 24: S3 Glacier & Archival Storage
Organizations store data they rarely access but must retain for compliance, legal, or business reasons. Healthcare records must be kept for 6 years. Financial transaction records for 7. Legal discovery holds can stretch indefinitely. Media companies archive raw footage that may not be touched for a
Module 25: Amazon Elastic File System
When multiple compute resources need to read and write the same files simultaneously, EBS will not work. EBS volumes are scoped to a single Availability Zone and, with limited exceptions, attach to a single instance at a time. That model works fine for a standalone database server. It falls apart th
Module 26: AWS Storage Gateway & Transfer Family
Hybrid storage is a reality for most enterprises. They cannot migrate everything overnight. A typical large organization has petabytes of data in on-premises file servers, SAN arrays, and tape libraries. Applications depend on NFS or SMB shares. Backup software writes to virtual tape libraries. Comp
Phase 5: Databases
8 modulesPackage apps in containers (ECS) and define your entire infrastructure as code.
Module 27: RDS Fundamentals
Every production application stores state somewhere, and for the majority of enterprise applications, that somewhere is a relational database. Relational databases have dominated enterprise computing for four decades because they solve the hardest persistence problems: maintaining consistency across
Module 28: RDS High Availability & Read Scaling
A database is usually the stateful bottleneck in any architecture. Application servers are disposable. You can terminate them, replace them, and scale them horizontally in seconds. Databases are different. They hold state. They hold the truth of your system. If the database goes down, everything dow
Module 29: Amazon Aurora
Aurora is AWS's cloud-native relational database. It is not simply "managed MySQL" or "managed PostgreSQL." It is a fundamental reimagining of how a relational database engine interacts with its storage layer, designed from the ground up to exploit the distributed nature of cloud infrastructure.
Module 30: DynamoDB Fundamentals
DynamoDB is the default choice for serverless applications and any workload that needs single-digit millisecond response times at any scale. It backs some of the highest-traffic systems on the internet, including Amazon.com's shopping cart and order pipeline during Prime Day.
Module 31: DynamoDB Advanced Features
DynamoDB basic CRUD is easy. PutItem, GetItem, Query. You can learn that in an afternoon. But basic CRUD does not build production systems. Production systems need multiple access patterns on the same data, real-time reactions to changes, sub-millisecond reads for hot data, global availability, and
Module 32: In-Memory Databases: ElastiCache & MemoryDB
When your database response times are not fast enough for your user experience, you add a caching layer. This is not an optimization you do for fun. It is a fundamental architectural decision that transforms how your application performs under load.
Module 33: Analytics Databases: Redshift & Athena
Transactional databases handle operations. Analytics databases answer questions. These are fundamentally different workloads that require fundamentally different architectures.
Module 34: Purpose-Built Database Services
AWS offers purpose-built databases because forcing all data into one database type leads to poor performance and unnecessary complexity. This is not marketing. It is an engineering reality.
Automate deployments with CI/CD pipelines and harden your architecture with defense in depth.
Module 35: Application Load Balancer
Every production web application that runs on more than one server needs a load balancer. Without one, you have a single point of failure, no horizontal scaling capability, and no ability to deploy new code without taking your application offline.
Module 36: Network Load Balancer
Not every workload speaks HTTP. Database connections use proprietary TCP protocols. Gaming servers use UDP. IoT devices send telemetry over MQTT (TCP). Financial trading systems use custom binary protocols optimized for latency. VoIP systems use SIP and RTP over UDP. All of these workloads need load
Module 37: Amazon API Gateway
Every modern application exposes APIs. Mobile apps call backend APIs. Single-page applications call backend APIs. Partner integrations call your APIs. Internal microservices call each other's APIs. The question is not whether you will build APIs, but how you will manage the cross-cutting concerns th
Module 38: Amazon SQS
Every distributed system eventually hits the same problem: what happens when one component produces work faster than another can consume it? Without a buffer, the producer either blocks (waiting for the consumer) or drops requests (losing work). Both outcomes are unacceptable in production.
Module 39: Amazon SNS
SQS gives you point-to-point delivery: one message, one consumer. But real-world architectures rarely have that luxury. When a customer places an order, you need to notify the payment service, the inventory service, the shipping service, and the analytics pipeline simultaneously. You could write cod
Module 40: Amazon EventBridge
SNS handles pub/sub broadcasting well, but it has limitations. Filter policies operate only on message attributes, not on the message body. There is no built-in event replay. Schema discovery requires manual documentation. Integration with third-party SaaS platforms requires custom webhook handling.
Module 41: AWS Step Functions
Lambda functions do one thing well: execute a single piece of logic in response to an event. But real-world business processes are not single steps. An order processing workflow might require payment validation, inventory check, fraud detection, fulfillment, and notification, each with different err
Module 42: Other Integration Services
SQS, SNS, EventBridge, and Step Functions cover the majority of integration patterns you will encounter. But not every integration fits neatly into a queue, topic, event bus, or state machine. Sometimes you need real-time data synchronization with GraphQL subscriptions. Sometimes you need to ingest
Monitor, optimize costs, plan for disaster recovery, and validate against the Well-Architected Framework.
Module 43: CloudFormation Fundamentals
Every AWS resource you have created in this course so far was created through the console. You clicked buttons, filled in forms, and watched resources appear. That approach works for learning. It does not work for production.
Module 44: CloudFormation Advanced
Module 43 gave you the ability to define infrastructure in templates and manage it through stacks. That works for a single application with 10-20 resources. It does not scale.
Module 45: AWS Cloud Development Kit (CDK)
CloudFormation templates work. You proved that in Modules 43 and 44. You also noticed something: YAML gets verbose fast. A VPC with two public subnets, two private subnets, an internet gateway, NAT gateways, route tables, and route table associations takes 200+ lines of YAML. Every resource must be
Module 46: AWS Serverless Application Model (SAM)
You know how to write Lambda functions (Module 17). You know how to define infrastructure in CloudFormation templates (Module 43). Now combine those two facts and look at what it takes to deploy a simple API endpoint with raw CloudFormation:
Module 47: Source Control & CodeCommit
Every piece of your cloud infrastructure starts as a file. CloudFormation templates, CDK constructs, Lambda function code, pipeline definitions, Dockerfiles, Kubernetes manifests, configuration parameters. If these files are not under version control, you have no audit trail, no ability to roll back
Module 48: AWS CodeBuild
Every CI/CD pipeline needs a build step. Code must be compiled, dependencies must be installed, tests must be run, and artifacts must be packaged for deployment. Traditionally, teams maintained dedicated build servers (Jenkins instances, self-hosted runners) that required patching, scaling, and capa
Module 49: AWS CodeDeploy
Building and testing code is only half the story. The other half is getting that code running safely on your production infrastructure. Manual deployments are slow, error-prone, and terrifying. They do not scale, they do not provide consistency, and they offer no automatic recovery when something br
Module 50: AWS CodePipeline
You now know how to store code (Module 47), build code (Module 48), and deploy code (Module 49). But without orchestration, these are disconnected manual steps. Someone has to trigger the build after a commit. Someone has to take the build artifact and hand it to CodeDeploy. Someone has to verify th
Module 51: Deployment Strategies
Deploying software is inherently risky. Every deployment is a change to a running system, and every change has the potential to introduce defects, performance regressions, or outages. The question is not whether something will eventually go wrong during a deployment. The question is how fast you can
Phase 8: Security & Compliance
9 modulesDesign real-world architectures, tackle advanced topics, prep for the AWS exam, and present your capstone project.
Module 52: AWS Organizations & Control Tower
A single AWS account is a single blast radius. If an attacker compromises credentials in that account, every resource is reachable. If a developer accidentally deletes a production database, nothing prevented it. If a runaway process spins up expensive instances, the same billing boundary absorbs th
Module 53: Encryption with AWS KMS
Encryption transforms readable data (plaintext) into unreadable data (ciphertext) using a cryptographic key. Without the corresponding decryption key, the ciphertext is computationally infeasible to reverse.
Module 54: Secrets Management
Every application needs credentials to access external systems: database passwords, API keys, OAuth tokens, SSH keys, TLS private keys. The question is where those credentials live at runtime.
Module 55: Certificate Management with ACM
Transport Layer Security (TLS, the successor to SSL) encrypts data in transit between a client and a server. Without TLS, all data including credentials, personal information, and session tokens travels across the network in plaintext. Any intermediary (ISP, network operator, attacker on the same Wi
Module 56: AWS WAF
Your web applications face a constant barrage of automated attacks. SQL injection bots probe your login forms. Credential stuffing tools replay stolen username/password pairs against your authentication endpoints. Scrapers consume your API rate limits. Reconnaissance scanners map your attack surface
Module 57: AWS Shield
A Distributed Denial of Service (DDoS) attack is not a sophisticated exploit. It is brute force. An attacker coordinates thousands or millions of compromised machines to send traffic to your application simultaneously, overwhelming your infrastructure's capacity to respond to legitimate requests.
Module 58: Threat Detection: GuardDuty & Inspector
Prevention fails. No matter how rigorous your security controls, eventually someone will misconfigure an IAM policy, a credential will leak into a public repository, or a zero-day vulnerability will be exploited before a patch is available. The question is not whether a security incident will happen
Module 59: Audit & Compliance: CloudTrail & Config
Two questions dominate every security investigation and compliance audit:
Module 60: Security Hub & Governance
Individual security services generate findings in isolation. GuardDuty detects threats. Inspector finds vulnerabilities. Config identifies misconfigurations. Firewall Manager reports policy violations. Each service has its own console, its own finding format, and its own severity scale.
Ready to start?
Jump into Module 1 and begin your journey from novice to architect.
Start Module 1: Cloud Fundamentals