A team I worked with had a simple setup: one small API, a Postgres database, and a couple of cron jobs. They ran it on a single virtual machine that cost about $40 a month. Then someone read an article about serverless and rewrote the whole thing on managed functions, a managed database, a message queue, and an API gateway. Two months later the bill was near $600 — not because serverless is expensive, but because they had moved a steady, predictable workload onto a model priced per request and per second of execution, and nobody was watching the logs. The architecture got more modern. The economics got worse. For a deeper dive into this topic, see Terraform & IaC.
That story is the whole reason cloud architecture is worth learning properly. It is not a list of services to memorise. It is a set of trade-offs — between managed and self-run, between per-request and per-hour, between convenience and lock-in — and the person who can see those trade-offs before writing the first line of infrastructure code saves money and sleep. For a deeper dive into this topic, see DevOps & Cloud.
What actually changes when you move to the cloud
On your own hardware, capacity is a purchase. You buy a server, it sits there, and it costs the same whether it serves one request or a million. In the cloud, capacity is a rate. Every design decision becomes a decision about what you pay per unit of time or per unit of work, and that changes how you think.
Three things follow from this, and they are the real content of the discipline:
- Elasticity is a design choice, not a default. Auto Scaling and managed load balancers only help if your application can run as more than one copy. A monolith that keeps sessions in local memory and writes files to local disk cannot scale horizontally no matter how many instances you add.
- Managed services shift the failure surface. A managed database removes patching and backup plumbing from your plate, but it also removes your ability to tune the engine at the kernel level and adds a per-hour premium on top of the raw compute.
- Identity is the new perimeter. In a data centre you defend a network edge. In the cloud, IAM policies — on AWS, Google Cloud, and Entra ID on Azure — decide who can do what, and a single over-broad role is a bigger risk than an open port.
One walkthrough: a public API that must survive a traffic spike
Take a concrete task: an API that serves product data, normally 20 requests per second, with a marketing campaign that will push it to 400 for a few hours. How a practitioner actually decides, in order.
Step 1 — pick the compute model by the shape of the load. For a workload that is idle most of the day and spikes hard, functions (Lambda, Cloud Functions) or a container service that scales to zero are attractive: you pay almost nothing at idle. For a workload that is busy around the clock, reserved instances or committed-use discounts on a fixed fleet are cheaper per hour. The mistake is choosing the model by what is fashionable rather than by the load curve.
Step 2 — decide where state lives. If the app keeps sessions in memory, scaling out means users get logged out when they hit a different instance. Move sessions to a shared store or make the API stateless with tokens. This one decision often determines whether autoscaling works at all.
Step 3 — put the database behind a connection budget. A managed relational database has a maximum number of connections. Ten instances each opening 50 connections will exhaust it. The fix is a connection pooler or a serverless-friendly database tier — and this is exactly where a design that looks fine on a laptop collapses under a spike.
Step 4 — cache at the edge, not only in the app. A CDN (CloudFront, Cloud CDN) in front of static and cacheable responses cuts origin load dramatically. If 80% of those 400 requests per second are for the same product pages, a CDN turns them into a rounding error at the origin.
Step 5 — set the scaling policy and the alarm before launch, not after. Target-tracking on CPU or request count, plus a budget alarm, is the minimum. Without the alarm, the first sign of trouble is the invoice.
Do the steps in a different order — say, autoscale first and worry about connections later — and you get a spike that takes the database down while every instance reports healthy. The instance health check passes; the app is dead. That gap between infrastructure health and application health is one of the most common blind spots.
The provider question: AWS vs Google Cloud vs Azure
People spend weeks on this and usually the answer is less dramatic than they expect. The three providers overlap on the fundamentals — virtual machines, object storage, managed SQL, functions, Kubernetes, identity, CDN — and differ mainly in emphasis and in the ecosystem around them.
| Criterion | AWS | Google Cloud | Azure |
|---|---|---|---|
| Breadth of services | Widest; almost any pattern has a native option | Strong in data and analytics (BigQuery) | Strongest if you already live in Microsoft tooling and Entra ID |
| Managed Kubernetes | EKS | GKE, often considered the smoothest | AKS |
| Identity model | IAM policies and roles | IAM, resource hierarchy by project | Entra ID, familiar to enterprise IT |
| Where it tends to win | General-purpose, large ecosystems, hiring pool | Data-heavy workloads, Kubernetes-first teams | Enterprises with existing Microsoft agreements |
What actually decides it in practice, in rough order of weight:
- What your company already pays for. An existing enterprise agreement or committed spend usually outweighs a feature preference.
- Where your team's knowledge is. A team fluent in one provider will ship faster on it than on a marginally better fit they have never touched.
- The specific managed service you need. If your product is analytics-heavy, BigQuery is a genuine argument. If your identity lives in Entra ID, Azure reduces friction.
Multi-cloud is the option people overestimate. Running the same workload on two providers doubles the operational surface and the skills required, and it rarely delivers the resilience people imagine unless the workload was designed for it from the start. The honest version of avoiding lock-in is not "use three clouds" — it is keeping your architecture portable at the seams: containers instead of proprietary runtimes, standard SQL where you can, Terraform instead of clicking in a console, and object storage behind your own abstraction. For the cost side of these decisions, FinOps — Cloud Cost Optimization is the right next read. For a deeper dive into this topic, see DevOps and Cloud Infrastructure.
Serverless vs containers vs virtual machines
This is the comparison that trips up the most people, because all three can run the same code and the difference only shows up at scale and on the bill.
Virtual machines give you full control and a flat per-hour price. You patch the OS, you manage the runtime, you own the failure modes. Right choice for legacy software, for workloads with unusual kernel needs, and for steady load where a reserved instance is the cheapest option.
Containers with orchestration (ECS or EKS on AWS, GKE on Google Cloud, AKS on Azure) sit in the middle: you package the app once, scale it horizontally, and let the platform handle scheduling. The cost is operational complexity — a Kubernetes cluster is a system you have to run, with its own upgrades, networking, and service mesh if you go that far.
Serverless functions are the cheapest option at low and spiky volume and the most constrained: execution time limits, cold starts, no persistent local state, and a pricing model that punishes long-running work. The failure modes here are specific enough that they deserve their own treatment — Serverless Architecture: Where Lambda and Cloud Functions Break goes through them in detail.
Where people actually go wrong
Over-broad IAM from day one. Someone grants an admin role to a service account "to unblock the deploy", and it stays. Six months later nobody knows which role is actually needed. The fix is boring and effective: start from a minimal policy, add permissions as errors appear, and review roles on a schedule.
Ignoring the data layer until it hurts. The application scales beautifully; the database is a single instance with no read replicas and no connection pooling. This is the most common production incident in cloud systems, and it is entirely predictable. If you are designing around relational data, SQL & Databases: How to Learn to Work with Databases covers the indexes and design decisions that decide whether the database survives the load.
Networking by default settings. A VPC with everything in public subnets, or security groups that allow 0.0.0.0/0 on a management port, is a breach waiting for a scanner to find it. Private subnets for anything that does not need to face the internet, and a bastion or session manager for access, is the baseline.
No tagging discipline. Without consistent tags you cannot answer "what does this team's environment cost?" — and cost optimisation becomes guesswork. Tags are cheap to add at creation and painful to reconstruct later.
Treating infrastructure as clicks. Anything built by hand in a console drifts and cannot be reproduced. Terraform (or an equivalent) turns infrastructure into reviewable code, which is the only reliable way to run more than one environment.
Who this field suits, and who it does not
Cloud architecture rewards people who like systems and consequences. If you enjoy tracing why a request is slow, why a bill jumped, or why a deploy broke one environment and not another, you will find it engaging. It also suits developers who are tired of handing infrastructure to someone else and want to own the whole path from code to running service. For a deeper dive into this topic, see Cloud Native.
It suits you less if you want purely visual, immediate work with no ambiguity. A large part of the job is reading documentation that is occasionally wrong, comparing two options that are both defensible, and making a call you will have to justify later. There is no single correct answer to "should this be a container or a function" — only a better or worse fit for this load, this team, and this budget.
A useful self-check before committing months to it:
- Can you read a billing dashboard and explain where the money went?
- Can you describe what happens to a request from DNS lookup to database write?
- Are you comfortable being the person who decides, not just implements?
If two of the three are shaky, that is exactly the gap a structured path closes.
Learning paths and what each actually costs you
Self-study is free in money and expensive in time and mistakes. The documentation is good and free, but it does not tell you which of five services fits your case, and nobody reviews your design. The expensive lessons — an over-provisioned cluster, a security group left open, a data transfer bill from cross-region traffic — are paid in production.
Hands-on practice in a personal account is the highest-value per hour: build a small system end to end, break it, watch the metrics, read the bill. The risk is that without a target you build the same comfortable thing repeatedly and never touch the parts you avoid.
Structured courses compress the decision-making. The value is not the syllabus — it is someone walking through the trade-offs with examples and giving feedback on your choices, which is the one thing self-study cannot supply. That is where Cloud Architecture (AWS/GCP/Azure) fits: it works through design, serverless and event-driven patterns, databases, networking, security, and cost optimisation across all three providers, with lessons adapted to your current level, so the trade-offs above get exercised rather than just read.
If you are already deep in one provider and chasing a senior role, the certification-oriented path is a reasonable parallel track, and the FinOps angle is worth going deeper on — AWS Solutions Architect Professional (SAP-C02): FinOps in Practice and the Google Cloud Architect — Professional (ACE + PCA) breakdowns show how the same cost logic plays out on each platform.
One warning about the certification route: passing an exam proves you can answer questions about services. It does not prove you can design a system that survives a spike and stays under budget. Treat the exam as a forcing function for breadth, and the design work as the actual skill.
A short note on what to build first
If you are starting, build one small system that touches the whole path: a public endpoint behind a load balancer, a managed database in a private subnet, object storage for static assets behind a CDN, identity with least privilege, and a budget alarm. Then break it on purpose — kill an instance during a load test, revoke a permission, exceed the free tier. The failures teach more than any diagram, and they cost almost nothing at small scale.
That single exercise covers what most people spend months circling: compute choice, state, networking, identity, and cost. Everything else is a variation on it.
The cloud does not reward knowing the most services. It rewards seeing the trade-off before it becomes an invoice or an incident. The course walks through those trade-offs with worked examples across AWS, Google Cloud, and Azure and gives feedback on the decisions you make — the details and enrolment are on the course page.