Lesson 1 of 17Intermediate14 min

What Cloud Computing Actually Means

By the end of this lesson

Explain what you stop being responsible for, and what you do not.

Cloud computing means renting computing from a company that operates datacentres, and paying for what you use rather than for hardware you own.

That is the commercial description. The part that changes how you work is different: a cloud provider takes over some of the responsibility for keeping your system running and secure, and leaves the rest with you. Knowing exactly where that line sits is the whole of this lesson, because almost every expensive cloud mistake is someone assuming the line was further along than it was.

Four terms used constantly from here on:

Provider: The company operating the datacentres and the services on top of them. Azure and AWS are the two used as examples in this course; the concepts apply to others.
Managed service: A service where the provider operates the software for you, not only the machine underneath. A managed database is the clearest example: you get a database endpoint, and nobody on your team logs into a server to patch it.
Elasticity: The ability to add and remove capacity quickly, and to pay only while it exists. This is the genuine difference from owning hardware, where capacity is bought months ahead and sits idle at 3am.
Shared responsibility: The split of security and operational duties between the provider and you. Every provider publishes its own version of this split, and every version says the same uncomfortable thing: your data and your access control are yours.

Where the line sits

For a typical managed application platform and managed database, responsibilities divide roughly like this. The exact boundary moves depending on which service you pick, which is the subject of the next lesson.

	The provider handles	You still handle
Hardware	Buildings, power, cooling, servers, disks, network equipment, physical access	Nothing
Host software	The virtualisation layer and the host operating system it runs on	Nothing on a managed platform; the guest operating system if you rent a virtual machine
Your application	Nothing	The code, its dependencies, and the vulnerabilities in both
Your data	Storing it durably and encrypting it at rest when you enable that	What you collect, how long you keep it, who can read it, and whether a copy is recoverable
Access control	The mechanism — the identity service, roles, policies, logs	Every decision made with that mechanism. Who has which role, and whether anyone still needs it
Configuration	Secure defaults on most services, and an audit trail of changes	Every setting you change, including the one that made a storage container public

Read the right-hand column again. It is longer than most people expect, and it contains the items that cause reported cloud data exposures: storage left readable by anyone, credentials with far more permission than the task needed, and access that was granted for one afternoon three years ago.

These are configuration mistakes on the customer side of the line, not failures of the provider's infrastructure. The provider's security is generally very good, and it is not the part that fails. This is worth saying plainly because moving to a cloud provider is sometimes sold internally as a security upgrade. It moves the physical risk to a company better equipped to handle it, and leaves the configuration risk exactly where it was.

Checking who can read the employee photo storage

Shell

# Azure — is public read access allowed on the storage account?
az storage account show \
  --name anviemployeesstore \
  --resource-group employees-prod \
  --query "allowBlobPublicAccess"

# AWS — is public access blocked on the bucket?
aws s3api get-public-access-block \
  --bucket anvi-employees-store

# AWS — who is granted access by the bucket policy?
aws s3api get-bucket-policy \
  --bucket anvi-employees-store

Both commands ask the same question in different words: can someone with no credentials read what is in here? For the employee photos uploaded by field staff, the answer needs to be no.
The Azure command returns true or false for the whole storage account. Set to false, it overrides any individual container that was made public, which makes it a useful safety net rather than a per-container decision.
The AWS public access block does the same job at the bucket level, and the separate bucket policy check matters because a policy can grant access that the block then prevents. Reading only one of the two gives you an incomplete answer.
Run these against your own storage before you assume the defaults are what you want. Defaults change between provider versions, and a resource created by a colleague two years ago was created under different defaults.

Common mistake

Common mistakes when starting out

Assuming the provider backs up your data. Some managed services take automated backups and some do not, retention varies, and an object storage container generally keeps exactly what you put in it until you delete it. Deleting a record with a bug in a loop is your problem, not the provider's.

Believing that redundancy is the same as backup. A provider storing three copies of your data protects against a disk failure. It faithfully replicates your accidental deletion to all three copies.

Treating the free tier as free. Several services are free at low usage and bill steeply above it, and a misbehaving retry loop can generate that usage overnight. Set a budget alert on day one, before the first deployment.

Leaving experiments running. A virtual machine created to try something out bills every hour until it is deleted. This is the single most common surprise on a first cloud invoice.

Summary

Cloud computing rents computing capacity, and the change that matters is which responsibilities move to the provider
The provider owns the infrastructure; you own your data, your access decisions and your configuration
Reported cloud data exposures are overwhelmingly customer configuration, not provider infrastructure failure
Redundancy is not backup, and free tiers are not free once usage grows
The trade-offs are unpredictable spend, effort to move providers, and inheriting the provider's outages

Practice

Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.

Think about it

Who is responsible?

For each of these, decide whether the provider or you are responsible: a failed disk in the datacentre; an employee record deleted by a bug in the employees API; a stolen access key that was committed to a repository; a security patch for the host operating system under a managed application platform.

Show solution

The failed disk and the host operating system patch are the provider's. That is the work you stopped doing, and it is genuine value — disks fail constantly at datacentre scale and you never hear about it.

The deleted record and the stolen key are yours. Both come from your code and your process, and the provider has no way to distinguish a bug from an intentional delete, or a stolen key from a legitimate one.

The pattern is worth naming: the provider is responsible for the infrastructure, and you are responsible for what you do with it. When you are unsure which side something falls on, ask whether a decision your team made caused it.

Try it yourself

Find out what you are paying for

In a cloud account you control, open the cost view and list every resource that is currently billing. Then set a budget alert at a figure that would worry you.

If you have no account, write the list you would expect for the employees API: what has to exist and keep running for it to serve a request?

Show solution

A minimal list is compute to run the API, a managed database, storage for uploaded photos, a secret store, and log collection. Each one bills separately, and log collection is the one that surprises people because its cost tracks how chatty your application is.

The budget alert matters more than it sounds. Cloud spend has no natural ceiling, so the only thing standing between a runaway loop and a large invoice is a notification you configured beforehand.

Knowledge check

Nothing is recorded and there is no score. The explanation appears either way.

Your team moves the employees API to a managed cloud platform. Which risk has genuinely decreased?

The risk of someone granting too much permission to a service accountThe risk of a hardware failure taking the service downThe risk of a SQL injection flaw in your own codeThe risk of a colleague deleting production data by mistake

Why is replication across three copies not a substitute for a backup?

Replication is slower than backupReplication only works within a single availability zoneReplication copies your deletions and corruptions along with everything elseReplication is not encrypted

Saved in this browser only.