PaaS vs IaaS: Where the Responsibility Line Actually Falls

Search for the difference between IaaS and PaaS and you will get the same picture from every result: a stack of horizontal layers, hardware at the bottom and your application at the top, with a line drawn across it. Above the line is yours. Below it is theirs. The picture is accurate and it is where almost every explanation stops.

Google's own generated answer for this comparison, as of writing, puts it in one sentence: with IaaS "you manage the operating system", and with PaaS the provider "takes care of servers, operating systems, and software updates". That is true. It also does not tell you what managing an operating system consists of, when any of it lands, or who a regulator will hold responsible when the data inside it leaks.

There are three lines, not one. The operational line decides whose calendar the work appears on. The security line runs somewhere else and has a category on it where both sides quietly assume the other one is covering it. The legal line, the one that determines who answers for personal data, is drawn by a completely different instrument and appears on none of the diagrams.

This article separates the three, lists what actually sits on each side, and gets to the part the comparison usually skips: the cases where the raw server is still the right answer, and what changes about all of it if you are operating in the EU.

The layer cake tells you the shape, not the bill

The layer diagram is a good model of one thing: what exists. Hardware, hypervisor, operating system, runtime, application, data. Both service models contain the same layers and disagree only about where responsibility for them changes hands. As a map of the territory it is fine.

The trouble is that responsibility is not evenly distributed across the height of the stack. Two layers of the diagram might be twenty minutes of work a year between them, and one layer might be the reason someone was awake at three in the morning last March. A diagram that gives each layer the same visual weight tells you nothing about that, and every comparison that stops at the diagram inherits the problem.

So the useful question is not which layers you own. It is which jobs you have signed up for, how often each one arrives, and whether it arrives on a date you chose.

Who manages what

That heading is lifted verbatim from Google's generated answer, where it appears as the subheading under both service models and is followed by one sentence each. Here is the longer version, written as a list of jobs rather than a list of layers. The pattern below is the common one across European providers as of writing; the details vary and yours are in your provider's documentation, not here.

Read down the IaaS column and the honest summary is that most of it is nothing most of the time. A well-configured server with unattended upgrades and a certbot timer can run for a year without a human decision, and people who say theirs has are telling the truth. One row is missing from the table on purpose, because it belongs to your application rather than to either party: the scheduled and background work you run yourself, where the choice between a cron job, a worker and a queue is yours under both models and the failure modes differ.

The jobs that only appear when they fail

Look at the fourth column instead. Almost nothing in it is scheduled. A certificate renewal that failed silently surfaces ninety days later, at the moment browsers start refusing the connection. A disk fills at a rate set by your traffic, so it fills fastest on your best day. A kernel advisory is published when the researcher finishes, and the window between publication and exploitation is not yours to negotiate.

That is the real content of the operational line. You are not choosing between more work and less work, because the average across a year may genuinely be close on both sides. You are choosing whether these events arrive as calendar items or as interruptions. Some teams should take the interruptions, and there is a section further down about who they are.

The security line does not run where the operations line runs

There is a second boundary, and the industry has a name for it. The shared responsibility model is the framework cloud providers use to state which security duties are theirs and which are yours. AWS published the first version of it in 2011, according to Datadog's account of its origin, and every major provider now publishes a variant.

These documents are worth reading, and worth reading as an answer to a different question from the one above. The operations line asks who does the work. The security line asks who is accountable if a control fails. Those produce different lists, and the gap between them is where incidents live.

"Security of the Cloud" and "Security in the Cloud"

AWS splits its model into two phrases that differ by one preposition. Security of the Cloud is the provider's half: the data centres, the hardware, the hypervisor, the managed services themselves. Security in the Cloud is yours: your data, who can reach it, how it is encrypted, and how everything you configured is configured.

The preposition carries the whole distinction, which is either elegant or a warning sign depending on your mood. In practice it means a provider can be completely correct about their half while your half is wide open, and nothing in the model has been violated. A long run of the cloud data exposures that made the news came down to a storage bucket left readable by anyone, and on every provider's diagram that sits squarely in the customer column.

Shared Controls: the row where both sides assume the other one has it

The models also contain a third category, and it is the one that repays attention. AWS calls it Shared Controls and defines it, in its own words as of writing, as controls "which apply to both the infrastructure layer and customer layers, but in completely separate contexts or perspectives".

The value of the shared category is that it is honest about ambiguity existing. The risk is that shared reads as covered. If a control appears in that row and neither party has written down who does what in your specific setup, it is not shared; it is unassigned.

This is the single largest practical difference between the two models. On IaaS, the shared row is short, because almost everything above the hypervisor is unambiguously yours. On PaaS, the shared row is longer, because the platform genuinely does more, and every job it does creates a boundary where an assumption can hide. Fewer jobs on your list, more edges to check.

The third line nobody draws: controller, processor, and Article 28

Here is the part missing from the pages that rank for either of these searches. We read the German first page for "paas vs iaas" and for "shared responsibility model" as of writing. Across both, the shared responsibility model is presented as a security framework and nothing else. The GDPR's own division of roles is not on any of them.

That matters because the GDPR draws its own line, and it does not follow the stack. Under the regulation, the controller is whoever determines the purposes and means of processing personal data, and the processor is whoever processes it on the controller's behalf. Those roles are decided by who is making decisions about the data, not by which layer of the diagram the data is sitting on.

The practical consequence is that moving from IaaS to PaaS does not change your role. You are the controller in both cases. What changes is how much of your stack has a processor attached to it, and what that processor has committed to in writing.

Notice the second row. On a raw server, the layers you took on have no processor behind them, so there is no one to hold accountable for them except you. Our comparison of self-hosted control planes against managed platforms puts it in a sentence: your data processing agreement now covers the metal, not the platform. Plenty of teams run their own infrastructure and meet their obligations properly, so this is not an argument against the server. It is a line item that belongs in the comparison rather than in a footnote.

Going the other way has its own homework. Every managed layer you adopt is a processor you have to check, and its sub-processors are ones you inherit. What an Article 28 data processing agreement has to commit each side to is the detail behind that, and it is a short enough read to do before signing rather than after.

"Is Azure an IaaS or PaaS?"

That question is quoted exactly as Google lists it, and it is one of the four things people most commonly ask alongside this comparison. The others in the block are "Is AWS SaaS or IaaS or PaaS?" and "Is Netflix IaaS, PaaS, or SaaS?".

All three have the same answer, which is that the question is aimed at the wrong noun. The service models classify services, not companies. Azure sells virtual machines, which are IaaS, and App Service, which is PaaS, and Microsoft 365, which is SaaS. Naming the vendor does not narrow anything down.

Netflix is the more interesting case, because the confusion there is about direction rather than granularity. Netflix consumes infrastructure as a customer and sells a finished application to viewers. From below it is an IaaS tenant; from above it is SaaS. Both descriptions are correct and they are descriptions of different relationships.

The distinction earns its keep the moment you try to use it. Ask which category a company belongs to and you get an argument. Ask which model a particular service is sold under, then read that service's terms, and you get the boundary you were looking for.

When the raw server is still the right answer

Plenty of the time. Everything above is a description of a trade, and there are situations where the trade goes the other way. On the responsibility question specifically, IaaS wins here:

• You need the boundary to sit below the operating system. Some contractual or regulatory regimes require you to control and evidence the full stack yourself. If you have to produce your own patch records for every layer, a platform that patches the base image for you has taken away the artefact you needed to show.
• The workload needs things a platform does not expose. Custom kernel modules, raw sockets, a licensed binary that checks the hardware it is running on, a GPU, or a process that has to hold connections open for hours. No amount of responsibility-shifting helps if the platform will not run the program.
• Your team already carries the operational line. If someone is already patching a fleet, the marginal host is close to free. The expensive server is the first one, and organisations that have crossed that threshold are paying a different price than the comparison assumes.
• You want the boundary unambiguous rather than convenient. On a virtual machine the shared-control row is nearly empty: above the hypervisor, everything is yours and there is nothing to negotiate. Some teams would rather own more and argue less, and that is a legitimate preference rather than a failure to optimise.

Where it goes wrong is the case in between. A small team, nobody whose actual job is operations, real customers, and a server configured during a week when someone had time. On that setup the operational line is technically owned and practically unattended, which is the worst of the two arrangements: you carry the responsibility and the work is not getting done.

Choosing in the EU: the examples nobody in the results uses

The examples that keep recurring in these results are American. The IaaS side gets illustrated with EC2 and Azure Virtual Machines, the platform side with Heroku, Google App Engine and Elastic Beanstalk. Google's generated answer for the comparison names those five and no others as of writing, which is a little strange given that it is answering a German query and that several of the pages it cites are German.

On the IaaS side the European market is not short of options. Hetzner, Scaleway, OVHcloud, Exoscale and UpCloud all sell virtual machines from European data centres under European corporate entities. If you decide the boundary belongs below the operating system, you do not have to leave the continent to put it there.

The platform side is thinner, and that thinness is part of why this question so often gets answered with a virtual machine. Teams who want their data in the EU look at the platform market, recognise most of the names as US companies, and conclude that they have to pick between convenience and residency. The conclusion is older than the market it describes.

Two things are worth checking on any candidate, whichever model you land on. The first is that a region is not an operator: a company incorporated outside the EU that offers an eu-central region is still governed by the law of the place it is incorporated, and what actually changes between an EU region and an EU provider is the useful version of that check. The second is the sub-processor list, because each managed layer you adopt brings its own, and the question of where your data physically rests is answered by the last name on that list rather than the first.

How Runsite handles it

For the PaaS side of this comparison, stated as the same three lines. Runsite runs managed web app hosting in the EU, with the operational line above the runtime: the base image, the operating system, the certificates and the release mechanism are ours, and your code, your dependencies, your secrets and your data are yours. The build runs from a webhook on push, releases are rolling behind a health check you configure, and a failed check returns to the last healthy version instead of publishing a broken one. The mechanics of that, if you want them, are in how git push to deploy actually works.

On the legal line: servers are in Germany as of writing, and a signed GDPR data processing agreement comes with every plan including the free one. That is the specific thing the IaaS row of the table above cannot give you, because on a virtual machine the obligation for everything over the hypervisor has nowhere to sit except with you. Managed PostgreSQL, Redis and object storage extend the same processor relationship to the data layer rather than leaving it on your side of the line.

Being fair about the trade: everything in the shared-controls discussion above applies to us as much as to anyone. Adopting a platform means adopting its boundaries, and the right response is to read the agreement rather than take the summary. If the four conditions in the IaaS section describe your situation, a European virtual machine is the better answer and we would rather you took it. Setup details are in the Runsite docs.

The short version

• There are three lines, not one. Operations decides whose calendar the work lands on, security decides who is accountable when a control fails, and data protection law decides who answers for personal data. They do not fall in the same place.
• The layer diagram is a map of what exists, not of what it costs. Two layers can be twenty minutes a year between them and one layer can be the reason someone was awake at 03:00.
• Read the fourth column, not the first. Almost nothing on the IaaS list is scheduled: certificates fail silently ninety days early, disks fill fastest on your best traffic day, and advisories are published when the researcher is ready.
• AWS's model splits on a preposition. Security of the Cloud is theirs, Security in the Cloud is yours, and a provider can be entirely correct about their half while your storage bucket is world-readable.
• Shared Controls is the row to watch. AWS defines it as controls applying to both layers "in completely separate contexts or perspectives". If nobody has written down who does what in your setup, that control is not shared, it is unassigned.
• PaaS shortens your job list and lengthens your boundary list. Fewer things to do, more edges where an assumption can hide.
• Your GDPR role does not change with the service model. You are the controller either way. What changes is how much of the stack has a processor attached and what that processor committed to in writing.
• On a virtual machine, the layers you took on have no processor behind them. That is not non-compliance, it is a line item, and it belongs in the comparison rather than a footnote.
• "Is Azure an IaaS or PaaS?" has no answer because the question classifies a company. The models classify services, and one vendor sells all three.
• The raw server wins when the boundary must sit below the OS, when the workload needs something a platform will not run, when your team already operates a fleet, or when you would rather own more and argue less.
• Every example in the current search results is American. On the IaaS side Europe has Hetzner, Scaleway, OVHcloud, Exoscale and UpCloud; on the platform side, check whether the region you were offered belongs to an operator under EU law.