Cloud computing is a simple trade: instead of owning computers, you rent them over the internet and pay only for what you use.

The one-sentence definition

Cloud computing means using computing resources that belong to someone else, reached over the internet, and paying only for the amount you actually use. Those resources include processing power, storage space, databases, networking, and ready-made software.

A server is a powerful computer whose job is to serve other computers. It stores files, runs applications, and answers requests from phones and web browsers. Before the cloud, any company that wanted a website had to buy servers, place them in a room, keep that room cool and powered, and hire people to look after everything. If the website became popular overnight, the company had to buy more machines and wait weeks for them to arrive. If the website became unpopular, the machines sat idle but still cost money.

Cloud computing removes that burden. You ask a cloud provider, which is a company that runs enormous collections of computers, for what you need. A few minutes later it is ready. When you no longer need it, you hand it back and the billing stops.

Where the word “cloud” comes from

For decades, engineers who drew network diagrams used a cloud-shaped doodle to represent “the internet, or some other network we do not need to describe in detail.” Over time the doodle became the name. There is nothing floating in the sky. The cloud is made of very real buildings, cables, and machines.

What can you rent?

Almost every part of a computer system can be rented as a service. The main categories are:

• Compute: processing power to run programs, from a single small machine to thousands at once.
• Storage: places to keep files, photos, videos, and backups safely.
• Databases: organised storage for data that applications need to search and update quickly.
• Networking: private virtual networks, traffic directors, and connections to the internet.
• Software: finished applications such as email, document editors, and customer-management tools.
• Specialised tools: analytics, machine learning, messaging, and monitoring.

The cloud did not appear overnight. It grew from sharing, then from smarter ways to slice up machines, then from companies that learned to rent out their own spare capacity.

Understanding the history helps you see why the cloud looks the way it does. Each step solved a real problem that people were struggling with at the time.

NIST says a service counts as cloud computing only if it has five traits. They are also a handy checklist for spotting “cloud in name only.”

Three words you will hear constantly

A virtual machine (VM) is a pretend computer that runs inside a real one. It has its own memory, disk, and operating system, yet it shares the physical hardware with other VMs. A region is a geographic area, such as “Mumbai” or “Frankfurt”, where a provider has data centers. An availability zone (AZ) is one separate data center, or a group of them, inside a region, with its own power and cooling. Spreading your work across several zones keeps it running even if one building has trouble.

Cloud services come in layers. The higher the layer, the more the provider does for you, and the less control you keep.

The word “service” in these names simply means “rented instead of owned.” The first letters tell you what is being rented: Infrastructure, Platform, or Software.

flowchart TB
  A["SaaS: finished apps such as email and CRM"]
  B["PaaS: a ready place to run your code"]
  C["IaaS: virtual servers, storage and networks"]
  D["Physical data center: buildings, power, hardware"]
  A --> B
  B --> C
  C --> D
    

Infrastructure as a Service (IaaS)

With IaaS you rent the raw building blocks: virtual servers, storage disks, and networks. You choose the operating system, install your own software, and handle updates. It offers the most freedom and needs the most skill. Amazon EC2, Azure Virtual Machines, and Google Compute Engine are well-known examples.

Platform as a Service (PaaS)

With PaaS the provider also manages the operating system and runtime. You bring only your application code. The platform runs it, scales it, and keeps it patched. Heroku, Google App Engine, Azure App Service, and AWS Elastic Beanstalk are examples. It is ideal when developers want to ship features rather than maintain machines.

Software as a Service (SaaS)

With SaaS you simply use a finished application through a browser or an app. Gmail, Microsoft 365, Slack, and Salesforce are SaaS. You never think about servers at all, only about your work.

Serverless, also called Function as a Service (FaaS)

Serverless is a newer style where you upload a small function and the provider runs it only when something triggers it, such as a file upload or a web request. You pay only for the moments the function actually runs. Servers still exist, but you never see or manage them. AWS Lambda is the best-known example.

Service models say what you rent. Deployment models say who shares the cloud with you and who owns it.

A cloud is a stack of cooperating parts, from concrete floors at the bottom to a friendly web console at the top.

Let us walk through the parts from the outside in. The picture below shows how a user’s request meets a typical cloud application.

flowchart LR
  U["User on phone or laptop"] --> DNS["DNS name lookup"]
  DNS --> CDN["CDN edge cache"]
  CDN --> GW["API Gateway"]
  GW --> LB["Load Balancer"]
  LB --> S1["App Server 1"]
  LB --> S2["App Server 2"]
  S1 --> CA["Cache"]
  S2 --> CA
  S1 --> DB["Managed Database"]
  S2 --> DB
  S1 --> OS["Object Storage"]
  S2 --> OS
    

The physical layer

At the bottom are data centers: large buildings with racks of servers, strong power supplies, backup generators, cooling systems, and tight physical security. Providers group these into regions and availability zones so that a problem in one place does not take down everything.

The building blocks you rent

The control plane and the data plane

Engineers split a cloud into two parts. The control plane is the management side: it receives your requests to create, change, or delete things. The data plane is the working side: it carries the traffic and runs the programs. Keeping them apart means that a flood of customer traffic does not stop you from managing your resources, and the other way round.

The secret behind the cloud is slicing big machines into many small, separate ones, then handing out the slices automatically.

Virtualization: one machine, many computers

A modern server is very powerful, far more than most single programs need. Virtualization is the technique of dividing one physical server into several virtual machines. A special program called a hypervisor sits between the hardware and the virtual machines. It gives each VM a share of processor time, memory, and disk, and it keeps the VMs from seeing each other’s data.

Because of the hypervisor, a customer who rents a “small server” does not get a whole physical box. They get a protected slice of one, and other customers get other slices of the same box. This is the heart of multi-tenancy, and it is why cloud computing can be so cheap. Modern providers also move much of this isolation work onto specialised hardware cards, which makes the slices both safer and faster.

Containers: lighter and faster

A virtual machine carries a full operating system, which makes it heavy. A container is a lighter package that holds an application and the files it needs, while sharing the operating system of the machine underneath. Containers start in seconds, use less memory, and behave the same on a laptop as in the cloud. That is why developers love them.

When a company runs thousands of containers, a human cannot place each one by hand. An orchestrator, with Kubernetes being the most popular, decides which machine runs which container, restarts any that crash, and adds more when traffic grows.

Three kinds of cloud storage

Storage is not one thing. Object storage keeps files as “objects” in huge flat buckets, which is perfect for photos, videos, and backups. Block storage behaves like a hard disk attached to a server and suits databases. File storage offers shared folders that several servers can open at once. Choosing the right kind is one of the first design decisions in any cloud project.

What happens when you click “Launch”

Follow one click from a phone to a database and back, then follow the life of a cloud resource from birth to retirement.

The journey of a single request

Suppose you open a shopping app and tap “My orders”. Here is the path that tap takes through a well-built cloud application.

sequenceDiagram
  participant U as User App
  participant C as CDN Edge
  participant G as API Gateway
  participant L as Load Balancer
  participant A as App Server
  participant K as Cache
  participant D as Database
  U->>C: Request page and images
  C-->>U: Cached images returned
  U->>G: Ask for my orders
  G->>L: Forward after login check
  L->>A: Choose a healthy server
  A->>K: Look for saved answer
  K-->>A: Not found
  A->>D: Read orders
  D-->>A: Order rows
  A->>K: Save answer for next time
  A-->>U: Orders shown
    

Step by step: the CDN (content delivery network) serves pictures and static files from a location near you, which makes pages load fast. The API gateway is the front desk of your application. It checks who you are, applies limits, and sends the request to the right place. The load balancer spreads requests evenly across several servers and skips any that are unhealthy. The application server asks the cache, a very fast memory store, whether the answer is already known. Only if it is not does the server read from the slower, durable database. Finally the answer is saved in the cache for the next visitor.

The lifecycle of a cloud resource

Every cloud resource, whether a server, a disk, or a database, goes through the same stages:

• Request: someone asks for it, ideally through a recorded, approved process.
• Provision: the provider creates it and starts the billing meter.
• Configure: you set its security, networking, and software.
• Run and scale: it serves users, and automatic rules add or remove copies as demand changes.
• Observe and maintain: you watch its health, apply updates, and take backups.
• Retire: you delete it, make sure its data is safely archived or erased, and confirm the billing has stopped.

How automatic scaling decides

Auto scaling is a loop. A monitor measures something, such as how busy the processors are. If the number crosses a rule you set, for example “above 70 percent busy for five minutes”, the system adds servers. When the number drops, it removes them. You define the rule once, and the cloud follows it around the clock.

The cloud is powerful, but it is a trade, not a gift. Knowing both sides helps you decide when it is the right tool.

The money trade: CapEx versus OpEx

Accountants talk about two kinds of spending. Capital expenditure (CapEx) is a large upfront purchase, like buying servers. Operating expenditure (OpEx) is a smaller, regular cost, like a monthly bill. The cloud turns CapEx into OpEx. That is wonderful for a young company with little cash and an uncertain future. For a large company with steady, predictable demand, however, owning machines can sometimes cost less over the years.

Cloud providers protect the building. You protect what you put inside it. Both halves matter.

The shared responsibility model

Every major provider describes security as a partnership. The provider is responsible for the security of the cloud: the buildings, the hardware, the hypervisors, and the core network. You are responsible for security in the cloud: who can log in, how your data is protected, how your software is configured, and how your network rules are written.

The main layers of protection

A simple security habit list

• Never use the all-powerful root account for daily work; keep it locked away.
• Rotate and protect secrets such as passwords and keys, and never place them in public code.
• Keep software patched, or choose managed services where the provider patches for you.
• Review permissions regularly and remove anything that is no longer needed.

You cannot fix what you cannot see. Good teams watch their cloud the way a pilot watches the cockpit instruments.

Because cloud systems are made of many moving parts that appear and vanish automatically, you need tools that constantly report what is happening. Three kinds of signals are used together, often called the three pillars of observability.

What to measure

• Latency: how long requests take, especially the slowest few percent.
• Traffic: how many requests arrive.
• Errors: how many requests fail.
• Saturation: how full your resources are, such as memory or disk.
• Cost: daily spending per team or per project, so surprises appear early.

Alerts that help instead of annoy

An alert is a message sent to a person when a number crosses a danger line. Good alerts point to problems that real users feel, such as a rising error rate. Too many noisy alerts train people to ignore them. Pair every alert with a short written guide, sometimes called a runbook, that says what to check first.

Servers are only useful if they can talk to the right people and to each other. Cloud networking decides who can reach what.

In your own office, a network is cables, switches, and routers that someone physically installs. In the cloud, all of that is made of software. You draw your network with settings instead of wires, and the provider turns those settings into real traffic rules.

Your private slice of the network

A virtual private cloud (VPC), called a virtual network on some providers, is your own private, isolated section of the provider’s network. You choose its range of addresses, and nobody else’s resources can enter it unless you allow it. Inside it you create smaller sections called subnets. A public subnet holds things that must be reachable from the internet, such as a load balancer. A private subnet holds things that must stay hidden, such as databases.

The main networking pieces

Almost every application needs to remember things. Choosing where and how to keep data is one of the most important cloud decisions.

Relational and non-relational databases

A relational database stores data in tables with rows and columns, like a set of linked spreadsheets, and uses a language called SQL to ask questions. It is excellent when data has a clear structure and when accuracy matters a lot, such as bank balances or orders. A non-relational database, often called NoSQL, uses more flexible shapes, such as documents or simple key and value pairs. It is chosen when data changes shape often, or when the application needs to handle enormous numbers of requests spread across many machines.

Why managed databases are popular

Running a database well is hard. You must install it, patch it, take backups, copy data to a standby machine, and repair it when something breaks. A managed database service does these chores for you. You choose a size, and the provider handles updates, automatic backups, and failover to a standby copy in another zone. Examples include Amazon RDS, Azure SQL Database, and Google Cloud SQL.

Storage classes and durability

Object storage services offer different storage classes, which trade price against how fast you can get your data back. Frequently used data goes in a standard class. Rarely used data, such as old records kept for legal reasons, goes in an archive class that costs far less but may take minutes or hours to retrieve.

Providers also speak about durability, which is the chance your stored data will not be lost. Object storage is designed so that each file is copied across several machines and buildings, which is why a single disk failure never loses your photo. Do not confuse durability with availability. Durability asks “will my data still exist?” while availability asks “can I reach it right now?”

A good cloud system grows when needed, stays up when parts break, and recovers quickly when something truly goes wrong.

Scaling up versus scaling out

Vertical scaling means replacing a server with a bigger one, with more memory and processors. It is simple, but there is a limit to how big one machine can get, and swapping may need downtime. Horizontal scaling means adding more servers of the same size and sharing the work among them. It has almost no ceiling and it is the favourite approach in the cloud, but the application must be built so that many servers can work together.

High availability across zones

High availability means a service keeps working even when a part of it fails. The standard recipe is to run copies of every layer in at least two availability zones and let a load balancer send traffic only to healthy copies.

flowchart TB
  U["Users"] --> LB["Load Balancer across zones"]
  LB --> A1["App Server in Zone A"]
  LB --> B1["App Server in Zone B"]
  A1 --> DBP["Primary Database in Zone A"]
  B1 --> DBP
  DBP -. "continuous copy" .-> DBS["Standby Database in Zone B"]
    

Measuring availability

Availability is often written as a percentage of time a service is working, and people casually say how many “nines” they have. The small differences matter more than they look:

Providers publish a service level agreement (SLA) that promises a level of availability for each service and offers credits if they miss it. Your own application’s availability can never be higher than the services it depends on, so combining many services usually lowers the total.

Disaster recovery

Sometimes a whole region is lost, or data is damaged by mistake or attack. Two numbers guide your plan. The recovery time objective (RTO) is how long you can afford to be down. The recovery point objective (RPO) is how much recent data you can afford to lose. Shorter targets cost more, so teams pick them according to how important each system is.

Paying only for what you use is a gift, but only if you know how the meter runs and keep an eye on it.

How you are charged

Cloud bills usually combine three things: how much compute you use and for how long, how much data you store, and how much data moves in and out of the provider. Moving data into the cloud is typically free, while moving it out to the internet usually carries a fee, often called an egress charge. This surprises many beginners.

Habits that keep bills small

• Tag everything with owner, project, and environment, so each cost has a name attached to it.
• Right-size servers by checking real usage and picking a smaller size when the machine is mostly idle.
• Switch off development and test environments at night and on weekends.
• Delete orphans, such as unattached disks, old snapshots, and unused addresses.
• Use storage classes so that rarely used data moves to cheaper archives automatically.
• Review monthly with both engineers and finance staff in the same room.

The practice of bringing technology and finance teams together to make smart cloud spending decisions is often called FinOps. Its main idea is simple: everyone who can create cost should also be able to see it.

Most companies were not born in the cloud. They move step by step, choosing the right path for each application.

A migration is the process of moving an existing application from your own machines to the cloud. There is no single best way, so teams decide for each application separately. The main choices are:

A sensible order of work

• Take inventory: list every application, who uses it, and what it depends on.
• Start small: pick a low-risk application first, so the team learns safely.
• Build the foundation: set up accounts, permissions, networks, monitoring, and cost controls before moving anything important.
• Move and test: migrate in stages, compare behaviour with the old system, and keep a way back.
• Improve afterwards: once things are stable, gradually modernise, so the move pays off.

A pattern is a proven recipe for a common problem. An anti-pattern is a tempting shortcut that usually hurts later.

Patterns worth knowing

Anti-patterns to avoid

Good habits are simple. Most cloud trouble comes from skipping them, not from missing some advanced trick.

Practising failure on purpose

Some teams go a step further and break things deliberately, in a controlled way, to prove their systems can cope. This practice is called chaos engineering. Netflix became well known for it with a tool named Chaos Monkey, which randomly shuts down servers during working hours so that engineers learn to build services that keep running regardless.

Famous companies show how the ideas in this guide look when they are used at large scale.

The cloud keeps changing. Knowing the main directions helps you choose skills and designs that will last.

The basic ideas in this guide will not disappear, however. Virtual slices of shared hardware, pay-as-you-go billing, global regions, shared responsibility, and design for failure will remain the foundation, even as the services built on top of them change names.

Keep this page handy. Every term below has appeared in this guide, now with a plain comparison you can remember.

Short, plain answers to the questions beginners ask most often.