Compute options: virtual machines, containers and serverless compared
In short: Virtual machines give full control but the most work, containers package apps for portable, efficient hosting, and serverless functions run code on demand with no servers to manage. Each shifts a different share of security work between you and the provider.
Three ways to run code
Every cloud application needs somewhere to run. The three main options differ in how much of the stack you look after. A good mental model: the less you manage, the less you can misconfigure, but the less you can customise.
How they compare
| Aspect | Virtual machines | Containers | Serverless functions |
|---|---|---|---|
| Examples | Amazon EC2, Azure VMs, Compute Engine | Amazon ECS/EKS, Azure Container Apps/AKS, GKE | AWS Lambda, Azure Functions, Cloud Run functions |
| Start time | Minutes | Seconds | Milliseconds to seconds |
| Billing | Per second or hour while running | Per node, or per task resources | Per request and execution time |
| Scaling | Scale sets / auto scaling groups | Orchestrator scales pods or tasks | Automatic, per event |
| You patch | OS, runtime, app | Base image and app (host too if self-managed) | Your code and its libraries |
| Limits | Few | Needs orchestration skills | Time limits, cold starts, stateless |
A container packages an application with its libraries but shares the host's kernel, so it is lighter than a VM. Serverless still runs on servers; you just never see them. The provider runs your function when an event arrives, such as an HTTP request, a file upload or a queue message.
Security responsibilities
- VMs: you harden and patch the operating system, manage SSH or RDP access, run endpoint protection, and control the network.
- Containers: scan images for vulnerabilities, use small trusted base images, avoid running as root, and lock down the orchestrator (for example Kubernetes role-based access control).
- Serverless: give each function its own least-privilege role, validate every input, keep secrets in a vault rather than environment variables in plain text, and watch dependencies.
Identity becomes more important as you move right. A function with an over-powerful role is a tempting target, because a single injection flaw can hand an attacker that role's permissions.
Choosing for a workload
- Does the software need a specific OS or kernel, or a licence tied to a machine? Use a VM.
- Is it a modern web service that you want to move between environments? Use containers.
- Is it short, event-driven code with unpredictable traffic? Try serverless.
- Check run time: long jobs may exceed serverless time limits.
- Check your team's skills; a well-run VM beats a badly run Kubernetes cluster.
Tip: many real systems mix all three, for example a container-based API, serverless functions for image resizing, and a VM for a legacy reporting tool.
Practice
Which option leaves you responsible for patching the guest operating system?
Why is a least-privilege role especially important for a serverless function?
A nightly job runs for three hours. Is a serverless function a good fit?
Key takeaways
- VMs give the most control and the most patching work.
- Containers share the host kernel and package apps portably.
- Serverless runs code per event, billed per request and duration.
- Moving towards serverless shifts more security work to the provider.
- Least-privilege identity matters at every level.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.