Cloud Computing Fundamentals
Compute Services
The actual compute options behind IaaS and PaaS: how virtual machines are sized and priced, what managed compute platforms take off your plate, and where containers and serverless functions sit on the same spectrum.
- Explain what compute means as a billed cloud resource
- Choose an appropriate virtual machine family for a given workload profile
- Distinguish vertical scaling from horizontal scaling as 2 different responses to running out of capacity
- Place virtual machines, managed compute, containers, and serverless functions on a single control-versus-convenience spectrum
What you are actually renting
The last topic told you that IaaS hands you a virtual machine and PaaS hands you a platform that runs your code. Neither one told you what is actually happening inside that box: some amount of CPU and memory, sitting in a data center, that you rent by the hour, the second, or the request. That resource is compute, and how much of it you get, how it is packaged, and how you pay for it are decisions that shape almost every other choice you make on a cloud platform.
Virtual machines: the baseline unit
A virtual machine is still the most common way compute gets sold, and providers group their VM offerings into families built around different resource ratios.
| Family | Optimized for | Typical use case |
|---|---|---|
| General purpose | A balance of compute, memory, and networking | Web servers, small-to-medium databases, dev environments |
| Compute optimized | High-performance processors, more vCPU per GB of memory | Batch processing, media transcoding, game servers |
| Memory optimized | Large amounts of RAM relative to vCPU | In-memory databases, real-time analytics |
| Storage optimized | High, low-latency local disk throughput | High-throughput databases, streaming data processing |
| Accelerated computing | GPUs or other hardware accelerators | Machine learning training, graphics rendering |
A batch job that spends its time doing floating-point math and barely touches memory belongs on compute optimized, not general purpose. A database holding a large working set in memory belongs on memory optimized. Picking the wrong family does not just waste money, it can leave a workload starved of the one resource it actually needed.
Instance sizes inside a family follow a doubling pattern: a large steps up to an xlarge, which steps up to a 2xlarge, roughly doubling vCPUs and memory at each step. You saw in the IaaS lesson that a t3.micro, 2 vCPUs and 1 GiB of memory, runs about $7.59 a month before storage. Moving up a size roughly doubles both the resources and the bill; moving to a different family at a similar size changes the resource ratio instead.
Vertical scaling versus horizontal scaling
Say that same application starts timing out under load. A quick look at its metrics shows CPU pegged at 100% while memory usage stays low. There are 2 different ways to respond, and they are not interchangeable.
Vertical scaling resizes the existing instance to a bigger one, more vCPUs, more memory, same single machine. It is simple, but it has a ceiling (the largest instance type in the family) and it briefly interrupts the instance during the resize.
Horizontal scaling adds more instances of the same size and spreads the load across all of them, typically behind a load balancer. It avoids the ceiling and does not require downtime on the existing instances, but it only works if the application can actually split its work across multiple machines instead of depending on one.
For the CPU-pegged, memory-fine application above, either move fixes the symptom. Which one a real team picks depends on whether the application was built to run on more than one instance at once, which is a design question, not a compute question, but one that compute options force you to confront.
Managed compute: someone else runs the fleet
You already met AWS Elastic Beanstalk, Google App Engine, and similar products as PaaS examples. Underneath, they are still running your code on virtual machines, the difference is who provisions and operates those machines. A managed compute platform takes over launching instances, deploying new versions of your code, and, in most cases, scaling the fleet up and down as traffic changes. You still choose your runtime and supply your application; you stop writing the scripts that would otherwise provision and babysit the instances by hand.
The full compute spectrum
Virtual machines and managed compute are 2 points on a longer line. Containers and serverless functions sit further along it, and this domain gives each one a full lesson later. For now, the shape of the whole spectrum matters more than the mechanics of any single stop on it.
| Option | What you manage | Typical startup |
|---|---|---|
| Virtual machine | OS, runtime, scaling | Minutes |
| Managed compute | Application code and configuration | Minutes |
| Container | Application, its runtime dependencies, packaged together | Seconds |
| Serverless function | Only the function code | Milliseconds |
A container shares its host's operating system kernel instead of running a full guest OS the way a virtual machine does, which is exactly why it starts in seconds instead of minutes. A serverless function, such as an AWS Lambda function, goes further still: the provider manages the entire execution environment, and you are billed per request and per fraction of a second the function actually runs, not for idle time between invocations.
The misconception: "serverless is always cheaper"
It is tempting to assume that paying only for what you use always beats paying for a machine that sits there. That is true for spiky or low-volume traffic, where a small always-on virtual machine spends most of its time idle and billed anyway. Run a workload at high, steady volume instead, and the math flips: per-invocation charges on a serverless function can add up past what a modest always-on instance would have cost for the same total work. Neither end of the spectrum is cheaper in every case. The traffic pattern decides, which is exactly why the full comparison waits for its own lesson later in this domain.
Where this leaves you
Every compute option on this spectrum answers the same underlying question, how much of the operating and scaling work do you want to keep versus hand to the provider, at the cost of how much control. Virtual machines keep the most in your hands; serverless functions keep the least. The next lesson leaves compute behind and covers what happens to the data those compute resources read and write: storage.