In the previous lesson we met Azure and Contoso Airlines. Now it is time to answer the two questions that condition every later design decision: how much responsibility do I want to keep? and where is my platform going to live physically?

The first question is answered by the service models (IaaS, PaaS, SaaS and serverless) and by the shared responsibility model. The second, by Azure's geographic hierarchy: geographies, regions, region pairs and availability zones. Both decisions are hard to undo later — moving a production system to a different region is a project, not an adjustment — so they are worth understanding properly before creating your first resource.

1. The service models and the control analogy
2. Comparison: who manages what
3. Serverless: the special case
4. The shared responsibility model
5. Geographies, regions and region pairs
6. Availability zones and availability sets
7. How to choose a region
8. SLAs and their relationship with redundancy
9. Contoso Airlines' decision
10. Common Mistakes and Tips
11. Exercises
12. Conclusion

The most useful analogy for understanding the service models is how you get to your destination when you travel. In every case you arrive; what changes is how much work you do and how much control you keep.

Translated into computing terms:

Azure gives you the virtualized infrastructure: virtual machines, disks, networks. You install the operating system (or pick an image), patch it, install the software, configure it and maintain it.

• Examples in Azure: Virtual Machines, managed disks, virtual networks.
• When to use it: fast migrations of existing systems, software that demands operating system control, legacy workloads.
• At Contoso: the legacy availability engine, which depends on a specific version of a library, will start its life in Azure as a virtual machine (module 2).

Azure gives you a platform ready to run your code or your data. You do not see the operating system and you do not patch anything: you upload the application and it works.

• Examples in Azure: App Service, Azure SQL Database, Azure Database for PostgreSQL, Azure Container Apps.
• When to use it: new or modernizable applications, when you want to spend the team's time on the product rather than on maintenance.
• At Contoso: the Contoso Bookings website and the Availability API will end up in App Service, and the booking database in Azure SQL Database (modules 2 and 3).

You consume a finished application by subscription. There is nothing to deploy.

• Examples: Microsoft 365, Dynamics 365, GitHub. From the user's point of view, Azure DevOps too.
• At Contoso: corporate email is already Microsoft 365; there is no intention whatsoever of managing it.

This table is the reference for the rest of the course. It marks who takes care of each layer. C = customer, M = Microsoft.

Look at the first two rows: data and identities are always the customer's responsibility, in every model. It is the most important idea in this lesson, and the reason module 4 exists.

Serverless is an unfortunate name: there are servers, but you do not see them, you do not size them and you do not pay when they are not in use. It is an evolution of PaaS with two distinctive traits:

• Automatic scaling down to zero. If nobody calls your function, there are no instances and there is no compute cost.
• Billing per execution. You pay for the number of invocations and the execution time consumed, not for an hour of server uptime.

• Examples in Azure: Azure Functions, Logic Apps, Event Grid, Azure Container Apps with scale to zero.
• At Contoso: generating the boarding pass PDF after a booking is confirmed is a textbook case for a function; it happens in bursts and does not justify a server running 24 hours a day. It will be built in module 6.

This model answers the question every security manager asks in their first week: "if Microsoft is certified, what do I have to worry about?".

The general rule: Microsoft is responsible for the security of the cloud; the customer is responsible for security in the cloud.

Three concrete examples applied to Contoso, so that it does not stay abstract:

Azure organizes its physical presence into levels. From largest to smallest:

• Geography: an area of the world that groups regions together and that respects the data residency and compliance boundaries of that territory (for example, Europe). Data in a geography does not leave it unless you explicitly configure it to.
• Region: a set of data centers within a low-latency perimeter, with a commercial name (West Europe, North Europe, Spain Central). It is the unit you choose when creating a resource.
• Region pair: each region is paired with another in the same geography, usually more than 300 km away, with two useful properties:
  • Some services replicate data automatically to the paired region (for example, geo-redundant storage, covered in module 2).
  • In a widespread outage, Microsoft prioritizes the recovery of one region of the pair, and it schedules platform updates for the two in a staggered way, not simultaneously.

Examples of pairs in Europe: West Europe (Netherlands) ↔ North Europe (Ireland); France Central ↔ France South; Spain Central is paired within the same European geography.

Important note: Microsoft is also introducing non-paired regions backed by availability zones. Always check the current pair of the region you use in the official documentation, because the map keeps evolving.

This is where you decide which specific failure you are protecting yourself from. Each level covers a different kind of disaster and none replaces the others.

An availability set is an IaaS concept. When you place several virtual machines in one, Azure spreads them across:

• Fault domains: groups of servers that share power supply and network switch. Spreading across fault domains prevents a power failure from taking down all your VMs.
• Update domains: groups that Azure restarts separately during planned maintenance. It never restarts two domains at once.

An availability zone is one or more physically separated data centers within the same region, with independent power, cooling and networking, connected to each other by very-low-latency fiber. Enabled regions have at least three zones.

Rule of thumb: availability set for legacy IaaS within a data center; availability zones when the region offers them and the service supports them; region pair for the big disaster.

There is no universal answer. You evaluate five criteria and document the decision.

On GDPR and sovereignty, three points that are often confused:

1. Choosing a European region keeps data at rest within that geography, but certain metadata and global services (such as the Microsoft Entra ID directory itself) have their own scope. Look into it if your sector requires it.
2. Geo-replication may move data to the paired region: check that the pair is also within the acceptable geography (in Europe, it is).
3. The responsibility for classifying which data is personal and for applying encryption and retention is always the customer's, as we saw in section 4.

The SLA (service-level agreement) is the availability commitment Microsoft makes for a service, with financial compensation in the form of a credit if it is not met. Two nuances almost nobody explains:

• The credit does not cover your business loss. If Contoso stops selling tickets for three hours, the credit on the bill does not make up for the lost sales. The SLA is a quality signal, not insurance.
• The SLA depends on how you deploy. It is not a fixed number for the service: it improves if you add redundancy.

Indicative values for virtual machines (always check the current figures in the official SLA document, because they get updated):

And here is the point that surprises people most: when you compose services, availabilities multiply. If the website has 99.95%, the database 99.99% and the storage 99.9%, and a sale needs all three at once:

That is around 70 minutes a month in the worst case, worse than any of the individual pieces. That is why availability design is done over the complete user journey, not service by service.

Marta Ríos documents the decision as follows, and we will inherit it throughout the course:

• Geography: Europe. Contoso sells to EU citizens and their personal data does not leave the European geography.
• Primary region: West Europe. Reasons: it has the most complete service catalog in the geography, it offers availability zones, and latency from Spain is a few tens of milliseconds, acceptable for sales.
• Secondary region: North Europe, which is its paired region. It will be used for geo-redundant backups and, later on, for disaster recovery (module 7).
• Within West Europe: the critical components (website and API) will be spread across at least two availability zones.
• What Contoso does NOT do: it does not deploy active-active across the two regions. That would be twice the cost and its recovery objective (a few hours) does not justify it. It is a conscious decision, not an oversight.

• Choosing a region out of habit or apparent proximity. "Since we are in Spain, I'll use the nearest region" is an incomplete criterion: it may not have the service you need, or it may have a different price. Evaluate all five criteria.
• Confusing availability zones with regions. Zones protect you against the loss of a building within the same region; they do not protect you from a regional disaster. And resources in one zone are not accessible as if they were in another region.
• Believing that PaaS removes all responsibility. In PaaS you are still responsible for data, identities, configuration and code. Only the operating system disappears.
• Thinking the SLA guarantees your availability. It only covers Microsoft's service, and only with the configuration you have deployed. A single-instance deployment does not get the SLA of a redundant deployment.
• Forgetting that replication is not a backup. If you delete a record by mistake, replication replicates the deletion. You need backups with retention (module 7).
• Mixing regions for no reason. Putting the application in one region and the database in another adds latency to every query and data egress cost. Keep the components that talk to each other a lot together.
• Cost tip: if you are just practicing, none of this costs anything yet because we have not created any resources. But remember that replicating across several zones multiplies the instances, and therefore the bill. Every availability level has a price; choose the one the business needs, not the highest one possible.

For each component of Contoso's platform, indicate which service model is the most appropriate (IaaS, PaaS, serverless or SaaS) and justify it in one sentence:

1. The public Contoso Bookings website, rewritten as a modern application.
2. The legacy availability engine, tied to a specific version of a system library.
3. Generating the boarding pass PDF when a booking is confirmed.
4. The staff's corporate email.
5. The booking database, which needs automatic backups and hands-off patching.

Classify each incident as Microsoft's or Contoso's responsibility, and explain why in one sentence:

1. A brute-force attack gets in using the weak password of an administrative account without multifactor authentication.
2. A cooling failure takes a data center in one West Europe zone out of service.
3. The availability engine's virtual machine has gone eight months without operating system security updates.
4. A failure in the underlying storage of Azure SQL Database causes 20 minutes of unavailability.

Contoso wants ticket sales to survive these three scenarios, at the lowest possible cost in each case. State which mechanism you would use:

1. Microsoft restarts the physical host running the VM during monthly maintenance.
2. A fire takes the building housing one West Europe zone out of service.
3. An operator accidentally deletes the whole booking table for the last month.

Also, calculate the composite availability of a purchase journey that goes through a load balancer (99.99%), the website (99.95%) and the database (99.99%).

Solution 1:

Solution 2:

1. Contoso. Identities and their protection (MFA, password policies) are always the customer's, in any model.
2. Microsoft. Physical data center infrastructure. That said, if Contoso deployed in a single zone, the consequence is indeed down to its own design.
3. Contoso. It is IaaS: patching the guest operating system is the customer's job.
4. Microsoft. It is PaaS and the failure is below the layer the customer manages; the service SLA applies.

Solution 3:

1. Availability set (or, better still, zones if the service supports them): it spreads the VMs across different update domains so that maintenance does not restart them at the same time. Added cost: none beyond having more than one instance.
2. Availability zones: instances spread across at least two West Europe zones, behind a zone-redundant load balancer.
3. Backups with retention and point-in-time restore. Neither zone replication nor geo-replication helps here: they would replicate the deletion.

Composite availability:

Around 30 minutes of unavailability a month, worse than any of the three components on its own.

The service models describe how much responsibility you hand over: IaaS leaves you the operating system, PaaS takes it away, serverless also takes away the idle capacity, and SaaS hands you the finished application. Whatever the model, the shared responsibility model always leaves data, identities and configuration on your side: that is the sentence to remember from this lesson.

Physically, Azure is organized into geographies → regions → availability zones, with region pairs for the big disaster and availability sets for rack failures. Each level protects against a different type of failure, has its own cost and is reflected in the SLA, which also multiplies downwards when you compose services. Contoso Airlines has chosen West Europe as its primary region, North Europe as its pair, and a spread across several zones for its critical components.

With the "which model" and the "where" resolved, all that is left is the practical part: creating the account. In the next lesson, Creating and Setting Up Your Azure Account, we will look at what you need in order to sign up, what the free account includes, what subscription types exist and — very importantly — how to set a budget and a spending alert before creating your first resource.