The 630-Hour Cloud Engineering Roadmap I Am Building In Public
I mapped my cloud engineering path into five phases, real projects, certification milestones, and a data center operations branch. Here is the full plan.
At 30 hours per week, that is roughly 21 weeks. Around five months.
At 40 hours per week, it becomes closer to four months.
That is not a casual pace. It is an intensive transition plan.
The important part is that every phase ends with a project. The projects matter more than the course list because they turn passive study into evidence.
Phase 1: Foundations Before Cloud
The first phase is deliberately boring.
Linux. Networking. Python. Git.
No Kubernetes. No advanced AWS architecture. No pretending that cloud engineering starts with clicking around the AWS console.
The goal is simple: become useful on a terminal, understand how systems communicate, write small automation scripts, and use version control properly.
The sources I mapped here include:
Linux Foundation LFS101.
The Linux Command Line by William Shotts.
Linux Journey.
Professor Messer Network+.
Practical Networking.
Cisco Networking Basics.
Automate the Boring Stuff with Python.
Corey Schafer's Python tutorials.
Pro Git.
MIT Missing Semester.
GitHub Skills.
The project:
Provision a single EC2 instance manually, SSH in, install nginx, configure systemd, write a Python script that calls a public API, schedule it with cron, and version everything in Git with a real pull request and merge.
That project is intentionally small.
But it forces the right habits:
Linux commands.
Package management.
Services.
Networking basics.
Python automation.
Git workflow.
Documentation.
If I cannot do that cleanly, I have no business rushing into advanced cloud topics.
Phase 2: Core AWS
Phase 2 is where AWS becomes the main platform.
The goal is to become productive across compute, storage, networking, and identity, then sit the AWS Solutions Architect Associate exam.
The main topics:
VPCs, subnets, route tables, internet gateways, NAT, security groups.
EC2, Auto Scaling, load balancers, Spot, capacity options.
S3, EBS, RDS, DynamoDB, ElastiCache.
IAM users, roles, policies, MFA, federation, least privilege.
CloudFront, Route 53, VPN, backup, lifecycle policies.
The sources:
AWS Skill Builder Cloud Practitioner Essentials.
Andrew Brown / ExamPro CLF-C02.
Stephane Maarek CLF-C02 and SAA-C03.
Adrian Cantrill AWS Tech Fundamentals and SAA-C03.
Tutorials Dojo practice exams.
Be A Better Dev for VPC and DynamoDB.
Coursera Amazon S3 Deep Dive.
The project:
Build a three-tier AWS web app:
VPC with public and private subnets.
ALB to an Auto Scaling group of EC2 instances.
RDS Multi-AZ.
S3 and CloudFront for static assets.
Secrets Manager.
Least-privilege IAM roles.
Architecture diagram.
Cost estimate.
This is where the plan becomes serious.
Passing an exam is useful. But being able to explain why a subnet is private, why a database is Multi-AZ, how IAM roles protect credentials, and how traffic moves from the user to the app is far more useful.
Phase 3: Containers And Orchestration
Once the AWS foundation exists, the next phase is containers.
Not because Kubernetes is trendy.
Because modern cloud work often means packaging, deploying, scaling, and operating workloads repeatably.
Topics:
Docker images.
Containers.
Volumes.
Networks.
Compose.
Registries.
Image scanning.
Kubernetes control plane.
Worker nodes.
Pods.
Services.
ConfigMaps.
Secrets.
Namespaces.
Persistent volumes.
ECR, ECS, EKS, Fargate.
Sources:
TechWorld with Nana Docker and Kubernetes.
KodeKloud.
Bret Fisher Docker Mastery.
Docker official docs.
Mumshad Mannambeth CKA/CKAD material.
Kubernetes official docs.
Kubernetes The Hard Way.
The project:
Containerize the Phase 2 app, scan the image with Trivy, push it to ECR, and deploy it to EKS with namespaces, ConfigMaps, Secrets, persistent volumes, ALB Ingress, and HPA scaling.
This is not about saying "I know Kubernetes."
It is about understanding what actually changes when an app moves from a server to a container platform.
Phase 4: Infrastructure As Code And Automation
Manual cloud work is useful when learning.
It is dangerous when repeated.
Phase 4 is about turning the earlier AWS environment into code.
Topics:
Terraform.
State.
Modules.
Providers.
Dependencies.
Credentials.
CloudFormation.
CDK.
boto3.
AWS SDK sessions, paginators, waiters, retries, and tagging.
Sources:
HashiCorp Learn.
DevOps Directive Terraform.
Stephane Maarek CloudFormation.
AWS CDK Workshop.
boto3 docs.
Real Python boto3.
freeCodeCamp boto3 automation.
The project:
Rebuild the Phase 2 environment in Terraform with modules for networking, compute, data, and IAM. Add one CloudFormation stack. Then write a boto3 script that tags untagged resources and snapshots non-prod RDS instances.
This phase is where I expect a lot of real learning to happen.
Terraform state, IAM permissions, drift, dependencies, credentials, and module design are the parts that do not feel obvious until you break something and have to reason your way out.
Phase 5: Security, CI/CD, Reliability, Architecture
The final phase is about production thinking.
Not just "can I deploy it?"
Can I secure it, observe it, recover it, reason about its cost, and improve it safely?
Topics:
Encryption at rest and in transit.
Secrets management.
GuardDuty, Inspector, Macie, Config, Security Hub.
GitHub Actions, Jenkins, AWS CodePipeline.
Monitoring and observability.
SLOs.
Rollback.
Disaster recovery.
AWS Well-Architected.
Reference architectures.
Sources:
Adrian Cantrill AWS Security Specialty.
Stephane Maarek Security Specialty.
AWS Security Docs.
AWS Ramp-Up Guide: Security.
TechWorld with Nana GitHub Actions.
freeCodeCamp Jenkins.
Google SRE Book and SRE Workbook.
AWS Well-Architected Framework and Labs.
AWS Architecture Center.
The project:
Add CI/CD to the Terraform repo:
`fmt`, `validate`, `tflint`, and `plan` on pull requests.
Apply on merge.
Container image scanning with Trivy.
Push to ECR.
Blue-green deployment.
CloudWatch dashboards and alarms.
GuardDuty, Security Hub, and Config rules.
Rollback and disaster recovery runbook.
This is the point where cloud learning stops being a course path and starts becoming operational judgment.
The Data Center Branch
There is a second track in my vault: data center operations.
That came from preparing for an AWS Data Center Technician / DCO role.
I interviewed, got rejected, and learned something useful:
The interview was not just technical.
It was mostly behavioral, structured around Amazon Leadership Principles, with hardware and networking troubleshooting layered in.
That experience changed how I think about cloud learning.
Cloud is not only services in a console. It is physical infrastructure, power, cooling, cabling, hardware, safety, tickets, SLAs, and people working shifts to keep everything alive.
So the data center branch includes:
AWS Academy Engineering Operations Technician.
AWS Academy Data Center Technician.
Schneider Electric Energy University DCCA.
Electrical fundamentals.
Low voltage systems.
HVAC fundamentals.
CompTIA Server+.
Network+.
CCNA.
CDCP and CDCTP as longer-term options.
The notes cover:
Reliability, availability, redundancy.
Data center tier levels.
White space.
Racks.
Power path from grid to server.
UPS, PDU, generators.
Cooling loops.
Fire protection.
Physical security.
Support spaces.
Hardware troubleshooting.
Fiber and network basics.
Safety and escalation.
This branch makes the AWS path feel less abstract.
When I study EC2, I also want to understand the physical server mindset behind it.
When I study availability zones, I want to understand why redundancy, power, cooling, and maintenance procedures matter.
When I study cloud reliability, I want to connect it to the people and infrastructure underneath.
What I Am Tracking Now
My course tracker currently shows:
AWS Cloud Practitioner: in progress, 60%, exam booked for June.
Python 100 Days of Code: in progress, 45%, focused on OOP and APIs.
AWS Solutions Architect Associate: planned after Cloud Practitioner.
Docker and Kubernetes: planned after Python.
Technical Writing for Cloud: planned from May through August.
That last item matters.
Writing is not separate from learning.
If I cannot explain what I learned, I probably do not understand it well enough.
My notes, diagrams, LinkedIn posts, Substack essays, GitHub READMEs, and project docs are part of the system.
What I Am Ignoring For Now
This is just as important as the plan.
I am not trying to do everything at once.
The cybersecurity roadmap in my vault is useful, but it is not the main path right now.
AI/ML is interesting, but it does not come before AWS fundamentals.
Advanced Kubernetes does not come before networking.
Professional-level certifications do not come before projects.
The filter is simple:
Does this make me more useful in cloud infrastructure within the next few months?
If yes, it can stay.
If no, it waits.
The Real Expectation
This plan will not be easy.
630 hours is a lot.
Thirty hours per week means studying almost like a second job. It means fewer random tutorials, fewer abandoned courses, and more repetition than I probably want.
But the structure is clear:
Learn the foundation.
Build the project.
Document the project.
Test the knowledge.
Turn the learning into public proof.
That loop matters more than the exact course list.
The Takeaway
If you are learning cloud, my strongest advice is this:
Do not start by asking, "What certification should I take?"
Start by asking:
What role am I aiming for?
What systems do I need to understand?
What projects will prove I can work with them?
What topics should I delay?
How will I track progress?
How will I explain what I learned?
A good learning path is not a pile of resources.
It is a sequence of decisions.
Mine is now:
Linux and networking first.
AWS core next.
Containers after that.
Infrastructure as code after that.
Security, CI/CD, reliability, and architecture once the base is real.
And through all of it: notes, projects, documentation, and public proof.
That is the path I am building.
I will share what works, what breaks, and what I would change as I move through it.
---
References from my vault:
roadmap.sh Cloud Engineer roadmap.
AWS Skill Builder.
Linux Foundation LFS101.
The Linux Command Line.
Professor Messer Network+.
Practical Networking.
Cisco Networking Basics.
Automate the Boring Stuff with Python.
Pro Git.
Adrian Cantrill AWS courses.
Stephane Maarek AWS courses.
Tutorials Dojo.
HashiCorp Learn.
Docker, Kubernetes, and AWS documentation.
Google SRE books.
AWS Well-Architected Framework.