Cloud Computing Explained: What the Cloud Really Is and How It Works

Every network diagram you have ever seen has a cloud in it. Engineers started drawing that shape in the 1960s for the part of the network they did not want to explain. The habit stuck. Cloud computing is the delivery of computing resources as a service over the internet, paid for by usage instead of bought and maintained in-house. The provider owns the servers, the storage and the network and keeps them running. You decide what to consume and you pay only for what you use.

Behind that plain idea sit five formal characteristics, three service models and several deployment models, plus a split of responsibilities you want to understand before you move a single workload. Get that split wrong and you pay for it in the invoice, in the audit or in both.

Here is what I will walk you through: the official NIST definition, how the model changed the way IT is paid for, IaaS, PaaS and SaaS, the deployment models, who the big providers are, what they sell, the real advantages, the real risks, security, cost control and the mistakes I keep seeing. By the end you should be able to tell what to rent and what to keep at home.

What is cloud computing? The NIST definition

The reference definition comes from NIST, the National Institute of Standards and Technology. Its document SP 800-145 (2011) describes the cloud as on-demand access to a shared pool of configurable computing resources that can be provisioned and released with minimal management effort or provider interaction.

Two words do most of the work there: shared and on-demand. Shared means the provider serves many customers from the same physical plant. On-demand means you get a slice of it in minutes, not after a procurement cycle. That combination is what separates a cloud service from a traditional hosting contract, where you reserve a fixed box and pay for it whether you use it or not.

From that definition NIST derives the five essential characteristics a real cloud service has to meet:

• On-demand self-service. You provision a machine, a database or storage yourself, through a console or an API, without waiting weeks for someone to rack a server.
• Broad network access. Resources are reachable over the network from any device, using standard mechanisms.
• Resource pooling. The provider serves many customers from a shared pool and reassigns capacity as demand moves.
• Rapid elasticity. Capacity grows or shrinks in near real time, often automatically, so you can follow the load curve.
• Measured service. Usage is metered and billed, which is why you pay for consumption instead of for a machine.

If a service fails any of those five, it sits closer to a familiar data centre contract than to a cloud. That matters, because sales decks call everything «cloud» these days. Ask which characteristic it meets and the marketing gets thin fast.

How it works: from owning servers to paying per use

Before the cloud, shipping a new service meant buying servers, racking them in a data centre, hiring people to keep them alive and replacing the hardware every few years. That is capital expenditure, or capex, and you pay it whether the capacity is used or not. A machine bought for a peak that never arrives still costs the same.

The cloud turns that bill into operating expenditure, or opex. You rent capacity and pay for what you consume. The provider absorbs the disks, the cooling and the refresh cycle. You concentrate on the application. Scaling stops being a construction project: if a database needs more headroom, you change one setting and it is ready in minutes.

Keep one thing straight. When you rent an instance you are still running an operating system and software on top of it. The cloud removes the physical layer, and it leaves the responsibility for what you put above it exactly where it was. That shift toward networked services is part of the wider history of operating systems.

The word itself is an old metaphor, as I said at the top. It took off around 2000 to describe services hosted on remote servers. Nothing about the drawing changed. What changed was that the cloud stopped being a placeholder and became something you could rent by the hour.

The three cloud service models: IaaS, PaaS and SaaS

They differ in how much the provider manages and how much is left to you. The higher you go toward SaaS, the less control and the less operations you take on. The lower you go toward IaaS, the more flexibility and the more responsibility you get back. There is no free lunch at either end of that scale.

	IaaS	PaaS	SaaS
What it offers	Machines, storage and networking on demand	A complete environment to build and run applications	Ready-to-use applications over the internet
The provider manages	Virtualisation, hardware and the physical network	Infrastructure, operating systems, middleware and runtime	The entire application, including data and updates
You manage	Operating system, patches, software and applications	Only the application and its data	Usage and user administration
Level of control	High	Medium	Low
Examples	Amazon EC2, Azure Virtual Machines, Compute Engine	Azure App Service, AWS Elastic Beanstalk, Google App Engine	Microsoft 365, Google Workspace, Salesforce

IaaS: infrastructure as a service

IaaS hands you the building blocks: virtual machines, storage, networks and IP addresses. It is the model closest to a data centre and the one with the most control, because you remain responsible for the operating system, the patches and whatever software you install. AWS documentation describes it as the foundation the other models build on.

PaaS: platform as a service

PaaS adds a layer of abstraction. The provider runs the infrastructure, the operating system, the middleware and the runtime. You take care only of your application and its data. It is convenient for building without administering servers, at the price of less control. Google Cloud sums it up as focusing on the code rather than the machine.

SaaS: software as a service

SaaS is the model most people already use without thinking about it: complete applications delivered over the internet, where the provider handles everything, from infrastructure to updates to availability. The user signs in and works. Webmail, an office suite or a cloud CRM are the obvious examples. The trade-off is the least control of the three, because you configure what the product exposes and not much more.

Deployment models: public, private, hybrid and community

The service model says what you consume. The deployment model says where and for whom. NIST recognises four, plus multi-cloud as a common practice in the real world.

Public cloud

The infrastructure belongs to the provider and is shared among many customers, logically isolated from one another. It is the model of AWS, Azure, Google Cloud, Oracle and IBM Cloud: anyone can rent capacity in minutes. It offers the greatest elasticity and the lowest entry cost. In return, physical control and much of the configuration rest with the provider.

Private cloud

The infrastructure is dedicated to a single organisation, either in its own data centre or run by a third party. It brings more control, compliance and predictability. It also demands investment and staff, and it gives up part of the public cloud’s elasticity. Banks, healthcare providers and public bodies often choose it for regulatory reasons.

Hybrid cloud

It combines two or more infrastructures, say a private one and a public one, that remain separate entities but are joined by technology that lets data and applications move between them. NIST defines it by exactly that portability. It is the usual answer when part of the workload cannot leave the premises while another part can take advantage of public elasticity. Connecting the two worlds needs well-sized networks and links.

Community cloud

Several organisations with shared interests, whether a common mission, security requirements or regulation, share it and manage it together. It is less common, but NIST keeps it as the fourth deployment model.

Multi-cloud

Multi-cloud sits outside the NIST list. Treat it as a strategy: using services from several providers at once for price, to avoid depending on a single one, or to exploit a particular strength of each platform. The cost is more complexity in management, security and billing. Three providers mean three sets of credentials, three dashboards and three invoices.

Who the major cloud providers are

The market is led by Amazon Web Services (AWS), Microsoft Azure and Google Cloud, followed by Oracle Cloud, IBM Cloud, Alibaba Cloud and Salesforce. For the buyer, the catalogue is increasingly similar. The differences that matter are the ecosystem, the pricing, the regions and the compliance certifications. All three big providers publish well-architected frameworks (AWS, Azure and Google) that work as a useful checklist of what a sound cloud design is expected to do.

What services are offered in the cloud

Beyond virtual machines, the catalogue usually includes:

• Object and file storage: an almost unlimited remote «hard drive» for backups, media and data.
• Managed databases: relational (SQL Server, PostgreSQL, MySQL) and NoSQL (document, key-value), with backups and patches included.
• Analytics and data lakes: storing and querying large volumes, structured or not.
• Networking services: virtual networks, gateways between your local network and the cloud, load balancers and managed firewalls.
• Serverless computing and containers: running code or packaged applications without managing machines, or reaching those machines over SSH when you need to.
• Artificial intelligence, machine learning and IoT: pre-trained models, training capacity and management of connected devices.

Advantages of cloud computing

The underlying benefit is that effort shifts from maintenance to the product. IT stops losing time buying hardware or scaling servers and spends it on applications instead. In practice:

• Low upfront cost and pay-as-you-go billing: you do not buy infrastructure you may never use.
• Elasticity: capacity follows demand, both up and down.
• Global reach: you can launch a service in several regions without opening data centres.
• Less operational load: patching, replication and high availability fall largely to the provider.
• Managed services: databases, queues, AI or monitoring are consumed without building them from scratch.

Risks and limitations

The cloud is neither free nor infallible. The most real risks are:

• Runaway cost. Pay-per-use punishes neglect: a resource left running and unused keeps on billing.
• Provider dependency (vendor lock-in): the more proprietary services you adopt, the more expensive it becomes to switch platforms.
• Misconfiguration. The provider secures the infrastructure, not your data or your permissions. Most incidents start with a configuration mistake.
• Latency and connectivity. If the network fails or the region is far away, the application feels it.
• Compliance and data residency. Data can end up in another country, with legal consequences.
• Loss of control over versions and maintenance windows the provider imposes.

Cloud security and compliance

The key idea is the shared responsibility model. The provider answers for security of the cloud, meaning facilities, hardware, hypervisor and physical network. The customer answers for security in the cloud: data, configuration, identities and permissions. Microsoft spells this out in its shared responsibility guidance, and AWS and Google apply the same logic. The exact dividing line moves with the service model. In IaaS you patch the operating system. In SaaS the provider does.

That is why security is played out above all in identity and access management. Applying least privilege and organising permissions through role-based access control (RBAC) keeps a single compromised account from reaching everything. Multi-factor authentication, encryption and network segmentation cover the rest. Most cloud incidents I have seen did not need a clever attacker. They needed one password with too many rights.

On the regulatory side, the EU’s GDPR governs personal data and international transfers. In Spain, the Esquema Nacional de Seguridad sets basic, medium and high categories for the public sector and its suppliers, and the AEPD is the data protection authority. For cloud specifically, the ISO/IEC 27017 and ISO/IEC 27018 standards cover security controls for cloud services and for personal data in the cloud. Any provider you consider should be able to show which certifications it holds in each region you use.

Cost management and FinOps

Cloud pricing is flexible and easy to lose track of. You pay for consumption: compute, storage, requests, data transfer. There are discounts for reservations or committed use. The gap between a reasonable invoice and an unpleasant surprise usually comes down to discipline, not to the provider.

That is what FinOps is for: a practice that combines technology, finance and business to decide with data. The FinOps Foundation framework sums the cycle up in three phases: inform (visibility and cost tagging), optimise (shut down what sits idle, right-size instances, pick the best purchasing model) and operate (budgets, alerts and accountability by team).

Measures that pay off immediately: tag resources, review idle ones, switch off development environments outside working hours, right-size machines and keep an eye on data transfer between regions. That last line item misleads more people than any other.

Common mistakes when adopting the cloud

• Dragging data centre habits along. Replicating the old architecture without using managed services or elasticity makes everything costlier and more complex.
• Not putting identity first. The security boundary is no longer the network but the permissions of each account and service.
• Ignoring the bill. Without tagging or alerts, spending grows out of neglect rather than need.
• Depending on a single provider and on proprietary services, which makes any future exit harder.
• Forgetting compliance. Choosing a region and services without checking the applicable rules can force you to redo the design.
• Not measuring. Without usage and performance metrics, you cannot tell whether the spend is well spent.

Conclusion

Cloud computing moved computing from the data centre to consumption by use. Five essential characteristics, three service models (IaaS, PaaS and SaaS) and several deployment models, with multi-cloud as a growing strategy. Its promise of agility and pay-per-use holds up. It demands that you manage security, compliance and cost well.

Understanding that framework helps you decide with judgement: what to buy as a service, what stays at home, who answers for each layer and how the bill is kept under control.

So before your next deployment, write down those four answers. If you cannot say who patches the operating system, where the data physically sits and which line of the invoice grows when nobody is looking, the cloud will teach you. It just charges tuition.

P.S. Tag every resource the day you create it. It is the cheapest habit in this whole article and the one that saves the most money.

Frequently asked questions

Are cloud computing and virtualisation the same thing?

No. Virtualisation is the technology that lets several machines run on one physical server. Cloud computing is the service model that, built on it, delivers resources on demand. You can have virtualisation without a cloud, but without virtualisation or containers the modern cloud does not make sense.

Who is responsible for security in the cloud?

Both, under the shared responsibility model. The provider protects the infrastructure and the physical network. The customer protects their data, identities, configuration and permissions. Most incidents happen on the customer’s side.

What is vendor lock-in and how do you avoid it?

It is the difficulty of changing providers when an application depends on their proprietary services. You reduce it by using standards and portability where it makes sense, and by keeping your data exportable.

Is the cloud cheaper than your own data centre?

It depends on the workload. For variable or growing demand, pay-per-use usually works out cheaper than over-provisioning hardware. For very steady loads, a well-used data centre of your own can pay off. An honest comparison includes staff, energy and equipment renewal.

Sources

• NIST SP 500-292: Cloud Computing Reference Architecture
• ENISA: Cloud security