Learn Cloud Computing - Cloud Service Models (IaaS, PaaS, SaaS, FaaS) & Shared Responsibility Model

#Introduction

In episode 1, you understood the evolution of the cloud: each era moved one layer of responsibility from you to someone else. Episode 2 measures how far that transfer can go — and that is the core of the cloud service models.

There's one question that determines everything: when you use a cloud service, who is responsible for which layer? The answer is captured in two complementary concepts: the service models (how much the provider supplies) and the shared responsibility model (who secures what).

#Shared Responsibility Model

The principle is simple: cloud security is a joint responsibility between the provider and the customer, with a dividing line that shifts depending on the service model.

• Security OF the cloud — the provider is responsible for securing the physical data center, network, and hypervisor.
• Security IN the cloud — you're responsible for securing what you build inside it: data, configuration, access.

By analogy, renting an office: the building owner is responsible for the structure, elevators, and lobby security. You're responsible for your desk keys, cabinet contents, and who you invite in. If you forget to lock the door, no one at the building can help you.

The responsibility map changes according to the service model:

The further right the model, the more the provider manages — and the less you can control. Choosing a service model means choosing a position on this spectrum.

#IaaS: Full Freedom, Full Responsibility

Infrastructure as a Service (IaaS) provides the most basic building blocks: virtual machines, storage, and networking, accessed as APIs. You manage everything from the operating system upward — updating kernels, applying security patches, and configuring applications.

Real-world examples: EC2 on AWS, Compute Engine on GCP, Azure Virtual Machines. It's like renting an empty plot of land: you're free to build anything, but the building, its security, and its upkeep are your business.

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-key

The command aws ec2 run-instances provisions a ready-to-use VM in seconds — something that took weeks in the on-premise era.

#PaaS: Focus on Code

Platform as a Service (PaaS) moves up a level: the provider manages the runtime, OS, and scaling. You just deploy code — the platform decides how to run it. System updates, patching, and scaling are handled by the provider.

Examples: Elastic Beanstalk on AWS, App Engine on GCP, Azure App Service. It's like renting a catering kitchen complete with equipment: you just focus on cooking the recipe; stove maintenance isn't your concern.

#FaaS: Serverless Functions

Function as a Service (FaaS) or serverless takes the PaaS concept to its logical end: you write a function, and the platform runs it only when invoked. No visible servers, no idle cost — billing is calculated per invocation and execution duration.

Examples: Lambda on AWS, Cloud Functions on GCP, Azure Functions. This series will cover serverless in depth later, but the key point here is: FaaS is the most extreme point of "not managing infrastructure."

gcloud functions deploy hello-world \
  --runtime python312 \
  --trigger-http \
  --allow-unauthenticated

gcloud functions deploy uploads your code and immediately gives you a public URL — without a single server you have to manage.

#SaaS: Ready-Made Products

Software as a Service (SaaS) is a complete product you just use: application, data, user management, and backups are all managed by the provider. You manage nothing except your users and your data.

The most familiar examples: Gmail, Microsoft 365, Salesforce. You never ask "what servers run Gmail" — you just use the result. SaaS answers needs, not infrastructure.

#Comparison of Equivalent Services

A key point for this series: although the service names differ, the three providers offer services that are conceptually aligned. You can map a capability from one provider to another:

Once you master a concept (for example "object storage"), that capability can be used at any provider — you just translate the service name. This is why the series compares three providers at once: concepts first, vendors later.

#Choosing a Service Model

No model is "the best" — there's only the model that best fits the context:

• IaaS — you need full control, legacy workloads, regulations that require managing things yourself.
• PaaS — your developer team focuses on the application and wants a provider-maintained platform.
• FaaS — unpredictable, event-driven workloads, and you want zero cost while idle.
• SaaS — business needs available as ready-made products, without wanting to build them yourself.

#Conclusion

Episode 2 is the operational roadmap of the cloud:

• Shared responsibility divides duties: the provider secures the infrastructure, the customer secures what's built on top of it.
• IaaS gives maximum control with maximum responsibility; SaaS is the opposite.
• FaaS eliminates idle cost and server management entirely.
• AWS, GCP, and Azure services are conceptually aligned — you can map capabilities between providers.

In episode 3, we enter the most important layer of "security IN the cloud": Identity & Access Management (IAM) — how to manage who can access what, comparing AWS IAM, GCP IAM, and Azure Entra ID.