There is a meeting most cloud teams have had. Someone says "the platform", someone else hears "the cloud setup", a third person hears "the Kubernetes cluster", and for forty minutes three people agree with each other while describing three different things.
It matters more than it sounds. Words in a cloud conversation turn into teams, budgets and tickets. If "platform" and "landing zone" are the same word in the room, you get one team owning two jobs, or two teams each assuming the other has it.
So here is the smallest set of definitions I know that survives a hard question.
A landing zone is the ground you are allowed to build on. A platform is what you build once so nobody rebuilds it. A workload is what the customer pays for. Tenancy is a fourth thing: not a layer, but a decision that cuts through all three.
One Test For the Seam
Here is the test I use, and it settles most arguments:
If it exists before any application does, it is landing zone. If a team consumes it to ship something, it is platform.
AWS describes a landing zone as "an orchestration framework for your foundational AWS environment", a baseline for multi-account architecture, identity and access management, governance, data security, network design and logging. Notice what that list has in common. Nothing on it is something a product team asked for. It exists so that, when the first team arrives, there is somewhere safe to put them.
A platform is the opposite kind of thing. It is a product with users, and its users are engineers: the place their containers run, how code reaches production, the managed databases, the messaging, the dashboards, the secrets. It has a roadmap, versions and a support burden, because someone depends on it every day.
| Landing zone | Platform | |
|---|---|---|
| The question it answers | Where do workloads live, under what rules | How do teams build and run things here |
| Who uses it | The organisation, security, auditors | Application engineers |
| What it is | A foundation, set up then evolved | A product, with a roadmap |
| How often it changes | Rarely, and each change is a big one | Continuously, versioned |
| What it contains | Accounts, identity, network foundation, central audit logging, guardrails, account creation | Runtime, delivery pipelines, persistence, messaging, observability, secrets |
Two things genuinely overlap, and it is worth having the answer ready. Both involve logging, but it is different logging: the landing zone keeps the central audit trail, the platform gives teams observability for their own applications. Both involve identity, and it splits the same way: who can reach the cloud account at all is the landing zone, and how a running service gets its permissions without a password in a file is the platform.
Who Gets Upset When It Changes
The third layer is the one everybody forgets to name, because it is the one everybody works in. The workload is the applications, their data and their releases. AWS defines it as "a set of components that together deliver business value", and says it is usually the level at which business and technology leaders talk to each other.
My favourite way to tell the three apart is not a definition. It is a question: who would be angry if this changed?
- Change the landing zone and security and finance are angry, and the change is rare and carefully made.
- Change the platform and every engineering team is angry at once, which is why it is versioned like a product.
- Change a workload and one product's customers are affected. The blast radius is bounded, and that is the point.
That question also explains a trade people forget they are making. The layer boundary is the autonomy boundary. Everything you standardise at the platform layer is autonomy you take from the teams above it. It has to buy them something they actually want, or they will route around it.
Tenancy Is Not a Layer
Now the word that gets mixed up with all of these. Tenancy is not a fourth layer sitting somewhere above or below. It is a set of decisions that cut across the three, and the real question is which of them becomes an account boundary.
The usual candidates:
| Axis | Where the boundary tends to land | Why |
|---|---|---|
| Tenant, meaning a company, customer or business unit | Often an account | Blast radius, cost attribution, the compliance story per tenant |
| Environment: development, staging, production | Almost always an account | Production should be unreachable from development by construction, not by policy |
| Region | Inside an account, as separate stacks | Residency is a question about data, not about identity |
| Business domain | Inside the workload, as services and schemas | It is a modelling boundary, not a security boundary |
| Product | Inside an account, as namespaces or services | Products of one tenant usually share a cost and compliance story |
The shape I reach for first is one account per tenant per environment. Ten tenants and three environments is thirty accounts plus the shared ones, and that is exactly why creating an account has to be automated. Account vending is not a nicety at that point. It is what makes the tenth onboarding a repeat of the second.
The trap is account per domain or per product, because it feels tidy. It multiplies accounts without buying isolation anyone needed, and every cross-domain call becomes a permanent networking tax. Boundaries should follow blast radius, cost attribution and compliance, not the organisation chart and not the domain model.
Silo, Pool, Bridge
When the tenants are customers of a SaaS product, AWS has names for the same decision one layer up, in its SaaS Lens.
In the silo model "tenants are provided dedicated resources", a fully independent stack or just a separate database each. AWS adds a detail that is easy to miss: a silo still shares identity, onboarding and operations, managed through one shared construct. That is what separates SaaS from selling the same product as a managed service with a separate operation for each customer.
In the pool model tenants share resources, "the more classic notion of multi-tenancy", for economies of scale.
The bridge model acknowledges that SaaS businesses are not always one or the other. Some microservices are siloed, others pooled. AWS gives the reasoning: the regulatory profile of a service's data and its noisy neighbour behaviour push it toward silo, while agility, access patterns and cost push another toward pool.
Here is my own reading of what each costs, and it is a reading, not a rule from AWS. Silo is the easiest thing to migrate into from an application that assumes a single customer, and the most expensive to operate many times over. Pool is the cheapest to run and the hardest to reach from that starting point. Most real conversions land in the bridge, and they land there because of one component at a time, not because anyone chose it on day one.
Before You Choose
I would not pick a model in the first meeting. I would ask five things first:
- Where does each tenant's data have to live, and what does each tenant's regulator expect to see?
- What cost attribution does each tenant need to see on its own bill?
- Can one tenant stay a version behind the others, or is it one release train for everyone?
- How much blast radius is acceptable, and how fine must a rollback be?
- How much of the existing application quietly assumes there is only one customer?
The fifth question is the one that decides the cost of everything else, and it is the one nobody has the answer to until someone reads the code.
Landing zone, platform, workload, and the tenancy decision cutting through all three. Four words, four jobs. If the room can say which one it means, the forty minutes get shorter.
If it exists before the first application, it is the landing zone. If a team consumes it to ship something, it is the platform. Most arguments about cloud architecture are two people using one word for both.