The Difference Between IaaS, PaaS and SaaS

When people talk about cloud computing, they often use phrases like Infrastructure as a Service, Platform as a Service, and Software as a Service.

At first, these terms can feel like yet another set of acronyms to memorise. IaaS. PaaS. SaaS. Not exactly friendly.

But the idea behind these service models is actually quite practical. They simply describe how responsibility for a technology system is divided between the provider and the customer.

In other words, they help answer questions such as:

Once you understand that, the difference between IaaS, PaaS, and SaaS becomes much easier to follow.

It is worth getting this clear now, because when we get to security later in the series, almost everything will come back to where one side's responsibility ends and the other's begins.

Start with the full stack

Imagine a company wants to host its own application completely from scratch. Before the application can run, several layers of technology need to be in place.

At the bottom is the infrastructure layer. This includes the physical servers that provide computing power, the networking that connects and protects them, and the storage used for files, databases, logs and backups. It also commonly includes virtualisation, which allows several virtual machines to share the same physical hardware while remaining logically separated.

Above the infrastructure sits the platform layer. This includes the operating system, such as Windows or Linux, along with the middleware and runtime components the application depends on. A web application, for example, might require a web server, a programming language runtime, frameworks, libraries or container support.

At the top is the software layer, consisting of the application itself and the data it creates or uses.

It is useful to think of the stack in these three broad parts: infrastructure, platform and software. The different cloud service models are largely defined by where responsibility for those layers is divided between the customer and the cloud provider.

On-premises means you manage everything

In a traditional on-premises environment, that dividing line does not really exist. The organisation remains responsible for every layer, from the physical equipment and facilities through to the application and its data.

This provides a high degree of control. The organisation can choose its hardware, design its own network, determine how systems are secured and decide when upgrades or changes take place.

That control, however, depends on having the right expertise in-house. In practice, this might mean relying on a network engineer or systems administrator who could manage the network and servers, keep the environment secure, maintain reliable backups and recover systems when something goes wrong.

The organisation must also manage practical concerns such as power, cooling, physical access and hardware procurement.

The work continues throughout the life of the environment. Equipment has to be monitored and maintained, failed components replaced, operating systems patched and future demand anticipated. Expanding capacity may involve purchasing, installing and configuring new hardware, which can take time and require significant upfront investment.

Photorealistic early-2010s office server rack packed with network switches, rack-mounted servers, patch cables, a pull-out monitor and keyboard, and a UPS inside a cramped cupboard.

None of this makes on-premises infrastructure inherently unsuitable. Some organisations need the control it offers to tailor the environment to particular operational, security or regulatory requirements, while others already have the people, processes and facilities needed to operate it effectively.

It is, however, the model in which the organisation carries the greatest operational responsibility. Cloud service models move the dividing line further down the stack, transferring some of that responsibility to a chosen provider, whether AWS, AZURE, and so on. The organisation essentially becomes the customer, and the management of their resources the service.

Infrastructure as a Service

Infrastructure as a Service, or IaaS, is the cloud model most similar to traditional on-premises IT.

With IaaS, the provider runs the data centre, maintains the physical hardware and manages the virtualisation layer. Virtualisation is the technology that divides a physical server into separate virtual computers. The customer manages everything that runs inside those virtual computers, including the operating system, installed software, applications and data.

A virtual machine, often shortened to VM, is a common example of IaaS. It behaves much like a physical computer, but it is created in software and runs on the provider's hardware. Instead of buying and installing a server, you create a virtual machine through the provider's management portal or tools.

When creating a virtual machine, you choose its machine size, which determines how much processing power and memory it receives. You also select an operating system, such as Windows or Linux, decide how much storage it needs and configure its network settings.

Because the virtual machine is running in the provider's data centre, you normally connect to it remotely. A Linux server is often accessed through a terminal using SSH, or Secure Shell, which provides a secure way to send commands to another computer over a network. A Windows server is commonly accessed through Remote Desktop, which lets you view and control its graphical desktop from your own computer. These connections may travel over the internet or through a private network set up by the organisation.

IaaS is useful when an organisation wants the flexibility of the cloud but still needs control over the server environment. Technical teams can choose the operating system, install specialist software and configure the server to suit the application.

It is often a good fit for moving an existing server-based application into the cloud without redesigning it. Organisations may also use IaaS for development and testing, backup and disaster recovery, or to connect cloud systems with infrastructure that remains on their own premises.

The trade-off is that much of the day-to-day administration still belongs to the customer. The provider keeps the physical infrastructure running, but the customer's technical team must maintain the operating system, apply security updates and make sure the virtual machine remains secure and reliable. IaaS removes the need to own the hardware, but not the need to manage the server running on it.

Platform as a Service

Platform as a Service, or PaaS, moves more responsibility from the customer to the cloud provider.

With PaaS, the provider manages both the infrastructure and the platform on which the application runs. This includes the physical hardware, virtualisation, operating system and routine patching. It also includes the middleware and runtime, which are the software components needed to support and run the application.

Instead of creating and maintaining a virtual machine, a development team deploys its code to a managed service. To deploy an application means to publish it to an environment where it can run and be used. The provider prepares and maintains that environment, so the team does not need to manage the underlying servers directly.

A managed web application service, for example, can run a website or application without requiring the customer to install and maintain a web server. A managed database service provides a ready-to-use database without the team having to install, patch and operate the database software itself.

Some PaaS services are described as serverless. This does not mean that no servers are involved. It means the provider manages them on the customer's behalf. Developers supply the code, while the service provides the computing resources needed to run it. In many cases, those resources can increase or decrease automatically as demand changes.

PaaS is particularly useful when building new applications for the cloud. It reduces the amount of server administration required and allows development teams to spend more time designing, building and improving the application itself.

The customer still has important responsibilities. The application must be built securely, the service must be configured correctly and access to the data must be controlled. Teams must also keep an eye on performance, availability and cost. However, much of the routine work needed to maintain the operating system and platform is handled by the provider.

Compared with IaaS, PaaS gives the customer less control over the underlying environment, but it also requires less day-to-day maintenance. For many modern applications, that is a useful trade-off.

Software as a Service

Software as a Service, or SaaS, provides a complete application that customers can access and use.

With SaaS, the provider manages the application and the technology behind it. This includes the infrastructure, operating systems, platform software, updates and much of the work needed to keep the service available and secure. The customer does not install the application on its own servers or maintain the systems on which it runs.

Users normally access a SaaS product through a web browser, mobile app or desktop client, which is an application installed on their computer that connects to the online service.

Many familiar workplace tools follow this model. Microsoft 365 and Google Workspace provide services such as email, document editing and online collaboration. Slack and Microsoft Teams provide team messaging and communication, while Dropbox and Google Drive offer online file storage and sharing. Salesforce is another well-known example. It provides a customer relationship management system, often shortened to CRM, which helps organisations manage customer information, sales activity and communications.

Can you think of any examples you use on a daily basis?

In each case, the organisation uses a finished application rather than building and operating the system itself. A company using hosted email, for example, does not need to maintain the mail servers or install updates for the software behind them. It subscribes to the service, configures the available settings and gives its users access.

SaaS is therefore a good fit when an organisation needs a ready-made product rather than a platform for building its own application. Most organisations do not want to design, secure and operate an email system or collaboration platform from scratch. They want a reliable service that is ready to use.

The provider manages the underlying technology, but the customer still has important responsibilities. The organisation must decide who can use the service, what each person is allowed to do and what information can be stored in it. It may also need to configure security policies, connect the service to other systems and decide how long data should be kept.

These responsibilities are particularly important when the service contains personal, confidential or regulated information. The provider may operate the system, but the customer remains responsible for using it appropriately and controlling access to its data.

SaaS provides less control over the underlying technology than IaaS or PaaS, but that is part of its purpose. It allows an organisation to use a ready-made application without having to build and operate the system behind it.

Comparing the models

The easiest way to compare these models is to look at how responsibility is divided between the customer and the cloud provider.

Infographic comparing responsibility across On-premise, IaaS, PaaS and SaaS, using blue and orange stacked layers to show whether each part of the technology stack is managed by the customer or the service provider.

No single model is inherently better than the others. The right choice depends on the workload, the level of control the organisation needs, the skills it has in-house and how much operational responsibility it wants to keep.

An existing server-based application that needs to move to the cloud with only minor changes may be a good fit for IaaS. A new web application may benefit from PaaS if the development team wants to focus on the code rather than managing servers. When an organisation needs a complete business application rather than a platform for building one, SaaS is often the most suitable option.

Whichever model is chosen, responsibility does not disappear. It shifts. The provider may manage more of the technology stack, but the customer is still responsible for using the service securely, controlling access and managing its data appropriately.

A simple way to remember the difference

Think of it like renting a place to work.

No analogy is perfect, but the pattern is useful. As you move from IaaS to PaaS to SaaS, the provider takes on more responsibility, and you manage less of the underlying system.