Compare IaaS and PaaS Hosting

Host web pages on Azure VM and App Service to compare IaaS and PaaS.

Introduction

30 Second Summary

A web page can feel effortless to visit even when someone had to configure an entire server behind it. The real difference is who handles that hidden work.

In this project, you will host one page using Azure Virtual Machines and another with Azure App Service. You will compare Infrastructure as a Service (IaaS) with Platform as a Service (PaaS) to make the shared responsibility boundary visible.

What You'll Build

Your finished lab shows an IIS welcome page from a virtual machine you managed beside a Hello World page hosted without a server login.

By the end of this project, you'll have:

A live IaaS endpoint where entering your virtual machine's public IP shows the IIS welcome page you installed yourself.
A live PaaS endpoint where opening the App Service address shows a Hello World page without an operating-system sign-in or an IIS installation.
A shared-responsibility map that helps you classify IaaS, PaaS, or SaaS scenarios by tracing who manages each layer.
Secret Mission: Defend five cloud-service choices using workload needs plus responsibility boundaries.

Are there any prerequisites?

You need a Windows PC with Remote Desktop Connection, a browser, and a Microsoft Learn profile. Your Azure subscription must allow resource creation and deletion because the virtual machine can generate charges.

Before We Start

Before the hands-on work begins, take a moment to commit to what you are building. Connecting the two web endpoints to their infrastructure responsibilities makes the service models easier to recall under AZ-900 exam pressure.

Prepare a Safe Azure Lab

The upcoming cloud workloads create several temporary resources. A dedicated resource group gives those resources one cleanup boundary.

This step confirms access to your intended Azure subscription through the Azure portal. It also checks Remote Desktop Connection before you depend on it.

In this step, get ready to:

Confirm access to your intended Azure subscription.
Verify Remote Desktop Connection on your Windows PC.
Create an empty resource group for the lab.

Confirm your Azure access

Your Azure subscription provides the permissions used to create the lab resources. Opening the Resource groups page confirms that your account can reach the management area you need.

Go to the Azure portal in your browser.
Sign in with the account connected to your intended Azure subscription.
Enter Resource groups in the portal search bar.
Select Resource groups from the results.

You should see the Resource groups page. The Create action should be available.

Resource Groups Unavailable?

Confirm that the signed-in account belongs to an Azure subscription.
Ask your subscription administrator to grant resource-management access if Create is unavailable.

I cannot access Resource groups in the Azure portal. Help me check my account and subscription access.

Verify Remote Desktop Connection

Remote Desktop Connection is the Windows client you use to reach the server in the next step. Checking it now prevents the virtual machine workflow from stopping halfway through.

Press Windows key + R to open the Windows Run dialog.
Type mstsc.exe into the Run dialog.
Press Enter.

You should see the Remote Desktop Connection window with a field for a remote computer.

Leave the Remote Desktop Connection window open for the final checkpoint.

Remote Desktop Connection Missing?

Use Microsoft's Remote Desktop guidance to restore access before continuing.

Remote Desktop Connection does not open when I run mstsc.exe. Help me check my Windows setup.

Create the dedicated resource group

A resource group is a container for related Azure resources. Placing this entire lab inside one group gives every temporary resource the same lifecycle.

Your Billing Boundary

This step creates only an empty resource group. The billable virtual machine and Azure App Service resources arrive in later steps.

Keeping those resources in this group makes the final cleanup safer.

Return to the Resource groups page from earlier.
Select Create.
Choose your intended subscription in Subscription.
Enter az900-service-model-lab-rg in Resource group.
Choose an available Azure region in Region.
Select Review + Create.
Select Create to create the resource group.

Good work. Your lab now has a dedicated cleanup boundary.

What Did You Verify?

Creating the resource group verifies that your account can create resources in the selected subscription. The group name also gives every later resource a clear destination.

Before the final check, picture the clean starting state. What should appear inside the new resource group?

Return to Resource groups after creation completes.
Select az900-service-model-lab-rg from the resource group list.
Confirm that Delete resource group is available without selecting it.

You should see an empty resource group with no resources listed. The available deletion action confirms that the cleanup route is ready.

Unable to Create or Delete the Group?

Choose another available subscription in Subscription if your current subscription blocks resource creation.
Ask your subscription administrator for permission to create resources if every available region is blocked.
Ask your subscription administrator for permission to delete resource groups if Delete resource group is unavailable.

I cannot create or delete az900-service-model-lab-rg. Help me identify the Azure access I need.

Your safe Azure boundary is ready. Next up, you will host your first page with IaaS and experience the server responsibilities yourself.

Host a Web Page on IaaS

Good work. Your dedicated resource group now gives the lab one safe boundary.

With Infrastructure as a Service (IaaS), Azure runs the physical infrastructure while you manage the virtual machine's operating system and applications. You will see that administrative burden as you take one web page from server provisioning to web-server installation.

In this step, get ready to:

Deploy a Windows Server virtual machine with network access and auto-shutdown.
Connect to Windows Server through Remote Desktop Connection.
Install IIS and open its welcome page from your local browser.

Create the Windows virtual machine

Azure Virtual Machines gives you control over a server's operating system. The selected image determines which operating system Azure installs.

Use the Azure portal search bar to search for virtual machines.
Select Virtual machines from the search results.
Select Create from the page toolbar.
Select Virtual machine.
Select the intended subscription for this lab.
Choose the existing az900-service-model-lab-rg resource group.

The deployment is now scoped to the same group you created for safe cleanup.

Enter az900-iaas-vm as the virtual machine name.
Select an Azure region available to your subscription.

The name identifies your IaaS server throughout the rest of the lab.

Choose Windows Server 2022 Datacenter: Azure Edition - x64 Gen 2 as the server image.
Choose Standard_B2s as the virtual machine size.

Why use Standard_B2s?

The Standard_B2s size provides 2 vCPUs plus 4 GiB of memory. That capacity supports this Windows Server and IIS lab without selecting a larger VM.

Can't select Standard_B2s?

Availability varies by subscription and region. Keep Standard_B2s as the size while choosing another available region.

Need help finding an available region?

Administrator credentials unlock full control of the server. A unique password protects that access.

Choose an administrator username in the portal.
Record that username here: your VM administrator username.

The recorded username lets you identify the correct account when the remote sign-in prompt opens.

Create an administrator password of at least 12 characters that meets the displayed complexity requirements.
Store the password in your password manager.

Configure access and deploy the VM

A network security group controls which inbound traffic can reach the VM. This server needs remote desktop traffic for administration plus web traffic for the IIS page.

Choose Allow selected ports under the inbound port rules.
Select RDP (3389) plus HTTP (80).

The RDP rule permits remote administration. The HTTP rule exposes the web server through its public IP address.

Select the Management tab.
Enable Enable auto-shutdown.

Auto-shutdown provides a safety net if the VM is left running after the lab.

Choose the earliest shutdown time after your planned finish.
Select your local time zone.
Select Review + create.

This is the point where billing starts. The portal's live estimate reflects your selected region and VM size.

Confirm the review page shows az900-iaas-vm inside az900-service-model-lab-rg.
Review the live cost estimate.
Select Create.

Provisioning can take several minutes, so a waiting screen is expected. Azure is creating the server plus its disk and networking resources.

Return to the az900-service-model-lab-rg resource group after the deployment completes.
Refresh the resource list.

You should now see az900-iaas-vm in the group. Its Azure-managed supporting resources should appear beside it.

What did Azure create?

The running az900-iaas-vm resource represents your Windows Server virtual machine.
An operating-system disk stores Windows Server plus the software you install.
A public IP address makes the VM reachable from your local browser.
A network interface connects the VM to its virtual network, subnet, and network security group.

Deployment not completing?

Check whether the portal reports a quota or regional availability problem. Keep Standard_B2s as the size while trying another available region.

Help me understand my VM deployment problem.

Connect to the server and install IIS

Remote Desktop Connection gives you an interactive Windows Server desktop. Inside that session, PowerShell installs the web-server feature that serves your page.

Select az900-iaas-vm from the resource group.
Select Connect from the virtual machine page.
Select Connect again on the connection page.
Select Check access.
Select Download RDP file.

The downloaded .rdp file contains the connection settings for this VM.

Open the downloaded .rdp file with Remote Desktop Connection.
Review any connection warning to confirm it refers to az900-iaas-vm.

The next prompt requests the administrator credentials you created earlier. Keep the password private while signing in.

Enter your VM administrator username in the sign-in prompt.
Enter your stored administrator password.
Submit the credentials.

You should see the Windows Server desktop. You are now controlling an operating system running inside Azure.

Can't reach the Windows Server desktop?

Confirm the VM status shows Running on its overview page.
Confirm the inbound rules include RDP (3389).
Confirm you entered the administrator username stored above.

Help me troubleshoot the RDP connection.

Press the Windows key inside the remote session.
Type PowerShell into the remote search.
Select PowerShell from the search results.

The feature installation may take a few minutes while Windows adds the web-server components. Keep the remote session open until PowerShell finishes.

Install IIS with its management tools by running this command:

Install-WindowsFeature -name Web-Server -IncludeManagementTools

What does this command do?

Install-WindowsFeature adds a Windows Server feature to the VM.
-name Web-Server selects the IIS web-server role.
-IncludeManagementTools adds the tools used to administer IIS.

PowerShell should finish with a successful installation result. The VM can now respond to web requests through port 80.

IIS installation not succeeding?

Confirm PowerShell is running inside the remote Windows Server session. Keep the session connected until the feature installation finishes.

Help me troubleshoot the IIS installation.

The VM keeps running

Closing Remote Desktop Connection ends your remote view of the server. The Azure VM remains running and billed until you deallocate or delete it.

Close the Remote Desktop Connection window.
Return to the VM's Overview page in the Azure portal.
Locate the listed public IP address.
Record that address here: your VM public IP address.

Before you test it, what page do you expect the new web server to return through port 80?

Open a new tab in your local browser.
Type http:// into the address bar.
Paste your VM public IP address immediately after http://.
Press Enter.

You should see the default IIS welcome page. This proves that your local browser can reach the web server running on the Azure VM.

You made the IaaS endpoint work by provisioning the server, opening network access, signing in to Windows Server, and installing IIS yourself.

Don't see the IIS welcome page?

Confirm the VM status shows Running.
Confirm the inbound rules include HTTP (80).
Confirm the browser address uses the VM's public IP address after http://.

Help me troubleshoot the IIS endpoint.

Your IaaS endpoint is live. Next, you will host a page with Azure App Service to see how PaaS changes the server-management workload.

Deploy a PaaS Web App

The IIS endpoint from earlier is live in your browser. Getting there also made you responsible for the Windows Server operating system.

Now you will deploy a second endpoint with Azure App Service, a Platform as a Service (PaaS) offering. A Microsoft ARM template creates the hosting plan and sample app without an RDP session or IIS installation.

In this step, get ready to:

Configure the App Service Windows ARM template for your existing resource group.
Deploy an App Service plan on the F1 tier with a Hello World sample.
Compare the PaaS workflow with the virtual machine workflow.

Check the cost boundary

Billing is worth a quick pause here. The F1 App Service tier in this template has no cost for this quickstart.

Your Windows VM remains running. It can continue generating charges until you delete the lab.

Configure the App Service template

The app name becomes part of its public address. Azure requires that name to be globally unique and lowercase.

Open Microsoft's App Service Windows ARM template guide in a new browser tab.
Select Deploy to Azure.
Confirm your intended subscription appears under Subscription.
Select az900-service-model-lab-rg under Resource group.
Enter az900-paas-<unique-suffix> in the web app name field.

What does the template create?

The template creates an App Service plan to supply hosting capacity. It also creates the App Service app that serves your page.

Both resources land inside az900-service-model-lab-rg. This keeps the PaaS resources inside the same cleanup boundary as your VM.

Keep sku set to F1.
Set language to html.
Set helloWorld to true.
Leave repoUrl empty.

Why use these settings?

The F1 value selects the Free tier for the App Service plan.
The html value configures the template for a static HTML app.
The true value for helloWorld tells the template to deploy its sample app.
The empty repoUrl value leaves the built-in sample as the deployment source.

Deploy and open the Hello World site

Azure validates the template before creating its resources. A successful deployment gives you a public web endpoint without creating another virtual machine.

Select Review + create.
Wait for the portal validation to finish.

The deployment can take a few minutes, so a quiet progress screen is normal.

Select Create.
Wait for the deployment to finish.

You should see confirmation that the deployment succeeded.

Open the new App Service app from the completed deployment.

Before you open the site, predict what the browser will display.

Open the app's default site link from its App Service page.

You should see the Azure App Service Hello World sample. The page loads without a Windows Server sign-in.

The address starts with http://. It includes az900-paas-<unique-suffix> before .azurewebsites.net/.

Hello World page not loading?

Confirm that the app name contains lowercase letters or numbers.
Check that the deployment completed successfully before opening the site.
Confirm that helloWorld is set to true.
Confirm that repoUrl is empty.

Help me troubleshoot my App Service Hello World deployment.

Compare the two endpoints

A fair service-model comparison keeps the visible outcome similar. Both hosting models now give you a web page that opens in your local browser.

Before you compare the two pages, predict which endpoint works without a Windows Server session.

Return to the browser tab containing the VM public IP from the previous step.

You should still see the default IIS welcome page. This confirms that the IaaS endpoint remains live.

Switch back to the App Service default site.

You should see the Hello World sample. This confirms that the PaaS endpoint is reachable.

Return to az900-service-model-lab-rg from earlier in the Azure portal.
Refresh the resource list.

You should still see az900-iaas-vm with its supporting resources. The App Service app should appear beside an App Service plan on F1.

What did PaaS remove?

Both endpoints serve a browser page. Their setup workflows reveal a different responsibility boundary.

The App Service deployment did not require you to choose a VM image.
You did not open Remote Desktop Connection.
You did not sign in to Windows Server.
You did not install IIS.

Microsoft manages the operating system for PaaS. You can focus on deploying the application.

Both web endpoints are live, but only one required you to administer a server. Next, you will turn that difference into a shared-responsibility map for AZ-900 scenarios.

Map Shared Responsibilities

Your IIS page on Azure Virtual Machines is reachable. Your Hello World page on Azure App Service is reachable too.

The setup difference exposed the shared responsibility boundary. Your virtual machine gave you IaaS control over the operating system.

Azure App Service belongs to PaaS. Microsoft 365 belongs to SaaS.

A clear responsibility map keeps managed application hosting separate from ready-made software. That distinction helps you classify service-model scenarios under exam pressure.

In this step, get ready to:

Assign each cloud layer to the customer, Microsoft, or both.
Connect each service model to an example from the project.
Defend three service-model choices using responsibility boundaries.

Build the responsibility map

Cloud service models shift parts of the technology stack between you and Microsoft. The ownership labels below capture that shift across the nine areas used in this project.

Use These Ownership Labels

Customer data: Customer for IaaS. Customer for PaaS. Customer for SaaS.
Configurations and settings: Customer for IaaS. Customer for PaaS. Customer for SaaS.
Identities and users: Customer for IaaS. Customer for PaaS. Customer for SaaS.
Applications: Customer for IaaS. Shared for PaaS. Shared for SaaS.
Network controls: Customer for IaaS. Shared for PaaS. Microsoft for SaaS.
Operating system: Customer for IaaS. Microsoft for PaaS. Microsoft for SaaS.
Physical hosts: Microsoft for IaaS. Microsoft for PaaS. Microsoft for SaaS.
Physical network: Microsoft for IaaS. Microsoft for PaaS. Microsoft for SaaS.
Physical datacenter: Microsoft for IaaS. Microsoft for PaaS. Microsoft for SaaS.

For PaaS applications, Shared means you manage your deployed code. Microsoft manages parts of the application stack underneath it.

For SaaS applications, you configure access to ready-made software. Microsoft operates the service that delivers it.

Create a three-column table in a document or notes app by copying the nine rows from the ownership guide.
Inspect your table to confirm that every row has an IaaS, PaaS, and SaaS ownership label.

Your map now shows how responsibility moves toward Microsoft as the service becomes more managed.

Connect each model to a service

Product examples make the responsibility boundary easier to recall. The two pages you built provide direct examples for IaaS and PaaS.

Add Azure Virtual Machines as the IaaS example in your map.
Add Azure App Service as the PaaS example in your map.
Switch back to the browser tab showing the IIS welcome page.
Refresh the IIS welcome page.

You should still see the IIS welcome page served from the public IP of az900-iaas-vm.

Switch back to the browser tab for http://az900-paas-<unique-suffix>.azurewebsites.net/.
Refresh the Hello World page.

You should still see the App Service Hello World sample without an RDP session or Windows Server sign-in.

Add Microsoft 365 as the SaaS example in your map.
Write ready-made application beneath the Microsoft 365 example.

Your examples now connect direct operating-system control to IaaS, custom application deployment to PaaS, and ready-made software to SaaS.

Defend three scenario decisions

A strong service-model answer starts with the amount of control the workload needs. It finishes by naming one customer responsibility and one Microsoft responsibility.

Scenario Prompts

A legacy application requires control over the operating system.
A team wants to deploy custom code without maintaining an operating system.
A company wants ready-made productivity software.

Complete all three scenario answers with a service-model choice plus one customer responsibility and one Microsoft responsibility.

Before you compare your answers, which scenario do you think transfers the most responsibility to Microsoft?

Check Your Decisions

Legacy software requiring operating-system control uses IaaS. The customer manages the operating system. Microsoft manages the physical hosts.
Custom code without operating-system maintenance uses PaaS. The customer manages deployed code. Microsoft manages the operating system.
Ready-made productivity software uses SaaS. The customer manages identities and users. Microsoft manages the operating system.

Correct any scenario answer that does not match the decision guide.

Before you open the official matrix, which three responsibility rows do you expect to remain with the customer in every service model?

Open the official shared-responsibility guidance on Microsoft Learn to compare its Responsibility matrix with your map.

Your map should show Customer for customer data, configurations and settings, and identities and users across all three models.

The operating system should show Customer for IaaS. It should show Microsoft for PaaS and SaaS.

Physical hosts, the physical network, and the physical datacenter should show Microsoft across all three cloud models.

Applications should show Customer for IaaS. They should show Shared for PaaS and SaaS.

Network controls should show Customer for IaaS. They should show Shared for PaaS and Microsoft for SaaS.

Does Your Map Differ From the Matrix?

Check the Applications row if you assigned all responsibility to one side in PaaS. Your deployed code remains your responsibility while Microsoft manages the platform underneath it.

Check the Network controls row if you missed the Shared label for PaaS. Microsoft provides baseline network security while you configure application-level controls.

Help me reconcile my shared-responsibility map with Microsoft's matrix.

You have turned two working web pages into a responsibility map you can use under exam pressure.

Next, you will delete the dedicated resource group so the temporary lab stops generating charges.

Delete the Lab Resources

Your two web endpoints have made the service-model contrast visible. Now the final cloud skill is removing every temporary resource safely.

Stopping a VM does not necessarily end every charge. Deleting the dedicated resource group removes the complete Azure Virtual Machines and Azure App Service lab.

In this step, get ready to:

Review every Azure resource contained in the lab resource group.
Delete the dedicated resource group to remove the complete lab.
Confirm that the resource group and both web endpoints are gone.

Review the resources in the lab

Every resource from both hosting models shares one cleanup boundary. A final inventory shows exactly what the deletion affects.

Return to the Azure portal from earlier.
Select Resource groups from the portal menu.
Select az900-service-model-lab-rg.
Review the resources listed inside the group.

You should find az900-iaas-vm, its operating-system disk, its public IP address, its network interface, its virtual network, its subnet, its network security group, an F1 App Service plan, and the az900-paas-<unique-suffix> App Service app.

Why Review Before Deleting?

The inventory connects each resource to the responsibility you experienced. The VM stack represents the infrastructure you managed for IaaS.

The App Service plan and app represent the managed platform used for PaaS. One resource group now contains both sides of your comparison.

Delete the dedicated resource group

The dedicated group gives every lab resource the same lifecycle. Deleting that group prevents its disks or networking resources from being left behind.

Deletion Is Permanent

Deleting the group is a big step because both web endpoints stop working. For this temporary lab, that clean break prevents billable VM resources from being left behind.

The F1 App Service plan is free for this lab. The VM and its supporting resources can generate charges until they are removed.

Your completed shared-responsibility map sits outside this resource group. It remains available for AZ-900 revision.

Select Delete resource group on the resource group page.
Enter az900-service-model-lab-rg in the confirmation field.
Complete the portal's final confirmation to start the deletion.

Azure processes the resources as one group operation. The completion signal is the group disappearing from Resource groups.

Deletion Not Starting?

Check that the confirmation field contains az900-service-model-lab-rg exactly.
Confirm that the intended Azure subscription remains selected.
Confirm that your account still has permission to delete resources in this subscription.

Help me troubleshoot why Azure is not deleting my lab resource group.

Confirm every endpoint is gone

Deletion succeeds when the resource group and both public endpoints are gone. This check proves the temporary Azure lab has been fully removed.

Before you check, consider this question: which web pages do you expect to survive after their resource group disappears? Your prediction gives you a result to test.

Return to Resource groups in the Azure portal.
Search for az900-service-model-lab-rg.

You should see no resource group with that name in the selected subscription.

Use your browser history to revisit the VM public-IP IIS endpoint from earlier.
Use your browser history to revisit http://az900-paas-<unique-suffix>.azurewebsites.net/.

Neither endpoint should load. This confirms that the VM, its disk, its networking resources, the App Service plan, and the App Service app were deleted with the group.

Still Seeing the Group or a Web Page?

Refresh the Resource groups list.
Confirm that you are viewing the intended Azure subscription.
Refresh each endpoint to rule out a cached browser page.

Help me work out why the resource group or endpoints still appear.

That closes the lab safely. Your shared-responsibility map remains ready for AZ-900 revision.

Secret mission

Defend Five Cloud-Service Choices

Classify five unfamiliar workloads as IaaS, PaaS, or SaaS. Support every choice with a workload-control reason. Name one customer responsibility plus one Microsoft responsibility.

Clean Up Your Resources

The main path already deleted the Azure resource group and every workload inside it. Your lab has no ongoing Azure resource charges.

What did the lab cost?

The F1 Azure App Service plan used a free tier.

The virtual machine could generate variable charges while it existed. Its supporting disk and networking resources could also generate charges.

Deleting az900-service-model-lab-rg removed those lab resources.

Resources you used:

The az900-service-model-lab-rg resource group, now deleted.
The Azure Virtual Machines workload named az900-iaas-vm, now deleted.
The operating-system disk for az900-iaas-vm, now deleted.
The virtual machine networking resources, now deleted with the resource group.
The F1 Azure App Service plan, now deleted.
The Azure App Service app named az900-paas-<unique-suffix>, now deleted.

Keep everything running

No action needed. Choose this if you are still revising with the completed responsibility map.

Keep the completed IaaS, PaaS, and SaaS responsibility map in its current location.
Keep the five defended service-model decisions with the map.

The Azure workloads remain deleted while your exam revision artifacts stay available.

Pause - I'll come back to this later

There are no Azure workloads left to pause. Use this choice to end your study session while preserving your revision work.

Close the Azure portal browser tab.
Leave the completed shared-responsibility map in its current location.
Leave the five service-model defenses in their current location.

Closing the portal does not recreate any deleted resources.

Delete - I don't want to use this again

The Azure lab is already deleted. Use this option to confirm the subscription still has no matching resource group.

Return to the Azure portal from earlier.
Enter Resource groups in the search bar.
Select Resource groups from the results.
Search the resource-group list for az900-service-model-lab-rg.

You should see no matching resource group. This confirms every Azure workload created inside the group remains deleted.

Nice Work!

You did it! You hosted web pages with Azure Virtual Machines and Azure App Service. Their different workflows made the boundary between IaaS and PaaS visible.

You've learned how to:

Demonstrated two hosting models through working browser endpoints. The IaaS workflow exposed operating-system administration. The PaaS workflow removed that server burden.
Completed a Microsoft-aligned shared-responsibility map across IaaS, PaaS, and SaaS. You identified the operating-system boundary. You also classified Microsoft 365 as ready-made software.
Restored a clean Azure subscription by deleting az900-service-model-lab-rg. You confirmed that both former web endpoints no longer load.
Completed the Secret Mission by defending five cloud-service choices. Each decision used a workload-control reason. Each decision also identified customer and Microsoft responsibilities.

Ready to quiz yourself?