What do you actually get when you rent computing power from someone else’s data center? That question sounds simple, but the answer decides whether your cloud bill is predictable or a monthly shock, whether your data stays where the law requires, and whether your team spends its time building products or debugging someone else’s network. (NIST SP 800-145: The NIST Definition of Cloud Computing)
This guide walks through what public cloud means in precise terms, how the service models differ, where the real costs and risks hide, and what to check before signing anything. It is written for people who have to make or live with these decisions, not for people shopping for buzzwords.
What “public cloud” actually means
The most-cited formal definition comes from a US standards body, which describes cloud computing as a model for enabling on-demand network access to a shared pool of configurable computing resources, with five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. That definition dates from 2011, which matters. It predates most of the services sold today, so treat it as a baseline rather than a description of the current market.
The word “public” trips people up constantly. In the formal sense, a public cloud is infrastructure provisioned for open use by the general public and owned by a provider. It says nothing about whether your data is publicly accessible. A well-configured public cloud tenant is far more locked down than a badly configured private server in a closet.
The four deployment models, briefly
| Model | Who runs it | Typical use |
|---|---|---|
| Public | A provider, shared across customers | Most web apps, startups, variable workloads |
| Private | One organization, dedicated | Regulated data, legacy systems, strict control needs |
| Hybrid | Mix of both, connected | Burst capacity, phased migration, data residency |
| Community | Several organizations with shared needs | Research consortia, sector-specific platforms |
Most real estates end up hybrid whether or not anyone planned it. A company moves its web tier to a provider, keeps its ERP system on-premises because replacing it is a five-year project, and connects the two over a private link. That is hybrid, and it is the normal state of affairs.
The service models, and where the taxonomy breaks
The familiar split is infrastructure, platform, and software as a service. It remains the standard teaching frame, but the market has outgrown it. Function-as-a-service and serverless offerings, plus managed data and AI services, do not fit neatly into any of the three boxes. This is a definitional gap, not a settled taxonomy, so be suspicious of anyone who presents the three-tier model as complete.
The practical difference between the models is where the operational burden lands. In infrastructure as a service, you patch the operating system, harden the network, and manage the database. In platform as a service, the provider handles the runtime and you handle the application. In software as a service, you handle configuration and identity, and almost nothing else.
The shared responsibility line
The split of security duties between provider and customer is a contractual and operational concept, not a single universal standard. Its exact boundary shifts with the service model and with each provider. In infrastructure as a service, you own the guest operating system, the application, and the data. In software as a service, you own the data, the access policies, and the configuration choices. Getting this wrong is one of the most common and most expensive mistakes in cloud operations, because teams assume the provider is watching something it is not. (9481.org)
Why scale changes the economics
The central promise of public cloud is that you stop buying for peak load. You rent what you use, when you use it, and you stop when you stop. That works beautifully for spiky workloads and badly for steady ones. A service that runs flat out all year is often cheaper on reserved capacity or on your own hardware, and finance teams discover this roughly eighteen months after the migration party.
Market concentration shapes the economics too. Three providers dominate global cloud infrastructure spending, which means pricing pressure is real but so is lock-in. Egress fees, proprietary managed services, and discount structures that reward commitment all make switching harder than the sales deck suggests. Regulators have noticed. The EU Data Act, in force since January 2024, includes provisions on switching between cloud providers and on charges for switching, with obligations phasing in over time. If you are planning a multi-year contract in Europe, that phase-in schedule is worth checking carefully, because it is easy to misread.
A practical tip on cost visibility
Tag everything from day one. Every resource gets an owner, an environment, and a cost center. Teams that skip this step spend the next two years reconstructing who launched what. A clearer way to track cloud data transfer costs is worth reading before your first invoice surprise, because transfer and egress charges are the line item most people fail to forecast.
Security, compliance, and the rules that bind you
Public cloud security is not a product you buy. It is a set of configurations, identity policies, and monitoring practices that you maintain. The provider secures the building, the hypervisor, and the physical network. You secure everything above that line, and in most breaches, the failure is above the line.
Two regulatory frameworks come up in almost every serious procurement conversation.
For US federal work, the Federal Risk and Authorization Management Program standardizes security assessment for cloud services sold to federal agencies. It was established in 2011 and given a statutory basis by legislation enacted in December 2022. The program has been undergoing reform, so confirm the current process before you build a timeline around it.
For European personal data, the General Data Protection Regulation governs processing, including transfers to providers outside the EU and EEA. The EU–US Data Privacy Framework adequacy decision was adopted in July 2023, replacing the Privacy Shield that a court invalidated in 2020. Litigation risk around transatlantic transfers has not disappeared, so legal teams should treat adequacy as a current state rather than a permanent one.
There is also the question of digital sovereignty. A European cloud certification scheme has been contentious over how much it should require of non-European providers, and its final status has shifted repeatedly. Treat it as unsettled. If a vendor tells you their sovereignty question is fully resolved, ask for the specific scheme, version, and date.
What to check before you commit
Procurement is where public cloud decisions become expensive or cheap for years. The technical evaluation usually gets the attention; the contractual one usually determines the outcome.
- Map your data. Know which datasets are personal data, which are regulated by sector rules, and which must stay in a specific country. Do this before you look at a single price sheet.
- Model three years, not one. Include storage growth, egress, support tiers, and the cost of the staff you will need to hire or retrain.
- Read the exit terms. What does it cost to leave, and how long does migration take? Providers that make export easy tend to say so plainly.
- Check the certification list. Confirm the specific service you want appears on the relevant authorization or certification list, rather than checking only the provider’s overall status.
- Test the support tier you bought. Open a real ticket during the evaluation. The response you get tells you more than any SLA document.
What to inventory before a cloud migration covers the asset and dependency mapping in more depth, and it is the step most often compressed into a single workshop when it deserves a month.
Common mistakes that show up again and again
Teams lift and shift everything, then wonder why the bill doubled. They give every developer broad permissions because granular roles slow things down, then struggle to audit anything. They build a landing zone after the first workload instead of before it. They pick a region for latency and forget that the region announcement also determines which services and compliance certifications are available there. Learning how to read a cloud region announcement properly saves a surprising amount of rework.
Operating in public cloud after go-live
The work does not end at migration. It changes shape. The ongoing job is governance: identity, cost, and change management.
Identity is the new perimeter. Multi-factor authentication, short-lived credentials, and least-privilege roles do more for your security posture than any network appliance. If your organization still has long-lived access keys in application configs, that is the first thing to fix.
Cost management becomes a discipline rather than a project. Making cloud cost reviews useful to engineers is a genuinely hard problem, because the people who can reduce spend are rarely the people who see the invoice. The teams that succeed push cost data into the tools engineers already use and attach it to the services those engineers own.
Account structure matters more than most people expect. When to split workloads across cloud accounts explains how separate accounts create blast-radius boundaries, simplify billing attribution, and make permission models comprehensible. A single giant account is easy to start with and painful to untangle later.
Finally, keep an architecture decision record. Why did you choose that managed queue? What did you reject, and on what grounds? Two years from now, when someone proposes moving off it, that record is the difference between a reasoned review and an argument from memory.
Conclusion
Public cloud is neither a cost-saving machine nor a trap. It is a set of trade-offs: you give up some control and some predictability in exchange for elasticity, global reach, and access to services you could never build alone. The organizations that do well with it are rarely the ones with the most sophisticated architecture. They are the ones that mapped their data before signing, tagged their resources before the first invoice, drew clear lines of responsibility, and kept reading the rules as they changed. Start with the boring parts, and the interesting parts get much easier.
Frequently asked questions
Is public cloud less secure than a private data center?
Not inherently. A major provider employs more security specialists than most companies can hire, and its physical controls are usually stronger than an on-premises server room. The risk shifts to configuration. Misconfigured storage buckets, over-broad permissions, and unpatched guest systems cause most incidents, and those are the customer’s responsibility under the shared responsibility model.
What is the difference between public cloud and the internet?
A public cloud is a provider’s infrastructure offered to many customers, running on shared hardware with logical isolation between tenants. The internet is the network you use to reach it. Your workloads in a public cloud are not automatically reachable from the open internet; that depends entirely on how you configure networking and access controls.
Do we need a multi-cloud strategy?
Usually not at the start. Running two providers doubles the operational surface, the skills gap, and the governance work. Multi-cloud makes sense for specific reasons: regulatory requirements in a particular market, avoiding dependence on one vendor for a critical service, or acquiring a company that already uses a different platform. “Avoiding lock-in” alone is rarely enough to justify the overhead.
How do we keep cloud costs under control?
Four practices do most of the work: tag every resource with an owner, review spend monthly with the engineers who can act on it, right-size instances after a few weeks of real usage data, and watch data transfer charges separately because they behave differently from compute. Commitment discounts help only after you understand your baseline.
What does data residency actually require?
It requires knowing where data is stored, processed, backed up, and replicated, including metadata and logs. Choosing a region in the right country is necessary but not sufficient, because support access, disaster recovery, and managed service replication can move data elsewhere. Ask for the specific data flows in writing.
How long does a typical migration take?
It depends heavily on scope. A single application can move in weeks. An estate with dozens of interdependent systems, legacy databases, and compliance obligations typically takes a year or more, and the inventory and planning phase often consumes a third of that. Anyone quoting a fixed timeline before seeing your dependency map is guessing.
