The cloud is renting computers, storage, and networking on demand instead of buying and racking your own. You pay for what you use and give it back when you are done. For DevOps this is the ground everything else in this series runs on. Learn a handful of building blocks, one shared responsibility rule, and how to not get a surprise bill, and the cloud stops being intimidating.
A small team is launching next week and expects a huge spike of traffic on day one, then far less after. Buying a hundred servers for a weekend and letting them gather dust afterward is absurd, and buying five means the launch falls over. The cloud dissolves this problem: rent a hundred machines for the weekend, then give ninety-five back on Monday, and pay only for the hours you used. That elasticity, capacity that grows and shrinks on demand, is why almost everything you have learned in this series now runs in the cloud.
The first thing to sort out is how much of the stack you rent. That is the difference between the three service models, and the clearest way to see it is side by side.
| Model | You manage | Provider manages | Example |
|---|---|---|---|
| IaaS | The OS and everything above | Hardware and virtualization | A rented virtual machine |
| PaaS | Just your app code | OS, runtime, and scaling | An app hosting platform |
| SaaS | Nothing, you just use it | Everything | Web email or docs |
Every part of this series has quietly assumed the cloud. The CI runners in Part 7, the container registries in Part 8, the Kubernetes cluster in Part 9, the servers Terraform built in Part 10: all of them live on cloud infrastructure. This part names the ground they stand on.
Who manages what
The service models are really a sliding scale of how much you hand off. With infrastructure as a service you get a bare virtual machine and do everything above the hardware yourself, which is the most control and the most work. With platform as a service you hand over the operating system and runtime and just push code. With software as a service you get a finished product and manage nothing. Moving up the stack trades control for convenience, and most DevOps work lives in the middle, using managed pieces where they help and raw machines where they must.
The building blocks: compute, storage, network
Under all the product names, cloud services fall into three families. Compute is anything that runs your code: virtual machines, containers, and serverless functions. Storage comes in two main flavors: object storage for files like images and backups, reached over the web, and block storage that acts like a disk attached to a machine. Networking is what connects it all and controls who can reach what, using private networks and firewall rules. Almost every cloud service you meet is a variation on one of these three.
The good news for a beginner is that the concepts are identical across providers, only the names change. Learn what object storage is once and you can find it on any cloud in a minute. Here is the same handful of building blocks across the three big providers, so a name in a job post never throws you.
| Building block | AWS | Azure | Google Cloud |
|---|---|---|---|
| Virtual machine | EC2 | Virtual Machines | Compute Engine |
| Object storage | S3 | Blob Storage | Cloud Storage |
| Managed Kubernetes | EKS | AKS | GKE |
| Managed database | RDS | Azure SQL | Cloud SQL |
The command line reaches the cloud too
You do not have to click through a console to use the cloud. Every provider ships a command line tool, and it is where real DevOps work happens because commands can be scripted and put in pipelines, exactly the lesson from Part 4. Here is the same feel using the AWS tool: list your storage buckets, upload a file, and check whether your machines are running.
$ aws s3 ls
2026-06-30 09:12:04 my-app-backups
$ aws s3 cp report.pdf s3://my-app-backups/
upload: ./report.pdf to s3://my-app-backups/report.pdf
$ aws ec2 describe-instances --query 'Reservations[].Instances[].State.Name'
[ "running" ]Three commands, and you listed storage, moved a file into the cloud, and checked the state of your servers, all without touching a mouse. The other providers work the same way with their own tools. This matters because it connects the cloud back to everything else in this series. A command like this can live in a script, run inside a pipeline from Part 7, or be generated by Terraform from Part 10. The console is fine for looking around and learning, but the command line is how the cloud gets automated, and automation is the whole point of DevOps.
The cloud console is where you learn and explore, but do not run production changes by clicking. Anything you do twice belongs in a script or in Terraform, so it is repeatable and reviewable. A useful early habit is to do a task once in the console to understand it, then find the command line or Terraform way to do it again. That is the path from cloud user to cloud engineer, and it is the same move that separates ClickOps from Infrastructure as Code back in Part 10.
Regions and availability zones
The cloud is not one giant building. It is data centers all over the world, grouped into regions like one in Europe and one in Asia. Within a region are several availability zones, which are separate data centers close enough to work together but far enough apart that one flooding or losing power does not take the others down. You spread your app across zones so a single data center failure does not take you offline, and you pick regions close to your users to keep things fast.
The shared responsibility model
This is the idea that gets people in trouble when they miss it, so learn it clearly. In the cloud, security is split. The provider secures the cloud itself: the physical data centers, the hardware, the core network. You secure what you put in the cloud: your data, your access rules, your configuration. The provider giving you a secure building does not mean you locked your own front door. Most cloud breaches are not the provider being hacked. They are a customer leaving a storage bucket open to the public or granting too broad an access permission.
Managed services are why DevOps loves the cloud
The real gift of the cloud is not renting bare machines. It is managed services, where the provider runs the hard parts for you. A managed database handles backups, patching, and failover so you do not. Managed Kubernetes runs the control plane you met in Part 9. Managed message queues, caches, and storage all remove operational work that used to eat entire teams. For a small team, leaning on managed services is how a handful of people run systems that once needed a department.
The tradeoff is cost and some lock-in, which brings us to the honest opinions. Managed services cost more per hour than raw machines, and they tie you a little more tightly to one provider. For most teams that is a good trade, because the time saved is worth more than the money spent. But it is a real choice, and knowing when a managed service earns its price is a mark of a thoughtful engineer.
Watch the bill, ignore the multi-cloud hype
Two honest opinions for beginners. First, the cloud will send you a surprise bill if you are careless, and this is the most common painful lesson. A machine left running over a holiday, a test cluster nobody shut down, or large amounts of data transferred out of the cloud, which is often charged and easy to forget, can all turn into real money. Treat every resource you create as a meter that is running, and set a billing alert on day one so a mistake stays small. Turning off what you are not using is a genuine DevOps skill, not an afterthought.
Second, do not chase multi-cloud as a beginner. The dream of running seamlessly across AWS, Azure, and Google at once sounds impressive and is a great deal of complexity for benefits most teams never need. Learn one cloud well. The concepts, compute, storage, networking, managed services, transfer almost entirely to the others, so depth in one beats a shallow tour of three. If a job later needs a second cloud, your foundation carries over. Pick one, get good, and let the multi-cloud debates happen above your pay grade for now.
Explain the shared responsibility model. Answer: cloud security is divided. The provider secures the infrastructure, the physical data centers, hardware, and core network, while the customer secures what they run on it, their data, access permissions, and configuration. Add the killer example: most cloud breaches come from customer misconfiguration, like a storage bucket left public, not from the provider being hacked. That shows you understand security in the cloud is a job you own, which is exactly what the question is testing.
You will be handed access to a cloud account and asked to find something, check a setting, or spin up a small resource. Knowing that a virtual machine, a storage bucket, and a network rule are the basic pieces, and that names differ but concepts do not, lets you navigate any provider is console without panic. Being the junior who checks the billing dashboard and says we left a test cluster running all weekend, I shut it down is quietly valued, because cloud cost is real money and few beginners think to look.
Free with a cloud free tier, about thirty minutes. Sign up for one provider and, using the free tier, create one small virtual machine and one object storage bucket. Upload a file to the bucket, connect to the machine over SSH from Part 4, then delete both when done. The most important step is the last one. How to check you did it right: the resources appear in the console while they exist and are gone from your account, and your bill, after you delete them. You just used compute and storage and, crucially, cleaned up.
The line item that surprises beginners most is data transfer out, often called egress. Moving data into the cloud is usually free, but pulling large amounts back out, or shuttling it between regions, is billed per gigabyte. A backup job that copies terabytes across regions, or an app serving big files to users without a CDN in front, can quietly run up a bill far larger than the servers themselves. The fix is boring and effective: keep traffic within one region where you can, put a CDN in front of anything users download a lot, from Part 6, and read the transfer section of the pricing page before you design anything that moves data at scale. Storage is cheap. Moving it is where the meter spins.
Cloud questions beginners ask
Which cloud should I learn first?
Any of the big three is a fine choice, and AWS has the largest market share and job demand, so it is a safe default. The concepts transfer, so pick one and go deep rather than sampling all three. Your foundation will carry to whichever cloud a future employer uses.
What is serverless?
A compute model where you run code without managing any server at all. You give the provider a function, it runs on demand and scales automatically, and you pay only while it runs. It is the far end of the convenience scale, great for small event driven tasks, less suited to every workload.
Is the cloud always cheaper than owning servers?
No. It is cheaper for variable or uncertain demand, where you pay only for what you use. For very steady, predictable, heavy workloads, owning hardware can cost less over time. The cloud sells flexibility and speed, and those are worth a lot, but it is not automatically the cheapest option.
How does the cloud connect to everything else in this series?
It is the ground under all of it. Terraform from Part 10 builds cloud resources, Kubernetes from Part 9 runs on cloud machines, and your pipelines and monitoring live there too. The cloud is where DevOps happens, which is why it sits near the end once the pieces make sense.
You now know the ground everything runs on. Next up is Part 15 on security in the pipeline, or DevSecOps, where you learn to build safety into everything you have set up rather than bolting it on at the end.
Want the cloud from the ground up? The Cloud for Beginners series goes deeper. Or revisit Part 10 on Terraform and Part 9 on Kubernetes, which run on this ground.
References
AWS: Shared responsibility model
Azure: Shared responsibility
Google Cloud Architecture Framework
About The Author
DrJha