Cloud services
Cloud services are computing you rent instead of run: servers, platforms and software that a provider operates and bills by use. This reference maps what each model leaves to you, which service does each delivery job, and how to keep the bill readable.
- On-premisesOn-prem
- IaaS
- PaaS
- SaaS
01 · Service models
What is the difference between IaaS, PaaS and SaaS?
NIST SP 800-145 separates the three service models with one question: what does the consumer still control?
This page covers public cloud; for the landing zone beneath it, see cloud infrastructure.
- IaaSInfrastructure as a service
-
You control the operating systems, storage and deployed applications.
In delivery: virtual machines for build agents and older services.
- PaaSPlatform as a service
-
You control the application, not the servers or operating systems beneath it.
In delivery: app platforms, managed databases, container platforms.
- SaaSSoftware as a service
-
Your control can shrink to “limited user-specific application configuration settings.”
In delivery: chat, issue trackers, hosted source control.
02 · Shared responsibility
Who is responsible for what in the cloud?
Every provider splits security with you, and the split moves with the service model. AWS keeps security “of the cloud” and leaves you security “in the cloud.” Microsoft: “For all cloud deployment types, you own your data and identities.” Google Cloud: in IaaS, “the bulk of the security responsibilities are yours.” The pipeline is always yours: its identities, the configuration it applies and the artifacts it ships.
- Yours
- Shared
- The provider’s
- Where your side ends
From the Nike case
The Nike work included cloud automation across AWS and Azure, and lowered Azure and AWS security risk by mitigating multiple high-priority vulnerabilities: the customer’s half, in practice. Read the Nike case
03 · The service matrix
Which AWS, Azure and Google Cloud services do the same job?
Same jobs, different names, and not always one service per job. Each name links to the provider’s documentation; for the rest of the catalog, see the mappings by Microsoft and Google Cloud.
| Delivery job | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Virtual machinesA server you patch | Amazon EC2 | Azure Virtual Machines | Compute Engine |
| Managed KubernetesThe provider runs the control plane | Amazon EKS | Azure Kubernetes Service | Google Kubernetes Engine |
| Containers without a clusterRun an image, no nodes | Amazon ECS on AWS Fargate | Azure Container Apps | Cloud Run |
| FunctionsCode an event starts | AWS Lambda | Azure Functions | Cloud Run functions |
| Build serviceBuild and test jobs on demand | AWS CodeBuild | Azure Pipelineswith Microsoft-hosted agents | Cloud Build |
| Container registryThe images you deploy | Amazon ECR | Azure Container Registry | Artifact Registry |
| SecretsCredentials for apps and pipelines | AWS Secrets Manager | Azure Key Vault | Secret Manager |
| Metrics and logsNumbers over time and records of what ran | Amazon CloudWatch | Azure Monitor | Cloud Monitoring and Cloud Logging |
04 · Choosing compute
Should you use virtual machines, containers or serverless?
“A trade-off exists between control and ease of management,” says Microsoft’s compute guide. AWS’s guide calls it control versus convenience. The five common options sit along that trade-off, from most control to least upkeep.
You control more
-
Virtual machines
- AWS
- EC2
- Azure
- Virtual Machines
- Google Cloud
- Compute Engine
- Pick it when
- You need the operating system itself: a kernel setting, a host agent.
- Still yours
- The operating system and its patches.
-
Managed Kubernetes
- AWS
- EKS
- Azure
- AKS
- Google Cloud
- GKE
- Pick it when
- Many services, custom networking, and a team that runs Kubernetes.
- Still yours
- Nodes and upgrades, unless a mode such as GKE Autopilot runs the nodes.
-
Containers without a cluster
- AWS
- ECS on Fargate
- Azure
- Container Apps
- Google Cloud
- Cloud Run
- Pick it when
- A few services already in images, and nobody to run a cluster.
- Still yours
- The image and the packages inside it.
-
App platform
- AWS
- Elastic Beanstalk
- Azure
- App Service
- Google Cloud
- App Engine
- Pick it when
- A web app or API on a runtime the platform supports.
- Still yours
- The code, its configuration and dependencies.
-
Functions
- AWS
- Lambda
- Azure
- Functions
- Google Cloud
- Cloud Run functions
- Pick it when
- Work starts on an event, like a webhook, and finishes quickly.
- Still yours
- The code and the time limit.
The provider runs more
No clear fit? Start with containers without a cluster. An image keeps the most options open. Pick one default per kind of workload: each extra model brings its own deploy path and on-call knowledge.
From the ASML case
At ASML, we initiated offloading selected production machine tests to Google Cloud Platform, to increase throughput and shorten feedback cycles. Selected tests make a bounded first workload with a clear measure: how long engineers wait. Read the ASML case
05 · Costs
Why do cloud costs get out of hand?
Because the people who create resources rarely see the bill, and most resources run until someone stops them. The FinOps Foundation answers with a practice, not a tool: financial accountability through collaboration between engineering, finance and business teams.
Where the money leaks
- Environments nobody stops. Preview and test environments run nights and weekends unless the pipeline that made them removes them.
- Logs kept forever. CloudWatch Logs keeps logs indefinitely unless you set retention per log group.
- Spend with no owner. AWS cost allocation tags show in Cost Explorer only once activated, and Azure resources don’t inherit tags from their resource group.
Before you change the cloud
Find out what your release waits on
Cloud services show up in release time as waits: for an environment, a credential, an approval. The free Release Check shows where your last release spent its time and what that costs a year, in under 5 minutes and without a call.