Describe Azure architecture and services

In Chapter 1, “Describe cloud computing,” you learned about the cloud and how you can benefit from using cloud services. Microsoft Azure was mentioned, but not in much detail.

In this chapter, we dive into the many services and solutions that Azure offers. You’ll gain an understanding of the key concepts in Azure’s architecture, which apply to all Azure services. We cover Azure datacenters and ways that Microsoft implements fault tolerance and disaster recovery by spreading Azure infrastructure across the globe. You’ll also learn about availability zones, which are Microsoft’s solution for ensuring your services aren’t affected when a particular Azure datacenter experiences a problem.

You’ll also discover how to manage and track your Azure resources and how you can work with resources as a group using Azure resource groups. You’ll learn how to use resource groups to plan and manage Azure resources and how resource groups can help you categorize your operational expenses in Azure.

Once you have the foundational understanding of Azure, you’ll dig into some of the compute and networking services in Azure. You’ll learn about Azure Virtual Machines and Virtual Machine Scale Sets. You’ll learn about some of the application hosting options such as Azure App Service, and you’ll learn about networking services in Azure, such as Azure Virtual Networks, Azure DNS, and Azure VPN Gateway.

We’ll then look at some of the storage services in Azure. You’ll learn about storage tiers and redundancy options, and we’ll look at how you can move files into Azure Storage easily.

We’ll close out the chapter with a discussion of identity, access, and security. You’ll learn about Azure Active Directory and authentication methods in Azure. You’ll also learn about how you can control access to your Azure resources and your options for keeping them secure.

If you think that’s a lot to cover, you’re right! It’s important for you to understand all these topics to pass the AZ-900 exam. With the foundational knowledge of the cloud from Chapter 1, “Describe cloud computing,” you’ll find that understanding Azure-specific concepts will be easier than you think.

Skills covered in this chapter:

• Describe the core architectural components of Azure

• Describe Azure compute and networking services

• Describe Azure Storage services

• Describe Azure identity, access, and security

Skill 2.1: Describe the core architectural components of Azure

If you were to ask any CEO to list the five most important assets of their company, it is likely that the company’s data would be near the top of the list. The world we live in revolves around data. Just look at companies like Meta (the company that owns Facebook) and Google. These companies offer services to us that we like. Everyone likes looking at pictures from friends and family on Facebook (mixed in with things we don’t like so much), and many people use Google to look for things on the internet. Meta and Google don’t offer those services because they want to be nice to us. They offer those services because it’s a way for them to collect a large amount of data on their customers, and that data is their most valuable asset.

Meta and Google aren’t alone. Most companies have vast amounts of data that is key to their business and keeping that data safe is at the cornerstone of business decisions. That’s why some companies are hesitant to move to the cloud. They’re afraid of losing control of their data. Not only are they afraid that someone else might gain access to sensitive data, but they’re also concerned about losing data that would be difficult (or even impossible) to re-create.

Microsoft is keenly aware of those fears, and Azure has been designed from the ground up to instill confidence in this area. Let’s look at some core architectural components that help Microsoft deliver on the cloud promise.

Azure regions, regional pairs, and sovereign regions

The term “cloud” tends to make people think of Azure as a nebulous entity that you can’t clearly see, but that would be a mistake. While there certainly are logical constructs to Azure, there are also physical components to it. After all, at the end of the day, we’re talking about computers!

In order to provide Azure services to people around the world, Microsoft has created boundaries called geographies. A geography boundary is oftentimes the border of a country, and there’s good reason for that. There are often regulations for data handling that apply to an entire country, and having a geography defined for a country allows Microsoft to ensure that data-handling regulations are in place. Many companies (especially ones that deal with sensitive data) are also much more comfortable if their data is contained within the confines of the country in which they operate.

There are numerous geographies in Azure. For example, there’s a United States geography, a Canada geography, a UK geography, and so on. Each geography is broken out into two or more regions, each of which is typically hundreds of miles apart. As an example, within the United States geography, there are many regions, including the Central US region in Iowa, the East US region in Virginia, the West US region in California, and the South Central US region in Texas. Microsoft also operates isolated regions that are completely dedicated to government data because of the additional regulations that governmental data requires.

Within each geography, Microsoft has created another logical boundary called a regional pair. Each regional pair contains two regions within the geography. When Microsoft must perform updates to the Azure platform, they perform those updates on one region in the regional pair. Once those updates are complete, they move to the next region in the regional pair. This ensures that the availability of your services operating within a regional pair aren’t impacted by updates.

Microsoft provides tools to control the use of Azure resources to meet corporate policies, but some compliance requirements can’t be met by simply applying policies. For example, some US government compliance scenarios require that data stays within the United States of America and that only citizens of the United States have any access to systems used to store that data. You can’t meet this requirement with policies. In fact, you can’t meet that requirement at all in the public cloud. To address this type of issue, Microsoft has several sovereign clouds that are separated from their public cloud offerings.

To address concerns related to the government of the United States, Microsoft developed completely isolated Azure datacenters that make up the Azure Government cloud. Azure Government datacenters are separate from public datacenters. All employees working in Azure Government are screened and are citizens of the US. Even Microsoft employees who provide technical support to Azure Government customers are required to be US citizens.

Because Microsoft also wanted to allow for compliant communication between the Azure Government cloud and on-premises government systems, they also developed dedicated networking infrastructure that is completely isolated from other Azure networks and that uses its own dedicated fiber-optic components.

Azure Government isn’t only for federal government agencies. Cities and municipalities also take advantage of Azure Government for compliance. When a customer signs up for Azure Government, Microsoft vets that user to ensure they are representative of a government agency. Only then are they given a subscription to Azure Government.

The Azure Government cloud has all the same features and services as the public cloud, but there are small differences. For example, the portal for Azure Government is located at https://portal.azure.us instead of https://portal.azure.com. URLs for Azure services also use the .us top-level domain, so if you create an App Service web app in Azure Government, your default domain name is https://webapp.azurewebsites.us. However, outside of that difference, everything else is the same, so developers who have a skill set in cloud development in Azure will find that their skills transfer directly to Azure Government.

The United States Department of Defense has additional compliance requirements called DoD Impact Level 5 Provisional Authorization. Compliance with this relates to controlled unclassified information that requires additional levels of protection. These additional DoD requirements are met by a subset of datacenters within Azure Government that are approved for DoD usage.

Microsoft also understands that the strict requirements in the EU need a unique approach, so they developed another sovereign cloud called Azure Germany. Much like Azure Government, Azure Germany is a distinct cloud system that’s designed to meet specific compliance needs. Azure Germany is available to customers doing business in the EU, the European Free Trade Association, and the UK.

Azure Germany datacenters are physically located in Germany and are operated under strict security measures by a local company named T-Systems International (a subsidiary of Deutsche Telekom) that operates as a data trustee. The data trustee has full control over all data stored in Azure Germany and all the infrastructure used to house that data. Microsoft is involved in managing only those systems that have no access at all to customer data.

Another region where Azure has specific requirements is China. Microsoft operates another separate cloud in China called Microsoft Azure China. Azure China is operated by Shanghai Blue Cloud Technology Co., Ltd. (frequently referred to as simply BlueCloud). BlueCloud is owned by Beijing 21Vianet Broadband Data Center Co., Ltd. (often called 21Vianet), an internet and datacenter service provider in China. Because of this relationship, you may see Azure China referred to as “Microsoft Azure operated by 21Vianet” or simply “Azure 21Vianet.”

Azure China doesn’t offer the full set of features offered in other Azure clouds, but Microsoft is working hard to add additional features and services. For all the details on what is and isn’t offered in Azure China, browse to https://bit.ly/az900-azurechina.

Availability zones

The fact that regions are physically separated by hundreds of miles protects Azure users from data loss and application outages caused by disasters in a particular region. However, it’s also important that data and applications maintain availability when a problem occurs at a particular building within a region. For that reason, Microsoft developed availability zones.

There are at least three availability zones within each enabled region, and each availability zone has a water supply, cooling system, network, and power supply that is isolated from other zones. By deploying an Azure service in two or more availability zones, you can achieve high availability in a situation where there is a problem in one zone.

Because availability zones are designed to offer enhanced availability for infrastructure, not all services support availability zones. For example, Azure has a service called App Service Certificates that allows you to purchase and manage an SSL certificate through Azure. It wouldn’t make any sense to host a certificate in App Service Certificates within an availability zone because it’s not an infrastructure component.

By deploying your service to two or more availability zones, you ensure the maximum availability for that resource. In fact, Microsoft guarantees 99.99 percent uptime for Azure virtual machines only if two or more VMs are deployed into two or more zones. Figure 2-1 illustrates the benefit of running in multiple zones. As you can see, even though availability zone 3 has gone offline for some reason, zones 1 and 2 are still operational.

There are two categories of services that support availability zones: zonal services and zone-redundant services. Zonal services are services such as virtual machines, managed disks used in a virtual machine, and public IP addresses used in virtual machines. To achieve high availability, you must explicitly deploy zonal services into two or more zones.

Zone-redundant services are services such as zone redundant storage and SQL databases. To use availability zones with these services, you specify the option to make them zone redundant when you create them. (For storage, the feature is called ZRS, or zone-redundant storage. For SQL database, there is an option to make the database zone redundant.) Azure takes care of the rest for you by replicating data automatically to multiple availability zones.

Azure datacenters

At each region, Microsoft has built datacenters (physical buildings) that contain the physical hardware that Azure uses. These datacenters contain climate-controlled buildings that house the server racks containing physical computer hardware. Each region also operates on its own network infrastructure, and Microsoft has designed the networks for low latency. Therefore, any Azure services you have in a particular region will have reliable and fast network connectivity with each other.

Each datacenter has an isolated power supply and power generators in case of a power outage. All the network traffic entering and exiting the datacenter goes over Microsoft’s own fiber-optic network on fiber owned or leased by Microsoft. Even data that flows between regions across oceans travels over Microsoft’s fiber-optic cables that traverse the oceans.

To ensure that data in Azure is safe from disasters and failures caused by possible problems in a particular region, customers are encouraged to replicate data in multiple regions. For example, if the South Central US region is hit by a devastating tornado (not out of the question in Texas), data that is also replicated to the North-Central US region in Illinois is still safe and available. To ensure that applications are still performing as quickly as possible, Microsoft guarantees round-trip network performance of 2 milliseconds or less between regions.

Azure resources and resource groups

You might think that moving to the cloud isn’t as simple as it first seemed. Creating a single resource in Azure is pretty simple, but most Azure services are made up of many resources. For example, when you create a virtual machine, you’re creating a virtual network, a network adapter, an IP address, a disk, and many other resources. Virtual machines aren’t unique in this respect. A single Azure deployment is typically made up of many Azure resources, some of which you explicitly create and others that are created implicitly by Azure.

Now add the complexity when you’re dealing with enterprise-level applications that consist of a complex array of Azure services or applications that involve multiple layers of complexity spread across multiple Azure regions. Things can certainly get chaotic quickly.

Fortunately, Azure provides a feature that helps you deal with this kind of problem: the resource group. A resource group is a logical container for Azure resources. By creating all Azure resources associated with a particular application in a single resource group, you can then deploy and manage all those resources as a single entity.

Organizing Azure resources in a resource group has many advantages. You can easily set up deployments using a feature known as an Azure Resource Manager (ARM) template. ARM template deployments are typically for a single resource group. You can deploy to multiple resource groups but doing so requires you to set up a complicated chain of ARM templates.

Another advantage to resource groups is that you can name a resource group with an easily recognizable name so that you can see all Azure resources used in a particular application at a glance. This might not seem so important until you start deploying Azure resources and realize that you have many more resources than you first thought. If you’re looking at all your Azure resources, it can be hard to differentiate which resources go with which app. Resource groups solve that problem.

In Figure 2-2, you can see a lot of Azure services. Some of these were automatically created by Azure to support other services, and in many cases, Azure gives the resource an unrecognizable name.

In Figure 2-3, you can see resources that are in the WebStorefront resource group. These are the Azure resources used in the e-commerce storefront.

It’s convenient to see all the resources associated with a particular app, but you aren’t locked into that paradigm. This is a useful example, because it’s a common use of resource groups; however, you can organize your resource groups any way you choose. Notice in Figure 2-3 that you see resources in several different Azure regions (Regions are in the Location column). If you have access to multiple Azure subscriptions, you can also have resources from multiple subscriptions in a single resource group.

If you look at the left side of Figure 2-3, you’ll see a menu of operations that you can perform on your resource group. We won’t go into all of these because it’s out of scope for the AZ-900 exam, but there are a few that clarify the benefit of resource groups.

If you click Resource Costs, you can see the cost of all the resources in this resource group. Having that information at your fingertips is especially helpful in situations where you want to make sure certain departments in your company are charged correctly for the resources they use. In fact, some companies will create resource groups for each department rather than creating resource groups scoped to applications. Having a Sales and Marketing resource group or an IT Support resource group, for instance, can help you immensely when reporting and controlling costs.

You can also click Automation Script, and Azure will generate an ARM template that you can use to deploy all these Azure resources. This is useful in a situation where you want to deploy these resources later or when you want to deploy them to another Azure subscription.

When you delete a resource group, all the resources in that resource group are automatically deleted. This makes it easy to delete multiple Azure resources in one easy step. Suppose you are testing a scenario and you need to create a couple of virtual machines, a database, a web app, and more. By placing all these resources in one resource group, you can easily delete that resource group after your testing and Azure will automatically delete all the resources in it for you. This is a great way to avoid unexpected costs associated with resources you are no longer using.

Azure subscriptions

You get an Azure subscription automatically when you sign up for Azure, and all the resources you create are created inside that subscription. You can, however, create additional subscriptions that are tied to your Azure account. Additional subscriptions are useful in cases where you want to have some logical groupings for Azure resources or if you want to be able to report on resources used by specific groups of people.

Each Azure subscription has limits (sometimes called quotas) assigned to it. For example, you can have up to 250 Azure storage accounts per region in a subscription, up to 25,000 virtual machines per region, and up to 980 resource groups per subscription across all regions.

Figure 2-4 shows an Azure subscription in the Azure portal.

On the Overview blade, you can see a chart of your spending rate and forecasted costs, along with a cost breakdown for each of the resources. If you click the View Details button on the Costs By Resource tile, you can see a further breakdown of the Azure expenses, as shown in Figure 2-5. In this view, you see costs by Service Name, Location (Azure region), and Resource Group, along with a graph of the costs for the month.

Azure invoices are also available for the subscription from within the Azure portal. You can see your current Azure invoice as well as all past invoices by clicking Invoices in the menu for the subscription.

You can create additional Azure subscriptions in your Azure account. This is useful in cases where you want to separate costs or if you are approaching a subscription limit on a resource. To create a new Azure subscription, type subscription in the search box and click Subscriptions, as shown in Figure 2-6.

To create a new subscription, click Add in the Subscriptions blade, as shown in Figure 2-7.

After you click Add, you need to choose which type of subscription you want to create. There are several types of Azure subscriptions:

• Free Trial Provides free access to Azure resources for a limited time. Only one free trial subscription is available per account, and you cannot create a new free trial if a previous one has expired.

• Pay-As-You-Go You pay only for those resources you use in Azure. There’s no up-front cost, and you can cancel the subscription at any time.

• Azure For Students A special subscription designed for exploring Azure services. It provides free Azure credits and access to many services free for 12 months.

You now understand Azure subscriptions and how you can create additional subscriptions if needed. Once you’ve created additional subscriptions and resources in those subscriptions, you might find that managing all your resources becomes more cumbersome. To help with that, Microsoft has developed a feature called management groups.

Management groups

Management groups are a convenient way to apply policies and access control to your Azure resources. Much like a resource group, a management group is a container for organizing your resources. However, management groups can contain only Azure subscriptions or other management groups.

In Figure 2-8, three management groups have been created for a company. The Sales Dept. management group contains subscriptions for the sales department. The IT Dept. management group contains a subscription and another management group, and two additional subscriptions are within that management group. The Training Dept. management group contains two subscriptions for the training department.

By organizing the subscriptions using management groups, you can have more precise control over who has access to which resources. You can also control the configuration of resources created within those subscriptions.

After you create a management group, you can move any of your subscriptions into that management group. You can also move a management group into another management group. There are, however, a few limitations:

• You’re limited to a total of 10,000 management groups.

• A management group hierarchy can only support up to six levels.

• You cannot have multiple parents for a single management group or subscription.

Hierarchy of resource groups, subscriptions, and management groups

You should have a general sense of the hierarchy of resource groups, subscriptions, and management groups, but it’s important for you to fully grasp how they are all related to each other.

At the top of the hierarchy is the management group. As you saw in the last section, you can create multiple management groups, but even if you never create one, you still have one by default called the Tenant Root Group. This default management group is part of your Azure Active Directory tenant.

Your Azure subscription is inside a management group. It can be a management group that you explicitly created or the Tenant Root Group management group.

Azure resources that you create must be inside of a resource group, and that resource group gets created inside of your Azure subscription. You can’t create an Azure resource without first specifying which resource group you want it to be created in. Unlike management groups, there isn’t a default resource group. You must explicitly create each resource group in your subscription.

Understanding this hierarchy becomes important when we start talking about things such as access control, policies, and so on. We will refer to this hierarchy at that point, but feel free to revisit this section if you need a refresher.