AWS Cloud Practitioner Study Notes · Part 3
Cloud Computing Models and Deployment Strategies
AWS Cloud Practitioner study notes comparing IaaS, PaaS, SaaS, public cloud, hybrid, on-premises, and multi-cloud deployments.
Cloud computing questions often become confusing because the word “model” can refer to two different decisions. A service model asks, “How much of the technology stack does the provider manage?” A deployment strategy asks, “Where does the workload run?”
These are separate dimensions. Amazon EC2 can represent an Infrastructure as a Service (IaaS) choice inside a workload that is deployed entirely in the public cloud. A company can also use a Platform as a Service (PaaS) product in a hybrid architecture that connects AWS to an on-premises data centre.
This is Part 3 of the AWS Cloud Practitioner Study Notes series. The fastest exam technique is to identify which question the scenario is asking:
- Who manages the infrastructure, operating system, or runtime? Think IaaS, PaaS, or SaaS.
- Where does the application or data run? Think cloud, hybrid, on-premises, or multi-cloud.
Service models: how much does AWS manage?
The traditional service-model spectrum is:
IaaS → PaaS → SaaS
As you move from IaaS toward SaaS, the provider manages more of the underlying stack and the customer manages less. That usually reduces operational work, but it also reduces direct control over the infrastructure and platform.
The exact responsibility boundary depends on the service. IaaS, PaaS, and SaaS are useful study categories rather than a perfect label for every AWS offering.
IaaS: Infrastructure as a Service
IaaS provides the basic building blocks of cloud IT, such as compute, storage, and networking. The customer chooses and configures much of the environment above the physical infrastructure.
Common AWS examples include:
- Amazon EC2 for virtual machines
- Amazon EBS for block storage attached to compute resources
- Amazon VPC for virtual networking
- Elastic Load Balancing for distributing traffic across targets
With EC2, AWS manages the physical facilities, hardware, networking infrastructure, and virtualisation layer. The customer typically manages:
- The guest operating system
- OS patches and security updates
- Installed software and runtime components
- Application code and configuration
- Data and access controls
For example, launching an EC2 instance gives a team virtual CPU, memory, storage options, and networking. The team can then install Ubuntu, Nginx, Java, MySQL, or other software. That control is useful when the application needs a specific operating system, runtime, network configuration, or installation process.
Exam clues for IaaS include:
- The company wants control over the operating system.
- The customer must install and patch software on a virtual machine.
- The scenario describes virtual machines, storage, or networking building blocks.
If a question asks for maximum control over the operating system and applications, Amazon EC2 is a strong IaaS-style answer.
PaaS: Platform as a Service
PaaS removes more of the infrastructure management burden so the customer can focus on deploying and operating application code. The provider manages the underlying hardware and usually the operating system and runtime components required by the platform.
AWS examples that are commonly discussed as PaaS-style or managed application platforms include:
- AWS Elastic Beanstalk for deploying applications without directly managing the underlying servers
- AWS App Runner for deploying web applications and APIs from source code or a container image
- AWS Lambda for running functions without provisioning servers; Lambda is more precisely a serverless compute service, but it is often used in exam comparisons as an example of the provider managing the execution environment
- Amazon ECS with AWS Fargate for running containers without managing the underlying compute instances
With Elastic Beanstalk, a customer provides application code and configuration while the service can provision and coordinate resources such as EC2 instances, load balancing, and Auto Scaling. The customer still owns the application, data, permissions, and configuration decisions.
Exam clues for PaaS include:
- The developer deploys code without managing servers.
- The provider manages the operating system or runtime.
- The team wants to focus on application development rather than infrastructure maintenance.
- The platform provides deployment, scaling, or runtime management.
PaaS is not “no responsibility”. Customers still need to secure their code, data, identities, dependencies, and configuration.
SaaS: Software as a Service
SaaS provides a complete software application that is run and managed by the provider. The customer generally accesses the product through a web browser or client instead of installing and operating the application’s infrastructure.
Examples include:
- Amazon QuickSight for business intelligence and dashboards
- Amazon Connect for cloud contact-centre capabilities
- Gmail for web-based email
- Salesforce for customer relationship management
- Microsoft 365 for productivity software
When using Gmail, for example, the user does not manage the mail servers, operating systems, runtime, or storage infrastructure. The user still manages account access, settings, and the data they put into the service. An organisation may also configure identity, retention, compliance, and security controls around its use of the SaaS product.
Exam clues for SaaS include:
- Ready-to-use software accessed through a browser or client.
- The customer does not deploy application code.
- The provider operates the application and underlying infrastructure.
- The scenario is about using a product rather than building and hosting one.
Comparing IaaS, PaaS, and SaaS
| Responsibility | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical facilities and servers | Provider | Provider | Provider |
| Operating system | Customer | Provider or platform | Provider |
| Runtime and middleware | Customer | Provider or platform | Provider |
| Application code | Customer | Customer | Provider |
| Data and access configuration | Customer | Customer | Customer |
| Typical customer activity | Configure infrastructure and deploy software | Deploy application code | Use the finished application |
The table is a study aid, not a contract. AWS responsibilities and customer responsibilities vary by service. The AWS Shared Responsibility Model is the more precise reference when assessing a real workload.
Deployment strategies: where does the workload run?
Deployment strategy is independent of the service model. The main scenarios in these notes are cloud, hybrid cloud, on-premises, and multi-cloud.
Cloud or public cloud
A cloud-based application is fully deployed in a cloud provider environment. For an AWS workload, the application’s compute, storage, databases, and networking resources run in AWS Regions and Availability Zones rather than in the customer’s own data centre.
A simple example is a website using EC2, Amazon RDS, Amazon S3, and AWS Lambda with no application servers running in the company’s office.
Exam clues include:
- Fully cloud-based
- No customer-owned data-centre infrastructure for the workload
- AWS services provide the application’s infrastructure
“Public cloud” does not mean that the customer’s data is publicly accessible. Access control, network design, encryption, and identity management are still customer responsibilities.
Hybrid cloud
Hybrid cloud combines an organisation’s on-premises environment with at least one cloud provider. The environments are connected so that applications, users, or data can work across both locations.
Common AWS services and technologies in hybrid designs include:
- AWS Direct Connect for dedicated network connectivity
- AWS Site-to-Site VPN for encrypted connectivity over the internet
- AWS Storage Gateway for integrating on-premises environments with AWS storage
- AWS Outposts for running supported AWS infrastructure and services on customer premises
A bank might keep a system in its own data centre while deploying new application services in AWS. A company migrating gradually may run old and new components across both environments while it establishes connectivity and migration processes.
Exam clues include:
- On-premises infrastructure plus AWS
- A gradual migration
- Private connectivity between a data centre and AWS
- Existing systems that must continue operating while new cloud resources are added
On-premises or private infrastructure
An on-premises deployment runs inside infrastructure owned or directly controlled by the organisation, usually in its own data centre or private facility. The organisation is responsible for procuring, operating, securing, and maintaining the physical servers, networks, storage, facilities, and software.
This option may remain appropriate for certain technical, legal, latency, or organisational requirements, but it carries the operational responsibilities that cloud computing can reduce.
Exam clues include:
- Customer-owned hardware
- A private data centre
- No public cloud resources for the workload
- The organisation manages the complete infrastructure stack
Multi-cloud
Multi-cloud means using cloud services from two or more cloud providers, such as AWS and Microsoft Azure. It is different from hybrid cloud:
- Hybrid cloud: on-premises infrastructure plus one or more cloud providers.
- Multi-cloud: multiple cloud providers.
An organisation might use AWS for its web application, Azure for Microsoft-specific workloads, and Google Cloud for a specialised analytics service. Reasons for a multi-cloud strategy can include provider-specific capabilities, contractual requirements, data sovereignty, mergers, or business-unit choices.
Multi-cloud also introduces more operational complexity. Teams may need different identity systems, networking models, observability tools, security controls, deployment workflows, and skills for each provider. It should be treated as an intentional architecture decision rather than an automatic way to avoid every form of vendor lock-in.
One scenario using both dimensions
Consider an online retailer:
- It runs the customer-facing application on EC2, so the application tier uses an IaaS-style service.
- It deploys a separate API through AWS App Runner, using a PaaS-style managed platform.
- Employees use Amazon QuickSight for sales dashboards, which is a SaaS-style product.
- The inventory system remains in an on-premises data centre while the web application runs in AWS, making the overall architecture hybrid.
The service model describes each component’s management boundary. The deployment strategy describes where the overall system’s components run. Mixing these two questions is what causes many exam mistakes.
Exam-ready memory aid
Use this sequence:
Service model = who manages the stack?
- IaaS → customer manages more, including the operating system.
- PaaS → provider manages the platform; customer deploys application code.
- SaaS → provider delivers the finished application; customer uses and configures it.
Deployment strategy = where does it run?
- Cloud → workload runs in a cloud provider environment.
- Hybrid → on-premises plus cloud.
- On-premises → customer-controlled private infrastructure.
- Multi-cloud → two or more cloud providers.
Conclusion
IaaS, PaaS, and SaaS describe the division of management responsibility. Cloud, hybrid, on-premises, and multi-cloud describe the placement of the workload. They can be combined, so a workload can use IaaS and PaaS services in a hybrid deployment, or SaaS products alongside a public-cloud application.
For the Cloud Practitioner exam, first identify whether the question is about management responsibility or deployment location. Then look for the clue: operating-system control points to IaaS, code deployment without server management points to PaaS, a ready-to-use application points to SaaS, and on-premises plus AWS points to hybrid cloud.