When Does Cloud Computing Make Sense? Four Honest Scenarios

"We need to be in the cloud" is the most common sentence in IT strategy and the least useful. It describes an aspiration, not a decision. Cloud computing is a deployment target, the same way a colocation cage or an on-premises closet is a deployment target. The question is never whether to use the cloud. The question is which workloads belong there and why.

After moving hundreds of workloads both ways — on-prem to cloud and cloud to on-prem — these are the four scenarios where we think the cloud genuinely earns its price tag, and the honest edges around each one.

1. Your demand is genuinely elastic

This is the original cloud value proposition and the one it still delivers on. If your workload has a real peak-to-trough ratio of 4x or more — seasonal retail, tax-season accounting software, back-to-school registration, event-driven batch processing, a service that gets a weekly spike from a marketing campaign — then paying by the hour for capacity you only need sometimes is cheaper than owning capacity for the peak and letting it sit idle.

The honest edge: most workloads are not elastic. They run at roughly the same load every day. Finance teams and CFOs like the idea of elasticity because it sounds like efficiency, but if you measure your actual utilization curve over a full year, you will usually find that the "peaks" are within 30 percent of the baseline. That is not elastic demand. That is normal business variation, and it is cheaper to handle with a fixed infrastructure sized to the top of the normal range.

Before you pay the cloud premium for elasticity, measure. If your peak-to-trough ratio is under 2x, the math almost never works in cloud's favor for steady-state compute.

2. You need global distribution faster than you can build it

If you need to put an application in front of users in North America, Europe, and Asia next quarter, the hyperscalers have already built the data centers, the backbone, the CDN edge, and the DNS. You can launch in six regions in an afternoon. Building that yourself would take years and a capital budget you do not have.

This is where cloud is unambiguously the right answer, and where we happily recommend it. SaaS products, customer-facing web applications, mobile backends, content distribution, anything where latency to the end user is a competitive feature — put it in public cloud and do not look back. The value is not the compute. It is the global footprint you are effectively renting.

The honest edge: a lot of "global" applications are actually regional. If 90 percent of your users are in one country, you do not need six regions. You need one region and a good CDN, and the cost profile changes dramatically.

3. You are doing something brand new and you do not know what you need

Greenfield projects are the other place cloud shines. When you are building a new product, you do not know what the traffic pattern will look like, how the database will grow, what the storage profile will be, or whether the project will still exist in six months. Committing capital to on-prem hardware for a workload you cannot size is a bad bet. Renting capacity by the hour while you figure it out is a good one.

The honest edge: once the product stabilizes, the economics flip. We have watched customers run a successful SaaS product on AWS for three years, post a cloud bill that has become a board-level concern, and then repatriate 70 percent of the steady-state workload to a private cloud for a fraction of the cost while keeping the burst capacity in AWS. The cloud was right for the first three years. It was wrong for the next five. Revisit the decision when the workload matures. Do not treat it as permanent because migration is expensive.

4. You need a specific managed service that is genuinely hard to run yourself

Some managed services in the hyperscaler catalogs are legitimately valuable because the thing they manage is hard to operate. A globally replicated NoSQL database. A managed Kubernetes control plane with certified upgrades. A serverless event bus with guaranteed delivery semantics. A real-time data warehouse. These are services where the engineering effort to build and operate the equivalent yourself would cost more than the cloud bill, and where the cloud version just works.

This is a narrow list. It does not include everything with "managed" in the name. Managed PostgreSQL on any hyperscaler is fine, but it is not magic — running PostgreSQL on a VM with good backups is not hard and is usually cheaper. Managed Redis is the same story. Managed file storage is often worse than running your own NFS on Linux with ZFS. Do not assume "managed" means "cheaper" or "better." Sometimes it does. Often it just means "metered by the GB."

The honest edge: every managed service you adopt is a lock-in decision. You are trading engineering effort today for portability tomorrow. That can be the right trade, but make it consciously. The managed services you should pay for are the ones where the engineering effort to replace them later is less than the engineering effort to build them yourself now. A lot of managed services fail that test once you think about it for ten minutes.

When cloud is the wrong answer

It is worth naming the scenarios explicitly because nobody in the cloud marketing ecosystem will say them out loud. Cloud is the wrong answer when your workload is steady-state and predictable. When your data sovereignty requirements mean you need to know exactly where bytes are at all times. When your bandwidth egress costs would dwarf the compute savings. When your team does not have the FinOps maturity to keep the bill from drifting. When regulatory or contractual requirements make the shared-tenancy model complicated. When you are running it because a consultant told you to without running the numbers.

We meet customers every quarter who adopted cloud for one of those wrong reasons and are paying for it. The repatriation conversation is usually uncomfortable because it feels like admitting a mistake. It is not a mistake. It is how you learn what your workload actually needs. The companies that run the cheapest, most reliable infrastructure we see are the ones that made cloud decisions per workload rather than per company, revisited them every year or two, and were not emotionally committed to either answer.

The short version

Cloud computing makes sense when the workload is elastic, global, new, or genuinely hard to run yourself. It does not make sense because a vendor, a consultant, or a conference said so. Run the math on your specific workloads, not on the industry average. The answer for your business might be "cloud." It might be "private cloud." It is almost always "both, in the right proportions, and revisited every year." That is a less exciting answer than "we are all-in on the cloud," and it is the one that actually works.