When you use the cloud, you’re not always renting “the same thing.” You can rent anything from a bare computer to a fully ready-to-use application. These levels are called service models, and there are three: IaaS, PaaS, and SaaS. Understanding them is key because they define how much work you do and how much the provider does.

The most famous (and useful) way to understand this is to think about how you can eat a pizza:

1. Make it at home from scratch: you buy flour, tomato, cheese… and cook. Total control, lots of work. → On-premise.
2. Buy a frozen pizza: it’s already made, you just use the oven. → IaaS.
3. Order pizza delivery: it arrives ready, you set the table and drinks. → PaaS.
4. Go to a restaurant: you sit and eat; you don’t do anything. → SaaS.

In all cases you eat pizza, but each time you delegate more work. Let’s look at each model in IT.

What you rent: the basic components. Virtual servers, storage, networks. The provider gives you the “virtual hardware” and you install and manage everything else: operating system, patches, your application, etc.

Analogy: you rent an empty apartment. The walls and floor are there; you bring the furniture.

You manage: operating system, software, configuration, your application. The provider manages: physical servers, virtualization, physical network, datacenter.

Examples in AWS:

• EC2 (virtual servers) — we’ll see this in Chapter 4.
• S3 (storage) — Chapter 5.
• VPC (networks) — Chapter 6.

When to use it: when you need control and flexibility, for example to migrate an existing application as-is or install very specific software.

What you rent: a ready-to-use platform where you just upload your code. The provider takes care of the operating system, patches, scaling, and server. You only worry about your application and your data.

Analogy: you rent a furnished apartment. You arrive with your suitcase and move in.

You manage: your code and your data. The provider manages: everything below (OS, runtime, servers, scaling).

Examples in AWS:

• AWS Elastic Beanstalk (you upload your app and AWS deploys it).
• AWS Lambda (you upload a function, AWS runs it) — Chapter 14.
• RDS (managed database) — Chapter 8.

When to use it: when you want to focus on coding and not on managing servers. Ideal for small teams that want to move fast.

What you rent: the final, finished application. You don’t install or program anything: you just use it, usually from the browser.

Analogy: you go to a hotel. You don’t bring furniture, cook, or clean. You just enjoy.

You manage: nothing technical, just your data within the app. The provider manages: absolutely everything.

Examples you already use:

• Gmail, Office 365, Dropbox, Slack, Netflix, Salesforce.

When to use it: when you need a solution and don’t want to build anything. Most of the tools you use daily are SaaS.

This table summarizes who is responsible for each layer. ✅ = you manage it; ☁️ = the provider manages it.

Notice the pattern: the further down the table you go towards SaaS, the fewer things you manage. That means less work, but also less control.

None is “better”: it depends on how much control you need versus how much work you want to save.

Real example: A company sets up its product like this:

• Uses Gmail (SaaS) for email, because they don’t want to maintain a mail server.
• Deploys their application with Lambda (PaaS) to avoid managing servers.
• But their video processing system, which needs special configuration, runs on EC2 (IaaS) for total control.

Mixing models according to each need is normal and recommended.

• IaaS = you rent the basic infrastructure; you manage the OS and above. (More control, more work.)
• PaaS = you rent a platform; you just upload your code. (Balance.)
• SaaS = you use a finished application. (Less work, less control.)
• The pizza analogy and the “who does what” table will help you place any service.
• It’s common to combine all three models as needed.

In the next subchapter we’ll look at the five pillars that formally define what the cloud is according to NIST, the reference organization.