Cloud service and deployment models

From one definition to many models

Chapter 0 introduced servers and the cloud: the NIST definition (Special Publication 800-145, 2011), with its five essential characteristics of on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service, and the idea that service models hand more or less of the stack to a provider. This section takes those ideas to the depth an architect needs to choose where a system runs and to defend the choice.

NIST defines three service models (infrastructure, platform and software as a service) and four deployment models: public (open to anyone, owned by a provider), private (for one organisation, wherever it is located and whoever operates it), community (shared by organisations with common concerns, such as government bodies) and hybrid (two or more of these, bound together so that data and applications can move between them). The industry has since added functions and containers as a service to the service models, and multi-cloud to the deployment vocabulary.

Where software runs is part of what Chapter 1 called the allocation structure of an architecture (defining architecture): the mapping of software onto hardware, networks and organisations. It is significant in the Chapter 1 sense because it is expensive to reverse, and because it fixes much of a system's cost, its availability, its security boundary and how quickly its teams can release.

Service models: who manages what

The service models form a spectrum. At one end you rent bare capacity and do everything above it yourself; at the other you rent a finished application and only configure it. Each step to the right removes operational work and removes choices. The table adds the two models that the NIST document predates: containers as a service and functions as a service.

The boundaries blur in practice. Serverless container platforms such as Google Cloud Run and Azure Container Apps run a container image like a PaaS runs code, scaling to zero like a function. Managed Kubernetes can be anything from a hosted control plane, where you still patch and upgrade the worker machines, to a fully managed mode where the provider runs the nodes too. The useful question is never which label applies but which concrete tasks remain yours: patching, scaling decisions, capacity planning, backups, failover, upgrades and on-call response.

A second useful distinction is the unit of deployment and billing. IaaS bills machines by the second or hour whether they are busy or not; FaaS bills invocations and execution time and costs nothing when idle; PaaS and serverless containers sit in between. Chapter 6 explains why per-request pricing is cheaper than always-on capacity below a crossover volume and more expensive above it (serverless architectures). The shape of a workload's load, not its size, decides which side of the crossover it is on.

The shared responsibility model

Every major provider publishes a shared responsibility model. AWS summarises it as the provider being responsible for security of the cloud and the customer for security in the cloud. The provider secures buildings, hardware, the network, the hypervisor and the services it runs; the customer secures what it builds and configures on top. Where the line falls depends on the service model, as the diagram shows.

Three things never transfer. The customer always owns its data (what is stored, where, for how long, who can read it), its identities and permissions, and the configuration of the services it uses. Many cloud breaches have been customer configuration failures rather than provider failures: object storage left readable by anyone, administrator keys committed to public repositories, overly broad permissions. In 2019, for example, an attacker exploited a misconfigured web application firewall at Capital One to obtain cloud credentials and copy data relating to more than 100 million people in the United States and Canada; the provider's infrastructure behaved as designed.

For an architect, the model is a checklist of work that must be assigned to someone. If a team moves the food-delivery platform's orders database from a virtual machine to a managed database service, patching the database engine moves to the provider, but choosing a maintenance window, testing major version upgrades, granting least-privilege access, enabling encryption and checking that backups can be restored do not. Chapter 8 covers the security principles behind these duties in depth (security principles for architects).

Deployment models and the real reasons behind them

Organisations rarely choose a deployment model for one reason, and the stated reason is not always the real one. It helps to separate the motives that survive scrutiny from the ones that do not.

The common error is to adopt multi-cloud as an abstract hedge. Making one workload run identically on two providers means using only the services both offer, building and testing two sets of infrastructure code, staffing skills for both, and often paying data transfer charges between them. That is the lowest-common-denominator trap: you pay the cost of portability every day in exchange for an exit you may never use. Section 10.8 treats lock-in as a trade-off to be priced, not a sin to be avoided at any cost (FinOps, cost architecture and vendor lock-in).

Regions and availability zones as design inputs

A region is a geographic area with its own independent set of data centres; an availability zone is one or more data centres within a region with separate power, cooling and networking, placed far enough from the others that a fire, flood or local power failure affects only one, and close enough for round trips of a few milliseconds at most. Chapter 0 explained the idea. For design, three further points matter.

First, every managed service has a failure scope: zonal resources (a single virtual machine, a disk) die with their zone; regional services (most managed databases in multi-zone mode, object storage, queues) are replicated across zones by the provider; a few global services (DNS, identity, some content delivery and load-balancing services) span regions, which makes their rare outages wide. Knowing which scope each dependency has is the first step in any availability analysis (see availability and reliability).

Second, spreading across zones is the cheap, high-value default. Running the food-delivery platform's stateless services in three zones behind a load balancer, with a database that keeps a synchronous standby in a second zone, survives the loss of a data centre with automatic failover and a small latency cost. Three zones rather than two matter for anything that uses quorums, such as etcd in Kubernetes or a consensus-based database, because a majority must survive. Cross-zone traffic is not always free, though: most large providers charge for data moving between zones, so chatty services spread across zones add a visible line to the bill.

Third, regions are not identical. Newer or smaller regions may lack services, some have fewer zones, prices differ by region, and legal jurisdiction follows the region. Section 10.6 deals with multiple regions, disaster recovery and data residency (multi-region, disaster recovery and edge computing).

Managed services versus self-managed

A managed service is a component (a database, queue, cache, search engine, Kubernetes control plane) that the provider installs, operates, patches, backs up and scales for you. The alternative is to run the same open-source software yourself on virtual machines or in containers. The trade-off is labour and risk against control, cost and portability.

Managed services win when the component is undifferentiated: every food-delivery company needs a reliable PostgreSQL database, but none wins customers because of how it applies database patches. In domain-driven design terms these are generic subdomains, the ones you should buy rather than build. A managed database gives multi-zone failover, point-in-time recovery and minor-version patching that would otherwise need a skilled team on call. Self-management wins when you need a version, extension or tuning parameter the provider does not offer, when the provider's limits or quotas do not fit, when the managed premium becomes large at scale, or when portability across environments matters more than convenience.

Managed does not mean maintenance-free. The provider will force major version upgrades on its own schedule when old versions reach end of support, will change defaults, will impose quotas you discover at the worst moment and will have outages you cannot fix, only wait out. You still own schema design, query performance, capacity choices, cost and the regular test that proves a restore works. Treat each managed service as a dependency with its own failure modes and its own exit cost.

What cloud native means

The Cloud Native Computing Foundation (CNCF), part of the Linux Foundation and home of Kubernetes, publishes the most cited definition of cloud native. Version 1.0 (2018) described technologies that let organisations build and run scalable applications in dynamic environments such as public, private and hybrid clouds, and named containers, service meshes, microservices, immutable infrastructure and declarative APIs as typical examples. Version 1.1, approved in 2024, shifts the emphasis from technologies to practices: developing, building and deploying workloads in a programmatic, repeatable way at scale, characterised by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

Two consequences follow. Cloud native describes how a system is built and operated, not where: a Kubernetes cluster in a private data centre, provisioned from code and deployed many times a day, is cloud native; a hand-configured virtual machine copied unchanged into a public cloud is not. And cloud native is a means rather than an end. Its practices (automation, disposable components, declarative configuration, elasticity, observability) pay off when a system needs frequent change, variable scale and high availability; they add cost and complexity for a stable internal tool used by twenty people.

Migrations are often described with the six Rs, which are worth knowing because they set expectations: rehost (lift and shift, unchanged), replatform (small changes such as moving to a managed database), refactor or re-architect (redesign for cloud-native operation), repurchase (replace with SaaS), retain (leave where it is) and retire (switch it off). Rehosting is fast but typically delivers few of the cloud's benefits and, run on always-on machines sized for peak, can cost more than the data centre it left.

When the cloud is not cheaper

The best-known counter-example is 37signals, the company behind Basecamp and HEY. In October 2022 its chief technology officer, David Heinemeier Hansson, announced that it was leaving the cloud, citing an annual AWS bill of more than USD 3 million for workloads with steady, predictable load. It bought roughly USD 700,000 of Dell servers, placed them in rented colocation space and moved its applications off AWS compute during 2023; it reported that this cut its cloud bill by about USD 2 million a year. In 2025 it announced the second stage: moving about 18 petabytes of files from Amazon S3 to roughly USD 1.5 million of storage arrays to replace an S3 bill of about USD 1.5 million a year, with the stated aim of closing its AWS account. The company has projected savings of about USD 10 million over five years. Moving workloads out of the cloud in this way is called cloud repatriation.

Both sides of the argument deserve a hearing. In favour of 37signals' reasoning: its load is steady, so it gained little from elasticity; it already employed experienced operations engineers and reported needing no extra staff; colocation providers handle power, cooling and physical security; and servers can be used for five years or more, so their cost per year of computing is far below on-demand rental. On the other side: 37signals is a mature business with predictable demand, which most new products are not; the comparison depends heavily on what the cloud bill would have been with commitment discounts and right-sizing; owning hardware means capital spending, lead times of weeks or months and capacity bought in advance; and a smaller team without deep operations skills would have to hire them, which can erase the saving. Critics also point out that the savings figures come from the company itself.