Enterprise cloud computing services: what each tier actually buys you
IaaS, PaaS and managed services compared by the work they remove from your team, with the governance and exit costs enterprises usually miss.
Cloud providers sell the same primitives under three different names, and the tier you pick decides how much operational work stays with your team. Most migration failures are not technical: they are a mismatch between the tier bought and the team that has to run it.
This guide maps each tier to the work it removes, then covers the parts that decide three-year cost: governance, identity and exit.
The three tiers, described by responsibility
Infrastructure as a service
You rent compute, storage and network; you still own the operating system, patching, scaling logic, database engines and backups. Best when you have platform engineers and unusual runtime or latency requirements. Cheapest on paper, most expensive in headcount.
Platform as a service
The provider owns the runtime, the scaling policy and the base image patching. You own the application, its data model and its access rules. This is the default for product teams that do not want to run a platform team of their own.
Managed services
The provider owns part of the data layer as well: managed queues, warehouses, search, identity. You own configuration, network policy and cost governance. Adoption is fast; the exit cost is the one enterprises underestimate.
What each tier really costs
| Tier | Team time | Flexibility | Typical exit cost |
|---|---|---|---|
| IaaS | High | Highest | Low |
| PaaS | Medium | Medium | Medium |
| Managed | Low | Lowest | High |
The exit column is where the three-year total diverges. A managed queue is trivial to adopt and expensive to leave, because the migration is a rewrite of the consumer logic rather than a data move.
Identity decides the timeline
Every migration plan that schedules identity late slips. Directory integration, federation, privileged access review and service account inventory take longer than moving the workloads, and they are the reason a six-month plan becomes fourteen.
Start with federation from the existing identity provider, then move the workloads that have the fewest service accounts. Applications with local database logins or embedded credentials are the long tail.
Governance that survives an audit
- Tag at creation. Owner, environment and cost centre, enforced by policy rather than convention. Untagged resources are unattributable spend.
- Review access quarterly against the identity provider, not against a spreadsheet — the spreadsheet is always stale.
- Keep a data residency register per service. It is the first artefact regulators ask for and the last one teams build.
- Version infrastructure as code so the audit trail is a diff, not a change request.
Choosing providers without a full bake-off
Most enterprises end up running two providers on purpose: one for the system of record under commercial terms, one for elastic or experimental workloads. A full multi-cloud control plane rarely pays for itself before the second migration, so the practical decision is which workloads justify the second provider — not whether to standardise.
Price three years, not one month: committed-use discounts, support tier, egress, and the cost of the engineers who will run it.
Migration patterns that work
- Strangler first. Route one user-facing path to the new platform, keep the rest in place, and retire components as they are proven.
- Data before compute. Move the data layer while the old system still serves traffic; the reverse order creates dual-write bugs that surface in month three.
- Freeze the platform, not the product. Teams ship features against a stable internal interface while the substrate changes underneath.
Support tiers and what they actually guarantee
Support is priced as a percentage of consumption, and the tiers differ far more in response time than in capability. Before upgrading, check three things in the contract: whether the response clock starts on ticket creation or on triage completion, who diagnoses the problem when the boundary is unclear, and whether the escalation engineer has access to your environment without you granting it each time.
The most common expensive upgrade is a support tier bought to compensate for a missing internal capability rather than for the provider's response time.
Data residency and sovereignty in practice
Residency is not a checkbox: it is the set of regions where data is stored, processed, backed up and replicated for disaster recovery. Read the four separately. A service with primary storage in one region and backup in another does not satisfy a strict residency requirement, and the provider's marketing page will not mention the backup region.
For regulated workloads, keep a register per service listing the four locations, the encryption key custody model, and who can access the data under the provider's own support process.
Reserved capacity, savings plans and the commitment trap
Commitments trade flexibility for discount, and the trap is committing to peak instead of baseline. A practical rule: cover the fifth percentile of the last ninety days with a one-year commitment, keep the rest on demand, and let the spiky services absorb price changes through shorter terms. Review the coverage percentage quarterly against actual usage, because a service that shrinks turns your discount into a fixed cost.
Migration patterns that work
- Strangler first. Route one user-facing path to the new platform, keep the rest in place, and retire components as they are proven.
- Data before compute. Move the data layer while the old system still serves traffic; the reverse order creates dual-write bugs that surface in month three.
- Freeze the platform, not the product. Teams ship features against a stable internal interface while the substrate changes underneath.
- One thin slice, end to end. The first migration should include monitoring, alerting, backup and support — not just a running container.
The six migration strategies, and when each applies
| Strategy | What it means | Use when |
|---|---|---|
| Rehost | Move as-is | Stable app, deadline pressure |
| Replatform | Minor managed-service swaps | Database or runtime is the pain |
| Repurchase | Move to SaaS | Someone else does it better |
| Refactor | Re-architect | Business case justifies the cost |
| Retire | Switch off | Nobody owns it any more |
| Retain | Leave in place | Compliance or latency reasons |
Most estates end up with a mix, and the useful discipline is deciding per application rather than adopting one strategy as a slogan. Retire is the strategy teams skip, and it is usually the cheapest saving available.
Frequently asked questions
Is multi-cloud worth it for a mid-size company?
Rarely on cost alone. It pays when one workload has a regulatory or latency requirement the primary provider cannot meet, or when a single provider's commercial terms become unacceptable.
How long does an enterprise migration take?
Six to eighteen months for a meaningful workload set, dominated by identity, data movement and the long tail of applications nobody wants to own.
What should we measure first?
Cost per service, percentage of workloads with a named owner, and the share of steady-state compute under commitment. Those three numbers predict the bill better than any dashboard.
Do we need a platform team to use Kubernetes?
Effectively yes. Managed container services remove control-plane work but not the operational surface — upgrades, ingress, policy, observability.
Check also
- CASB vs SSE vs SASE — which security layer you actually need once workloads move
- Cloud cost management basics — the four controls that reduce the bill, in payback order
- Hospitals in Singapore — how healthcare groups run their own referral and records infrastructure
Notes on sources
Tier definitions follow provider documentation and public pricing pages; committed-use terms and egress pricing are re-checked before publication. Verify current discounts before signing anything, because the commercial terms move faster than the technical ones.
Frequently asked questions
Is multi-cloud worth it for a mid-size company?
Rarely on cost alone. It pays when one workload has a regulatory or latency requirement the primary provider cannot meet, or when a single provider's commercial terms become unacceptable.
How long does an enterprise migration take?
Six to eighteen months for a meaningful workload set, dominated by identity, data movement and the long tail of applications nobody wants to own.
What should we measure first?
Cost per service, percentage of workloads with a named owner, and the share of steady-state compute under commitment. Those three numbers predict the bill better than any dashboard.
Do we need a platform team to use Kubernetes?
Effectively yes. Managed container services remove control-plane work but not the operational surface — upgrades, ingress, policy, observability.
MMarta K.
The identity section matches our experience exactly — we scheduled identity last and the programme slipped five months. Nobody believes it until it happens to them.