Cloud vs on-prem: what are the real trade-offs?
Quick answer: on-prem gives you fixed costs and full control at the price of capacity you must buy ahead of demand and staff to maintain; cloud gives you elastic, pay-for-what-you-use infrastructure and managed services at the price of ongoing spend that scales with usage (and can surprise you) — most organisations end up hybrid, not purely one or the other, and the access/security model has to work identically across both.
Capital vs operating cost
On-prem is a capital-heavy model: buy the servers, storage, and networking gear up front, sized for peak demand you may only hit a few times a year, then depreciate it over years while staff maintain it. Cloud flips that to operating cost: pay for what you provision, when you provision it, and scale down when demand drops — see What is cloud computing and how does it fit into the DevOps era? for the elasticity argument in full. The trade-off is that operating cost is easier to start with but harder to forecast — a badly configured auto-scaling group or an unused environment left running can quietly cost more over a year than the on-prem box it replaced.
Control vs managed convenience
On-prem gives full control over hardware, network topology, and data location — valuable for regulatory or latency-sensitive workloads, and for organisations that already have the capacity and staff to run it well. Cloud trades that control for managed services (databases, queues, WAF, DNS) you do not have to patch or scale yourself, at the cost of being bound to the provider's roadmap, pricing, and outages.
Where hybrid actually shows up
Most real organisations aren't "all cloud" or "all on-prem" — they run some workloads on-prem (legacy systems, data-residency-bound systems, steady predictable load) and some in the cloud (spiky demand, new development, anything needing managed services), connected together. That split is exactly the multisite/connectivity problem in How do you connect multiple sites and offices with cloud-based communications? — and it means whatever access model you pick (VPN or Zero Trust) has to cover the on-prem data centre and the cloud VPC identically, or you end up running two separate access systems with two separate sets of stale accounts.
Practical takeaway
The trade-off is rarely "which is cheaper" in isolation — it is "which workload profile fits which cost model," plus whether your access/security tooling can span both without doubling admin overhead. Running Zero Trust/Access across a hybrid estate is exactly where seat counts drift from actual usage (on-prem admins added years ago, cloud contractors added recently, nobody reconciling the two) — the kind of drift a Zero Trust seat audit is built to catch.