What do a two-person startup, a hospital network, and a national tax agency have in common? All three can rent computing power by the minute instead of buying servers they might never fill. That shift is central to cloud computing use cases, and it explains why the question is no longer whether to use the cloud but which workloads belong there.
The most widely cited definition comes from NIST SP 800-145, published in September 2011, which describes cloud computing as a model for convenient, on-demand network access to a shared pool of configurable resources. It lists five essential traits: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Those traits are the lens for everything below. A use case fits the cloud well when it benefits from at least a few of them.
The service models, and why the labels blur
Before the use cases, a quick map. The same NIST document distinguishes three service models: Infrastructure as a Service (IaaS), where you rent raw compute, storage, and networking; Platform as a Service (PaaS), where the provider manages the runtime and you bring the code; and Software as a Service (SaaS), where you simply use someone else’s application.
In practice, the boundaries are messier than the taxonomy suggests. Containers-as-a-service and serverless functions do not map cleanly onto any single bucket. Teams that argue about labels waste time. Teams that ask “who patches the operating system?” get useful answers. That question, more than any acronym, tells you what you are really buying.
The four deployment models, also from NIST, are private, community, public, and hybrid cloud. Multi-cloud, meaning several public providers at once, is a later industry term and not part of that document.
Web and mobile applications that need to breathe
Hosting a public-facing application is the archetypal use case, and it is still the one most organizations start with. The appeal is elasticity: capacity that follows demand instead of being provisioned for the worst hour of the year.
Consider a retailer whose traffic triples during a seasonal sale. On owned hardware, it pays for peak capacity all year. In the cloud, it pays for peak capacity during the peak. That is the theory, anyway. In practice, many teams over-provision “just in case” and quietly rebuild the old cost structure. The ones who win set autoscaling policies, test them under load, and review the bill monthly.
A common mistake here is treating the cloud as a faster data center. Lifting an application unchanged and expecting savings rarely works. Applications designed to scale horizontally, with stateless components and externalized sessions, capture far more of the benefit. This is where architecture decisions matter most, and it is worth reading up on cloud infrastructure and architecture before committing to a migration plan.
Backup, disaster recovery, and long-term archives
Data protection is one of the least glamorous and most reliable cloud use cases. Off-site backup used to mean tapes in a vault or a second data center. Now it can mean object storage in a different region, replicated automatically. (9481.org)
Disaster recovery benefits from the same logic. A standby environment that sits idle most of the year is expensive to own and cheap to rent, especially if you can bring it online in minutes rather than days. Recovery point and recovery time objectives become engineering targets rather than wishful thinking.
Public-sector records offer a useful reference point. The US National Archives and Records Administration publishes records management bulletins that address cloud storage for federal records, which is a good model for anyone who has to prove that archived data stays intact, findable, and lawfully retained. Retention rules, legal holds, and deletion schedules need to be designed before the first byte lands in a bucket, not after an audit.
Big data analytics and batch processing
Some jobs are naturally bursty. Training a model, reprocessing a year of logs, or running a nightly risk calculation may need hundreds of machines for a few hours and none for the rest of the week. Renting that capacity is close to ideal.
This pattern has deep roots in research computing. University and government-funded programs have used cloud credits to support large-scale analysis since roughly the early 2010s, and the model has since spread into finance, genomics, and media processing. The economics work because the work is finite. The trap is leaving a cluster running over a long weekend. Tagging, budgets, and automatic shutdown policies are not bureaucracy; they are the difference between a successful project and a surprising invoice.
Data transfer deserves special attention in analytics workloads. Moving large datasets between regions or out of the cloud can cost more than the compute itself, so it pays to learn a clearer way to track cloud data transfer costs before the first big job runs.
SaaS for productivity and collaboration
By user count, the largest cloud category is probably the least discussed: email, documents, video meetings, and customer management delivered as software. Nobody calls it a cloud project, yet it is the cloud use case most employees touch every day.
The trade-offs are real. You gain zero-maintenance upgrades and access from anywhere. You give up some control over update timing and data location. For regulated industries, the questions to ask are where data is stored, who can access it, and what happens when the contract ends. Those are procurement questions, not technical ones, and they belong in the contract.
Security, compliance, and regulated workloads
Security is both a use case and a constraint. Hosting regulated workloads in the cloud requires evidence that controls work. Two frameworks come up constantly.
In the US, the Federal Risk and Authorization Management Program, known as FedRAMP, authorizes cloud services for federal use and has shaped how vendors document their controls since it launched in 2011. It has been undergoing reorganization in recent years, so check the current status before relying on any summary. Internationally, ISO/IEC 27017:2015 provides a code of practice for cloud-specific information security controls, extending the general ISO/IEC 27001 family with guidance on shared responsibilities between provider and customer.
That shared responsibility model is the concept most often misunderstood. The provider secures the building, the hypervisor, and the physical network. You secure your configuration, identities, and data. Misconfigured storage buckets remain a leading cause of breaches, and no certificate prevents them. Enterprise AI and cloud security practices deserve the same scrutiny as any on-premises control set, arguably more, because a single wrong setting can expose data globally in seconds.
Government and public-sector cloud programs
Public-sector adoption has been driven by policy as much as by technology. The US “Cloud First” policy, issued in 2010, told federal agencies to consider cloud options first; “Cloud Smart,” from 2018, refined that into a more pragmatic stance. In Europe, the Gaia-X initiative, founded in 2019, and the EU Cloud Rulebook pursue a different goal: federated infrastructure with strong data-sovereignty guarantees.
These are policy documents, not technical standards, and they change. Anyone citing them should check the current version. The practical lesson for private organizations is that procurement rules often shape architecture more than engineering preferences do. If a regulator requires data residency in a specific country, that requirement eliminates certain regions before any design discussion begins. Learning how to read a cloud region announcement is a genuinely useful skill for exactly this reason.
AI and machine learning workloads
Training and serving models has become one of the fastest-growing cloud use cases, and also one of the most expensive. The hardware matters: GPUs and specialized accelerators are scarce, costly, and often available only in specific regions. Understanding AI chips and computing infrastructure helps teams plan capacity instead of discovering mid-project that the instance type they need is unavailable.
Two patterns dominate. The first is training in the cloud and serving on-premises, chosen when latency or data gravity favors local hardware. The second is fully managed, where the provider handles the infrastructure and the team focuses on models. Both are legitimate. The failure mode is running experiments on expensive accelerators around the clock because nobody set a budget alert.
Migration, inventory, and account structure
Most organizations end up with a mix of use cases, and the hard part becomes organization rather than technology. Two habits separate calm cloud estates from chaotic ones.
First, inventory before you move. A clear picture of what you run, who depends on it, and how it talks to everything else prevents most migration surprises. A practical checklist for what to inventory before a cloud migration is worth working through before the first workload moves.
Second, split accounts deliberately. Separate accounts for production, development, and each major application limit the blast radius of mistakes and make cost attribution possible. There is a sensible point at which to split workloads across cloud accounts, and it usually arrives earlier than teams expect.
Where the cloud fits less well
Balance matters. Some workloads are poor fits. Very steady, predictable compute can be cheaper on owned hardware over several years. Applications with hard real-time requirements may suffer from network variability. Extremely large datasets can make egress fees painful. Legacy software with licensing tied to physical cores may not be economically portable at all.
None of this argues against the cloud. It argues for matching workload to environment, which is what the NIST characteristics were always meant to help you do.
Conclusion
Cloud computing use cases range from a startup’s first web server to a government’s records archive, and the good ones share a pattern: they exploit elasticity, measured service, or geographic reach in a way that owned infrastructure cannot match. The poor ones treat the cloud as a data center with someone else’s logo on the door. Start with the workload, ask who patches what, watch the bill, and let the deployment model follow the requirements rather than the other way around. The organizations that get this right rarely talk about “going to the cloud.” They talk about which problem they are solving this quarter.
What are the main cloud computing use cases?
The most common are web and mobile application hosting, backup and disaster recovery, big data analytics, SaaS productivity tools, AI and machine learning workloads, and regulated workloads that need documented security controls. Most organizations run several at once rather than picking one.
What is the difference between IaaS, PaaS, and SaaS?
IaaS rents raw infrastructure such as servers and storage. PaaS provides a managed runtime where you deploy code. SaaS delivers a finished application you simply use. The lines blur with containers and serverless, so ask who manages patching and operations rather than relying on the labels.
Is cloud computing cheaper than owning servers?
Sometimes, and not automatically. The cloud wins when demand is variable or growth is uncertain, because you pay for what you use. Steady, predictable workloads can be cheaper on owned hardware over several years. Savings depend on architecture, discipline, and how well teams rightsize resources.
What is the shared responsibility model?
It is the division of security duties between provider and customer. The provider secures physical facilities, hardware, and the underlying platform. The customer secures identities, configurations, access policies, and data. Most cloud breaches trace back to customer-side configuration, not provider failures.
Which workloads should stay off the cloud?
Workloads with hard real-time requirements, very steady compute demand, licensing tied to physical hardware, or massive datasets that would incur heavy egress fees are candidates to keep on-premises. The decision should follow measured costs and latency needs, not fashion.
How do organizations control cloud costs?
Tag every resource, set budgets and alerts, shut down idle environments automatically, and review the bill monthly with engineering present. Data transfer and forgotten non-production environments are the two most common sources of avoidable spend.
