What happens when a company “moves to the cloud”? Often, it rents computing power from someone else’s data center, paying by the hour or by the second. That arrangement is the public cloud, and it now runs a huge share of the software people use every day.
The idea sounds simple, but the details matter. Who owns the hardware? Who controls the data? What happens when a provider raises prices or changes its terms? This article walks through the definition, the service and deployment models, the real trade-offs, and the rules that govern public cloud use in the United States and Europe.
What Is the Public Cloud?
The most widely cited definition comes from the U.S. National Institute of Standards and Technology. NIST describes cloud computing as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be provisioned quickly with minimal management effort. The same document, NIST SP 800-145, published in September 2011, sets out five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.
The public cloud is one of four deployment models in that framework. NIST defines it as infrastructure provisioned for open use by the general public. It sits on the premises of the cloud provider, and the provider’s organization owns, manages, and operates it. The other three models are private, community, and hybrid clouds.
A common misunderstanding: “public” does not mean anyone can read your data. It means the underlying hardware is shared and offered to any customer who signs up. Your workloads are logically isolated from other tenants through virtualization, network controls, and identity management. The provider’s staff do not browse your databases for fun, and contracts and audits back that up.
The Three Service Models, in Plain Terms
NIST also defines three service models, and they remain the clearest way to sort through vendor marketing.
| Model | What the provider manages | What you manage | Typical use |
|---|---|---|---|
| IaaS (Infrastructure as a Service) | Servers, storage, networking, virtualization | Operating systems, middleware, applications, data | Lift-and-shift migrations, custom stacks |
| PaaS (Platform as a Service) | Everything in IaaS plus runtime and middleware | Applications and data | App development without server upkeep |
| SaaS (Software as a Service) | The entire stack | Configuration, users, and your data | Email, CRM, collaboration tools |
In practice, most organizations mix all three. A company might run virtual machines for a legacy system, deploy new services on a managed platform, and pay for SaaS tools for HR and accounting. The lines blur further with functions-as-a-service and managed databases, which sit between IaaS and PaaS. (9481.org)
Who Runs the Public Cloud?
Three providers dominate the infrastructure market: Amazon Web Services, Microsoft Azure, and Google Cloud. AWS is generally reported as the largest, though exact shares shift every quarter and depend heavily on which analyst is counting. Figures from different research firms rarely agree, because they measure different things, such as infrastructure only versus infrastructure plus platform services.
Market size estimates have the same problem. Analysts have repeatedly projected worldwide public cloud spending in the hundreds of billions of dollars annually, with double-digit growth. Treat any specific number as time-stamped. If a figure matters to a business case, pull it from the current forecast release and note the publication date.
That concentration has drawn regulatory attention. Competition authorities in the United Kingdom and the European Union have examined lock-in, egress fees, and licensing practices in cloud infrastructure. The UK Competition and Markets Authority opened a cloud services market investigation in 2023, and the European Commission has reported proceedings of its own. Outcomes change, so check the current status rather than relying on older summaries.
What Public Cloud Is Good At
The advantages are real and well documented.
Speed. A team can spin up a database in minutes instead of waiting weeks for hardware procurement.
Elasticity. Capacity scales up for a product launch and back down afterward. You pay for what you use, at least in theory.
Global reach. Providers operate regions on every inhabited continent. Deploying close to users reduces latency without building data centers.
Managed services. Databases, message queues, machine learning toolkits, and security tooling come as services. That shifts undifferentiated work off internal teams.
Capital to operating expense. Instead of buying servers, an organization pays a monthly bill. For many finance teams, that is a feature, not a bug.
The trade-off is that costs become variable and can drift. A team that leaves a test environment running over a long weekend discovers this quickly. A clearer method for tracking cloud data transfer costs matters: compute is only part of the bill, and sneaky line items often relate to network and storage.
Where Public Cloud Hurts
Honest assessments list the drawbacks too.
Cost unpredictability. Pay-as-you-go pricing rewards discipline. Without tagging, budgets, and reviews, spending creeps. Engineers who understand the bill make better choices, which is the argument behind making cloud cost reviews useful to engineers rather than treating cost as a finance-only problem.
Lock-in. Proprietary services are convenient until you try to leave. Moving a workload built on a provider’s unique database or messaging system to another provider can take months. The EU Data Act includes provisions meant to make switching between cloud providers easier; the regulation sets out those obligations and the dates they apply.
Shared responsibility confusion. The provider secures the physical facility and the underlying platform. You secure your configurations, identities, and data. Most breaches trace back to customer-side misconfiguration, not provider failure. Teams that assume “the cloud is secure by default” learn this the hard way.
Compliance complexity. Data location, residency, and transfer rules do not disappear when data moves to a provider. They get more complicated.
Compliance and Sovereignty: The Rules That Shape Adoption
Public cloud adoption in regulated sectors depends heavily on legal frameworks.
In the United States, federal agencies generally require cloud services to go through FedRAMP, the Federal Risk and Authorization Management Program, established in 2011. It standardizes security assessment and authorization so an agency does not have to audit every vendor from scratch. The FedRAMP program site explains how authorization works and which products have it.
In Europe, the General Data Protection Regulation (Regulation (EU) 2016/679), applicable from 25 May 2018, governs how personal data is processed, including in cloud arrangements, and restricts transfers of personal data outside the EU and European Economic Area. The official GDPR text on EUR-Lex is the authoritative source. For many organizations, the practical question is not whether a provider is compliant but whether the specific configuration, contract, and data flow are.
Sovereignty has become its own topic. European institutions have been developing frameworks that grade cloud offerings by how much control stays within EU jurisdiction. The European Commission published a draft EU Cloud Sovereignty Framework in 2025, proposing sovereignty levels for public-sector cloud procurement. Details and status move quickly, so anyone citing a sovereignty framework should verify the current version before building a procurement decision on it.
The EU Data Act (Regulation (EU) 2023/2854) adds another layer, with provisions on switching between cloud providers and on access to data held by connected products. It entered into force in January 2024 and applies from 12 September 2025. The application date should be verified against the official text.
Public, Private, or Hybrid: Choosing a Deployment Model
The deployment question is rarely all-or-nothing.
| Consideration | Public cloud | Private cloud | Hybrid |
|---|---|---|---|
| Upfront cost | Low | High | Medium |
| Scaling speed | Fast | Limited by hardware | Mixed |
| Control over hardware | Low | High | Mixed |
| Compliance flexibility | Depends on provider | High | High |
| Operational burden | Shared | Mostly internal | Split |
A practical pattern: keep regulated or latency-sensitive workloads in a private environment, run customer-facing and bursty workloads in the public cloud, and connect the two with private networking. Before committing, it helps to know what to inventory before a cloud migration: applications, dependencies, data classifications, and owners. Skipping that step is the most common cause of migration surprises.
Organizations that grow quickly also face an account-structure question. One giant account becomes ungovernable; too many small ones become unmanageable. There is a useful rule of thumb for when to split workloads across cloud accounts, usually around billing boundaries, security isolation, and team ownership.
Practical Tips That Actually Work
Advice from teams that run public cloud at scale tends to converge on a few points.
- Tag everything from day one. Cost allocation, ownership, and environment tags are painful to add later.
- Set budgets and alerts before the first production workload. Not after the first surprise invoice.
- Use infrastructure as code. Manual console changes are undocumented changes. Code is reviewable.
- Centralize identity. One identity provider, strong multi-factor authentication, least privilege. Most cloud incidents start with a compromised credential.
- Read the region announcements. New regions affect latency, data residency, and pricing. Knowing how to read a cloud region announcement helps separate marketing from what actually changes for your workloads.
- Test the exit before you need it. Export a dataset, restore a backup elsewhere, and document the process. If nobody has tried, assume it does not work.
- Review the shared responsibility model for every service. A managed service shifts some duties to the provider, but rarely all of them.
Common mistakes show up again and again: leaving default network settings in place, granting broad permissions because narrow ones take time, ignoring egress costs when designing architectures, and treating the cloud bill as unchangeable. None of these are exotic. They are ordinary operational hygiene problems wearing new clothes.
Security in the Public Cloud
Security in a shared environment depends on isolation and on customer discipline. Providers invest heavily in physical security, hardware supply chains, and hypervisor isolation. Customers are responsible for patching their systems, managing keys, and configuring storage and network access correctly.
A few practices consistently separate mature teams from struggling ones. Encryption keys are managed centrally, not scattered across projects. Logging is centralized and retained long enough to investigate incidents. Access is reviewed on a schedule rather than after an audit finding. And security teams have visibility into what is deployed, which requires an accurate inventory. For organizations building this out, enterprise AI and cloud security guidance covers how these controls fit together as AI workloads join the estate.
Conclusion
The public cloud is neither a magic cost-saver nor a trap. It is a set of rented infrastructure and services with clear characteristics: shared hardware, on-demand provisioning, measured billing, and a provider that owns the physical layer. It excels at speed, elasticity, and access to managed services. It punishes poor governance with unpredictable bills, configuration-driven breaches, and lock-in that is expensive to undo.
The organizations that do well with it tend to be unglamorous about the basics. They tag resources, centralize identity, automate deployments, review costs with the engineers who create them, and understand the compliance rules that apply to their data. They also keep an exit plan, even if they never use it. Whether the workload sits in a public, private, or hybrid environment matters less than whether someone clearly owns it and understands what the provider is and is not responsible for.
FAQ
What is the difference between public cloud and private cloud?
The public cloud is owned and operated by a provider and offered to any customer, with resources shared across tenants and isolated through virtualization. A private cloud is dedicated to a single organization, either on its own premises or hosted by a third party. Public cloud offers faster scaling and lower upfront cost; private cloud offers more control over hardware and data location. (How to read a cloud region announcement) (Cloud computing)
Is public cloud data secure?
It can be, but security is shared. Providers secure the physical facilities and underlying platform, while customers secure their configurations, identities, and data. Most incidents stem from customer-side mistakes such as exposed storage or overly broad permissions. Strong identity controls, encryption, and centralized logging are the basics that matter most.
What are IaaS, PaaS, and SaaS?
These are the three service models. IaaS rents raw infrastructure such as virtual machines and storage. PaaS adds runtime and middleware so teams deploy code without managing servers. SaaS delivers complete applications, such as email or CRM, that the customer configures but does not operate. Most organizations use a mix of all three.
Why do companies worry about cloud lock-in?
Proprietary services are convenient but hard to replicate elsewhere. Moving a workload built on a provider-specific database or messaging system to another provider can take significant time and money. Contracts, egress fees, and data formats all affect how easily an organization can switch. Testing an exit before it is needed is the practical safeguard.
Does the public cloud always save money?
No. Pay-as-you-go pricing can be cheaper than owning hardware, especially for variable workloads, but costs drift without governance. Idle resources, oversized instances, and data transfer charges are common sources of waste. Organizations that tag resources, set budgets, and review spending regularly usually see better results than those that simply migrate and hope.
What rules govern public cloud use in regulated sectors?
In the United States, federal agencies typically require cloud services to be authorized through FedRAMP. In Europe, the GDPR governs processing of personal data and restricts transfers outside the EU and EEA. Sector rules and national laws add further requirements. The specific configuration and contract matter as much as the provider’s certifications.
