Tell me about cloud computing, and the clearest starting point is this: cloud computing is the delivery of computing resources—servers, storage, databases, networking, software, analytics and other digital capabilities—over networks as services that can be provisioned, scaled and managed without every user owning the underlying hardware. The “cloud” is not a weightless place where data floats. It is a coordinated system of real data centres, fibre networks, power systems, virtualization software, identity controls, automation platforms and distributed applications. What changes is the operating model: instead of buying every server in advance, an organization can request capacity when needed and pay for what it consumes, while a provider manages much of the physical infrastructure.

People searching for how cloud computing works often want several connected questions answered: where cloud data is physically stored, what virtual machines and containers are, why one server can host many customers, how applications scale when traffic rises, what “serverless” means, how cloud storage differs from a hard drive, what regions and availability zones are, why cloud outages still happen, how cloud security works, what IaaS, PaaS and SaaS mean, and whether the cloud is cheaper than running a private data centre. All of those questions become easier once cloud computing is understood as a stack of abstractions built on top of physical machines and networks.

This guide explains cloud computing from first principles. It covers data centres, virtualization, containers, regions, availability zones, load balancing, object storage, databases, identity, networking, infrastructure as code, autoscaling, serverless computing, observability, security, resilience, cost, vendor lock-in, edge computing and practical architecture. It also includes worked examples, misconceptions and diagnostic questions. The goal is not to memorize cloud-service names. It is to build a durable model of what resources exist underneath, what each service hides, what remains the customer’s responsibility and why cloud systems behave differently from one computer sitting under a desk.

The 50-second explanation

A cloud provider operates large fleets of servers in data centres connected by high-speed networks. Software divides those machines into logical resources that customers can request through a web console, command line or application programming interface. A customer might ask for a virtual server with four processors, a database, one terabyte of object storage and a private network. Automation allocates those resources from the provider’s fleet, configures them and begins metering usage.

Cloud applications are usually designed so capacity can change without rebuilding the whole system. A load balancer can distribute requests across many application instances. Autoscaling can add instances when traffic rises and remove them when demand falls. Data can be replicated across disks, servers or facilities. Managed databases automate backups, patching and failover. Serverless platforms go further by asking customers to supply code while the platform decides where and when to run it.

The key idea is abstraction. The user sees a service—compute, storage, database, queue, function or API—while the provider handles more of the machinery underneath. The more abstraction a service provides, the less infrastructure the customer manages directly, but the customer still owns architecture, data, access decisions, application behavior and cost control. Cloud computing moves responsibility; it does not eliminate it.

Core definitions

Cloud provider

A cloud provider operates computing infrastructure and exposes it as services. Large providers run multiple regions, private backbone networks and many categories of managed service. Smaller providers may specialize in particular geographies or workloads. The defining feature is not company size but the service model: shared infrastructure, remote provisioning, automation and metered or subscription-based use.

Data centre

A data centre is the physical facility containing servers, storage systems, networking equipment, cooling, power distribution and security controls. Cloud computing depends on data centres but adds software that turns physical capacity into programmable resources. A useful internal route is Tell Me About Data Centres.

Virtual machine

A virtual machine, or VM, behaves like a computer with virtual processors, memory, disks and network interfaces. A hypervisor coordinates access to the physical hardware so multiple VMs can run on one server while remaining logically isolated. Each VM can run its own operating system.

Container

A container packages an application with its libraries and configuration while sharing the host operating system kernel. Containers are usually lighter and faster to start than full virtual machines. Orchestration platforms schedule many containers across a fleet, replace failed instances and manage networking and deployment.

Region and availability zone

A region is a geographic area where a provider operates cloud infrastructure. Within a region, providers often divide infrastructure into multiple isolated locations or availability zones. The exact architecture varies, but the design goal is to let customers spread workloads across separate failure domains so one building-level problem does not necessarily stop the entire application.

Elasticity

Elasticity means capacity can expand or contract as demand changes. It differs from merely owning a large server. An elastic system can create or remove resources through automation, ideally matching capacity to workload rather than keeping peak hardware powered all year.

Why cloud computing emerged

Traditional information technology required organizations to estimate future demand, purchase servers, wait for delivery, install operating systems, configure networks and maintain spare capacity. The process could take weeks or months. If demand was underestimated, applications slowed or failed. If demand was overestimated, expensive hardware sat idle.

Virtualization made physical servers more flexible by letting multiple isolated workloads share them. Broadband networks and standardized APIs then made it practical to offer that virtualized capacity remotely. Instead of buying a machine, a developer could request one in minutes. The cloud business model grew from that combination of virtualization, automation, large-scale infrastructure and metering.

The deeper change is organizational. Cloud infrastructure can be described in code, deployed repeatedly and integrated with software-development workflows. Infrastructure becomes programmable. That allows teams to test architectures quickly, create temporary environments and automate operations that previously required manual tickets and physical intervention.

Virtualization: how one physical server becomes many logical servers

The hypervisor

A hypervisor sits between hardware and virtual machines or uses hardware-assisted virtualization features to control access to processors, memory and devices. Each VM sees virtual hardware and runs its own operating system. The hypervisor schedules CPU time, maps memory and isolates devices so one VM cannot casually read another VM’s memory.

Why virtualization improves utilization

A physical server dedicated to one modest application may use only a small fraction of its processor and memory most of the day. Running many VMs on the same host increases average utilization. Large providers aggregate thousands of customers with different usage patterns, reducing the amount of idle hardware needed per workload.

Isolation is not magic

Virtualization provides strong logical separation, but it depends on correct hardware, hypervisor and configuration. Security patches, host hardening and tenancy controls remain important. Cloud isolation is engineered continuously rather than assumed from the word “virtual.”

Containers and orchestration

Containers package applications in a reproducible way. A container image describes the filesystem and dependencies needed to run a service. Because containers share the host kernel, they can start quickly and use fewer resources than a comparable full VM. This makes them attractive for microservices and bursty workloads.

At scale, the challenge becomes scheduling. Which server should run each container? What happens when a node fails? How is traffic routed to new replicas? Orchestration systems maintain a desired state: for example, “run six copies of this service.” If only five are healthy, the orchestrator starts another. If demand rises, an autoscaler may increase the desired count.

Containers do not remove infrastructure concerns. Teams still need image security, secrets management, networking, storage, resource limits and observability. Orchestration adds powerful automation but also adds its own control plane and operational complexity.

The three classic service models

Infrastructure as a Service: IaaS

Infrastructure as a Service provides building blocks such as virtual machines, disks and networks. The provider manages physical servers, facilities and core virtualization. The customer manages the guest operating system, installed software, patches, application and data. IaaS offers control close to traditional servers while making provisioning much faster.

Platform as a Service: PaaS

Platform as a Service hides more infrastructure. A developer supplies an application or runtime configuration while the platform handles operating-system maintenance, deployment and much of the scaling. The trade is less control over the exact host environment.

Software as a Service: SaaS

Software as a Service delivers complete applications through a browser, mobile app or API. Users configure the application and manage their own data and permissions but do not administer the servers or runtime. Email platforms, collaboration suites and customer-relationship systems are common examples.

The boundaries are not perfectly fixed. Managed databases, container platforms and serverless products sit between traditional categories. The useful question is always: which layers does the provider operate, and which layers remain the customer’s job?

Cloud networking

Virtual private networks

Cloud providers let customers create logically isolated network spaces. Subnets divide address ranges. Route tables decide where traffic goes. Security groups or firewall rules control which connections are allowed. Private networks can connect to the public internet through gateways or to offices through encrypted tunnels or dedicated links.

Load balancers

A load balancer accepts incoming connections and distributes them across multiple healthy application instances. It can remove failed instances automatically and may terminate encrypted connections, route by hostname or path and apply security rules. Load balancing is central to horizontal scaling because users no longer need to know which individual server handles a request.

Content delivery networks

A content delivery network caches files or responses near users in geographically distributed edge locations. This reduces latency and takes load away from the origin application. Static images, video segments and software downloads benefit especially from caching.

Private backbone networks

Large providers connect regions and data centres using dedicated high-capacity networks. This can give cloud traffic more predictable paths than sending every internal transfer across the public internet. Even so, network design must account for latency, bandwidth cost and failure.

Cloud storage

Block storage

Block storage presents raw volumes that behave much like disks attached to a server. Operating systems format them with filesystems and databases can perform random reads and writes. Block volumes are appropriate when applications expect disk-like behavior.

File storage

Managed file systems expose hierarchical files and directories through standard protocols. Multiple servers can often mount the same filesystem. This suits shared content, home directories and applications built around file semantics.

Object storage

Object storage keeps data as objects addressed by keys inside buckets or containers. It scales to enormous quantities of files and metadata and is commonly used for backups, media, logs, data lakes and application assets. It generally does not behave like a local disk with arbitrary in-place writes; applications use HTTP-style APIs to store and retrieve objects.

Durability versus availability

Durability asks whether data is lost. Availability asks whether data can be accessed at a particular moment. A storage service can be highly durable because it keeps redundant copies while still experiencing a temporary outage that makes those copies unavailable. Good architecture distinguishes these properties rather than treating “reliable storage” as one number.

Managed databases

Cloud databases automate tasks that organizations traditionally performed themselves: installation, replication, patching, backups, failover and monitoring. Relational databases organize structured data into tables with defined relationships and transactions. NoSQL systems trade some relational features for flexible documents, wide columns, key-value access or graph relationships.

A managed database does not eliminate database design. Developers still need suitable indexes, schemas, query patterns, retention policies and capacity planning. A badly designed query can be slow on expensive cloud hardware just as easily as on a local server.

Cloud databases also make geographic replication easier but not free. Replicating across regions increases resilience and reduces read latency for distant users, but adds cost, network transfer and consistency challenges. Distributed systems must decide how to behave when two locations cannot communicate.

Autoscaling and elasticity

Autoscaling uses measurements such as CPU load, request count, queue length or custom business metrics to adjust capacity automatically. If traffic rises, more application instances can be created. When traffic falls, excess instances can be removed. This reduces both overload risk and idle cost.

Autoscaling is easiest when application instances are stateless. If user state lives only in one server’s memory, adding or replacing servers becomes difficult. Cloud-native designs place shared state in databases, caches or object stores so any application instance can handle the next request.

Scaling is not instantaneous. New instances take time to start, databases have connection limits and downstream systems may become bottlenecks. Good autoscaling combines predictive planning, sensible minimum capacity and load testing rather than assuming automation can rescue any sudden surge.

Serverless computing

“Serverless” does not mean there are no servers. It means the customer does not manage individual servers as the primary unit of deployment. A serverless function platform accepts code and runs it when events occur, allocating underlying capacity automatically. Customers are billed for requests, execution time or related usage rather than for a permanently running VM.

Serverless is useful for event-driven tasks, APIs, file processing and intermittent workloads. It can scale rapidly and removes much operating-system work. Limits include startup latency, runtime restrictions, provider-specific interfaces and difficulty with long-running or stateful processes.

The broader serverless idea extends to managed queues, databases and workflows where capacity management is highly automated. The trade is usually less infrastructure control in exchange for less operational burden.

Infrastructure as code

Cloud resources are exposed through APIs, which makes infrastructure programmable. Infrastructure-as-code tools describe networks, servers, permissions and services in configuration files. Teams can review those files like software and reproduce environments consistently.

This reduces “snowflake” servers configured manually over years. If an environment can be rebuilt from code, disaster recovery and testing become more reliable. Version history shows who changed a firewall rule or database size and when.

Infrastructure code must still be secured. A mistaken template can deploy insecure settings repeatedly at great speed. Automation multiplies good practice and bad practice equally efficiently.

Identity and the shared-responsibility model

Identity is the control plane

Cloud systems are controlled through APIs, so identity permissions are critical. Users, applications and automated services receive credentials or temporary tokens. Policies define which actions each identity may perform. Least privilege means granting only the permissions needed for the task.

Shared responsibility

The provider is responsible for some layers and the customer for others. In a virtual machine, the provider protects the physical data centre and hypervisor while the customer patches the guest operating system and application. In a managed database, the provider manages more layers, but the customer still controls users, data and application queries. In SaaS, the customer may mainly manage accounts, configuration and information governance.

Misconfiguration as a common failure

A cloud storage bucket can be cryptographically strong yet exposed publicly by a mistaken access policy. Security therefore depends on configuration, identity, monitoring and human process, not merely on provider technology.

Reliability, regions and failure domains

Cloud providers design infrastructure around failure domains because disks, servers, racks, networks and entire facilities can fail. An application becomes resilient by placing redundant components in independent domains and ensuring traffic can move between them.

Running two application instances in the same VM does not protect against host failure. Running two VMs on one physical host may not protect against rack failure. Running all copies in one availability zone may not protect against a facility outage. Resilience requires understanding what failures are actually independent.

Multi-region systems can survive larger events but introduce complexity. Data replication across long distances creates latency and consistency questions. DNS, certificates, user sessions and operational procedures must all work during failover. More redundancy is valuable only if it is tested.

Observability

Metrics

Metrics summarize numeric behavior over time: CPU utilization, latency, error rate, queue depth or database connections. They are efficient for dashboards and alerts.

Logs

Logs record discrete events. Application logs can explain why a request failed, while infrastructure logs show network or access activity. Centralizing logs helps correlate events across distributed services.

Traces

Distributed tracing follows one request through many microservices. It shows where latency accumulated and which dependency returned an error. This is increasingly important because cloud applications may involve dozens of services behind one user action.

Observability is not the same as monitoring. Monitoring asks whether known conditions are healthy; observability helps investigate unknown problems by giving enough internal evidence to infer what happened.

Cloud security in practice

Cloud security combines identity, encryption, network segmentation, patching, backups, logging, vulnerability management and application security. Encryption at rest protects stored data if media or underlying storage is compromised. Encryption in transit protects network traffic. Key-management systems help control cryptographic keys and audit their use.

Zero-trust approaches avoid assuming that traffic is trustworthy merely because it comes from an internal network. Requests are authenticated and authorized based on identity, device, context and policy. This matters in cloud environments because users, services and resources can be globally distributed.

Security also includes recovery. Ransomware-resistant backups, immutable storage and tested restore procedures matter because prevention can fail. A cloud architecture that cannot restore its own data is not resilient even if it has sophisticated firewalls.

Cost: why cloud can be cheap or unexpectedly expensive

Cloud economics replace much capital expenditure with variable operating expenditure. A small project can start cheaply because it pays for only a little compute and storage. A mature service can become expensive if resources run continuously, data crosses regions, logs grow without retention limits or unused disks and addresses accumulate.

Unit economics matter. Engineers should know cost per user, per transaction or per processed gigabyte, not merely the monthly bill. Autoscaling reduces idle compute but can also scale a software bug into a large invoice. Budget alerts and quotas are therefore technical controls, not only accounting tools.

Reserved capacity or long-term commitments can reduce price for stable workloads, while on-demand capacity provides flexibility. The best mix depends on how predictable demand is and how much interruption the workload can tolerate.

Vendor lock-in

Cloud services create convenience by providing proprietary managed features. That same convenience can make migration harder. A basic virtual machine can often move between providers with modest changes; an application deeply built around one provider’s database, event bus, identity system and serverless runtime can be expensive to redesign.

Lock-in is not automatically bad. Organizations routinely choose specialized technology because its benefits exceed switching risk. The useful question is whether the business consciously accepts the dependency and has a realistic exit or continuity plan for critical systems.

Abstraction layers and containers can improve portability but do not eliminate differences in networking, identity, databases or managed services. True multi-cloud portability often costs more engineering than teams expect.

Migration patterns: moving existing systems into cloud services

A cloud migration can take several forms. Rehosting moves an application largely unchanged onto virtual machines. It is fast but may preserve old operational weaknesses. Replatforming changes selected layers, such as moving from a self-managed database to a managed database. Refactoring redesigns the application around cloud-native services, queues, containers or functions. Replacing means retiring the application and adopting SaaS. These strategies have different costs, risks and benefits, so a migration program should not treat every workload identically.

The most important migration question is often not “How do we move this server?” but “What business capability must survive the move?” Dependencies may include identity systems, file shares, network addresses, scheduled jobs, external vendors and hidden manual processes. Mapping these dependencies before cutover prevents the classic failure in which the main application moves successfully but cannot reach a forgotten service that still lives in the old environment.

Migration also changes operations. A team accustomed to repairing one long-lived server may need to learn immutable deployments, automated scaling, infrastructure code and distributed tracing. Cloud adoption is therefore an organizational transformation as much as a hosting decision. The technology works best when architecture, finance, security and operating practice evolve together.

Worked examples

Example 1: a school website handles enrolment day

Most days the website needs two application servers. On enrolment day traffic rises tenfold. A load balancer distributes requests across an autoscaling group that expands to twenty servers. Shared session data sits in a managed cache and enrolment records go to a managed database. After the surge, the extra servers shut down. The cloud advantage is not that each server is faster; it is that capacity is programmable and temporary.

Example 2: object storage versus block storage

A photo archive contains ten million image files. Object storage is a natural fit because each image can be addressed by a key and stored with metadata. A transactional database server instead needs block storage because it performs frequent random writes to database files and expects disk-like semantics.

Example 3: why one region is not automatically resilient

An application runs four servers but all are in one availability zone. A facility-level network failure stops all four. Redesigning so two run in each of two zones, with a multi-zone database and load balancer, protects against that class of failure. Redundancy counts only when copies fail independently.

Example 4: serverless economics

A function runs only when a file is uploaded, perhaps 500 times per day for two seconds each. Paying for a continuously running VM may waste capacity. A serverless platform charges around actual execution. If usage grows into a constant high-throughput service, a continuously running container platform may become cheaper or easier to control.

Example 5: cloud storage durability

A user stores one document in object storage that automatically replicates data across multiple devices. A single disk can fail without losing the object. But if the user’s credentials are compromised and the attacker deletes the object everywhere, physical replication alone does not help. Versioning, retention locks and backups address a different failure mode.

Example 6: runaway cost

A logging service receives ten times more events after a software change. The application remains healthy, but storage and analytics charges explode. The technical system succeeded at scaling while the economic system failed. Cost monitoring is therefore part of observability.

Misconceptions and diagnostics

Misconception: the cloud is someone else’s computer

That phrase is useful as a reminder that physical machines exist, but it hides the automation, distributed storage, networking, identity and managed-service layers that make cloud computing distinctive. A cloud is not merely remote hosting.

Misconception: cloud automatically means highly available

A single VM in a cloud region can fail like any other computer. High availability must be designed using redundancy, health checks, replication and tested recovery.

Misconception: serverless means no servers

Servers still run the code. The difference is that the provider manages allocation and lifecycle while the customer deploys functions or higher-level services.

Misconception: cloud security is entirely the provider’s responsibility

Providers secure the layers they operate, but customers still control identities, application code, data access, configuration and often operating-system patches. Shared responsibility changes by service type.

Diagnostic: application latency rises only for distant users

Likely categories include geographic network latency, a single-region backend or missing edge caching. Moving static content to a CDN or deploying read replicas closer to users can help.

Diagnostic: CPU is low but requests are slow

The bottleneck may be database queries, external APIs, network latency, locks or storage rather than processor capacity. Autoscaling CPU-based instances alone may not solve it.

Practical applications

Web applications

Cloud platforms host websites, APIs and mobile backends. Managed load balancing and autoscaling suit traffic that changes by time of day or campaign.

Data analytics

Organizations can store large data sets in object storage and launch temporary processing clusters only when analysis is required. This separates long-term storage cost from short-term compute cost.

Artificial intelligence

Machine-learning workloads can rent specialized accelerators for training and inference rather than purchasing them. Managed model platforms also provide deployment and monitoring.

Backup and disaster recovery

Cloud storage provides geographically separate backup locations and on-demand recovery infrastructure. Recovery still requires tested procedures, credentials and data integrity checks.

Business software

SaaS applications let organizations use email, collaboration, finance and customer-management tools without operating the underlying servers. Administration shifts toward identity, configuration and governance.

Frequently asked questions

Where is cloud data actually stored?

On physical storage systems in data centres. The service may replicate or move data across devices or locations according to the product configuration and provider design.

Can the cloud go down?

Yes. Servers, networks, software and whole facilities can fail. Cloud providers reduce risk through redundancy, but customers must architect applications for the level of availability they need.

Is cloud computing always cheaper?

No. It can reduce upfront cost and improve flexibility, but stable high-utilization workloads can sometimes be cheaper on owned infrastructure. Architecture, labor, scale and data-transfer patterns matter.

What is multi-cloud?

It means using services from more than one cloud provider. Organizations may do this for specialization, regulation or bargaining power, but it increases operational complexity.

What is hybrid cloud?

Hybrid cloud combines cloud services with private data-centre or on-premises systems. Applications may keep sensitive or latency-critical components locally while using cloud capacity for other workloads.

What is edge computing?

Edge computing runs processing closer to users, devices or data sources. It reduces latency and bandwidth use for applications such as industrial control, content delivery and connected vehicles.

What is cloud migration?

Cloud migration is the process of moving applications or data from another environment into cloud services. Strategies include rehosting, replatforming, refactoring or replacing software with SaaS.

Why do cloud providers charge for data transfer?

Moving data consumes network capacity and infrastructure. Pricing also reflects business models and encourages architectures that avoid unnecessary cross-region or internet traffic.

What is a cloud API?

It is a programmable interface for creating, reading, changing or deleting cloud resources. Consoles and command-line tools usually call the same underlying APIs.

What is a cloud region?

A region is a geographic cluster of cloud infrastructure. Choosing a region affects latency, data residency, service availability and resilience architecture.

What is an availability zone?

It is an isolated infrastructure location within a region, intended to provide an independent failure domain. Applications can spread resources across zones to improve availability.

What does “managed service” mean?

It means the provider operates more of the underlying software and infrastructure. The customer still configures the service and remains responsible for data and application behavior.

Can cloud providers read customer data?

Access depends on service architecture, encryption, key ownership and provider controls. Customers with strict requirements may use customer-managed keys or application-level encryption so the provider has less practical access to plaintext.

What is cloud-native?

Cloud-native usually describes software designed around automation, distributed services, containers, managed platforms, immutable deployment and elastic infrastructure rather than simply moving an old server image into a VM.

Why are backups still needed in the cloud?

Replication protects against hardware failure but may replicate accidental deletion, corruption or ransomware. Independent backups and retention policies protect against different failure modes.

Big picture: cloud computing is programmable infrastructure

The deepest idea is that cloud computing turns computing resources into programmable services. Physical servers, networks and disks still exist, but customers interact with them through abstractions and APIs. Virtualization turns servers into pools. Object storage turns disks into durable addressable objects. Managed databases turn replication and backup into service features. Serverless platforms turn execution itself into an on-demand event.

Once that model is secure, many cloud questions become connected. Autoscaling is possible because infrastructure is programmable. High availability requires independent failure domains. Security centers on identity because APIs control everything. Cloud cost can rise suddenly because metered resources scale automatically. Vendor lock-in grows as applications depend on higher-level managed services. The cloud is best understood not as a place, but as an operating model for distributed computing.

Useful routes for deeper learning

• Tell Me About Data Centres — the physical infrastructure underneath cloud services.
• Tell Me About the Internet — the network layer connecting users to cloud services.
• Tell Me About Computers — the compute, memory and storage foundations behind virtual machines.
• Tell Me About Cryptography — encryption, keys and trust for cloud systems.
• NIST SP 800-145: The NIST Definition of Cloud Computing — a foundational external definition of cloud service and deployment models.