The Cloud Leader Course

From zero knowledge to fluently leading a team of cloud engineers.

How this course works

You are not training to be a cloud engineer. You are training to lead cloud engineers: to follow every conversation in the room, ask the questions that matter, make good decisions about money, risk, and people, and earn the respect of experts without pretending to be one. That is a different, entirely learnable skill — and it is the skill this course teaches.

The course has three stages. Stage 1 (Weeks 1–8): Speak the language. You learn what the cloud actually is and the vocabulary of every core building block, so meetings stop sounding like noise. Stage 2 (Weeks 9–16): Think like the room. Architecture, security, and money — the three conversations every cloud team has every week, and the three where a leader either adds value or gets ignored. Stage 3 (Months 5–24): Lead. Certifications, hiring, running decision meetings, and the honest two-year path to holding your own with senior engineers.

Rules for the whole course: study one hour a day, six days a week — consistency beats intensity. Every module ends with a Fluency Drill (things you say out loud until they’re natural) and a Milestone (proof you’re ready to move on). Do them; reading alone builds recognition, not fluency. And from Week 1, keep a Decision Journal: every time you learn a concept, write one sentence on how it affects money, risk, or people — because that translation is your entire job.

STAGE 1 — SPEAK THE LANGUAGE (Weeks 1–8)

Module 1 (Weeks 1–2): What the cloud actually is

The big idea: The cloud is someone else’s computers, rented by the hour, managed by software. Before cloud, a company bought physical servers, put them in a room, and paid people to maintain them — slow, expensive, inflexible. AWS, Microsoft Azure, and Google Cloud built warehouses of millions of computers (data centers) and let anyone rent slices of them per second, from anywhere, through a webpage or a line of code. That’s it. Everything else in this course is detail on top of that one idea.

The big three providers, defined:

Your free AWS account — set this up in Week 1. Go to https://aws.amazon.com/free and click “Create a Free Account” (the direct sign-up page is https://signin.aws.amazon.com/signup?request_type=register). You’ll need an email address, a phone number, and a credit/debit card for identity verification — the Free Tier gives you a monthly allowance of the basic services free (including 750 hours/month of a small EC2 server your first year), and this course’s exercises stay inside it. Two safety habits from day one: turn on MFA (Module 6 explains it) and set a billing alert at $5 (Module 7 explains how) so you can never be surprised. After sign-up you log in at https://console.aws.amazon.com — the “console” is simply AWS’s control webpage.

Why companies use the cloud: speed (a new server in 60 seconds instead of 6 weeks), elasticity (rent 100 servers for the big sale day, give back 90 the day after), no upfront cost (operating expense instead of capital expense), and global reach (put your app near your customers in Bangkok, Tokyo, and Frankfurt without building anything).

The three service layers — the most useful mental model in cloud:

Regions and availability zones: a Region is a geographic cluster of data centers (Thailand has its own AWS Region as of January 2025, in and around Bangkok). An Availability Zone (AZ) is one or more isolated data centers inside a region. Apps that matter run in at least two AZs, so one building’s failure doesn’t take them down. When engineers say “we’re multi-AZ,” they mean “one data center can burn down and we stay up.”

Vocabulary:

Videos for this module (all free, links verified):

Fluency drill — say these until natural: “Is that workload on-prem or in the cloud?” · “Which region are we in — and are we multi-AZ?” · “Is this an IaaS approach or is there a managed service that removes the maintenance?”

Exercises: (1) Create your free AWS account at https://aws.amazon.com/free — the sign-up flow itself teaches you more vocabulary than a chapter of reading. (2) Watch the four videos in the table above (under 20 minutes total). (3) In your journal: write the elevator explanation of cloud you’d give a Thai school director in one breath.

Milestone: you can explain IaaS vs PaaS vs SaaS with your own analogy, and explain why AWS opening a Bangkok region mattered to Thai banks (answer: latency + data residency — see Module 6).

Module 2 (Weeks 3–4): The building blocks — compute, storage, and databases

Compute — the engines that run code. A virtual machine (VM/instance) is a slice of a physical server that behaves like a whole computer; you pick a size (CPU/RAM) and pay per second it runs. A container is a lighter, faster way to package one application so it runs identically anywhere; Docker packages them and Kubernetes (K8s) orchestrates fleets of them — when you hear “K8s,” think “the system that runs and heals our hundreds of containers automatically.” Serverless (AWS Lambda) means you upload only a function of code; the cloud runs it when triggered and you pay per invocation — no servers to manage at all. The pattern to notice: VM → container → serverless is a slider from “more control, more maintenance” to “less control, near-zero maintenance.” Good teams pick per workload, not by fashion.

Storage — three shapes. Object storage (Amazon S3): a bottomless bucket for files — images, videos, backups, datasets; cheap, eleven-nines durable, the default answer to “where do we put files?” Block storage (EBS): the virtual hard disk attached to a VM. File storage (EFS): a shared drive many machines mount at once. Then tiers: hot (frequent access, costly) vs cold/archive (Glacier — cheap, slow) — moving old data to cold tiers is one of the easiest cost wins any team can ship.

Databases — two families. Relational/SQL (MySQL, PostgreSQL; managed as Amazon RDS/Aurora): data in tables with strict structure; the default for money, orders, users — anything where correctness is sacred. NoSQL (DynamoDB, MongoDB): flexible, massively scalable; the default for huge, fast, simpler-shaped data (sessions, catalogs, feeds). “Managed database” means the provider handles backups, patches, and failover — teams should have a strong reason to run their own.

Vocabulary:

Videos for this module:

Fluency drill: “Should this run on VMs, containers, or serverless — and what’s the operational cost of each choice?” · “Is that data hot or can it go to a cheaper tier?” · “Why are we self-managing that database instead of using RDS?”

Exercises: (1) In your free account: launch the smallest EC2 instance, then terminate it. Upload a file to S3. You have now personally used IaaS. (2) Ask an AI assistant to quiz you: “Give me 10 scenarios; I’ll answer VM, container, or serverless, and you grade me.”

Milestone: given any simple app described in one sentence (“a website where students order lunch”), you can name its compute, storage, and database pieces out loud in 60 seconds.

Module 3 (Weeks 5–6): Networks, and how the pieces talk

The VPC — your private neighborhood. A Virtual Private Cloud is your own fenced-off section of the provider’s network. Inside it are subnets — public ones (reachable from the internet, e.g., web servers) and private ones (unreachable, e.g., databases). The single most common security sentence you’ll hear: “the database sits in a private subnet.” If you understand why — attackers can’t touch what has no path from the internet — you understand half of network security.

The traffic layer: a load balancer spreads incoming traffic across multiple servers (and quietly removes the sick ones); DNS (Route 53) translates names like yourcompany.com into addresses; a CDN (CloudFront) caches your content in hundreds of cities so it loads fast everywhere; an API is the doorway one piece of software offers another — when engineers say “we’ll expose an API,” they mean “we’ll give other software a controlled way to use ours”; an API gateway is the front desk that manages those doorways.

Connecting worlds: VPN (encrypted tunnel over the internet) or Direct Connect (a private physical line) links a company’s offices/on-prem systems to its cloud. Hybrid cloud = running both on-prem and cloud (most Thai enterprises); multi-cloud = using more than one provider.

Vocabulary:

Video for this module: AWS Networking Basics — VPC & Subnets for Beginners — KodeKloud — https://www.youtube.com/watch?v=QM63dyA_4Pc (watch the first half now; return for the rest after Module 5).

Fluency drill: “Is the database in a private subnet?” · “What happens when one web server dies — is the load balancer health-checking?” · “Are we exposing that as an API or is it internal only?”

Exercises: (1) Have an AI walk you through drawing, on paper, the network of a food-delivery app: users → CDN → load balancer → web servers (public subnet) → database (private subnet). Draw it three times until you can do it from memory. (2) Find your company’s or any sample architecture diagram and circle every box you can now name.

Milestone: you can sketch that standard three-tier diagram on a whiteboard and narrate the path of one customer’s click through it.

Module 4 (Weeks 7–8): How cloud teams work — DevOps, IaC, and reading the room

DevOps is the culture of merging “the people who write software” (Dev) and “the people who run it” (Ops) into one team that ships small changes frequently and safely, with automation doing the heavy lifting. Its heartbeat is the CI/CD pipeline: every code change is automatically built, tested, and deployed (Continuous Integration / Continuous Delivery). When a team says “it’s in the pipeline,” they mean the robot is testing and shipping it.

Infrastructure as Code (IaC) — the idea that changed everything: instead of clicking around a console to create servers, engineers write text files that declare the infrastructure (“two servers, one load balancer, one database, these firewall rules”), and a tool (Terraform, CloudFormation) makes reality match the file. Why leaders care: the files live in Git (version control), so every infrastructure change is reviewed, reversible, and auditable — the difference between a workshop and a factory.

The rituals you’ll sit in: stand-up (daily 15 minutes: what’s done, what’s next, what’s blocked — listen for blockers; removing them is your job), sprint (a 1–2 week unit of planned work), retro (what to improve), post-mortem/incident review (after an outage: blameless analysis of what failed and what will prevent it — the health of a team shows in whether these are honest), on-call (the rotation of who gets woken at 3 a.m.; if on-call is miserable, your best people will leave — ask about it monthly).

The health metrics that matter: uptime/availability (“three nines” = 99.9% ≈ 8.8 hours down/year; each extra nine multiplies cost), SLA (the promise, with penalties), SLO (the internal target), MTTR (how fast you recover — mature teams optimize recovery, not the fantasy of zero failures), deployment frequency (healthy teams ship small changes often; fear of deploying is a smell).

Vocabulary:

Videos for this module:

Fluency drill: “Is that change through the pipeline or was it manual?” · “What did the post-mortem conclude, and what’s the prevention item?” · “What’s our MTTR trending like?” · “Is this in Terraform, or did someone click it into existence?” (the latter is called “ClickOps,” said with a frown).

Exercises: (1) Watch one real incident post-mortem write-up being discussed (many are public — Cloudflare’s and AWS’s outage reports are famous) and summarize it in your journal in five sentences. (2) Sit in (or watch a recording of) any stand-up and write down the three blockers you heard.

Milestone — end of Stage 1: you can sit through a 30-minute technical planning meeting and follow ≥80% of it, and your journal proves it: notes from one real or simulated meeting with every acronym correctly expanded. This is also when you should schedule the AWS Cloud Practitioner exam (CLF-C02) — 2–4 focused weeks of prep on top of these modules is the published norm, and passing it is your first external proof.

STAGE 2 — THINK LIKE THE ROOM (Weeks 9–16)

Module 5 (Weeks 9–10): Architecture — judging designs without drawing them

Your role in a design review is not to design — it is to interrogate. The framework the whole industry uses is AWS’s Well-Architected Framework, six pillars every design should answer to: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability. Learn the bold three deeply; they’re where the money and risk live.

Reliability, in plain words: everything fails eventually, so good systems assume it. Redundancy (no single point of failure — two of everything important), multi-AZ (survive a data-center loss), auto-scaling (machines added/removed automatically with demand), backups that are tested (an untested backup is a hope, not a plan), RTO/RPO (Recovery Time Objective: how long can we be down; Recovery Point Objective: how much data can we lose — these two numbers are the disaster-recovery conversation, and they are business decisions, i.e., yours).

The trade-off triangle: fast, cheap, resilient — pick two. Every architecture argument you will ever referee reduces to where on that triangle the business needs to sit for this workload. A payment system and a marketing site do not deserve the same answer.

The leader’s seven questions — memorize these; they make you dangerous in any design review:

1. “What happens when this component fails?” (there is always a “when”)
2. “What are the RTO and RPO, and who signed off on them?”
3. “Where does this run — single AZ, multi-AZ, multi-region — and why?”
4. “What will this cost per month at 10× today’s load?”
5. “What’s the simplest version that meets the requirement?” (over-engineering is the junior disease; simplicity is the senior virtue)
6. “What are we locked into, and what would leaving cost?” (vendor lock-in is a price, sometimes worth paying — knowingly)
7. “Who else has built this before — are we inventing or assembling?” (prefer boring, proven patterns)

Fluency drill: practice delivering questions 1, 4, and 5 in a warm tone — they land as wisdom or as attack depending entirely on delivery. “Help me understand what happens if the cache goes down” beats “did you think about failure?”

Exercises: (1) Take three sample architectures (ask an AI to generate: an e-commerce site, a mobile-app backend, a data-analytics platform) and run all seven questions against each, writing the answers you’d expect. (2) Read the one-page summary of the Well-Architected pillars at https://aws.amazon.com/architecture/well-architected/.

Videos for this module:

Milestone: in a mock design review (do it with an AI playing the engineer), you ask five substantive questions and correctly summarize the design’s weakest point at the end.

Module 6 (Weeks 11–12): Security and compliance — the conversation that can end companies

The shared responsibility model — the first thing to understand: the provider secures the cloud itself (buildings, hardware, hypervisors); you secure what you put in it (your data, access rules, configurations). Most breaches are customer misconfigurations — an S3 bucket left public, a leaked access key — not provider failures. So “AWS is secure” and “we are secure on AWS” are different sentences.

The vocabulary of defense: IAM (Identity and Access Management — who may do what; the single most audited thing in cloud), least privilege (everyone gets the minimum access needed — the golden rule), MFA (second factor on every human login — non-negotiable), encryption at rest and in transit (data scrambled on disk and on the wire — table stakes, always on), root account (the master key — locked away, never used daily), secrets management (passwords/keys in a vault, never in code), zero trust (verify everything, trust no network location by default), penetration test (hired attackers proving your defenses), ransomware (why tested, offline backups are a security control, not just an ops control).

PDPA — Thailand’s data law, and your market advantage. The Personal Data Protection Act is Thailand’s GDPR: consent required for collecting personal data, a 72-hour breach notification duty, Data Protection Officers for large-scale processors, and rules on sending data across borders. Enforcement became real in 2025 — over THB 21.5M in first fines, including a hospital fined for poorly supervising a vendor. Two consequences for you: (1) every Thai enterprise now has a compliance problem your company can be paid to manage; (2) data residency — keeping Thai data on Thai soil — is a real driver pushing workloads into the Bangkok regions. This paragraph is half of your sales pitch in Thailand; know it cold.

The leader’s security questions: “Who has access to production, and when did we last review the list?” · “Are we alerted on unusual access, or would we find out from the news?” · “When did we last restore a backup?” (not “do we have backups”) · “If we lost this dataset, is it a PDPA-notifiable breach — and could we notify within 72 hours?” · “What did the last pen test find, and what’s still open?”

Vocabulary:

Video for this module: The AWS Shared Responsibility Model — Digital Cloud Training — 4 min — https://www.youtube.com/watch?v=ESPBBEK-cvo

Fluency drill: “Is that bucket public? Why?” · “Least privilege — does the intern really need prod access?” · “Where does the PDPA line sit in this design — what’s personal data here and where does it physically live?”

Exercises: (1) Read one famous cloud-misconfiguration breach story (Capital One 2019 is the classic) and write the three-sentence version for your journal. (2) Have an AI simulate a customer asking “why should I trust you with my data?” and practice the answer using shared-responsibility + PDPA language.

Milestone: you can explain the shared responsibility model and PDPA’s practical meaning to a non-technical Thai business owner in under three minutes — because that explanation is the MSP sales meeting.

Module 7 (Weeks 13–14): The money — cloud economics and FinOps

This is where a non-engineer leader adds value fastest, because most engineers were never taught it and the waste is enormous — surveys consistently find roughly a third of cloud spend is wasted.

How the meter runs: compute is billed per second it’s on (not per use — an idle server bills fully; “we left it running” is the classic waste), storage per GB-month, and — the famous trap — egress: data flowing out of the cloud costs money while data in is free. Large egress bills surprise everyone once; after this module, not you.

The pricing menu: on-demand (full price, full flexibility) · reserved instances / savings plans (commit 1–3 years for 30–70% off — the single biggest lever on a steady workload) · spot instances (up to 90% off for interruptible work like batch jobs) · rightsizing (most servers are over-provisioned; shrinking them is free money) · storage tiering (Module 2) · auto-scaling as a cost tool (why pay for midnight capacity at noon prices?).

FinOps is the practice of making cloud spend visible, allocated, and optimized continuously: tagging every resource with its owner and project (untagged spend is unaccountable spend), showback/chargeback (showing each team its bill — behavior changes instantly), budgets with alerts (never discover overspend from the invoice), and unit economics — the leader’s metric: not “our bill is ฿800k/month” but “our cost per customer transaction is falling.” The FinOps Certified Practitioner credential takes about two weeks and is, for a business-side leader, the highest-credibility-per-hour certificate in the entire cloud world. Get it.

The leader’s money questions: “What’s our cost per [customer/transaction/tenant], and which direction is it moving?” · “What percentage of our steady workload is on reservations?” · “What’s untagged?” · “What died but is still billing?” (orphaned disks and idle IPs — every account has them) · “What would this bill look like at 10× growth — does our architecture get cheaper or more expensive per unit?”

Vocabulary:

Video for this module: What is FinOps? — FinOps Foundation (official) — 2 min — https://www.youtube.com/watch?v=Y-c_xw9bHFw · then the free “Introduction to FinOps” course at https://learn.finops.org.

Exercises: (1) Open the AWS pricing calculator and price a small real system (two servers, a database, 500GB storage, 1TB egress) — the exercise of doing it once demystifies every future cost conversation. (2) Ask an AI to roleplay an engineer defending an oversized server; practice negotiating the rightsizing kindly.

Milestone: take (or schedule) the FinOps Practitioner exam, and in a mock review, find four cost problems in a sample bill an AI generates for you.

Module 8 (Weeks 15–16): Fluency bootcamp — putting the language together

This fortnight is pure integration — the difference between knowing words and being fluent in meetings.

Daily drill (30 min): have an AI generate a realistic meeting transcript (design review, incident retro, or cost review), with two deliberate technical errors buried in it. Your job: summarize the meeting in five sentences, catch the errors, and write the three questions you’d have asked. Alternate meeting types daily.

The translation muscle (15 min): take one technical statement per day and translate it for three audiences — the CFO (money), a customer (risk/benefit), and a new junior engineer (teaching). Example: “We’re moving the session store from the database to Redis” → CFO: “cuts database load so we defer a ฿2M upgrade” → customer: “pages load faster at peak” → junior: “Redis keeps hot data in memory, so we stop hammering the database for every click.”

Reading practice (15 min): one real engineering blog post per day (AWS Architecture Blog, or the engineering blogs of Netflix/Grab — Grab is especially relevant: Southeast Asian scale, Thai-adjacent market). You will now understand 70–80% of them. Look up the rest.

Your exam-prep companion for this stage: the famous free full course — AWS Certified Cloud Practitioner (CLF-C02) 2026 by Andrew Brown on freeCodeCamp — https://www.youtube.com/watch?v=7HKot-brXFE (the earlier 14-hour edition, also valid for the same exam code, is at https://www.youtube.com/watch?v=NhDYbskXRgc). Watch it at 1.25× across Weeks 13–16; after Modules 1–7 most of it will feel like revision, which is exactly the sign you’re ready.

Milestone — end of Stage 2, your graduation exam: (1) Pass the AWS Cloud Practitioner if you haven’t yet. (2) The mock gauntlet: an AI plays a senior engineer walking you through a flawed architecture for a Thai e-commerce client; you must find the single-AZ database, the public S3 bucket, the missing egress estimate, and the absent PDPA consideration — and deliver the feedback in a tone that makes the “engineer” feel helped, not caught. When you can do that, you are conversationally dangerous, sixteen weeks in.

STAGE 3 — LEAD (Months 5–24)

Module 9 (Months 5–8): The deep certification and the technical floor

Work through AWS Solutions Architect Associate (SAA-C03) material — 2–3 months at your one-hour pace. You may or may not sit the exam (as a leader, the material is the value; the badge is optional theater), but this is where regions, VPCs, IAM, and pricing stop being vocabulary and become a connected system in your head. In parallel, keep the Module 8 daily drills at half dose. This is also the window to add Azure fundamentals (AZ-900 level) — Thailand is a Microsoft-heavy enterprise market, and bilingual (AWS+Azure) literacy widens your customer conversations.

Module 10 (Months 5–12, running continuously): Hiring and managing engineers

Hiring when you can’t fully judge the skill: structure beats instinct. Use a consistent loop: a screening conversation you lead (motivation, communication, how they explain a past project to a non-engineer — if they can’t, they’ll fail your customers too) + a technical interview conducted by your bar-raiser (your technical #2 or a paid senior contractor) + a reference call where you ask exactly one question that matters: “would you hire this person again for this role?” Watch for the two failure archetypes: the fluent talker with no depth (your bar-raiser catches them) and the deep-but-silent expert (often gold in Thai teams, where modesty is cultural — don’t let interview polish outweigh evidence of real work).

The technical #2 — the most important decision of the venture: hire them first, pay with meaningful equity (10–20% if a true co-founder), and define the deal explicitly: they hold the technical bar and own architecture decisions; you own customers, money, priorities, and people; disagreements between you happen in private and resolve before the team sees them.

The rituals that make engineers stay: weekly or biweekly 1:1s that are about them (career, friction, energy — not status updates); a written growth path per person (in Thailand’s 70k/year talent-shortage market, growth and certification budgets retain better than salary alone — pay for every cert, with a 12-month vesting bonus on completion); public credit, private correction; and ruthless protection of their focus time — a leader who cancels a sprint-mid meeting is a hero.

Decision forums — how you make technical calls you can’t fully evaluate: for any big decision, require a one-page decision doc from the proposing engineer: the problem, 2–3 options, costs, risks, recommendation. Then run the meeting with your seven questions from Module 5. You are not the smartest architect in the room and never need to be — you are the person who makes the best-argued option win, on schedule, with the money and risk trade-offs made explicit. Engineers deeply respect this when it’s done honestly; write down who predicted what (your Decision Journal again) and review predictions quarterly — it calibrates both you and them.

Module 11 (Months 6–24): The credibility curve, honestly

Published experience from engineering-leadership literature converges on this timeline, and pretending otherwise is how non-technical founders fail: ~90 days to run the business rhythm competently · ~6 months to baseline effectiveness (meetings fluent, decisions structured, team stable) · 12–18 months before your technical instincts are independently worth much · ~2 years before you genuinely hold your own with senior engineers on architecture trade-offs. The mitigations while the curve climbs: borrow credibility (your #2 presents the technical half of sales meetings — customers need to see the bench anyway), never bluff (the fastest credibility-killer; “I don’t know — walk me through it” is a leadership sentence), and let your questions do the talking: a leader asking “what’s our RPO and who signed off on it?” sounds like thirty years of scars, and after this course, you’ll mean it.

Module 12 (Ongoing): The Thai-market layer

Fold in the specifics from TSI Part 5 as operating knowledge: PDPA as both compliance duty and product (§Module 6); the partner ladders (AWS Select needs a handful of certified staff + 3 launched deals; Microsoft Solutions Partner needs a 70/100 capability score — your team’s certifications are literally sales assets, which is another reason to fund them); BOI promotion for 100% foreign ownership of the company; Bangkok salary bands (junior ฿50–75k → architect ฿180–280k/month) so you price bids and offers correctly; and the sales math of the moment — $27B+ of approved data-center investment, a government cloud-first mandate, and a 70,000/year skills gap that your certified bench exists to fill.

The one-page syllabus

A closing word from your teacher. Sixteen weeks from now you will follow every conversation in the room. That is not the finish line — it’s the license to start. The two-year curve to real technical judgment is not a wall; it is a moat: every week of it you complete is a week your competitors’ non-technical founders didn’t. Study daily, journal every decision, never bluff, and hire people better than you and make them glad they came. That is the whole job.

Companion to “The Thailand Strategic Investment (TSI),” Part 5. Certification prep-time estimates and leadership timelines are drawn from the sources cited there (CBT Nuggets, StudyTech, FinOps Foundation, First Round Review, The Pragmatic Engineer).