Compute Across the Three Clouds

You've met the three ways to rent computing power: virtual machines, containers, and serverless functions. Every major cloud provider offers all three — but each uses its own names, and those names can make the same landscape look like three completely different worlds.

This topic lines them up. The goal is simple: by the end, when you see "EC2", "GKE", or "Azure Functions" in a job posting or an architecture diagram, you'll know immediately which compute model it belongs to and which cloud it's on.

The Mapping: Same Three Models, Different Names

Start with the constant: the three models exist on every cloud. AWS, Google Cloud, and Azure all offer virtual machines, managed container services, and serverless functions. The concepts from the previous three topics apply to every provider — only the product names change.

AWS calls its VM service EC2 (Elastic Compute Cloud), a name that gives little away. Google Cloud calls its equivalent Compute Engine, which is more descriptive. Azure simply calls it Virtual Machines — the most literal name of the three. All three rent you a software-defined slice of a physical server, with full OS control.

For containers, each cloud has a managed service built on top of Kubernetes — AWS's is called EKS (Elastic Kubernetes Service), Google's is GKE (Google Kubernetes Engine), and Azure's is AKS (Azure Kubernetes Service). Each also offers a simpler service for running containers without managing Kubernetes directly: AWS has ECS (Elastic Container Service), Google has Cloud Run, and Azure has Container Apps.

For serverless functions, the naming is cleaner: Lambda on AWS, Cloud Run functions on Google Cloud, and Functions on Azure. All three run event-driven code without a server to manage.

Where the Three Clouds Actually Differ

Knowing the names is one thing; knowing the real differences is what makes the map useful.

Google's Cloud Run occupies an interesting position: it runs containerized code in a serverless way — you package your app as a container, and Cloud Run runs it without you managing any servers, scaling to zero when idle. AWS handles this with two services: ECS (for managed containers with servers) and Lambda (for serverless functions, and containerized code). Because no single AWS service does exactly the same thing as Cloud Run, moving a Cloud Run workload to AWS requires a real choice, not a simple rename.

Azure's strength here is its tight integration with the Microsoft ecosystem. Teams already running Windows servers, Active Directory, or Microsoft 365 find that Azure's compute services slot into their existing setup more naturally than the alternatives. The services work identically at the concept level; the ecosystem around them differs.

AWS has the broadest menu — more VM sizes, more specialized compute options, more years of services built on top of each other. That breadth also means more choices, which can slow down a team that just wants a simple answer.

Choosing a Compute Model

The three models form a clear ladder based on how much you control versus how much the provider handles.

A virtual machine gives you the most control — the whole OS, any software, any configuration — but asks the most of you in return: you patch it, secure it, and keep it running. Choose VMs when you need that control, or when you're running software that expects a full traditional server environment.

Containers sit in the middle: you control the app's environment (the container image) but hand off the scheduling, scaling, and machine management to an orchestrator. Choose containers when you want consistency and portability, run many services, and are willing to learn the container toolchain.

Serverless functions give you the least control and the least to manage. You provide code; the provider handles everything else. Choose functions when your workload is event-driven and short-lived, and when the pay-only-when-running billing is a genuine advantage for your usage pattern.

Reading a Job Listing or Architecture Diagram

Cloud job postings and architecture discussions use the product names, not the model names. "Experience with EC2 and Lambda" means: VMs and serverless functions, on AWS. "GKE workloads" means: containerized applications managed by Kubernetes, on Google Cloud. "Azure Functions" means: serverless event-driven code, on Azure.

With the three-model map in mind, any of these names lands somewhere familiar rather than somewhere opaque. The rest of a job's requirements, or the intent of a diagram, becomes readable even before you know every detail of the specific product.