2- Core Azure Services

Describe the Core Azure Architectural Components

Azure Regions and Regional Pairs

Azure has multiple data centers distributed around the globe. Those data centers house the servers and other infrastructure on which Azure is built. The data centers are distributed into various geographies.

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.

A region is a grouping of data centers that interact to provide redundancy and availability for the services hosted within that region. For example, West US, Central US, and North Central US are three of many regions in the United States. Each region is paired with another in the same geography to allow for replication of resources across multiple data centers to reduce the effects of natural disasters, outages, or other potential events that would affect a given data center’s ability to serve up the services hosted in that data center. For example, West US and East US are paired regions, North Europe and West Europe are paired, and UK West and UK South are paired.

Within each geography, Microsoft has created another logical boundary called a regional pair. Each regional pair contains two regions within the geography. When Microsoft has to 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 your services operating within a regional pair aren’t impacted by updates.

Note: The fact that each geography contains at least two regions separated by a large physical distance is important. That’s how Azure maintains disaster recovery.

Availability Zones

Azure offers another level of availability protection through availability zones.

An availability zone is a physically separate zone within a region, each with its own power, network, and cooling. You might think of an availability zone as a data center, although the separation of power, network, and cooling defines the zone, not the physical data center. An availability zone might encompass more than one data center. There are a minimum of three availability zones per region, although not all regions offer availability 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.

Note: Availability zones provide high-availability and fault tolerance, but they might not help you with disaster recovery. If there is a localized disaster, such as a fire in a datacenter housing one zone, you will benefit from availability zones. Because availability zones are located in the same Azure region, if there is a large-scale natural disaster such as a tornado, you might not be protected. In other words, availability zones are just one facet to an overall disaster recovery and fault-tolerant design.

Availability zones offer an additional layer of service availability

Some organizations require high availability of availability zones and protection from large-scale phenomena and regional disasters. Azure regions are designed to offer protection against localized disasters with availability zones and protection from regional or large geography disasters with disaster recovery, by making use of another region.

Because Availability zones are designed to offer enhanced availability for infrastructure, not all services support availability zones.

Currently, availability zones are supported with the following Azure services.

  • Windows virtual machines
  • Linux virtual machines
  • Virtual Machine Scale Sets
  • Azure Kubernetes Service
  • Managed disks
  • Zone-redundant storage
  • Standard Load Balancer
  • Standard IP address
  • VPN Gateway
  • ExpressRoute Gateway
  • Application Gateway V2
  • Azure Firewall
  • Azure Data Explorer
  • Azure SQL Database
  • Azure Cache for Redis
  • Azure Cosmos DB
  • Event Hubs
  • Service Bus (Premium tier)
  • Event Grid
  • Azure AD Domain Services
  • App Service Environments ILB

By deploying your service to two or more availability zones, you ensure the maximum availability for that resource. In fact, Microsoft guarantees an SLA of 99.99 percent uptime for Azure virtual machines only if two or more VMs are deployed into two or more zones.

Note: Don’t confuse availability zones with availability sets. Availability sets allow you to create two or more virtual machines in different physical server racks in an Azure datacenter. Microsoft guarantees a 99.95 percent SLA with an availability set.

An availability zone allows you to deploy two or more Azure services into two distinct datacenters within a region. Microsoft guarantees a 99.99 percent SLA with availability zones.

Azure includes two categories of services that support availability zones:

  • Zonal services: Resources are pinned to a specific zone. To ensure redundancy for zonal services, you must deploy the services across multiple availability zones. Zonal services are services such as virtual machines, managed disks used in a virtual machine, and public IP addresses used in virtual machines.
  • Zone‐redundant services: Azure replicates the service automatically across zones.

Resources and Resource Groups

Creating a single resource in Azure is pretty simple, but when you’re dealing with enterprise-level applications, you’re usually dealing with a complex array of services. Not only that, but you might be dealing with multiple applications that use multiple services, and they might be 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 services. By creating all Azure services associated with a particular application in a single resource group, you can then deploy and manage all of those services as a single entity.

You can apply various properties to the resource group, and those properties apply to all the resources in that resource group.

  • For example, assume you have a group of resources that you want to prevent from being deleted but want resource admins to be able to modify. You can create a resource group, assign the resources to that group, and apply a CanNotDelete lock on the resource group. Any resources that you later apply to the resource group will also be automatically protected from deletion.
  • Another example, assume you stand up 10 VMs for a proof‐of‐concept project. When the project is completed and it’s time to delete the VMs, you simply delete the resource group. All the VMs in the resource group, along with any supporting resources that you also added to the resource group for the project, are deleted.
  • For example, when you create an Azure virtual machine, Azure creates not only a virtual machine, but it also creates a disk resource, network interface, public IP resource, and network security group. 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.

Note: An Azure resource can only exist in one resource group. In other words, you can’t have a virtual machine in a resource group called WebStorefront and also in a resource group called SalesMarketing, because it must be in one group or the other. You can move Azure resources from one resource group to another.

Azure Resource Manager

Azure Resource Manager (ARM) is the service that enables you to manage resources, serving as the deployment and management service for Azure. ARM is not a tool or interface. Rather, as a service it functions as the broker between management tools like the Azure portal and resource providers. When you create a new Azure service, ARM authenticates you to make sure you have the right access to create that resource, and then it talks to a resource provider for the service you’re creating.

  • For example, when you create a VM in the Azure portal, the portal sends the properties to the ARM application programming interface (API). ARM then communicates with the resource provider to create the VM.
  • If you’re creating a new web app in Azure App Service, ARM will pass your request on to the Microsoft.Web resource provider because it knows all about web apps and how to create them.

The flow of a typical ARM request to create or manage a resource is straightforward.

  1. Tools such as the Azure portal, PowerShell and Azure CLI make a request to the ARM API.
  2. The API passes that request to ARM where the user is authenticated and authorized to perform the action.
  3. ARM then passes the request to a resource provider, and the resource provider creates the new resource or modifies an existing resource.

ARM supports the use of templates for creating, managing, and monitoring resources. The request that is made to ARM isn’t a complicated, code-based request. Instead, ARM uses declarative syntax. ARM templates are JavaScript Object Notation (JSON) files that define one or more resources and their properties to deploy a tenant, management group, subscription, or resource group. So, you can automate the deployment of an entire Azure environment by using templates. ARM templates significantly simplify the creation of resources because you only need to declare in the template what you want to create and what its properties will be, and ARM then passes that information to the Azure providers, which then actually create the resources.

As you can see, ARM has many benefits:

  • ARM allows you to easily deploy multiple Azure resources at once.
  • ARM makes it possible to reproduce any deployment with consistent results at any point in the future.
  • ARM allows you to create declarative templates for deployment instead of requiring you to write and maintain complex deployment scripts.
  • ARM makes it possible to set up dependencies so that your resources are deployed in the right order every time.
The role Azure Resource Manager plays in handling Azure requests

Azure Subscriptions

Just as a resource group serves as a logical container for resources, an Azure subscription serves as a logical container for your Azure resources but at a higher level. Think of a subscription as a big box that contains all your resource group boxes. Also, a resource group can only exist in one subscription. Using the box analogy, imagine you have two subscription boxes side by side. A resource group box could only exist inside one of them; it cannot be in two places at once.

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.

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.
  • Pay-As-You-Go Dev/Test: A special subscription for subscribers to Visual Studio that can be used for development and testing. This subscription offers discounted rates on VMs, but you cannot use this for production applications.

Each subscription is associated with a unique identifier called a subscription ID. You can give each subscription a descriptive name to help you identify it, but Azure will always use the subscription ID to identify your subscription. When you talk to Microsoft about your Azure account, they’ll also often ask for your subscription ID.

You now have an understanding of 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.

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.

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.
Management groups organizing subscriptions and other management groups
The four scope levels for organizing your Azure resources

Describe Core Resources Available in Azure

  • Azure virtual machines
  • Azure App Service
  • Azure Container Instances (ACI)
  • Azure Kubernetes Service (AKS)
  • Windows Virtual Desktop
  • Virtual networks
  • Azure VPN Gateway
  • Virtual network peering
  • ExpressRoute
  • Container (Blob) Storage
  • Disk Storage
  • Azure Files
  • Storage tiers
  • Cosmos DB
  • Azure SQL Database
  • Azure Database for MySQL
  • Azure Database for PostgreSQL
  • The Azure Marketplace and its usage scenarios

Azure Virtual Machines

A virtual machine (VM) is a software-based computer that runs on a physical computer. The physical computer is considered the host, and it provides the underlying physical components such as disk space, memory, CPU power, and so on. The host computer runs software called a hypervisor that can create and manage one or more VMs, and those VMs are commonly referred to as guests.

To create an Azure virtual machine:

  • Click Create A Resource.
  • Click Compute.
  • Click the See All link.
  • Click Ubuntu Server.
  • Click the Create button.

  • After you click Review + Create, Azure will validate your settings to make sure you haven’t left anything out. Once your validation has passed, you will see a Create button. Click the Create button to start the deployment of your new VM.

Note: When you click Create to create your VM, the Azure portal is actually using an ARM template to deploy your VM. That ARM template contains parameters that are replaced with the information you entered for your VM. Every VM that is created in Azure is created using an ARM template. This ensures that the deployments are consistent.

Our new VM is a guest on a physical computer in an Azure datacenter. In that datacenter is a physical rack of computer servers, and our VM is hosted on one of those servers. The host computer is managed by Microsoft, but the VM is managed by you because this is an IaaS offering in Azure.

Note (VMs and Billing): You are charged for Azure VMs as long as they are running, and using the default settings as we have here led to a few expensive options. To stop billing for this VM, click the Stop button at the top of the screen. Azure will save the current state of the VM and billing will stop. You won’t be able to use the VM while it’s in a stopped state, but you will also avoid the billing of that VM. Keep in mind that unless you have configured a static IP address for your VM, your IP address will likely change the next time you start it.

As of right now, this VM is susceptible to downtime due to three types of events:

  1. planned maintenance,
  2. unplanned maintenance, and
  3. unexpected downtime.

Planned maintenance refers to planned updates that Microsoft makes to the host computer. This includes things like operating system updates, driver updates, and so on. In many cases, updates won’t affect your VM, but if Microsoft installs an update that requires a reboot of the host computer, your VM will be down during that reboot.

Azure has underlying systems that constantly monitor the health of computer components. If one of these underlying systems detects that a component within the host computer might fail soon, Azure will flag the computer for unplanned maintenance. In an unplanned maintenance event, Azure will attempt to move your VM to a healthy host computer. When it does this, it preserves the state of the VM, including what’s in memory and any files that are open. It only takes Azure a short time to move the VM, during which time it’s in a paused state. In a case where the move operation fails, the VM will experience unexpected downtime.

In order to ensure reliability when a failure occurs in a rack within the Azure datacenter, you can (and you should) take advantage of a feature called availability sets. Availability sets protect you from maintenance events and downtime caused by hardware failures. To do that, Azure creates some underlying entities in an availability set called update domains and fault domains. (In order to protect yourself in the event of maintenance events or downtime, you must deploy at least two VMs into your availability set.)

Availability Sets

Availability sets are another feature of Azure that help you avoid potential outages caused by hardware issues, updates, or other events.

Two elements that enable availability sets are update domains and fault domains.

  1. A fault domain is a logical grouping of hardware that shares a power source and network switch, similar to a physical rack in a data center.
  2. An update domain is a logical group of hardware that undergoes maintenance activities or reboot events at the same time.

An availability set distributes VMs across multiple fault domains and update domains. Distributing the VMs in this way helps guard against outages caused by a power or networking event in a fault domain and also enables the VMs to be updated or otherwise maintained within their respective update domains without causing the set as a whole to be unavailable.

Fault Domain

  • Fault domains are a logical representation of the physical rack in which a host computer is installed.
  • By default, Azure assigns two fault domains to an availability set.
  • If a problem occurs in one fault domain (one computer rack), the VMs in that fault domain will be affected, but VMs in the second fault domain will not. This protects you from unplanned maintenance events and unexpected downtime.

Update Domain

  • Update domains are designed to protect you from a situation where the host computer is being rebooted.
  • When you create an availability set, Azure creates five update domains by default. These update domains are spread across the fault domains in the availability set.
  • If a reboot is required on computers in the availability set (whether host computers or VMs within the availability set), Azure will only reboot computers in one update domain at a time and it will wait 30 minutes for computers to recover from the reboot before it moves on to the next update domain. Update domains protect you from planned maintenance events.
Availability sets distribute VMs across multiple fault domains and update domains.


  • Notice that the availability set is named WebAvailabilitySet.
  • In this availability set, we run five VMs that are all running a web server and host the website for an application.
  • Suppose you need a database for this application, and you want to host that database on VMs as well. In that situation, you would want to separate the database VMs into their own availability set. As a best practice, you should always separate your workloads into separate availability sets.
An availability set in the Azure portal showing fault domains and update domains

Availability sets certainly provide a benefit in protecting from downtime in certain situations, but they also have some disadvantages.

  • First of all, every machine in an availability set has to be explicitly created. While you can use an ARM template to deploy multiple virtual machines in one deployment, you still have to configure those machines with the software and configuration necessary to support your application.
  • An availability set also requires that you configure something in front of your VMs that will handle the distribution of traffic to those VMs. For example, if your availability set is servicing a website hosted on the VMs, you’ll need to configure a load balancer that will handle the job of routing users of your website to the VMs that are running it.
  • Another disadvantage to availability sets relates to cost. In a situation where your VM needs to be changed often based on things like load on the application, you might find yourself paying for many more VMs than you need.

Azure offers another feature for VMs called scale sets that solves these problems nicely. When you create a scale set:

  • You tell Azure what operating system you want to run and then you tell Azure how many VMs you want in your scale set.
  • You have many other options such as creating a load balancer or gateway and so forth.
  • Azure will create as many VMs as you specify (up to 1,000) in one easy step.

Virtual Machine Scale Sets

  • Scale sets are deployed in availability sets automatically, so you automatically benefit from multiple fault domains and update domains. Unlike VMs in an availability set, however, VMs in a scale set are also compatible with availability zones, so you are protected from problems in an Azure datacenter.
  • A scale set can automatically scale out or scale in to adjust to changes in demand. Load balancing adjusts automatically to ensure that the access to the VMs in the set is balanced across VMs appropriately as VMs are added or removed from the set.
  • A scale set supports up to 1,000 standard VM instances, or up to 600 instances if you create and upload your own custom images.
  • As you might imagine, you can also scale a scale set in a situation where you need more or fewer VMs. You might start with only one VM in a scale set, but as load on that VM increases, you might want to automatically add additional VMs. Scale sets provide that functionality by using Azure’s auto-scale feature. You define scaling rules that use metrics like CPU, disk usage, network usage, and so forth. You can configure when Azure should add additional instances and when it should scale back and deallocate instances. This is a great way to ensure availability while reducing costs by taking advantage of the elasticity that auto-scale provides.
  • The VMs in a scale set are all created from the same OS image, which ensures consistency across all VMs in the scale set. So, if a VM in the scale set hangs or is removed through a scale‐in event, the remaining VMs can continue to service requests. If you need to include applications and other required components in the VMs, you create an instance with the appropriate services and configuration, save the image, and then use that image to create the scale set. All VMs in the set will then have the same components, applications, and configuration.

Using a custom image: The default set of templates for VMs are basic and include only the operating system. However, you can create a VM, install all of the necessary components you need (including your own applications), and then create an image that can be used when creating scale sets.

Differences between VMs and Scale Sets

Azure App Service

The Azure App Service is a PaaS offering that enables you to quickly develop and deploy web applications. Azure App Service supports many development languages, including .NET, Java, Ruby, and Python, among others. Web apps developed and deployed using Azure App Service run and scale on Windows and Linux environments.

Azure App Service offers much more than just development tools. It encompasses load balancing, autoscaling, automated management, and security features to support not only the development of your web application, but also hosting and scaling to make it easy to deploy and manage your web applications. It also enables your web applications to scale appropriately to respond to demand changes.

Figure illustrates the basics of how App Service works.

  • Azure Load Balancer distributes traffic to a special VM within App Service called a front end.
  • The front end is running special software that allows it to effectively distribute traffic to the VMs that are actually running your web app.
  • These VMs run inside of an App Service plan, a logical container for one or more VMs that are running your web app.
  • Every web app you create in App Service runs inside of an App Service plan.
  • Multiple apps can run inside of a single App Service plan. All apps in an App Service plan will share the same VMs in that App Service plan.
  • You are charged for App Service plans even when no web apps are running in them. If you do have web apps in your App Service plan, you are still charged if you stop the web apps. The only way to avoid being billed for an App Service plan is to delete it.
  • Pricing tiers available: Free (A no-cost tier), Shared (A low-cost tier) and Basic, Standard, Premium, and PremiumV2 (Higher-cost tiers).
  • When you move from a lower pricing tier to a higher pricing tier, you are scaling up. You can also scale down at any time by moving to a lower pricing tier.
  • When you create a new web app, you can create it in an existing App Service plan, or you can create a new App Service plan for the app. All apps in an App Service plan run on the same VMs, so if you are already stressing the resources of an existing App Service plan, your best choice might be to create a new App Service plan for your new web app.

Note: Creating a web app in App Service is very fast and scaling it out to multiple instances is also very fast. That’s because the VMs that are running App Service web apps are already up and running. When you create a web app, you are simply allocating an existing VM for your use.

A high-level representation of Azure App Service

Azure Container Instances (ACI)

Azure Container Instances (ACI) is a PaaS service that offers the ability to run a containerized application easily.

Docker is an open source project for automating the deployment of containers, and Docker containers provide a means for packaging and deploying applications virtually. The container serves as a virtual environment that includes the resources necessary for its hosted application to function.

  • For example, assume you have a simple web application that includes a web front‐end server to handle web requests, an application server to handle app processing, and a database to store and serve the data needed by the other two servers. You could deploy that solution using VMs, but that requires managing the OS environments and other resources within the VMs. Containers abstract much of that and provide only the resources needed by the application so that you only need to deploy an image to the container, rather than build a VM and manage the OS and other resources. Although the container relies on the underlying OS on which it runs, you don’t have to configure or manage the VM. Instead, you focus solely on the application.

Azure Container Instances (ACI) is the Azure service that gives you the ability to create and deploy containerized applications. ACI supports both Windows and Linux containers.

  • Containers offer a potentially significant cost savings because you are only paying for consumption of CPU and memory resources used by the container, rather than paying for a VM instance. In addition, containers can easily scale out to accommodate demand changes for the containerized app.
  • Each container typically operates within an isolated environment. It has its own network, its own storage, and so on. Other containers running on the same machine cannot access the data and systems used by another container unless the developer of the image takes explicit steps to allow it. This makes containerized applications an ideal solution when security is a concern.
  • ACI makes it easy to start a container with minimal configuration. You simply tell ACI where to find the image (using either a Docker tag or a URL to the image) and some basic configuration for the VM you want the container to run on.
  • Azure creates server resources as needed to run your container, but you’re not paying for an underlying VM. Instead, you pay for the memory and CPU that your container uses. That translates into extremely low costs in most cases. For example, if your ACI app is running on a machine with 1 CPU and 1 GB of memory and you use the app for 5 minutes a day, your cost would be less than 5 cents at the end of the month!

Azure Kubernetes Service (AKS)

Kubernetes is a container orchestration service. This means that it’s responsible for monitoring containers and ensuring that they’re always running. It can also scale to add additional containers when the needs require it to, and it can then scale back when the needs are reduced.

Each of the containers in the Kubernetes cluster is called a node. There will typically be multiple nodes within a Kubernetes instance, and they are all controlled by a master node called the Kubernetes master. The entire environment of the master and all its nodes is called a Kubernetes cluster. AKS simplifies deployment because once you’ve defined a container image, you can use AKS to easily deploy as many instances of that image as needed within a cluster, as well as deploy multiple clusters.

Windows Virtual Desktop

Most businesses have applications that all their employees need to use. For example, employees might need access to Microsoft Word, Microsoft Excel, Microsoft Outlook, and so on. In many situations, businesses fill this need by purchasing a Microsoft Office license for all employees and installing Office apps on each computer.

This classic model of each employee using one computer with applications installed on it is not only inefficient for businesses, but it’s also insecure. First off, it requires that the business purchase operating system and application licenses for each employee. It also requires that the IT department be available to troubleshoot any operating system or application issues. Users of local applications also have data that is stored on the local hard drive, and this represents a security risk if an unwanted person gets access to the machine.

For these reasons and many others, many businesses take advantage of desktop virtualization. In a desktop virtualization model, a business installs an operating system and applications on one central server. The desktop virtualization infrastructure makes it possible for employees to access the operating system and applications from virtually any device, provided it has access to the network. The OS and applications aren’t downloaded to the employee’s device. Instead, the employee uses the applications in a virtualized environment that makes it feel like the applications are running locally.

Desktop virtualization might sound like the perfect solution for many businesses, but in fact, it’s quite complex to configure, and it requires many components in order to ensure a secure environment. For that reason, Microsoft developed a service in Azure called Windows Virtual Desktop.

Windows Virtual Desktop (WVD) is an Azure service that enables users to run a Windows client in the cloud. The user accesses the Windows client either through a Virtual Desktop client application on their Windows device or through an HTML 5 browser like Edge or Chrome.

Virtual Networks

An Azure virtual network (often called a VNet) allows Azure services to communicate with each other and with the Internet. You can even use a VNet to communicate between your on-premises resources and your Azure resources. When you create a virtual machine in Azure, Azure creates a VNet for you. Without that VNet, you wouldn’t be able to remote into the VM or use the VM for any of your applications. However, you can also create your own VNet and configure it any way you choose.

An Azure VNet is just like any other computer network. It’s comprised of a network interface card (a NIC), IP addresses, and so on. You can break up your VNet into multiple subnets and set up a portion of your network’s IP address space for those subnets. You can then configure rules that control the connectivity between those subnets.

The IP addresses within the VNet at this point are all private IP addresses. They allow resources within the VNet to talk to each other, but you can’t use a private IP address on the Internet. You need a public IP address in order to give the Internet access to your web tier.

Note: A public IP address doesn’t have to be assigned to a resource in order for that resource to connect outbound to the Internet. Azure maintains a pool of public IP addresses that can be dynamically assigned to a resource if it needs to connect outbound. That IP address is not exclusively assigned to the resource, so it cannot be used for inbound communication from the Internet to the Azure resource.

Azure offers a feature called Network Security Groups that allow you to enforce rules about what kind of traffic is allowed on the VNet.

Azure VPN Gateway

In most cases, you’ll want to connect your VNet to other networks. You might need to connect your VNet to another VNet in Azure, or you might also want to connect your VNet to on-premises resources. In both of these cases, network traffic is going to travel over the Internet, and that incurs a certain amount of risk. To provide more security for your network traffic, you can use a secure virtual private network (VPN) connection.

Azure VPN Gateway uses VPN connections to enable secure connectivity between an Azure VNet and other networks. VPN Gateway secures these connections using Internet protocol security (IPSec) and the Internet key exchange (IKE) protocol. This ensures that traffic flowing over the public Internet is encrypted and secure.

A VPN Gateway uses two or more VMs that are created inside a subnet (called the gateway subnet) that is created explicitly for the VPN Gateway. These VMs run services that implement the functionality of VPN Gateway, and they also have network routing tables that enable them to properly route network traffic. You can’t use these VMs for anything other than VPN Gateway, and you also can’t remote into them or change their configurations.

Steps to create a VPN Gateway:

  • Before you can create a VPN Gateway, you create the gateway subnet and specify the IP address range for that subnet.
  • Once you’ve created a subnet for VPN Gateway, you can create the VPN Gateway.

Note: It can take a long time to create a VPN Gateway. Azure must create VMs in the gateway subnet to support the gateway, and it also must configure VPN Gateway services and network routing tables. It can take up to 45 minutes before your VPN Gateway is ready for use.

After you create your VPN Gateway, you can configure a connection to it. There are three connection types supported by VPN Gateway:

  1. VNet-to-VNet,
  2. site-to-site, and
  3. point-to-site

A VNet-to-VNet connection allows you to connect two Azure VNets to each other. Each VNet must have a VPN Gateway configured, and the VNets don’t have to be in the same Azure region or even in the same Azure subscription. Communication between VNets that are using a VNet-to-VNet connection is encrypted and travels over Microsoft’s backbone infrastructure, not over the Internet.

Note: VPN Gateway has several pricing tiers, and each pricing tier has an associated bandwidth cap. When connecting two VNets using a VNet-to-VNet connection, make sure you can live with the bandwidth restrictions imposed by the VPN Gateway pricing tier you are using. If you need to avoid a bandwidth restriction, using VNet peering might be a better option for you.

A site-to-site connection allows you to connect your VNet to an on-premises network using an encrypted VPN connection. Site-to-site connections require you to configure a VPN device on your on-premises network, and that VPN device must have a public-facing IP address. Network traffic between your VNet and your on-premises network travels over an encrypted VPN connection.

A point-to-site connection connects your VNet to a single device. That device can be a computer, but it can also be a mobile device, such as a tablet or a smartphone. When using a point-to-site connection, software on the device establishes a VPN connection to VPN Gateway, and all traffic is encrypted and travels over that connection.

Virtual Network Peering

You can connect two VNets together using a VNet-to-VNet connection with VPN Gateway, but when you use that method, you might experience some latency because of the two VPN Gateways that are involved. As I pointed out earlier, you are also going to incur a bandwidth restriction based on the VPN Gateway pricing tier you are using.

To avoid both of those situations, you can connect your VNets using virtual network peering. Traffic between two VNets that are peered travels over Microsoft’s private backbone infrastructure and not over the Internet; however, unlike a VNet-to-VNet connection, the traffic is not encrypted.

Note: You can peer VNets that are in the same region or in different regions. Microsoft refers to peering VNets between two Azure regions as global virtual network peering.

Virtual Network Peering


You can use Azure VPN Gateway to connect your Azure VNet to on-premises resources, and many customers use this method. However, there are some aspects of using a VPN that might not meet the requirements of some customers. For example, a VPN is limited to a maximum of 1.25 Gbps in network speed. If a customer needs more speed than that, VPN isn’t a good choice. VPN Gateway also sends all traffic over the public Internet, and that might not be a viable option for some people.

For these reasons, Azure offers a service called ExpressRoute that can offer speeds up to 10 Gbps over dedicated fiber-optic connections. When you use ExpressRoute, you connect from your on-premises network to a Microsoft Enterprise Edge router (MSEE), and that MSEE router then connects you to Azure.

In most situations, customers connect to the MSEE router using a third-party service provider. The service provider is a major network service provider, often an Internet service provider. The service provider has network connections directly into the MSEE router, and those connections have dedicated bandwidth.

Because data in ExpressRoute doesn’t traverse the public Internet, bandwidth is much more reliable. However, the ExpressRoute configuration you see in Figure does require that you trust the service provider with the data flowing through the circuit. If you want to remove the service provider from the picture, you can use an offering called ExpressRoute Direct that allows you to connect directly to a physical port on the MSEE router. ExpressRoute Direct also provides for much higher bandwidth if that’s a concern for you.

Note: ExpressRoute is designed for high availability. Each circuit uses redundant connections, so if you create a circuit at 5 Gbps, the actual bandwidth allocated to that circuit is 10 Gbps. Microsoft will even allow you to use that extra bandwidth for short bursts.

A typical ExpressRoute configuration

Core Azure Storage

Container (blob) Storage

Azure Blob Storage is designed for storing unstructured data, which has no defined structure. That includes text files, images, videos, documents, and much more. An entity stored in Blob Storage is referred to as a blob.

Blob storage can be accessed in several ways, including through HTTP or HTTPS, the Azure Storage REST API, Azure PowerShell, Azure CLI, or an Azure Storage client library.

There are three types of blobs in Azure Storage:

  1. Block blobs: Used to store files used by an application.
  2. Append blobs: They are like block blobs, but append blobs are specialized for append operations.
  3. Page blobs: They are used to store virtual hard disk (.vhd) files that are used in Azure virtual machines.

Blobs are stored in storage containers. A container is used as a means of organizing blobs, so you might have a container for video files, another container for image files, and so on. The choice, however, is entirely up to you.

If you’re planning on moving data from on-premises into Azure Storage, there are many options available to you. You can use Azure Storage Explorer, a free tool available from Microsoft, to upload data. You can also use command line tools that Microsoft provides for uploading to Azure Storage.

  • If you want to move a large amount of data, Microsoft offers a service called Data Box. Data Box has an online service called Data Box Edge that makes copying data to Azure Storage as easy as copying it to a hard drive on your system.
  • For even larger amounts of data, Microsoft offers a Data Box offline service where they will ship you hard drives. You simply copy your data to the hard drives, encrypt the drives with BitLocker, and then ship them back to Microsoft.
  • Microsoft even offers Data Box Heavy, a service where they’ll ship you a rugged device on wheels that can hold up to 1 petabyte of data!

Disk Storage

Disk storage in Azure refers to disks that are used in virtual machines.

Azure disks are available as either managed disks or unmanaged disks.

  • When you use unmanaged disks, they use an Azure Storage account in your Azure subscription, and you must manage that account. This is particularly troublesome because there are limitations in Azure Storage, and if you have heavy disk usage, you might end up experiencing downtime because of throttling.
  • When you move to managed disks, Microsoft handles the storage account, and all storage limitations are removed.

Azure managed disks support two types of encryption: server‐side encryption and disk encryption. Server‐side encryption provides encryption‐at‐rest to safeguard your data and meet compliance and policy requirements. Server‐side encryption is enabled by default for all managed disks, snapshots, and images. Disk encryption on Windows volumes uses BitLocker, and Linux volumes use DM‐Crypt. Disk encryption enables you to encrypt OS and data disks.

Azure offers three main disk roles:

  1. data disk
  2. OS disk
  3. temporary disk

OS and data disks are persistent, meaning they don’t go away if you reboot a VM or redeploy it. Temporary disks are not managed and do not necessarily persist during maintenance events and reboots, although data stored on a temporary disk will persist during a normal, successful reboot of the VM that hosts it. Temporary disks therefore should be used only for swap files, temporary files, and other data that could be lost.

Managed Disk vs Unmanaged Disk

Perhaps an even more important reason to use managed disks is that by doing so, you avoid a possible single point of failure in your VM. When you use unmanaged disks, there is a possibility that the Azure Storage accounts backing up your disks might exist within the same storage scale unit. If a failure occurs in that scale unit, you will lose all your disks. By ensuring that each managed disk is in a separate scale unit, you avoid the situation of a single point of failure.

  • Managed Disks: are managed by Microsoft Azure and you don’t need any storage account while created new disk. Since the storage account is managed by Azure you do not have full control of the disks that are being created.
  • Un-managed Disks: is something which requires you to create a storage account before you create any new disk. Since, the storage account is created and owned by you, you have full control over all the data that is present on your storage account. Additionally, you also need to take care of encryption, data recovery plans etc.
VM Backup Architecture

Azure Files

Azure disks are a good option for adding a disk to a virtual machine, but if you just need disk space in the cloud, it doesn’t make sense to take on the burden of managing a virtual machine and its operating system. In those situations, Azure Files is the perfect solution.

Note: Azure Files shares are backed by Azure Storage, so you will need a storage account to create an Azure Files share.

Files stored using this service can be accessed by using the Server Message Block (SMB) protocol or Network File System (NFS) protocol. Azure file shares can be concurrently accessed by on‐premises as well as Azure services.

Note: You can mount Azure Files shares on Azure VMs and on-premises on Windows, Linux, and MacOS. You can’t, however, use Windows 7 or Windows Server 2008 to mount an Azure Files share on-premises because those operating systems only support SMB 2.1. Also, because Azure Files shares use SMB, you’ll need to make sure that TCP port 445 is open on your network.

One possible problem with using Azure Files is the remote location of files. If your users or applications are using a file share mapped to Azure Files, they might experience longer-than-usual file transfer times because the files are in Azure. To solve that problem, Microsoft introduced Azure File Sync.

The Azure File Sync service allows you to cache Azure file shares on an on-premises Windows Server file server.

Install Azure File Sync on one or more servers in your local network and it will keep your files in Azure Files synchronized with your on-premises server. When users or applications need to access those files, they can access the local copy quickly. Any changes you make to the centralized Azure Files share are synchronized to servers running Azure File Sync.

Azure Files Share
Azure Files Share Backup
  1. The first step in configuring backup for Azure file shares is creating a Recovery Services vault. The vault gives you a consolidated view of the backups configured across different workloads.
  2. Once you create a vault, the Azure Backup service discovers the storage accounts that can be registered with the vault. You can select the storage account hosting the file shares you want to protect.
  3. After you select the storage account, the Azure Backup service lists the set of file shares present in the storage account and stores their names in the management layer catalog.
  4. You then configure the backup policy (schedule and retention) according to your requirements, and select the file shares to back up.
  5. Based on the policy specified, the Azure Backup scheduler triggers backups at the scheduled time.
  6. You can restore the Azure file share contents (individual files or the full share) from snapshots available on the source file share.
  7. If you’re using Azure File Sync, the Backup service indicates to the Azure File Sync service the paths of the files being restored, which then triggers a background change detection process on these files.
  8. The backup and restore job monitoring data is pushed to the Azure Backup Monitoring service.

Storage Accounts

Before you can begin using storage in Azure, you must create a storage account. A storage account contains Azure Storage objects and provides a unique namespace through which you can access those storage objects via HTTP and HTTPS. As you might expect, Azure offers several types of storage accounts, each intended for specific purposes and each with different costs.

The following list provides a brief overview of each type of storage account:

  • General‐purpose v1: This is a legacy account type intended for blobs, files, queues, and tables.
  • General‐purpose v2: This storage account type is also intended for blobs, files, queues, and tables, as well as Data Lake Gen2.
  • BlockBlobStorage: This storage account type is intended for block blobs and append blobs in high‐performance scenarios such as high storage transaction rates, or where storage consists of small objects and/or low latency.
  • FileStorage: This storage account type is intended for files‐only storage scenarios where premium performance is required.
  • BlobStorage: This is a legacy blob‐only storage account type.

Core Data Services

Cosmos DB

Many database systems use relational data. A relational database contains tables of data that are related to each other. Part of the database design defines the relationship between tables, and when new data is added to the database, it must conform to the schema (the way the database is set up).

Some database systems, known as NoSQL databases, are not relational. In a NoSQL database system, you’re not locked into a schema for your data. For example, in a relational system, if you’re storing information about some customers and you want to add customer birthdays to your data, you have to edit the schema of your database to allow for the birthday to be added. However, in a NoSQL system, you simply add the birthday to your data and add it to the database. The database doesn’t care about the type of data or fields it contains.

There are four types of NoSQL database systems:

  1. key-value,
  2. column,
  3. document, and
  4. graph.

There are many different NoSQL database systems, and most of them are geared toward a particular database model. Microsoft offers a hosted NoSQL database system in Azure called Cosmos DB, which supports all the NoSQL database types.

Azure SQL Database

To host your own database in SQL Server on‐premises, you generally must deploy a server (physical or virtual), install Microsoft SQL Server on it, and use that server application to create and manage a SQL database. Standing up and managing that server and application can be time consuming and expensive.

Azure SQL Database is a PaaS offering for SQL Server database hosting. Microsoft manages the platform, so all you must worry about is your database and the data in it.

SQL Server databases are relational databases made up of tables of data, and each table has a schema that defines what the data should look like. For example, the schema might define that your data contains an ID number, a first name, a last name, and a date. Any data that you add to the table must follow the schema, so data you add must not have fields that are not defined in the schema.

A database will contain many tables of data that are related to each other, and by using specialized queries, developers can return data that is a result of joining related data from multiple tables.

Azure Database for MySQL

Like SQL Server databases, MySQL databases are relational databases. However, MySQL is an open-source system.

Azure Database for MySQL offers several pricing plans based on your specific needs.

  • The Basic plan is best for users who have light usage.
  • The General-Purpose plan is more suitable for business use.
  • The Memory Optimized plan is for high-performance requirements.

Azure Database for PostgreSQL

PostgreSQL is another relational, open-source database system. While PostgreSQL was initially designed to run on Unix or Linux, it’s now available for MacOS, Linux, OpenBSD, FreeBSD, and Windows.

Azure Database for PostgreSQL is a managed version of PostgreSQL in Azure. Like Azure Database for MySQL and Azure SQL Database, Azure Database for PostgreSQL allows you to utilize a powerful database system without having to manage the server, database security, performance, and other administrative tasks.

Pricing for Azure Database for PostgreSQL is similar to Azure Database for MySQL. Basic, General Purpose, and Memory Optimized plans are available, and prices increase as you add additional database resources like CPU and memory.

Thought Experiment

[Regions/Availability Zones]

ContosoPharm has contacted you for assistance in setting up some Azure virtual machines for hosting their Azure services. They want to ensure that their services experience high availability and are protected against disasters that might occur in a datacenter at a particular Azure regionIn addition to that, they want to ensure that a power outage at a particular datacenter doesn’t affect their service in that region.

To ensure that their VMs are protected against disasters at a datacenter within a particular Azure region, you should recommend that ContosoPharm use availability zones. By deploying VMs in availability zones, the company can ensure that VMs are distributed into different physical buildings within the same Azure region. Each building will have separate power, water, cooling system, and network.

A region is a set of datacenters deployed within a latency-defined perimeter and connected through a dedicated regional low-latency network.

Azure Availability Zones are physically separate locations within each Azure region. To ensure resiliency, a minimum of three separate availability zones are present in all availability zone-enabled regions.

[Resource Groups/Azure Subscription]

ContosoPharm plans on having a large number of VMs, but they’re only going to be hosting three different services in the cloud. Each of these services will have other Azure services associated with them in addition to the VMs. They’re very interested in having a way to easily view all the Azure resources associated with a particular service inside the Azure portal.

Two of the services they plan on deploying belong to the marketing department. The other service belongs to the development division. They need a way to report on each of these departments, so they’d like a way to logically group these services.

Along those same lines, the CTO wants to ensure that they can control who has access to the services in each department. He also wants to have control over how those services are configured.

To easily view Azure resources associated with a particular service, ContosoPharm can create separate resource groups and create the resources for each service within its own resource group. To logically group its services for the marketing and development divisions so the company can report on them, ContosoPharm can create separate Azure subscriptions for each division.

To resolve the CTO’s concern over who has access to services and how those services are configured, you can recommend the use of management groups. Because you’ve already recommended that each division have their own subscription, management groups are a logical choice because each subscription can be moved into a separate management group.

ContosoPharm’s VMs will also be using specific configurations for virtual networks, and they want to ensure that they can easily deploy these resources into new Azure regions, if necessary later. It’s critical to them that the later deployments have the exact same configuration as all other deployments because any differences can cause application incompatibilities.

In order to ensure consistent deployments now and in the future, ContosoPharm can create an ARM template for their deployment. By using an ARM template, the company can ensure that every deployment of its resources will be identical.

[Availability Set/Scale Sets]

The CTO is also worried about VMs in particular from experiencing availability problems due to possible hardware failures. He’s also heard that some cloud customers experience issues when the cloud provider must reboot the underlying host computer for some reason. This kind of thing cannot happen in ContosoPharm’s case, so you will need to make a recommendation to prevent that.

To protect the application when a VM has a hardware problem or must be rebooted, ContosoPharm should use an availability set. An availability set would provide the company with multiple fault domains and update domains so that if a VM must be rebooted, it would still have an operational VM in another update domain.

During some periods of time, ContosoPharm has noticed that their applications can cause extreme CPU spikes. They’d like a system that will account for that and possibly add additional VMs during these peak times, but they want to control costs and don’t want to pay for these additional VMs when they aren’t experiencing a usage spike. Any advice you can offer for that would be a bonus.

To ensure that they, ContosoPharm has enough VMs to handle the load when CPU spikes, it should use Scale Sets. The company can then configure auto-scale rules to scale out when the load requires it and scale back in to control costs.

An Availability Set is a logical grouping of VMs that allows Azure to understand how your application is built to provide for redundancy and availability. We recommended that two or more VMs are created within an availability set to provide for a highly available application. There is no cost for the Availability Set itself, you only pay for each VM instance that you create.

Azure Virtual Machine Scale Sets let you create and manage a group of load balanced VMs. The number of VM instances can automatically increase or decrease in response to demand or a defined schedule. Scale sets provide high availability to your applications, and allow you to centrally manage, configure, and update a large number of VMs.

[Azure App Service]

One of ContosoPharm’s services has a web portal that was written using PHP. They’ll need to move this web portal to the cloud, but they don’t want to have to hassle with a lot of configuration. They need it to be available for users reliably and they need to be able to update the code if necessary, but they don’t want to worry about anything else. They’re looking to you to suggest the best Azure solution for that, and keep in mind that they need to be able to scale this web portal easily when usage increases during busy times of the month.

The best option for hosting the company’s PHP web portal in the cloud is Azure App Service. Because it’s a PaaS service, ContosoPharm won’t have to worry about a lot of configuration, and because App Service offers scaling capabilities, that meets the requirement of needing to react to increases in usage.

Azure App Service enables you to build and host web apps, mobile back ends, and RESTful APIs in the programming language of your choice without managing infrastructure.


Another portion of one of their services exists as a Docker image. They want to run this in Azure as well, but the CTO is concerned about costs. This part of their service is only needed for specific operations, so it runs only for a few minutes every month. Even so, it’s a critical component, so they need it to be reliable. The CTO wants you to suggest an option that will be the most cost-efficient option in Azure.

One of their other services is also containerized, but it’s quite a bit more complex. Usage of this service is all over the place. Sometimes they require a lot of computing resources for it, and other times, they don’t require much at all. However, when it’s needed, they need to ensure that it’s always running.

The best option for hosting ContosoPharm’s Docker image in the cloud is Azure Container Instances. There are other options in Azure for this, but because the CTO is concerned with costs and this component only runs for a very small amount of time each month, ACI is clearly the cheapest alternative.

The second containerized component would benefit better from Azure Kubernetes Service. The fact that it’s more complex and sometimes requires a lot of computing resources makes it an ideal candidate for AKS, especially because Kubernetes can ensure that the container is always running and available.

Application development continues to move toward a container-based approach, increasing our need to orchestrate and manage resources.

Containers are becoming the preferred way to package, deploy, and manage cloud applications. Azure Container Instances (ACI) offers the fastest and simplest way to run a container in Azure, without having to manage any virtual machines and without having to adopt a higher-level service.

For scenarios where you need full container orchestration, including service discovery across multiple containers, automatic scaling, and coordinated application upgrades, Azure Kubernetes Service (AKS) is recommended.

[Virtual Desktop]

Sales managers in the ContosoPharm sales department need access to Office applications reliably, but the CIO is greatly concerned about sensitive sales data being stored on laptop hard drives. He’d like for you to recommend a way for these employees to access the applications they need while keeping data secure. Being able to access these applications from any device (or even a web browser) would be a real game-changer.

To provide sales managers with access to Office applications without having to worry about the security aspects of storing files on their laptops, you should recommend Windows Virtual Desktop. They would then be able to access these applications from any device or a web browser.

[Azure VNet]

Much of the infrastructure ContosoPharm is moving to the cloud is made up of multi-tiered applications, and each of these tiers needs to be able to communicate with each other and with the Internet. The on-premises network engineers at ContosoPharm completely understand the on-premises network and how it’s configured, but they have no idea how to translate that to the cloud. They’ll need you to provide some recommendations in that area as well.

Your recommendation to the network engineers should be to configure an Azure virtual network (VNet). They can easily configure subnets within that network exactly like they have on-premises, and all the networking features they’re used to will be available to them.

Vnet is the fundamental building block for your private network in Azure. VNet enables many types of Azure resources, such as Azure Virtual Machines (VM), to securely communicate with each other, the internet, and on-premises networks. VNet is similar to a traditional network that you’d operate in your own data center, but brings with it additional benefits of Azure’s infrastructure such as scale, availability, and isolation.

[Azure VPN Gateway/VNet Peering]

ContosoPharm might need to use two different virtual networks for its marketing department. It’s important that ContosoPharm be able to connect the VMs in those networks, but it wants to ensure that no traffic between the VMs flows over the Internet. It’s also critical that the company gets maximum network speed between these VMs because ContosoPharm will be transferring some massive files between them. ContosoPharm needs you to recommend options for connecting these VMs.

To connect ContosoPharm’s two VNets, you have a couple of options. You can either use Azure VPN Gateway with a VNet-to-VNet connection, or you can use Virtual Network Peering. Because ContosoPharm has stated it needs maximum network speed and because employees are transferring huge files and will likely use a lot of bandwidth, virtual network peering is a better choice. This option reduces the latency that can be associated with VNet-to-VNet peering, and it also removes the bandwidth restriction that comes with VPN Gateway connections.

VNet Peering enables you to seamlessly connect two or more Virtual Networks in Azure, allowing traffic of one virtual network to communicate to another virtual network.

[Azure VPN Gateway/Point-to-Site VPN]

Some sales associates in the field will need to be able to connect to the marketing VMs, and the information they will be accessing is confidential in nature. These associates might be accessing these VMs from public Wi-Fi hotspots in places like hotels, and it’s critical that ContosoPharm keep this data safe when it’s accessed using laptops and mobile devices in the field. ContosoPharm needs you to recommend a solution for that.

You can recommend that ContosoPharm use Azure VPN Gateway and a point-to-site connection to allow sales associates to securely connect to the marketing VMs from laptops and mobile devices. This will ensure that the network traffic is encrypted, so even if the associates use a public Wi-Fi access point, the data will be secure.


ContosoPharm also has an on-premises system that cannot be migrated to the cloud, so it will remain on-premises. This system uses 3D animations of cell structures and how different drugs interact with them. The file sizes are very large, and ContosoPharm is concerned that transferring these large files from the cloud is going to make their application slow. Also, ContosoPharm is concerned over privacy implications and would prefer to keep these files from being transferred over the Internet if possible.

The 3D animation system ContosoPharm uses sounds like it needs a lot of bandwidth. In that scenario, ExpressRoute is likely a good choice, especially because the company would also like to keep files from being transferred over the Internet. With ExpressRoute, data transfers over a private connection, and ContosoPharm can adjust its bandwidth based on the needs of the app, up to a max of 10 Gbps.

[Blob Storage/Disk Storage/Azure Files]

ContosoPharm is required to keep a copy of each order invoice from its customers. These invoices are uploaded to the website as a PDF, and ContosoPharm wants to keep them in the cloud. ContosoPharm doesn’t need to be able to run any kind of reporting on these invoices, but it does need them in case regulators ask for them in the future.

ContosoPharm also needs to persist data that’s stored on any of their VMs, even if a maintenance event happens in Azure or they are moved to another VM for some reason. It’s critical data, so ContosoPharm wants to ensure it chooses the right solution.

Another part of their application also needs to persist data, but ContosoPharm needs to be able to access the data from an on-premises server running Windows Server 2016. The company doesn’t want to have to install anything special on the server to be able to access these files that are in the cloud.

To store their invoices in the cloud, ContosoPharm can use Azure Blob Storage. The company could store them in a database as binary blobs, but because they don’t need to run any kind of reporting or queries against them, Azure Blob Storage will be cheaper.

To persist the data on the VMs between reboots or VM moves, ContosoPharm should use Disk Storage. You should probably also recommend that they use managed disks for ease of use and reliability. For the part of the app that needs to persist data that’s available by a Windows Server 2016 on-premises server, you should recommend Azure Files. The company can then use SMB to access the files, and existing systems on-premises can map to the files without having to install anything extra.

Blob storage is optimized for storing massive amounts of unstructured data such as text or binary data.

Azure managed disks are block-level storage volumes that are managed by Azure and used with Azure Virtual Machines. Managed disks are like a physical disk in an on-premises server but, virtualized. With managed disks, all you have to do is specify the disk size, the disk type, and provision the disk. Once you provision the disk, Azure handles the rest.

Azure Files offers fully managed file shares in the cloud that are accessible via the industry standard SMB or NFS protocol. Azure Files file shares can be mounted concurrently by cloud or on-premises deployments.


All ContosoPharm’s chemicals and pharmaceuticals are kept in a large research facility. The company would like to integrate a database in that facility with its Azure services and needs that connection to be encrypted and secure. The developers of the current system used the Community Edition of MySQL to develop the database, and ContosoPharm is interested in the easiest solution to have this hosted in the cloud without needing to keep up with configuration and maintenance.

For the company’s database needs, the best choice by far is Azure Database for MySQL. Because it’s a managed service, ContosoPharm won’t have to worry about maintenance or configuration, and because it’s based on the Community Edition of MySQL, they should be able to simply transfer the database directly to the cloud and be done with it.

Exam Essentials

Describe the core Azure architectural components.

Geographies align to markets but can generally be considered as aligning to countries or regions. For example, Europe is a geography that encompasses multiple countries. The United States is another geography that represents a single country. Within each geography are regions. Within the regions, availability zones enable services to be distributed across multiple physical data centers to ensure high availability, resiliency, and fault tolerance. An availability zone has its own power, cooling, and network resources, so that if an incident occurs in one availability zone, that incident does not affect resources in other availability zones.

Resource groups are logical containers that you use to group together Azure resources and enable you to control access to the resources and their management, and otherwise manage the resources in the group as a whole. The service that enables management of resources is Azure Resource Manager (ARM). ARM lets you create resources in a declarative way using templates, which it then passes to the target Azure service provider to create the service.

Billing is another key concept in Azure. Azure billing accounts are the mechanism by which you are billed for Azure services. Subscriptions serve as a container for Azure resources, and a resource can exist only in one subscription, although you can move resources between subscriptions. Subscriptions serve as a billing boundary, enabling you to charge different groups within your organization for various Azure resources.

Describe some of the core products available in Azure.

Although certainly not the only Azure service, virtual machines (VMs) are in some ways one of the most easily understood and certainly one of the most common Azure products. A VM is a virtual instance of a computer running as a guest operating system on a physical host device. A given host can run both Windows and Linux guests.

Virtual machine scale sets enable you to easily scale VMs out or in as needed to accommodate demand changes. The scale set includes load balancing to distribute load among the VMs in the set. Because all of the VMs in a scale set are based on the same image, scale sets also make it easy to roll out many VMs at once.

An availability set distributes VMs across multiple fault domains and update domains. Distributing the VMs in this way helps guard against outages caused by power or networking events in a fault domain, and it also enables the VMs to be updated or otherwise maintained within their respective update domains without causing the set as a whole to be unavailable.

Azure App Service is a PaaS offering that simplifies developing and deploying web applications. The Azure App Service takes care of the underlying infrastructure so that you can focus on developing the app, and the service also provides for deployment, load balancing, and other resources necessary to deploy and manage your app.

The Azure Container Instance service supports the creation and management of containers, which is a virtualized environment that includes the resources necessary for its hosted application to function.


  • An Azure region is an area within a specific geographical boundary, and each region is typically hundreds of miles apart.
  • A geography is usually a country, and each geography contains at least two regions.
  • A datacenter is a physical building within a region, and each datacenter has its own power, cooling supply, water supply, generators, and network.
  • Round-trip latency between two regions must be no greater than 2ms, and this is why regions are sometimes defined as a “latency boundary”.
  • Customers should deploy Azure resources to multiple regions to ensure availability.
  • Availability zones ensure that your resources are deployed into separate datacenters in a region. There are at least three availability zones in every region.
  • Resource groups allow you to separate Azure resources in a logical way, and you can tag resources for easier management.
  • All your Azure resources are created within an Azure subscription, and you can create additional subscriptions if you need to group or report on resources more easily.
  • Azure subscriptions have limits associated with them.
  • Management groups allow you to assign policies and access control to Azure resources.
  • Only subscriptions or other management groups can be added to a management group.
  • Azure Resource Manager (ARM) is how Azure management tools create and manage Azure resources.
    • ARM uses resource providers to create and manage resources.
    • An ARM template allows you to ensure consistency of large Azure deployments.
  • Azure virtual machines are an IaaS offering where you manage the operating system and configuration.
  • Availability sets protect your VMs with fault domains and update domains. Fault domains protect your VM from a hardware failure in a hardware rack. You are protected from VM reboots by update domains.
  • Scale sets allow you to set up auto-scale rules to scale horizontally when needed.
  • Azure App Service makes it easy to host web apps in the cloud because it’s a PaaS service that removes the management burden from the user.
  • App Service apps run inside of an App Service plan that specifies the number of VMs and the configuration of those VMs.
  • Containers allow you to create an image of an application and everything needed to run it.
  • Azure Container Instances (ACI) allow you to run containers for very little cost.
  • Azure Kubernetes Service (AKS) is a managed service that makes it easy to host Kubernetes clusters in the cloud.
  • Windows Virtual Desktop makes applications and OSes easily available to multiple users from almost any device.
  • An Azure virtual network (VNet) allows Azure services to communicate with each other and the Internet.
    • You can add a public IP address to a VNet for inbound Internet connectivity. This is useful if a website is running in your VNET and you want to allow people to access it.
  • Azure Load Balancer can distribute traffic from the Internet across multiple VMs in your VNet.
  • Azure VPN Gateway allows you to establish encrypted connections between Azure VNets and other VNets or on-premises networks. You can configure VNet-to-VNet connections, site-to-site connections, and point-to-site connections.
  • Virtual network peering connects two Azure VNets to each other without the bandwidth restriction associated with a VNet-to-VNet connection. Peering VNets in different regions is called global virtual network peering.
  • ExpressRoute allows you to have a high-bandwidth connection to Azure of up to 10 Gbps by connecting to a Microsoft Enterprise Edge (MSEE) router.
    • Traffic over ExpressRoute does not travel over the Internet.
  • Azure Blob Storage is a good storage option for unstructured data such as binary files.
  • If you need to move a large amount of data to Blob Storage, Azure Data Box is a good option. You can have hard drives of numerous sizes shipped to you. Add your data to them and ship them back to Microsoft where they’ll be added to your storage account.
  • Azure Disk Storage is virtual disk storage for Azure VMs. Managed disks allow you to remove the management burden of disks.
  • Azure Files allows you to have disk space in the cloud that you can map to a drive on-premises.
  • Azure Blob Storage offers Hot, Cool, and Archive storage tiers that are based on how long you intend to store the data, how often the data is accessed, and so on.
  • Azure Cosmos DB is a NoSQL database in the cloud for unstructured data.
  • Azure SQL Database is a relational database system in the cloud that is completely managed by Microsoft.
  • Azure Database for MySQL is based on the Community Edition of the open-source MySQL database system. It’s a managed service that removes the burden of management from the user.
  • Azure Database for PostgreSQL is a managed service for hosting PostgreSQL databases.
  • The Azure Marketplace is a source of templates for creating Azure resources. Some are provided by Microsoft and some are provided by third parties.

Leave a Reply

Related Post

Azure SolutionsAzure Solutions

Core Solutions Available in Azure Serverless Computing Azure Functions Logic Apps AI Azure Machine Learning Cognitive Services Azure Bot Service IOT Azure IoT Hub IoT Central Azure Sphere Big Data