Cloud Computing Fundamentals
The Shared Responsibility Model
Where your cloud provider's security duties end and yours begin, and why that boundary moves depending on whether you're using IaaS, PaaS, or SaaS.
- Explain the shared responsibility model and state which security tasks the provider always owns versus which the customer always owns
- Identify how the responsibility split shifts across IaaS, PaaS, and SaaS for a given resource
- Apply the model to a worked example comparing an EC2-based application to a serverless one
- Correct the misconception that a provider's compliance certification covers a customer's own application
Whose failure is the empty bucket
A team spins up a storage bucket to hold files their app's users upload. To move fast during testing, they turn on public access, meaning to lock it back down before launch. They forget. Six months later, a security researcher finds the entire bucket sitting one search away, every uploaded file readable by anyone with the link. Who failed: the cloud provider, or the team?
The team did. Not because they mistyped a command, but because they treated a decision that was always theirs to make as if the provider had made it for them. That gap between what a provider secures and what a customer configures is exactly what the shared responsibility model exists to close.
Security of the cloud, security in the cloud
AWS names its half of the split "security of the cloud": the physical data centers, the racks inside them, the hypervisor that carves one physical server into many virtual machines, and the global network connecting AWS regions. You never see any of it, and you never patch any of it. Azure and Google Cloud describe the same division for their own platforms, in different words but the same shape.
Your half is "security in the cloud": everything you build, configure, and store using the services the provider hands you. That always includes your data and your access policies. Depending on which service you picked, it can also include your guest operating system and your application code.
The boundary moves with the service model
That split is not fixed in one place. It slides along the stack depending on how much of the stack you asked the provider to manage.
| Responsibility | IaaS (a virtual machine) | PaaS (a managed database or app platform) | SaaS (a ready-made application) |
|---|---|---|---|
| Data and access configuration | Customer | Customer | Customer |
| Application code and settings | Customer | Customer | Provider |
| Guest operating system | Customer | Provider | Provider |
| Network controls (firewalls, routing) | Customer | Shared | Provider |
| Hypervisor and physical host | Provider | Provider | Provider |
| Physical network and data center | Provider | Provider | Provider |
Read the table top to bottom rather than column by column: the top two rows almost never move to the provider, and the bottom two rows almost never move to the customer. The middle rows are where the interesting decisions live, and where most exam questions and most real misconfigurations happen.
Worked example: the same feature, two service models
Say a team runs a Node.js API on an Ubuntu virtual machine. AWS handles the physical server, the hypervisor, and the network between availability zones. The team handles patching Ubuntu when a kernel vulnerability ships, configuring the security group so only port 443 is reachable, and rotating the SSH key used to log in. That is IaaS: heavy on the customer's side of the table.
Now the same team rebuilds the upload feature as an S3 bucket plus a Lambda function that resizes images on arrival. AWS now manages the operating system and runtime patching for Lambda's execution environment entirely; there is no server for the team to patch at all. What is still theirs: the S3 bucket's access policy, the IAM role the function assumes and what that role is allowed to touch, and whether the stored files are encrypted. Moving from IaaS to a serverless PaaS-style service removed an entire row from the customer's side of the table. It did not remove the top row.
What never crosses the line
Regardless of IaaS, PaaS, or SaaS, two things stay the customer's job in every case: the data itself, including its classification and encryption choices, and identity and access management, meaning who can sign in and what they can do once they're in. A provider can encrypt a disk by default, but only the customer decides which files are sensitive enough to restrict further, and only the customer decides who on the team gets access to them. The next two lessons in this topic cover exactly those two rows in depth: identity first, then encryption.
Misconception: a certificate you didn't earn
It's tempting to assume that because your cloud provider is SOC 2 or ISO 27001 certified, your own application inherits that certification. It does not. The provider's certificate covers the infrastructure it operates: the data centers, the hypervisor, the internals of its managed services. Whether your application's access controls, encryption settings, and data-handling practices meet a given framework is a separate audit, and only you can produce evidence for it. The last lesson in this topic returns to this exact gap and walks through how teams close it.
Exam cues: reading a shared-responsibility question
| The scenario says... | Points to |
|---|---|
| "Physical security of the data center," "the hypervisor" | Always the provider |
| "Patching the guest operating system" on a virtual machine | Customer (IaaS) |
| "Patching the operating system" a managed database runs on | Provider (PaaS) |
| "Configuring a bucket policy," "IAM permissions," "encryption settings" | Customer, in every service model |
| "Physical network between data centers" | Always the provider |
The trap to watch for: a question that mentions a managed or serverless service and expects you to assume the provider now owns everything. It owns more than it did under IaaS, but data and identity never move.
Where this leaves you
As you move from IaaS toward SaaS, the provider's slice of the table grows and the customer's shrinks, but the top two rows, data and identity, never cross that line in either direction. Learning to read a scenario and place it correctly on this table is the single most tested skill in cloud security fundamentals. The next lesson opens the identity half of that job in full: how the cloud actually verifies who you are and decides what you're allowed to do once it knows.