Full Curriculum
A 12-week progressive program: structured instructor-led training plus 60+ hours of self-study. 74 modules across 12 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
Understand cloud computing and AWS global infrastructure, then secure your account with IAM users, roles, and federation.
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 modulesDesign VPCs from scratch: subnets, gateways, security groups, DNS with Route 53, and content delivery with CloudFront.
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 modulesMaster three compute paradigms: EC2 instances, serverless with Lambda, and containers with ECS, Fargate, and EKS.
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 modulesStore anything at any scale with S3, lifecycle and Glacier archival, EFS file systems, and hybrid Storage Gateway.
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 modulesChoose the right database: RDS and Aurora, DynamoDB, ElastiCache, Redshift, and purpose-built engines.
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.
Build decoupled architectures with load balancers, API Gateway, SQS, SNS, EventBridge, and Step Functions.
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
Phase 7: Infrastructure as Code
4 modulesDefine infrastructure as code with CloudFormation, the AWS CDK, and SAM for repeatable, version-controlled deployments.
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:
Phase 8: CI/CD Pipelines
5 modulesAutomate delivery with source control, CodeBuild, CodeDeploy, CodePipeline, and blue/green and canary strategies.
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 9: Encryption & Secrets
4 modulesProtect data at every layer with AWS Organizations, KMS encryption, Secrets Manager rotation, and ACM certificates.
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
Phase 10: Detection & Compliance
5 modulesDetect and respond with WAF, Shield, GuardDuty, CloudTrail, Config, and a unified view in Security Hub.
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.
Phase 11: Operations & Observability
8 modulesOperate with confidence using CloudWatch, X-Ray, cost management, backups, disaster recovery, and Systems Manager.
Module 61: CloudWatch Metrics & Alarms
Every AWS service you deploy produces metrics. EC2 instances report CPU usage every 5 minutes. Lambda functions report invocation count, duration, and errors after every execution. RDS databases report connection count, freeable memory, and IOPS consumption. ALBs report request count, target respons
Module 62: CloudWatch Logs
Metrics tell you something is wrong. Logs tell you why.
Module 63: Distributed Tracing with AWS X-Ray
In a monolithic application, debugging is straightforward. A request enters one process, executes sequentially, and you can trace the entire path through a single log file or debugger session. When that request fails or runs slowly, you know exactly where to look.
Module 64: Cost Management
AWS bills you for what you use. This is simultaneously the greatest advantage and the greatest risk of cloud computing. There is no upfront capital expenditure gate that forces you to justify resource allocation before deployment. You can launch a fleet of instances, provision a terabyte database, a
Module 65: Resource Optimization
Cost management tells you where money is going. Resource optimization tells you where money is being wasted. The distinction matters because most organizations skip straight to commitment purchases (Reserved Instances, Savings Plans) without first eliminating the waste they are committing to.
Module 66: AWS Backup
Every AWS service that stores data has its own backup mechanism. RDS has automated backups and manual snapshots. EBS has snapshots. DynamoDB has on-demand backups and point-in-time recovery. EFS has its own backup process. S3 has versioning and replication.
Module 67: Disaster Recovery
Disaster recovery is not about whether a disaster will happen. It is about when. AWS Regions are highly available, but they are not invincible. The 2017 S3 outage in us-east-1 cascaded across dozens of major services. The 2020 Kinesis failure in us-east-1 brought down services across the Region for
Module 68: AWS Systems Manager
Managing one EC2 instance is simple. You SSH in, run commands, install patches, check configurations. Managing 50 instances is tedious but possible with scripts and SSH key distribution. Managing 500 instances across multiple accounts and Regions with SSH is a security and operational nightmare.
Phase 12: Architecture & Capstone
6 modulesThink like an architect: Well-Architected reviews, architecture patterns, migration, data lakes, ML, and your capstone.
Module 69: Well-Architected Framework
Building an architecture that works is not the same as building an architecture that is well-designed. A system can serve traffic, store data, and process requests while simultaneously being fragile, insecure, wasteful, and impossible to operate. Working is the floor, not the ceiling.
Module 70: Architecture Patterns
Every architecture problem you will encounter has been solved before. Not identically, but structurally. The team that needs a customer-facing web application with a database backend faces the same structural challenge as thousands of teams before them. The team that needs to process events asynchro
Module 71: Migration Strategies
The reality of enterprise cloud adoption is that very few organizations start from zero. Most have years or decades of existing applications running on physical servers, in virtualized data centers, or in colocation facilities. These applications represent significant business value and institutiona
Module 72: Data Lakes & Analytics
Every application generates data. Transaction records. User behavior events. System logs. Sensor readings. Financial reports. Most organizations store this data in isolated systems: the CRM has customer data, the ERP has financial data, the application databases have operational data, the logging sy
Module 73: Machine Learning on AWS
Machine learning is no longer a specialty reserved for teams with PhDs in statistics. It is an architectural capability that solves specific categories of problems more effectively than traditional rule-based programming. Problems like: "Is this image appropriate for our platform?" "What is the sent
Module 74: Capstone Project
You have spent 73 modules learning individual services, integration patterns, operational practices, and architectural frameworks. Each module gave you a piece of the puzzle. The Capstone is where you assemble the puzzle into a complete picture.
Ready to start?
Jump into Module 1 and begin your journey from novice to architect.
Start Module 1: Cloud Fundamentals