Microsoft Azure Networking: The Definitive Guide

Avinash Valiramani

Microsoft Azure Networking: The Definitive Guide

Published with the authorization of Microsoft Corporation by: Pearson Education, Inc.

Copyright © 2023 by Pearson Education Inc.

All rights reserved. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, request forms, and the appropriate contacts within the Pearson Education Global Rights & Permissions Department, please visit www.pearson.com/permissions.

No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein.

ISBN-13: 978-0-13-756989-2

ISBN-10: 0-13-756989-0

Library of Congress Control Number: 2022938822

ScoutAutomatedPrintCode

Trademarks

Microsoft and the trademarks listed at http://www.microsoft.com on the “Trademarks” webpage are trademarks of the Microsoft group of companies. All other marks are property of their respective owners.

Warning and Disclaimer

Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an “as is” basis. The author, the publisher, and Microsoft Corporation shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the programs accompanying it.

Special Sales

For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales department at corpsales@pearsoned.com or (800) 382-3419.

For government sales inquiries, please contact governmentsales@pearsoned.com. For questions about sales outside the U.S., please contact intlcs@pearson.com.

Credits

Editor-in-Chief

Brett Bartow

Executive Editor

Loretta Yates

Sponsoring Editor

Charvi Arora

Development Editor

Kate Shoup

Managing Editor

Sandra Schroeder

Senior Project Editor

Tracey Croom

Copy Editor

Sarah Kearns

Indexer

Timothy Wright

Proofreader

Donna E. Mulder

Technical Editor

Thomas Palathra

Editorial Assistant

Cindy Teeters

Cover Designer

Twist Creative, Seattle

Compositor

codeMantra

Graphics

codeMantra

Pearson’s Commitment to Diversity, Equity, and Inclusion

Pearson is dedicated to creating bias-free content that reflects the diversity of all learners. We embrace the many dimensions of diversity, including but not limited to race, ethnicity, gender, socioeconomic status, ability, age, sexual orientation, and religious or political beliefs.

Education is a powerful force for equity and change in our world. It has the potential to deliver opportunities that improve lives and enable economic mobility. As we work with authors to create content for every product and service, we acknowledge our responsibility to demonstrate inclusivity and incorporate diverse scholarship so that everyone can achieve their potential through learning. As the world’s leading learning company, we have a duty to help drive change and live up to our purpose to help more people create a better life for themselves and to create a better world.

Our ambition is to purposefully contribute to a world where:

Everyone has an equitable and lifelong opportunity to succeed through learning.

Our educational products and services are inclusive and represent the rich diversity of learners.

Our educational content accurately reflects the histories and experiences of the learners we serve.

Our educational content prompts deeper discussions with learners and motivates them to expand their own learning (and worldview).

While we work hard to present unbiased content, we want to hear from you about any concerns or needs with this Pearson product so that we can investigate and address them.

Please contact us with concerns about any potential bias at https://www.pearson.com/report-bias.html.

Contents at a Glance

About the author

Acknowledgments

Introduction to Azure networking services

Chapter 1     Azure virtual networks

Chapter 2     Azure Application Gateway

Chapter 3     Azure VPN gateway

Chapter 4     Azure Load Balancer

Chapter 5     Azure Firewall

Chapter 6     Azure DNS

Chapter 7     Azure Traffic Manager

Chapter 8     Azure Front Door

Chapter 9     Azure Bastion

Chapter 10   Azure Private Link

Index

Contents

About the author

Acknowledgments

Introduction to Azure networking services

Chapter 1     Azure virtual networks

Overview

Azure virtual networks features

Design concepts and deployment considerations

Address space

Subnets

vNET peering

Routing

Network security groups (NSGs)

Availability zones support

vNET network address translation (NAT)

Integrations for enhanced security

Service tags

Disaster recovery planning

vNET walkthrough

Best practices

Chapter 2     Azure Application Gateway

Overview

Azure Application Gateway features

Design concepts and deployment considerations

Front-end IP addresses

Back-end pools

Listeners

Request routing rules

HTTP settings

Health probes

Sizing and scaling

TLS policy

Application gateway walkthrough

Best practices

Chapter 3     Azure VPN gateway

Overview

Azure VPN gateway features

Design concepts and deployment considerations

VPN types

Gateway SKUs

Connection types

Gateway subnet

Border Gateway Protocol (BGP)

Local network gateways

VPN gateway redundancy

Deployment models

Best practices

Chapter 4     Azure Load Balancer

Overview

Azure Load Balancer features

Design concepts and deployment considerations

Front-end IP address

Back-end pool

Health probes

Load-balancing rules

Load-balancing algorithms

Availability zones

Azure Load Balancer walkthrough

Best practices

Chapter 5     Azure Firewall

Overview

Azure Firewall features

Design concepts and deployment considerations

Support for availability zones

Inbound DNAT

Outbound SNAT

Traffic filtering

Groupings

Forced tunneling

Threat intelligence

Azure Firewall Manager

Classic rules versus firewall policies

Firewall rule processing

DNS proxy

Active FTP support

Azure Monitor logging

Azure Firewall deployment walkthrough

Best practices

Chapter 6     Azure DNS

Overview

Azure DNS features

Azure DNS limitations

Design and configuration considerations

Types of DNS zones

Linking with Azure virtual networks

Auto registration

Alias record sets

Reverse DNS lookup

Zone delegation

Best practices

Chapter 7     Azure Traffic Manager

Overview

Traffic Manager features

Design concepts and deployment considerations

Traffic Manager endpoints

Nested Traffic Manager profiles

Traffic routing methods

Endpoint monitoring

Traffic Manager walkthrough

Best practices

Chapter 8     Azure Front Door

Overview

Key features

Design concepts and deployment considerations

Back ends

Back-end pools

Health probes

Load balancing

Traffic routing

URL rewrite

URL redirect

Wildcard domains

Rules Engine

Caching

Network and security

Azure DDoS Protection Basic

Protection against unwanted protocols

Handling large volumes of traffic

WAF security features

Front Door service walkthrough

Best practices

Chapter 9     Azure Bastion

Overview

Azure Bastion features

Azure Bastion limitations

Design concepts and deployment considerations

Architecture

SKUs

High-availability hosts

Virtual network peering

Disaster recovery

Service requirements

Best practices

Chapter 10   Azure Private Link

Overview

Azure Private Link features

Design concepts and deployment considerations

Private endpoints

Azure Private Link service

Best practices

Index

About the Author

Avinash Valiramani is an IT Infrastructure and Cloud Architect with more than 15 years of expertise in areas of Microsoft Technologies such as Microsoft Azure, Microsoft 365, Office365, Windows Server, Microsoft Exchange, SCCM, Intune, Hyper-V, and others. He is a certified Architect on Azure and Microsoft365 and primarily helps enterprises globally in their Cloud Roadmap Architecture and Onboarding/Migration Strategies & Implementation. Avinash is publishing four books on Microsoft Azure Best Practices series including this current one, collating real-world experiences to deliver a comprehensive and concise experience for new and budding technologists. Avinash also holds certifications in Barracuda, AWS, Citrix, VMware, and many other IT/Security industry certifications to complement his Microsoft expertise. He has authored a course of Azure Virtual Desktop for Oreilly Media and is planning many others in the coming months. You can follow Avinash on Twitter at @avaliramani.

Acknowledgments

I would like to thank Loretta Yates for trusting me with this huge responsibility. These books would not have been possible without your confidence in me and I will be forever grateful for that. I would especially like to thank Kate Shoup for editing and reviewing this book and for all her guidance and attention to detail throughout these series of books. Kate, it has been a wonderful experience working on these books with you and I could not have hoped for a better editor for this collaboration.

Thanks to Thomas Palathra, Sarah Kearns, and Tracey Croom for adding the final touches to bring this across the finish line. A big Thank you to Charvi Arora and the entire Microsoft Press/Pearson team for their constant support and guidance on this project. This second book is the fruit of all our labour, I am extremely happy, and grateful we worked together on it.

Most importantly, I would like to appreciate and thank my family, especially Celine on this effort. Celine, sincerely Thank you for being there whenever I needed you on this journey. This book would not have been possible without your constant push and guidance.

To my family, am forever grateful for all your love and support. Thank you mom and dad, without you these books would not have been possible.

To my extended family, thank you for tolerating my absence for over a year while I closed myself off to focus on these books. Two down, two more to go!

Introduction to Azure networking services

Welcome to Microsoft Azure Networking: The Definitive Guide. This book was developed to convey in-depth information about various Azure services that provide networking capabilities, as well as best practices based on real-life experiences using the product in different environments. The book is largely based on the versions of Azure networking services available during 2021 and early 2022, and takes into account the development work done on these services over the years. At that time, there were a few features and functionalities under preview. Because these features could change before becoming available to the general public, the most notable ones will be covered in subsequent iterations of this book, as they become available globally.

Who is this bookfor?

Microsoft Azure Networking: The Definitive Guide is for anyone interested in Azure infrastructure solutions—not just IT and cloud administrators, network professionals, security professionals, developers, and engineers, but the entire spectrum of Azure users. Whether you have basic experience using Azure or other on-premises or cloud virtualization technologies or you are an expert, you can still derive value from this book. It provides introductory, intermediate, and advanced coverage of each networking service.

The book especially targets those who work in medium to large enterprise organizations and have at least one year of experience in designing, administering, deploying, managing, monitoring, and migrating network infrastructure to services such as Azure virtual networks, Azure Firewall, Azure Web Application Firewall, and others that comprise the Azure network stack.

How is this book organized?

This book is organized into ten chapters:

Chapter 1: Azure virtual networks

Chapter 2: Azure Application Gateway

Chapter 3: Azure VPN gateway

Chapter 4: Azure Load Balancer

Chapter 5: Azure Firewall

Chapter 6: Azure DNS

Chapter 7: Azure Traffic Manager

Chapter 8: Azure Front Door

Chapter 9: Azure Bastion

Chapter 10: Azure Private Link

Each chapter focuses on a specific Azure networking service, covering the inner workings of each one in depth, walking you through how to build and test the service, and offering real-world best practices to help you maximize your Azure investment.

The approach adopted for this book is a unique mix of didactic, narrative, and experiential instruction:

Didactic instruction covers the core introductions to the services.

Narrative instruction leverages what you already understand to help you bridge that knowledge with new concepts introduced in the book.

Experiential instruction takes into account real-world experiences and challenges facing small and large environments, as well as what factors to consider when designing and implementing workloads. Guided step-by-step walkthroughs show you how to configure each Azure networking service and its related features and options to gain all the benefits each service has to offer.

System requirements

This book is designed to be tested using an Azure subscription. Microsoft offers a 30-day, $200 USD trial subscription that you can use to test most services covered in this book. However, some services, such as dedicated hosts, cannot be used with a trial subscription. Testing and validating these services requires a paid subscription.

The following list details the minimum system requirements needed to use the content provided on the book’s companion website:

Windows 10/11 with the latest updates from Microsoft Update Service

Azure PowerShell (https://docs.microsoft.com/en-us/powershell/azure/install-az-ps)

Azure CLI (https://docs.microsoft.com/en-us/cli/azure/install-azure-cli)

Display monitor capable of 1024 x 768 resolution

Microsoft mouse or compatible pointing device

About the companion content

The companion content for this book can be downloaded from the following pages:

MicrosoftPressStore.com/AzureNetworkingTDG/downloads

or

https://github.com/avinashvaliramani/AzureNetworkingTDG

Errata, updates, & book support

We’ve made every effort to ensure the accuracy of this book and its companion content. You can access updates to this book—in the form of a list of submitted errata and their related corrections—at:

MicrosoftPressStore.com/AzureNetworkingTDG/errata

If you discover an error that is not already listed, please submit it to us at the same page.

For additional book support and information, please visit MicrosoftPressStore.com/Support.

Please note that product support for Microsoft software and hardware is not offered through the previous addresses. For help with Microsoft software or hardware, go to http://support.microsoft.com.

Stay in touch

Let’s keep the conversation going! We’re on Twitter: http://twitter.com/MicrosoftPress.

Overview

Over the years, Microsoft has introduced various services related to the Azure networking stack alongside the Azure compute services designed to leverage them. Microsoft has enhanced these services on a regular basis, making them more robust and resilient as well as easier to deploy and manage. The first of these services was Azure virtual machines (VMs). After that came additional platform as a service (PaaS) solutions like Azure App Service, Azure Container Service, Azure Functions, and Azure Virtual Desktop.

Following is a brief timeline of the announcement of each of these services in public preview:

Azure Traffic Manager Nov 2013

Azure VPN Gateways Dec 2014

Azure Load Balancer Sept 2015

Azure Firewall Nov 2015

Azure Application Gateway Sept 2016

Azure DNS Sept 2016

Azure Front Door April 2019

Azure Bastion Nov 2019

Azure Private Link Feb 2020

Over the years, each service has added new capabilities to Azure’s networking stack. These have provided customers with various networking-service options for use based on their application and security requirements.

Each service helps address different requirements in an organization’s application design and architecture as well as overall security requirement. Each chapter of this book covers a single service, enabling you to dive into each one to better understand how it works and includes the associated best practices.

Each chapter initially focuses on factors to consider when selecting a particular networking service. Thereafter, it conveys in-depth concepts related to each service and the components that make up that service. This enables you to better understand how each service works. Once you have gained this understanding, you will focus on deployment considerations and strategies, with step-by-step walkthroughs of deployment methods, followed by best practices.

Cloud service categories

As in other books in this series, let us start by first presenting the various cloud-service categories. Currently, cloud services are broken down into four main categories: infrastructure as a service (IaaS), platform as a service (PaaS), function as a service (FaaS), and software as a service (SaaS). SaaS is not relevant to the content covered in this book series, so the following explanations relate to the first three categories:

Infrastructure as a service (IaaS) Using VMs with storage and networking is generally referred to as IaaS. This is a traditional approach to using cloud services in line with on-premises workloads. Most on-premises environments use virtualization technologies such as Hyper-V to virtualize Windows and Linux workloads. Migrating to IaaS from such an environment is a much easier first step than migrating to PaaS or FaaS. Over time, as an organization’s understanding of various other types of cloud services grows, it can migrate to PaaS or FaaS.

Platform as a service (PaaS) One of the biggest benefits of using a cloud service is the capability to offload the management of back-end infrastructure to the service provider. This model is called platform as a service (PaaS). Examples of back-end infrastructure include the various layers of an application, such as the compute layer, storage layer, networking layer, security layer, and monitoring layer. Organizations can use PaaS to free up their IT staff to focus on higher-level tasks and core organizational needs instead of on routine infrastructure monitoring, upgrade, and maintenance activities. Azure App Service and Azure Container Service are examples of Azure PaaS offerings.

Function as a service (FaaS) These offerings go one step beyond PaaS to enable organizations to focus only on their application code, leaving the entire back-end infrastructure deployment and management to the cloud service provider. This enables developers to deploy their code without worrying about back-end infrastructure deployment, scaling, and management. It also enables the use of microservices architectures for applications. An example of an Azure FaaS offering is Azure Functions.

In the Azure networking stack, the services largely fall under the PaaS category. For example:

Azure Firewall is a PaaS service that allows you to deploy a native firewall in Azure to protect both IaaS and PaaS workloads.

Azure Bastion is a PaaS service that gives you the ability to securely access IaaS VM workloads in Azure using a browser without exposing them directly to the internet.

Each of these cloud service categories has various features and limitations. Limitations might relate to the application, technological know-how, and costs for redevelopment, among others. As a result, most organizations use some combination of various types of cloud services to maximize their cloud investments.

Each service provides a different level of control and ease of management. For example:

IaaS provides maximum control and flexibility in migration and use.

FaaS provides maximum automation for workload deployment, management, and use.

PaaS provides a mix of both at varying levels, depending on the PaaS service used.

Each service also offers varying levels of scalability. For example:

IaaS requires the use of additional services to achieve true scalability and load balancing—for example, using Azure Load Balancer, a PaaS service, to balance requests across multiple Azure IaaS VMs.

PaaS and FaaS services are generally designed with built-in scalability and load-balancing features.

Cost-wise, each service provides varying levels of efficiency. For example:

FaaS offerings charge for compute based only on the usage hours for compute services, making it extremely cost-effective.

IaaS products charge for compute services regardless of usage once the compute service (for example, a VM) is online.

PaaS offerings are a mixed bag depending on how the service is configured. Some PaaS products charge for the service regardless of usage, while others, if configured correctly, charge based on usage. For example, Azure Bastion has a fixed monthly cost for the service whereas Azure DNS is charged based on number of domains and number of queries per month.

Service selection factors and strategies

There are certain factors to consider when selecting which Azure networking service would be ideal for a given environment based on the application architecture, connectivity requirements, application security requirements, application delivery requirements, and other business needs. Some of these key factors, and the Azure networking services that best addresses them, are as follows:

Deliver applications securely The networking stack provides multiple services that you can leverage to securely deliver applications to your end users. These include Azure Front Door, Azure Traffic Manager, and Azure Load Balancer.

Protect application connectivity You can protect connectivity to the applications using services such as Azure Firewall, Azure Private Link, Azure Web Application Firewall, and Azure Load Balancer. You can use these services individually or in combination to provide higher levels of protection.

Provide connectivity to Azure and on-premise resources Services such as Azure virtual networks, Azure VPN Gateway, Azure vNET Peering, ExpressRoute, Azure Bastion, and Azure DNS provide you with different connectivity options to securely connect your Azure services to each other and to on-premise hosted services.

As you can see, there are multiple services for each factor. As you get more clarity on your requirements and a better understanding of each of these services, it will become clearer to you when each of these services should be used in your environment, as each one provides distinct capabilities.

Selecting the right load-balancing service

Certain network load-balancing services provide functionality that is similar or overlapping in nature, such as Azure Front Door, Azure Traffic Manager, Azure Load Balancer, and Azure Web Application Gateway. Let us take a moment to narrow down which of these load-balancing services might be best suited for your application. Figure I-1 offers a good starting point for identifying which service might best serve your requirements. While the diagram shown in the figure is not exhaustive, it can help you narrow down which services to focus on before making your final decision.

FIGURE I-1 Load-balancing service selection considerations.

Let us examine the flowchart shown in Figure I-1 in more detail.

Non-web application workloads The first factor you should consider is whether your workload is web application–published using HTTP/HTTPS. If not, then the Azure Load Balancer service might be best suited to handle your needs. If your application is hosted in multiple Azure regions with local redundancy in each region, a combination of Azure Traffic Manager and the Azure Load Balancer might be best suited to meet those needs.

Web application workloads When it comes to web application workloads, you need to consider a few factors before you can identify the appropriate service:

Will the web app be accessible only internally? If it will only be accessible internally, then you can use the Azure Application Gateway service. If, however, the web app will be publicly accessible, then you’ll need to consider the following factors as well.

Will the web application be hosted in multiple Azure regions? If you plan to host the application in a single Azure region, then Azure Application Gateway might suffice (unless you need to accelerate application performance). If you will be hosting the web app in multiple Azure regions, then there are multiple Azure networking services that you can choose from, including Azure Front Door, Azure Application Gateway, Azure Load Balancer, or a combination of these. To better narrow down the appropriate option, let us continue further down the chain.

Will the multi-region public web application require SSL offloading or application request processing? If this is a requirement, then the Azure Front Door service might be most appropriate for your needs. If, however, you do not require SSL offloading or application request processing, then depending on the application hosting model (such as Azure Kubernetes Service, Azure App Service, Azure Functions, or Azure VMs), you can work with a combination of the Azure Front Door, Azure Application Gateway, and Azure Load Balancer services.

As you can see, different factors can affect your decision-making process. Moreover, these may evolve over time, as your application requirements evolve. You might start with an application hosted in a single region and over time move it to multiple regions for global scalability.

As you read this book, you will better understand how you can leverage these networking services as needed over time to meet your ongoing needs and business demands.

Conclusion

Now that you have an overview of the various Azure networking cloud offerings, let us dive deeper into each of the networking services. We’ll start with the network service that forms the backbone of most Azure deployments: Azure virtual networks.

Chapter 1

Azure virtual networks

Overview

In traditional, on-premises datacenters, virtual networks (vNETs) help connect devices, virtual machines, and datacenters to make services accessible in different locations and across geographic boundaries. A vNET emulates a physical network in that it is a combination of hardware and software resources working together to provide networking capabilities for virtual infrastructure resources. In Azure, a vNET provides the base layer for a private network to host Azure resources, such as Azure virtual machines (VMs), Azure virtual machine scale sets (VMSS), virtual private network (VPN) gateways, firewalls, and so on, to securely connect and communicate with each other and other resources hosted on on-premises networks or on the internet.

Azure virtual networks features

An Azure vNET has a number of unique features to take advantage of the Azure cloud’s extensibility, scaling, and global availability. These features help address different types of vNET requirements or scenarios, such as the following:

Communication with on-premises resources and services Various options are available to communicate with on-premises resources and services such as Azure ExpressRoute, Site-to-Site (S2S) VPN, and Point-to-Site (P2S) VPN. An Azure vNET helps support Azure-based connectivity services, Azure resources, and on-premises resources and services.

Communication between Azure resources in the same and different Azure regions Azure vNET enables resources within the same vNET, as well as resources in different vNETs in the same or different Azure region using vNET peering, to securely communicate with each other.

Communication between Azure and internet-based resources and services Inbound connectivity to resources in a vNET requires the use of either a public IP address or public-facing load balancer that can route traffic to internal resources. However, all resources in a vNET can communicate externally by default.

Network traffic management Azure vNET supports the use of network security groups (NSGs) and network virtual appliances (NVAs) to filter traffic between subnets in the same vNET and between vNETs. Azure vNET also supports using route tables and Border Gateway Protocol (BGP) routes to route traffic between different subnets or networks on-premises or the internet.

Integration with Azure services Azure vNET supports integration with Azure services such as Azure SQL Database and Azure Storage using Azure Private Link and service endpoints for secure communication over public and private networks.

Design concepts and deployment considerations

vNETs are a backbone of any Azure deployment. It is important to understand the design concepts behind vNETs to deploy them in an optimal manner to achieve scale, security, and redundancy.

Address space

An address space is a private IP address range or series of ranges allocated to a vNET and is used to provide IP addresses to resources hosted in the vNET. For example, if you create a private address space of 10.10.10.0/24, VMs hosted in that vNET would obtain IP addresses between 10.10.10.1 to 10.10.10.251.

Subnets

You can split or segment an address space into multiple network subnets and assign portions of the address space to each subnet. You can then host different Azure resources in different subnets, and apply different routing, traffic-management, and security policies to each subnet based on its resource requirements.

You can extend your current on-premises network address space to Azure to maintain the same IP series in both locations. You should do this only if there are IP dependencies for applications being migrated to Azure, as this type of setup requires careful planning and integration to avoid routing issues.

You can also set up subnet delegation to integrate Azure PaaS services directly into an Azure vNET. This gives full control to the Azure service to set up rules for access to the service via that vNET subnet. You can choose to set up specific subnets just for delegation to such services.

vNET peering

An Azure vNET is scoped to a single region. So, resources that must be hosted in different regions cannot be set up within the same vNET. You can only achieve this using multiple vNET setups in each Azure region where resources must be hosted. However, vNETs can be connected to other vNETs using peering. This enables VMs on vNETs in the same or different Azure region to communicate with each other securely. This allows organizations to set up resources as close as possible to the intended target audience, but consolidate key services such as monitoring, logging, data warehousing, and so on in a single region by enabling all resources across vNETs to be able to talk to each other.

Note

A vNET can be part of only a single Azure subscription. However, a single Azure subscription can host multiple vNETs.

Routing

Azure supports several different types of routing types:

Default system routes

Optional system routes

User-defined routes

The following sections offer details about each of these routing types to give you a better understanding of each one and how best to use them.

Default system routes

Default system routes are automatically created and assigned to every subnet in a vNET. These routes are created and managed by the Azure service itself. Table 1-1 outlines the default system routes defined automatically by Azure whenever a vNET is created. Each default system route defines the source network, address prefix, and next-hop type.

TABLE 1-1 Default system routes

Source

Address prefix

Next-hop type

Default

Unique to the vNET

vNET

Default

0.0.0.0/0

Internet

Default

10.0.0.0/8

None

Default

192.168.0.0/16

None

Default

100.64.0.0/10

None

Note

You cannot manually modify, add, or delete any default system route.

Table 1-1 notes various next-hop types. These depend on the purpose of the address prefix, as detailed here:

vNET If an address space contains multiple IP ranges or subnets, Azure creates an individual route for each subnet, and routes traffic between them without requiring the use of a gateway. When the next-hop type is vNET, the traffic for those IP address ranges will be contained within the vNET itself.

Internet This is the default route for all traffic to the internet, including any traffic that does not have a specific route defined in the route table. The only exception to this is traffic to Azure services, which is routed using the Microsoft Azure backbone network instead.

None Azure automatically creates default routes to the following three reserved address prefixes. If the next-hop type is None, it implies the traffic is dropped:

10.0.0.0/8 Reserved for private use in RFC 1918.

192.168.0.0/16 Reserved for private use in RFC 1918.

100.64.0.0/10 Reserved in RFC 6598.

Note

If any of these IP address ranges are used in a vNET address space, Azure changes the default route configuration to vNET instead of None to ensure traffic routing for that network is working.

When traffic exits a subnet, Azure matches the destination address prefix to the default route defined for that address prefix and routes accordingly. If multiple routes are defined for the same IP address prefix or if overlapping IP prefixes exist, Azure has a pre-defined algorithm and logic to determine the best course of action. (For more on this, see the section “Route selection in Azure” later in this chapter.)

Optional system routes

Beyond the default routes that are added to every subnet, optional routes are added after you enable specific Azure capabilities. Azure adds these routes to specific subnets or to the entire vNET, depending on the capability enabled. Table 1-2 shows an example of how these optional default routes are added. Each route defines the source, address prefix, next-hop type, and subnet with which the route is associated.

TABLE 1-2 Optional system routes

Source

Address prefix

Next-hop type

Subnet within VNet to which route is added

Default

Unique to the vNET (for example, 10.10.10.0/24)

vNET peering

All

vNET gateway

Prefix advertised from on-premises via BGP or configured in the local network gateway

vNET gateway

All

Default

Multiple

VirtualNetworkServiceEndpoint

Only the subnet for which a service endpoint is enabled

The next-hop type depends on the purpose of the route, as explained here:

vNET gateway When a vNET gateway is added to a vNET, optional routes are added based on the subnet defined in the gateway configuration or on the routes propagated from the on-premises network gateway using the BGP.

Note

If possible, consolidate the on-premises ranges to the largest address range. This way, you can propagate as few routes as possible to avoid hitting any Azure service limits.

vNET peering As discussed, you can use peering to connect different Azure vNETs. When peering is established, a route for each address range is added to the route table.

VirtualNetworkServiceEndpoint If you integrate an Azure PaaS service to a vNET using a service endpoint, Azure adds a route for the service endpoint to the route table. Azure adds routes only for the subnets for which the service endpoint is enabled. Azure maintains this information automatically when changes are made to subnet associations.

Custom routes

In addition to default and optional system-generated and system-managed routes, you can set up custom routes to direct traffic to on-premises networks or other services, per your requirements. There are two ways to do this, as follows:

User-defined routes

Border Gateway Protocol (BGP) routes

User-defined routes

User-defined routes are custom routes that you define to override the default system routes created by Azure or as additional routes to address specific routing requirements for your environment for compliance or monitoring purposes. To create a user-defined route, you create a route table that contains a series of routing rules; you then associate this route table with one or more subnets.

Note

The same route table can be associated with multiple subnets, or you can have different route tables for different subnets. However, a single subnet can have at most a single user-defined route table associated with it.

As mentioned, user-defined routes either override system-defined routes or work alongside them. This implies that user-defined routes take precedence over system-defined routes in the event of a conflict.

User-defined routes support some of the same next-hop types as default and optional system routes, such as vNET, Internet, None, and vNET gateway. In addition, they support a next-hop type called virtual appliance, which routes traffic to vNET appliances such as firewalls. However, user-defined routes do not support vNET peering VirtualNetworkServiceEndpoint next-hop types.

Border Gateway Protocol (BGP) routes

BGP routes are another type of user-defined route. These are supported only in scenarios where an Azure virtual gateway S2S VPN or Azure ExpressRoute connection is used to establish connectivity with on-premises networks.

With BGP routes, the initial route exchange occurs when a connection between an on-premises gateway and an Azure VPN gateway is established. This allows either end to automatically propagate the required routes and maintain them as changes occur, without manual intervention.

Route selection in Azure

Now that you have a better understanding of the different routing types available in Azure, it is important to understand how the routing algorithm selects the most appropriate route for outbound traffic from a subnet.

If there is only a single route defined for a destination IP address, the logic for the algorithm is extremely simple: It must use that single available route. However, if multiple routes exist for the same destination IP address, Azure must identify which route’s IP address prefix most closely matches the destination IP address. If multiple routes contain the same address prefix, and that IP address prefix is the one that most closely matches the destination IP address, Azure selects the route based on the following priorities, in order:

User-defined route.

BGP route.

Default or optional system route.

Network security groups (NSGs)

You can use NSGs to set up inbound and outbound traffic-filtering rules to and from Azure resources in an Azure vNET. You can set up each rule to allow or deny traffic, inbound or outbound, and identify other parameters such as source and destination, port, and protocol.

An NSG can be applied on a subnet level and another applied on a resource level, such as an Azure VM. In such scenarios, traffic is evaluated against the rules configured in both NSGs, and the more restrictive action of the two is applied.

Note

A network security group can contain zero or as many rules as desired.

Availability zones support

vNETs span across all availability zones in a defined Azure region. There is no requirement or even possibility to spread them across different availability zones. This is by design. Any resources set up to use availability zones can use the same vNET without additional configuration.

vNET network address translation (NAT)

Network address translation (NAT) helps route inbound or outbound traffic using a set of static public IP addresses to or from specific internal hosts. In the case of an Azure vNET NAT, outbound internet-based traffic is routed via a single or range of static public IP addresses. This eliminates the need to associate a public IP address with each VM requiring a static outbound IP or using a load balancer for outbound traffic routing.

NAT can be set up for a single or multiple subnets in a vNET. All subnets can use the same NAT, or separate NATs can be set up for every subnet in the vNET. Once defined, NAT is set as the default internet destination of a subnet.

Integrations for enhanced security

Azure vNETs support integration with Azure PaaS services to restrict access to the service from specific networks and endpoints. You can achieve this by using one of the following methods, depending on your environment’s access requirements:

Network isolation using dedicated vNETs or subnet segmentation You can create a dedicated vNET on which to deploy Azure services and use NSGs or Azure firewall services to control traffic, depending on your organization’s security requirements. You can also segment subnets to create services in their own subnet and set up NSGs to restrict access as needed.

Private endpoints and Private Link You can use private endpoints and Private Link services to enable private access to Azure services over an internal network instead of the public internet. You can securely connect to Azure PaaS services over peered Azure networks and interconnected on-premises networks. This is a one-way communication from internal networks to Azure services and does not support outbound connections from PaaS services to on-premises resources.

Service endpoints Service endpoints allow access to Azure PaaS services over the Azure backbone without completely exposing the service to all internet-based endpoints. You can integrate Azure vNETs with the service endpoint connected to the service, thereby providing secure access to the service even from customer environments.

Service tags

Service tags are pre-defined groups of IP addresses created and managed by Microsoft for different Azure services. For example, the AzureActiveDirectory service tag contains all IP address prefixes used by the Azure Active Directory service. If the IP address prefixes for a service change over time, the service tag automatically notes the change when used to define network access controls.

The VirtualNetwork service tag defines all IP address prefixes associated with the vNET, any peered vNETs, any on-premises address spaces connected over VPN or ExpressRoute, and any default and user-defined routes.

Disaster recovery planning

If a disaster brings an Azure region offline, the vNETs in that region will not automatically be available in another. If facing such a scenario, you have a few options to consider:

You can preconfigure the same vNET address space and subnets in another Azure region. However, the two regions cannot be connected to or communicate with each other, as the network addresses overlap.

You can set up a different vNET address space and subnet configuration in another Azure region and replicate, pre-create, or automatically provision all the related Azure resources when necessary. In such a scenario, both regions can be connected and communicate with each other. You’ll need to take resource-level conflicts into consideration separately during the redundancy planning for each workload.

vNET walkthrough

The following sections walk you through the process of creating a vNET using the Azure Portal, Azure PowerShell, and the Azure CLI. If you are following along, be sure to select resources and resource names based on your environment, including a unique vNET name for each of your deployments. Also be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft for these resources.

Using the Azure Portal

To create a vNET using the Azure Portal, follow these steps:

Log into the Azure Portal, type virtual networks in the search box to locate the service, and select it from the list that appears. (See Figure 1-1.)

FIGURE 1-1 Create a virtual network.

Click Create or Create Virtual Network to start the Create Virtual Network wizard. (See Figure 1-2.)

FIGURE 1-2 Click Create Virtual Network.

In the Basics tab of the Create Virtual Network wizard (see Figure 1-3), enter the following information and click Next:

Subscription Select the subscription to host the vNET.

Resource Group Select the resource group you want to host the vNET. Alternatively, click the Create New link and follow the prompts to create a new resource group.

Name Type a name for the vNET. If the name you type is already in use, the wizard will prompt you to enter another name.

Region Select the Azure region in which you want to create the vNET.

FIGURE 1-3 The Basics tab of the Create Virtual Network wizard.

In the IP Addresses tab of the Create Virtual Network wizard, review the default IPv4 address space defined by the Azure service. To associate a different address space with the vNET, replace the current address space with the one you want. (See Figure 1-4.)

FIGURE 1-4 The IP Addresses tab of the Create Virtual Network wizard.

Review the default subnet defined by the Azure service and change it if needed. Then click Next.

In the Security tab, leave the default settings as is (set to Disable for all services) and click Next. (See Figure 1-5.)

FIGURE 1-5 The Security tab of the Create Virtual Network wizard.

In the Tags tab, enter any tags required for the vNET or leave the fields blank (see Figure 1-6) and click Next.

FIGURE 1-6 The Tags tab of the Create Virtual Network wizard.

In the Review + Create tab (see Figure 1-7), review your settings and click Create.

FIGURE 1-7 The Review + Create tab of the Create Virtual Network wizard.

When the deployment is complete, click Go to Resource to access the vNET setup. (See Figure 1-8.)

FIGURE 1-8 Click Go to Resource.

Using Azure PowerShell

You can create a vNET using Azure PowerShell with the New-AzVirtualNetwork command and various switches to set the vNET’s parameters. The following code shows you how. Use this snippet to create the same vNET as you did in the Azure Portal; when you do, be sure to either delete the previous network or give this new network a different name:

Click here to view code image

#Define variables
$vnetName = 'vNET01"
$rg = "RG01"
$location = "East US"
$Subnet = New-AzVirtualNetworkSubnetConfig -Name default -AddressPrefix "10.0.0.0/24"
#Create virtual network with the default subnet configuration
New-AzVirtualNetwork -Name $vnetName -ResourceGroupName $rg -Location $location
-AddressPrefix "10.0.0.0/16" -Subnet $default

Using the Azure CLI

You can create a vNET using the Azure CLI with the az network vnet command and various switches to set the vNET’s parameters. The following Bash script shows you how. Use this snippet to create the same vNET as you did in the Azure Portal; when you do, be sure to either delete the previous network or give this new network a different name:

Click here to view code image

#Define variables
vnetname = "vNET01"
rg = "RG01"
location = "East US"
subnet = "default"
#Create virtual network with the default subnet configuration
az network vnet create -g $rg -n $vnetname –location $location --address-prefix
10.0.0.0/16 --subnet-name $subnet --subnet-prefix 10.0.0.0/24

Best practices

Following are some general best practices for designing and securing vNETs in Azure:

Identify unique address spaces across the organization Be sure to use Azure address spaces that do not overlap with others already in use in the on-premises or other connected cloud environments. Although you can use the same address spaces if necessary, this requires careful planning, execution, and maintenance to avoid routing issues.

Size address spaces for long-term use When sizing address spaces in Azure, take into account long-term goals and requirements. Don’t use all address ranges for subnets right away, with no room for expansion later. Although you can add more address spaces to the vNET at a later stage, considering this during initial planning can reduce issues in the future.

Consolidate into fewer larger vNETs Although it is possible to connect multiple vNETs, it is a better practice to consolidate, such that you have fewer larger vNETs that cover the necessary requirements. This reduces the environment’s complexity and management overhead.

Secure internal traffic Use NSGs to secure internal traffic between Azure and on-premises networks to ensure that the only networks that can communicate with each other are the ones you require to do so. Isolate critical networks in their own subnets or vNETs and ensure that access to those subnets or vNETs is restricted to only the required source and destination endpoints, protocols, and ports. Finally, use Azure ExpressRoute instead of an S2S VPN if you require all internal communications to route over a completely private network.

Protect against DDoS attacks Use Azure Firewall and Azure Security Center to detect and prevent distributed denial of service (DDoS) attacks from known malicious IP ranges. You can set up the environment to automatically respond to such threats once detected or simply alert you so you can take action manually. (See Figure 1-9.)

FIGURE 1-9 The DDoS Protection tab of the Azure vNET.

Use Log Analytics to analyze vNET flow logs This will provide you with a better understanding of traffic on the vNET. Set up Log Analytics integration to gain deeper visibility into the traffic on a vNET to make better decisions about vNET security and the routing setup.

Use Azure Firewall’s Threat Intelligence capabilities Azure Firewall is connected to the Microsoft Threat Intelligence feed, which is constantly updated from different sources regarding ongoing and new threat vectors around the globe. By enabling this for a firewall instance connected to an Azure vNET, you can better protect your environment from known bad actors on the internet.

Use service tags to reduce complexity in network security rules Service tags are a great way to manage traffic rules associated with Azure services. Use service tags whenever possible to reduce the management overhead of tracking and maintaining service changes that could potentially affect communications within your vNET.

Use tags to document vNET configuration Label different components and vNET security rules to easily identify or filter them as required.

Use Azure Policy to standardize the vNET configuration Azure Policy can help you enforce vNET security standards, including policy requirements, policy documentation, and so on, to ensure that all vNETs across an organization are created with the same set of guidelines.

Use automated logging and monitoring You can use Azure Activity Logs and Azure Monitor to track and alert on events on an Azure vNET, such as configuration changes. It is a good practice to set up alerts for critical events that could have a detrimental impact on your environment. You can also integrate Azure Log Analytics to store logs for longer periods of time for historical reporting and comparisons.

Chapter 2

Azure Application Gateway

Overview

Azure Application Gateway is an ideal load balancer for web servers and applications that require HTTP/HTTPS traffic load-balancing and routing. It operates at the application layer (OSI layer 7 of the TCP and UDP stack) and can therefore analyze incoming traffic for custom routing based on URL paths and host headers in the incoming request. (See Figure 2-1.)

FIGURE 2-1 The Azure Application Gateway handles incoming traffic using routing rules to back-end services.

Traditional load balancers operate at OSI layer 4, meaning they can only route traffic with limited parameters, such as the source IP or port and the destination IP and port. Due to these limitations, complex application traffic routing is difficult on traditional load balancers. In contrast, Azure Application Gateway can route traffic based on the URL in the header information of the incoming traffic request. This makes it possible to route traffic for the same host header, directed to the same Azure Application Gateway IP, to a different server or server pool. For example, a request with the URL www.contoso.com/videos can be routed to one server or server pool hosting video-based content, a request for www.contoso.com/images can be routed to another server or server pool hosting image-based content, and so on. (See Figure 2-2.) This can help you design and optimize a web application server pool based on the content hosted by the pool.

FIGURE 2-2 Azure Application Gateway URL-based routing.

You can deploy an Azure Application Gateway in one of two ways:

As an internal-only Azure Application Gateway This is ideal for environments in which the application must be accessible only over internal virtual networks (vNETs). The gateway has an internal IP address, and the DNS records for it are set up in an internal or custom DNS server or service that is accessible only via vNETs for client connectivity.

As an internet-facing Azure Application Gateway This has a public IP, which publicly exposes the gateway. So, back-end applications can be publicly accessed by clients by way of the internet. The DNS name for a public-facing load balancer is added to the public DNS by the Azure service.

Azure Application Gateway features

The following list outlines the main features of the Azure Application Gateway. These features help explain how this service can be a key component of any web application design:

Web application firewall (WAF) The Azure Application Gateway can act as a WAF, monitoring incoming traffic from clients and intercepting any malicious activities to provide centralized protection from well-known vulnerabilities for multiple web applications in your environment. You can host an application behind the WAF even if you have not yet been able to patch the vulnerabilities on the web servers themselves. You can centrally protect an application or even a large server farm that needs patching from a known vulnerability by patching the WAF. This serves as an interim solution until the application or server farm itself can be updated.

Note

WAF rules are based on Open Web Application Security Project (OWASP) core rule sets 3.1 (WAF v2), 3.0 (WAF v1 and v2), and 2.2.9 (WAF v1 and v2).

Multiple-site hosting Azure Application Gateway supports the use of multiple host, domain, or subdomain names on the same application gateway. So, you can use a single application gateway to handle web traffic for multiple web applications. This enables you to maximize your investment in the service by using each instance to its fullest capacity. You can map more than 100 web applications to a single application gateway. And, by using multi-site listeners, you can route traffic sent to a single public IP to different back-end server pools based on the URL request or host header.

Web-traffic redirection By redirecting web traffic meant for one port to another, you can mask the application ports used internally on the web application servers, which can improve the security of your web applications. Traffic redirection also enables you to centrally route HTTP traffic to HTTPS, ensuring that no unencrypted communication occurs between your clients and web services. Web-traffic redirection supports the following scenarios:

Global traffic redirection This type of redirection enables you to redirect all traffic from HTTP to HTTPS on a site or to any other non-standard port required by the web application.

Path-based redirection With this type of redirection, you can redirect HTTP to HTTPS or any other non-standard port only on specific site areas, such as traffic to /videos/* or /checkout/*.

Redirection to an external site This type of redirection allows you to redirect traffic to an external site.

Secure Sockets Layer/Transport Layer Security (SSL/TLS) termination You can use Azure Application Gateway to offload SSL/TLS processing for your web applications. This helps reduce the overhead of SSL/TLS encryption/decryption as well as server resource consumption. Traffic between the application gateway to the web application hosted internally behind it can be unencrypted. In some scenarios, however, you might need the back-end traffic to be encrypted for compliance or application-design reasons. Azure Application Gateway supports these types of end-to-end encryption scenarios, too.

Session affinity handling You can set up Azure Application Gateway to support cookie-based session affinity, thereby ensuring that any sessions that are interrupted or dropped will reconnect to the same server as before. This can be a critical requirement for some applications where a user’s session state is stored locally on the server.

Static virtual IP (VIP) assignment The Standard_v2 version of Azure Application Gateway supports the use of static VIP addresses, ensuring the VIP is maintained as-is for the lifetime of the application gateway.

Zone redundancy You can set up Azure Application Gateway to span multiple availability zones, thereby improving the gateway’s SLA and resiliency.

Note

Currently, only the Standard_v2 version of Azure Application Gateway supports zone redundancy.

Path-based routing This enables you to analyze and route traffic based on the path indicated in the incoming web request. You can set up the application gateway to route traffic to different back-end servers or server pools based on the paths found in the request. So, content for different paths of a URL can be hosted on different servers or server pools, and the content itself can be optimized to deliver the best end-user experience possible.

Automatic scaling You can set up Azure Application Gateway to automatically scale up or down based on traffic load at any given time. You need not select the “perfect” size for the application gateway when you provision it, because the gateway can scale as needed as traffic grows over time.

Support for WebSocket and HTTP/2 traffic Azure Application Gateway natively supports WebSocket and HTTP/2 protocols. WebSocket is enabled by default and cannot be turned off. It allows full duplex communication between the web application server and client over long-running TCP connections, which can be optimized and used for multiple requests and responses. HTTP/2 protocols can be used only for client-to-application gateway communications. HTTP/2 is designed to function more efficiently than HTTP-based communications by eliminating the need for the constant polling required by HTTP to keep long-running sessions alive, which reduces the application gateway’s overhead with client communications. Both protocols are designed to work over ports 80 and 443, so you can easily incorporate them into an environment without making firewall changes.

Design concepts and deployment considerations

Azure Application Gateway consists of a number of components that come together to filter traffic and provide secure routing services for your web applications. The main components of the Azure Application Gateway service are as follows (see Figure 2-3):

Front-end IP addresses

Back-end pools

Listeners

Request routing rules

HTTP settings

Health probes

FIGURE 2-3 Azure Application Gateway components.

It is important to have a solid understanding of each of these components to be able to design and deploy them appropriately based on your environment’s requirements. In addition, you should have a strong grasp of sizing and scaling as well as TLS policy. This section covers all of these topics.

Front-end IP addresses

A front-end IP address is the ingress point for the application gateway to receive web application traffic. It is referenced in the internal and/or public DNS and used to route application traffic. The front-end IP address can be an internal private IP address, a public IP address, or both.

If a private IP address is to be used, the gateway should be deployed in the same region as the vNET with which it is associated. Similarly, you should create any public IP that must be associated as the front-end IP address in the same region as the application gateway.

The application gateway supports both static and dynamic IP addresses for the private and public IP addresses. However, based on the SKU of the gateway, the support varies for each. SKU v1 supports dynamic public IP addresses and static or dynamic private IP addresses; there is no support for static public IP addresses. SKU v2 supports static and dynamic private and public IP addresses. You cannot set up a static private IP address along with a dynamic public IP address, but you can set up a static public IP address with a dynamic private IP address if required.

Note

In general, if the gateway is stopped or started, the dynamic IP address changes. However, the dynamic IP address is retained if the gateway restarts due to failure or during upgrades or Azure host updates.

Pro-tip

Use the application gateway DNS name as a CNAME record in any public or internal DNS zones. This name does not change unless the application gateway is deleted.

Back-end pools

Back-end pools are back-end servers or services to which web traffic requests from clients are routed. They serve the client request with the required application response via the application gateway.

Back-end pools support the following types of services:

Virtual network interfaces

Virtual machine scale sets (VMSS)

Public IP addresses associated with Azure virtual machines (VMs) or services

Internal IP addresses associated with Azure or on-premises servers or services

Fully qualified domain names (FQDNs)

Azure services, such as App Service

Back-end pools can be located across Azure regions, across different clusters, or outside Azure in a client’s or third-party datacenter. As long as the application gateway can reach the back-end endpoint over TCP/IP, it can serve as a front-end to that web application.

For communications with on-premises servers, a VPN gateway or Azure ExpressRoute connection is necessary. For communication with Azure VMs and services over their private internal IPs, vNET peering or VPN gateway integration is needed.

Note

A single application gateway can support different types of back-end pools to address different web application requirements and scenarios.

Listeners

Every application gateway requires a minimum of one listener and can contain multiple listeners. A listener helps you define the protocol, port, hostname, and source IP address that is allowed to communicate with the back-end pool. Based on the configuration of the listeners defined on the application gateway, traffic is passed through or dropped. If the listener allows traffic through, the gateway evaluates it against routing rules configured to route traffic to the correct back-end pool.

There are two types of listeners:

Basic A basic listener can listen for requests only for a single domain.

Multi-site A multi-site listener can listen to requests for multiple host names or domain names. This type of listener can support more than 100 websites, which you can route to their own back-end pool.

Both types of listeners support the following ports:

SKU V1 Ports 1 – 65502

SKU V2 Ports 1 – 65199

In addition, they support the following protocols:

HTTP

HTTPS

HTTP/2

WebSocket

There are a few caveats to be aware of, as follows:

WebSocket protocol support is enabled by default and cannot be turned off.

HTTP/2 protocol support is disabled by default and must be turned on manually.

HTTP/2 protocol support is limited to the client and application gateway communications. Any back-end communications occur over HTTP/1.1.

Request routing rules

A request routing rule defines how traffic received by the application gateway should be routed. It binds the listener to a back-end server pool based on the HTTP settings defined to monitor in the request. One listener can be attached to only one rule.

Routing to the back-end pool depends on the rule configuration that defines which back-end pool binds to which URL or URL path. The routing rule also specifies whether any request must be rewritten before being routed to the back-end pool.

There are two types of request routing rules:

Basic A basic request routing rule forwards all traffic to the associated back-end pool based on the HTTP settings associated with the rule.

Path-based A path-based request routing rule analyzes the URL path in the request to identify the back-end pool to which to route the request. The rule contains different URL paths, set up to route to different back-end pools. If the incoming request does not match any of the rules, the traffic is routed to the default back-end pool based on associated HTTP settings.

A request routing rule is evaluated based on the priority assigned to that rule. By default, the priority is automatically assigned based on the order of rule creation (unless a specific priority is provided at the time of rule creation or set later on).

It is important to take priority into consideration in case there are rules that contain domains that overlap—for example, *.fabrikam.com and blogs.fabrikam.com. In such cases, wildcard rules should be lower in priority to ensure the individual domain rules are evaluated before the wildcard rules. Otherwise, requests will be routed to the back-end pools associated with the wildcard domains only.

Redirection support

In addition to routing traffic to back-end pools, request routing rules can be set up to redirect traffic to and from any port to a redirection target. The redirection could be to another listener or an external site. Redirection routing helps redirect HTTP traffic to HTTPS, or traffic from a standard web port (such as 80) to a non-standard port.

Azure Application Gateway supports different types of redirection:

310 Permanent Redirect

302 Found

303 See Other

307 Temporary Redirect

Rewriting of HTTP headers and URLs

Azure Application Gateway allows HTTP request and response headers to be modified before the packet is sent to the back-end pool. So, the URL can be rewritten with custom security header fields, removing sensitive header information such as port information on X-Forwarded-For (XFF) headers. This feature can apply these changes only when certain conditions are met, so you can target rewrites to address any complex scenario as required.

HTTP settings

HTTP settings define the back-end servers’ port number, protocol, encryption settings, and other details. The application gateway uses these settings to route traffic to back-end servers when it receives a matching request.

HTTP settings are also used to define other settings, such as the following:

Cookie-Based Session Affinity This setting instructs the gateway to use affinity to always route requests from the same client to the same hosts (assuming the host is online).

Connection Draining This setting instructs the application gateway to gracefully drain connections on back-end servers, as they may be taken down for maintenance.

Custom Health Probe This setting helps the gateway understand how it should validate the health of the back-end pool.

Health probes

Monitoring the health of back-end pool instances is a critical function. It helps the service decide which back-end pool instances are healthy and usable for request routing and which ones need to be taken out of service to avoid application outages. Health probes provide the application gateway with the hostname, URL path, probe interval, and failed response limits to help it identify unhealthy back-end pool instances. The application gateway performs health monitoring by default. However, custom health probes help the gateway target the right parameters to evaluate instance health. Therefore, it is highly recommended to define custom health probes for each individual back-end pool.

Sizing and scaling

The v1 SKU offers different gateway sizes:

Small Appropriate for test and dev scenarios.

Medium Appropriate for small environments with a few hundred users accessing a web application.

Large Recommended for most enterprise or multi-site scenarios, to handle higher loads.

With the v2 SKU, autoscaling is available, eliminating the need for different gateway sizes. In this case, you use manual scaling or auto-scaling configurations to handle load instead of attempting to determine the right instance size at the outset.

TLS policy

With Azure Application Gateway, you can offload SSL/TLS. This way, SSL connections from clients are terminated on the application gateway, and internal communications with the application back-end can be encrypted or unencrypted (thereby reducing overhead on instances of the application). If the back-end instances are set up to communicate with the application gateway in an unencrypted manner, application certificates can be deployed and managed only on the application gateway. This makes it easier to track, maintain, and update them.

A TLS policy defines the different TLS protocol versions and cipher suites to be used during a TLS handshake. The order of the ciphers specifies the order in which they are evaluated at the time of the handshake. There are two mechanisms to control this, as follows:

Using a predefined TLS policy Every application gateway interface includes three predefined TLS policies—each one defined to support different TLS protocol versions and cipher suites. The names of the policies indicate the dates on which they were introduced; it’s recommended that you use the newer ones.

Using a custom TLS policy If a predefined policy does not meet your requirements, you can customize a policy to include the TLS protocols and cipher suites (and their priority) based on your needs.

With both predefined and custom TLS policies, SSL 2.0 and 3.0 are set to disabled, and you cannot override this. However, with a custom policy, you can set up any of the three TLS protocol versions (v1_0, v1_1, or v1_2) as the minimum required version. You can also set up all three of these with no minimum requirement if needed.

Application gateway walkthrough

The following sections walk you through the process of creating an application gateway using the Azure Portal, Azure PowerShell, and the Azure CLI. If you are following along, be sure to select resources and resource names based on your environment, including a unique application gateway name for each of your deployments. Also be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft for these resources. Finally, to complete this walkthrough, you need to have created at least two back-end VMs with IIS web services to integrate with the Application Gateway. Microsoft provides Windows Server templates in the Azure Marketplace that install and set up IIS with the default configuration; alternatively, you can create a custom configuration based on your requirements.

Using the Azure Portal

To create an application gateway using the Azure Portal, follow these steps:

Log into the Azure Portal, type application gateway in the search box to locate the service, and select it from the list that appears.

Click Create or Create Application Gateway to start the Create Application Gateway wizard. (See Figure 2-4.)

FIGURE 2-4 Click Create Application Gateway.

In the Basics tab of the Create Application Gateway wizard (see Figure 2-5), enter the following information and click Next: Frontends:

Subscription Select the subscription to host the application gateway.

Resource Group Select the resource group you want to host the application gateway. Alternatively, click the Create New link and follow the prompts to create a new resource group.

Name Type a name for the application gateway. If the name you type is already in use, the wizard will prompt you to enter another name.

Region Select the Azure region in which you want to create the application gateway.

Tier Choose Standard V2.

Enable Autoscaling Select the Yes option button.

Minimum Instance Count Enter the minimum number of hosts to set up.

Maximum Instance Count Enter the maximum number of hosts to which the gateway should scale.

Availability Zone Leave this set to None.

HTTP2 Leave this set to Disabled.

Virtual Network Select an existing vNET for which you have created back-end VMs.

Subnet Select a subnet for the application gateway.

FIGURE 2-5 The Basics tab of the Create Application Gateway wizard.

In the Frontends tab of the Create Application Gateway wizard (see Figure 2-6), for Frontend IP Address Type, select the Public option button.

FIGURE 2-6 The Frontends tab of the Create Application Gateway wizard.

Under the Public IP Address box, click the Add New link.

On the Add a Public IP page, in the Name box, type a name for the public IP address. (See Figure 2-7.) Then click OK.

FIGURE 2-7 The Add a Public IP dialog box.

In the Frontends tab of the Create Application Gateway wizard, click Next: Backends.

In the Backends tab of the Create Application Gateway wizard (see Figure 2-8), click the Add a Backend Pool link.

FIGURE 2-8 The Backends tab of the Create Application Gateway wizard.

In the Add a Backend Pool dialog box (see Figure 2-9), enter the following information and click Add:

Name Type a name for the back-end pool.

Add Backend Pool Without Targets Click No.

Target Type Select Virtual Machine.

Target Select one of the VMs you created for this walkthrough.

FIGURE 2-9 The Add a Backend Pool dialog box.

In the Backends tab of the Create Application Gateway wizard (see Figure 2-10), verify that the back-end pool configuration is correct and click Next: Configuration.

FIGURE 2-10 The updated Backends tab of the Create Application Gateway wizard.

In the Configuration tab of the Create Application Gateway wizard (see Figure 2-11), click Add a Routing Rule to create a routing rule for incoming traffic.

FIGURE 2-11 The Configuration tab of the Create Application Gateway wizard.

In the Listener tab of the Add a Routing Rule settings (see Figure 2-12), enter the following information:

Rule Name Type a name for the rule.

Listener Name Type a name for the listener.

Frontend IP Select Public.

Protocol Select the protocol used by your application.

Port Type the port used by your application.

Listener Type Select the Basic option button.

Error Page URL Select the No option button.

FIGURE 2-12 The Listener tab in the Add a Routing Rule settings.

Click the Backend Targets tab (look ahead to Figure 2-13).

For Target Type, select the Backend Pool option button.

Open the Backend Target drop-down list and select the back-end pool target.

Under HTTP Settings, click the Add New link.

In the Add a HTTP Setting settings (see Figure 2-14), enter the following information and click Add. (Leave the other settings as is.)

HTTP Settings Name Enter a name for the HTTP settings.

Backend Protocol Select the back-end protocol used by the application.

Backend Port Type the back-end port used by your application.

Cookie-Based Affinity Select the Disable option button.

Connection Draining Select the Disable option button.

Request Time-Out (Seconds) Enter a request time-out value (in seconds) that reflects the responsiveness of your application.

FIGURE 2-13 The Backend Targets tab of the Add a Routing Rule settings.

FIGURE 2-14 The Add a HTTP Setting settings.

In the Configurations tab (see Figure 2-15), confirm that the configuration is correct and click Next: Tags.

FIGURE 2-15 The updated Configuration tab of the Create Application Gateway wizard.

In the Tags tab, enter any tags required for the application gateway or leave the fields blank (see Figure 2-16) and click Next: Review + Create.

FIGURE 2-16 The Tags tab of the Create Application Gateway wizard.

On the Review + Create tab (see Figure 2-17), review your settings, and click Create. You can now test whether your application is accessible by accessing the application gateway URL. (The URL will be visible in the application gateway’s Overview tab.)

FIGURE 2-17 The Review + Create tab of the Create Application Gateway wizard in the Azure Portal.

Using Azure PowerShell

You can create an application gateway using Azure PowerShell with the New-AzVirtualNetworkGateway and New-AzVirtualNetworkGatewayConnection commands and various switches to set the application gateway’s parameters. The following code shows you how. Use this snippet to create the same application gateway as you did in the Azure Portal. (Replace all the variables and on-premises firewall configuration as per your environment.) When you do, be sure to either delete the previous application gateway or give this new application gateway a different name:

Click here to view code image

#Define variables
$agSubnetConfig = New-AzVirtualNetworkSubnetConfig `
  -Name myAGSubnet `
  -AddressPrefix 10.21.0.0/24
$backendSubnetConfig = New-AzVirtualNetworkSubnetConfig `
  -Name myBackendSubnet `
  -AddressPrefix 10.21.1.0/24
New-AzVirtualNetwork `
  -ResourceGroupName myResourceGroupAG `
  -Location eastus `
  -Name myVNet `
  -AddressPrefix 10.21.0.0/16 `
  -Subnet $agSubnetConfig, $backendSubnetConfig
New-AzPublicIpAddress `
  -ResourceGroupName myResourceGroupAG `
  -Location eastus `
  -Name myAGPublicIPAddress `
  -AllocationMethod Static `
  -Sku Standard
#Create IP Config and front-end port
$vnet   = Get-AzVirtualNetwork -ResourceGroupName myResourceGroupAG -Name myVNet
$subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name myAGSubnet
$pip    = Get-AzPublicIPAddress -ResourceGroupName myResourceGroupAG -Name myAGPublicIPAddress
$gipconfig = New-AzApplicationGatewayIPConfiguration `
  -Name myAGIPConfig `
  -Subnet $subnet
$fipconfig = New-AzApplicationGatewayFrontendIPConfig `
  -Name myAGFrontendIPConfig `
  -PublicIPAddress $pip
$frontendport = New-AzApplicationGatewayFrontendPort `
  -Name myFrontendPort `
  -Port 80
#Create backend pool
$backendPool = New-AzApplicationGatewayBackendAddressPool `
  -Name myAGBackendPool
$poolSettings = New-AzApplicationGatewayBackendHttpSetting `
  -Name myPoolSettings `
  -Port 80 `
  -Protocol Http `
  -CookieBasedAffinity Enabled `
  -RequestTimeout 30
#Create listener and add rule
$defaultlistener = New-AzApplicationGatewayHttpListener `
  -Name myAGListener `
  -Protocol Http `
  -FrontendIPConfiguration $fipconfig `
  -FrontendPort $frontendport
$frontendRule = New-AzApplicationGatewayRequestRoutingRule `
  -Name rule1 `
  -RuleType Basic `
  -HttpListener $defaultlistener `
  -BackendAddressPool $backendPool `
  -BackendHttpSettings $poolSettings
#Create application gateway
$sku = New-AzApplicationGatewaySku `
  -Name Standard_v2 `
  -Tier Standard_v2 `
  -Capacity 2
New-AzApplicationGateway `
  -Name myAppGateway `
  -ResourceGroupName myResourceGroupAG `
  -Location eastus `
  -BackendAddressPools $backendPool `
  -BackendHttpSettingsCollection $poolSettings `
  -FrontendIpConfigurations $fipconfig `
  -GatewayIpConfigurations $gipconfig `
  -FrontendPorts $frontendport `
  -HttpListeners $defaultlistener `
  -RequestRoutingRules $frontendRule `
  -Sku $sku

Using the Azure CLI

You can create an application gateway using the Azure CLI with the az network vnet-gateway create command and various switches to set the application gateway’s parameters. The following Bash script shows you how. Use this snippet to create the same application gateway as you did in the Azure Portal. (Replace all the variables and on-premises firewall configuration as per your environment.) When you do, be sure to either delete the previous application gateway or give this new application gateway a different name:

Click here to view code image

#Define variables
#Create network
az network vnet create \
  --name myVNet \
  --resource-group myResourceGroupAG \
  --location eastus \
  --address-prefix 10.21.0.0/16 \
  --subnet-name myAGSubnet \
  --subnet-prefix 10.21.0.0/24
az network vnet subnet create \
  --name myBackendSubnet \
  --resource-group myResourceGroupAG \
  --vnet-name myVNet   \
  --address-prefix 10.21.1.0/24
az network public-ip create \
  --resource-group myResourceGroupAG \
  --name myAGPublicIPAddress \
  --allocation-method Static \
  --sku Standard
#Create application gateway
address1=$(az network nic show --name myNic1 --resource-group myResourceGroupAG | grep
"\"privateIpAddress\":" | grep -oE '[^ ]+$' | tr -d '",')
address2=$(az network nic show --name myNic2 --resource-group myResourceGroupAG | grep
"\"privateIpAddress\":" | grep -oE '[^ ]+$' | tr -d '",')
az network application-gateway create \
  --name myAppGateway \
  --location eastus \
  --resource-group myResourceGroupAG \
  --capacity 2 \
  --sku Standard_v2 \
  --public-ip-address myAGPublicIPAddress \
  --vnet-name myVNet \
  --subnet myAGSubnet \
  --servers "$address1" "$address2"

Best practices

Following are some recommended practices for deploying and managing your application gateway environment. These practices can help you make the most of your investment in this service:

Monitor and plan instance count to avoid resource crunch Azure Application Gateway v2 supports auto-scaling, but if you are using Azure Application Gateway v1, you will have to scale manually. The v1 SKU supports scaling up to 32 instances. To identify the right instance count, monitor CPU utilization for the application gateway for at least a month and identify the peak CPU usage. Then add a buffer of 15% to 20% to handle unexpected spikes and growth. Finally, select your instance count based on this sizing.

Upgrade to the v2 SKU as soon as possible As mentioned, Azure Application gateway v1 supports manual scaling only—which is not the most efficient or cost-effective way to manage your gateway instances. In addition to auto-scaling, the v2 SKU offers other performance benefits, including SSL/TLS offloading, improved deployment performance, zone redundancy, and many others. You should upgrade to the v2 SKU as soon as you can so you can benefit from all these (and other) features.

Set the maximum instance count in the v2 SKU Because the v2 SKU supports auto-scaling, and because charges are levied based on how many units are used, it is important to consider budgetary requirements when setting the maximum instance count. The v2 SKU supports a maximum of 125 instances—which means unplanned spikes can result in more instances being activated than are budgeted for.

Size the gateway subnet for future growth Size the subnet in which you plan to host application gateway instances to take into account future scalability requirements. Changes to the subnet configuration are not currently supported and require a redeployment of the service, resulting in possible disruption.

Set the minimum instance count for v2 SKU Bringing additional instances online to accept traffic when auto-scaling does take some time—usually between six and seven minutes. Any unexpected spikes during this period can result in traffic drops or higher response latency. You should monitor CPU usage for at least a month to identify the minimum instances required, and maintain a buffer of 15% to 20% to allow for unexpected spikes.

Monitoring and alerting Set up alerts for different gateway metrics to monitor CPU usage, instance scaling, and network utilization so you can be notified of any anomalies that might cause potential outages. Examples of alerts could include average CPU usage spiking by 75% to 80% for a sustained period of time, too many failed requests, gateway not responding, logs containing numerous 4xx or 5xx errors (indicating response issues), and too many unhealthy back-end hosts.

Set up geo-filtering to block unwanted countries/regions The v2 SKU supports geo-filtering, which enables you to allow or block traffic from specific countries or regions. It is a good practice to use this feature to prevent (or allow) traffic from certain locales to connect to your web applications to reduce your attack surface.

Set up bot protection to prevent attacks The v2 SKU has a feature to prevent traffic from known bot networks. Enable this feature to intercept known malicious traffic before it reaches your web applications.

Set up diagnostics logging and long-term retention Collect firewall, performance, and access logs for your application gateway instances and save them in Azure storage, Log Analytics, or an event stream. These logs can help you identify potential issues and take proactive action. Set up retention policies based on historical data storage comparison and compliance requirements for your organization.

Set up the latest TLS policy version for extra security Use the latest TLS policy version (currently AppGwSslPolicy20170401S) to enforce TLS 1.2 and stronger ciphers.

Chapter 3

Azure VPN gateway

Overview

A virtual private network (VPN) gateway is a device that you can use to connect different networks over the internet for secure communications. These can include on-premises networks connected to Azure virtual networks (vNETs) or one Azure vNET connected to another Azure vNET. IPSec/IKEv2 is used to encrypt traffic between networks. In Azure, the service to create VPN gateways is known as the virtual network gateway service.

Azure VPN gateway features

Following are some key concepts and benefits of using a VPN gateway in your Azure design:

Managed gateway When a VPN gateway is deployed in an Azure vNET, the Azure service provisions two or more VMs in an associated subnet called the gateway subnet. These VMs are set up with gateway routing services, route tables based on the configuration of the VPN tunnel, and the Azure vNET in which the gateway is provisioned. The Azure service itself sets up and manages these VMs; you cannot modify or otherwise manage them yourself.

High availability Each Azure vNET supports the use of only one VPN gateway. For high-availability, you can set up the gateway in an active-active architecture and connect it to multiple remote gateways at the same time. The total bandwidth available for use on the VPN gateway depends on its SKU and is shared across all active connections.

Coexistence with ExpressRoute gateway Azure supports two types of gateways: VPN gateways and ExpressRoute gateways. An ExpressRoute gateway enables secure connectivity to on-premises networks over a private connection; in contrast, the VPN gateway uses the public internet to connect networks. After you use the VPN gateway to establish an IPsec/IKE VPN tunnel between two sites, Azure creates routes in the route table based on the subnets defined in the VPN configuration or propagated automatically when the connection is established.

Note

A vNET can have one VPN gateway and one ExpressRoute gateway at the same time.

Support for remote work scenarios using a point-to-site VPN connection In addition to a site-to-site (S2S) VPN connection, a VPN gateway also allows you to create a point-to-site (P2S) VPN connection, using OpenVPN, IKEv2, or SSTP. This allows you to connect to the vNET directly over your home or remote network to access resources using their private internal IPs.

Support for availability zones Azure VPN gateway supports deployment in availability zones, bringing the scalability, resiliency, and redundancy features associated with availability zones to the VPN gateway. When a VPN gateway is deployed in an availability zone, it is physically and logically separated within a region, thereby protecting the service against zonal failures.

Support for Azure PowerShell, Azure CLI, and ARM templates In addition to using the Azure Portal to manage the VPN gateway, you can use Azure PowerShell, Azure CLI, and ARM templates.

Note

The Azure VPN gateway service uses Azure Blob storage to automatically replicate the system metadata and store it securely using encryption-at-rest features.

Design concepts and deployment considerations

Before setting up a VPN gateway, it is important to identify all your requirements for connectivity. This includes the end clients in scope, throughput required, protocols supported, on-premises firewall or VPN devices available, and support, resiliency, redundancy, and authentication mechanisms required.

After you’ve identified these requirements, you can use the following table to identify what will be the best solution, including the type of VPN connection (P2S or S2S), the gateway SKU, deployment models, protocols, and so on.

Point-to-Site

Site-to-Site

Azure-Supported Services

Cloud services and virtual machines (VMs)

Cloud services and VMs

Typical Bandwidths

Based on the gateway SKU

Typically < 1 Gbps aggregate

Protocols Supported

Secure Sockets Tunneling Protocol (SSTP), OpenVPN, and Internet Protocol Security (IPsec)

IPsec

Routing

Route-based (dynamic routing)

Policy-based (static routing) and route-based (dynamic routing)

Connection Resiliency

Active-passive

Active-passive and active-active

Typical Use Case

Secure access to Azure vNETs for remote users

Dev, test, and lab scenarios and small- to medium-scale production workloads for cloud services and VMs

The following sections discuss in more detail the various components and design elements to consider in order to design and deploy the most appropriate VPN solution for your environment.

VPN types

Azure supports two types of VPNs: route-based and policy-based. The type of VPN you select will depend on your VPN connection requirements. P2S connections support only route-based VPNs, whereas S2S connections support both route-based and policy-based VPNs.

Policy-based VPNs support only one VPN tunnel and require the use of the Basic SKU, so it has fewer use cases. In contrast, route-based VPNs support both P2S and S2S connections simultaneously, although other available features and tunnels depend on the gateway SKU.

There’s one more important difference between these VPN types: In a policy-based VPN, static routing is defined using an access list, whereas in a route-based VPN, routes are dynamically added (or removed) from the route table when a connection is established (or shut down).

Gateway SKUs

There are different SKUs available for VPN gateways. The one you choose will be based on your organization’s throughput, features, and SLA requirements.

The Basic SKU is recommended for test and dev workloads. Other SKUs, starting with VPNGw1, are recommended for production environments. Which of these SKUs you choose will depend on the feature set you require. For example, the VpnGw1AZ SKU supports availability zones, whereas the VpnGw2 SKU does not. However, the VpnGw2 SKU allows for greater throughput (1 Gbps compared to 650 Mbps).

You can switch between SKUs in the same generation. For example, you can switch from a VpnGw1 gateway to a VpnGw2 gateway. However, you cannot switch from a VpnGw1 gateway to a VpnGw2AZ gateway.

Note

You can upgrade a legacy Basic gateway to a VPNGw1 gateway, but you will have to delete the Basic gateway and then create a new VPNGw SKU gateway.

Connection types

VPN gateway devices support four connection types, as follows:

IPsec Use this to establish an S2S connection with an on-premises gateway device.

Vnet2Vnet Use this to interconnect two Azure vNETs using a VPN gateway.

ExpressRoute Use this when the gateway type is set to ExpressRoute to establish connections between secure private networks and Azure.

VPNClient Use this to establish a P2S connection between a client device and the VPN gateway device.

Gateway subnet

Before you provision a VPN gateway, you need to create a special subnet, called a gateway subnet, to host it. The gateway subnet is set up as part of the Azure vNET address space. It can be a subnet as small as /29, but it is generally recommended to size it to /26 or /27 to handle active-active configuration scenarios that require the deployment of additional VMs to handle redundancy.

Border Gateway Protocol (BGP)

Border Gateway Protocol (BGP) is a standard routing protocol that supports route exchange between connected networks called BGP peers or neighbors. This requires both ends of the connection to support BGP; its use with Azure VPN gateways is optional.

The primary advantages of using BGP are as follows:

Dynamic routing BGP enables the Azure VPN gateway to support dynamic routing. Route exchange can then occur to update either end of the connection, in the event modifications to the routing paths occur due to network changes or outages.

Better control over network access BGP allows you to declare only the IP address prefixes to which you want to give access instead of opening access to the entire IP address prefix in the on-premises or Azure network. This allows you to better control traffic between both sites.

Support for multiple active tunnels After you set up BGP on the on-premises network, you can set up multiple active-active or active-standby connections to the on-premises network or Azure network to increase redundancy and resiliency in both environments. Traffic is automatically routed via the active tunnels on either end.

Support for transit routing Regardless of whether networks are connected to each other directly or indirectly, BGP enables gateways to automatically learn and propagate IP address prefixes across all networks. This enables you to set up transit routing between the Azure VPN and on-premises networks and other interconnected networks.

Local network gateways

Local network gateways are gateways set up in Azure that represent your on-premises gateway device and corresponding networks. It is referenced in the gateway configuration when you set up the VPN tunnel. Generally, you need only define the public IP address of the on-premises VPN gateway, the shared secret to use for the connection, and the IP address prefixes to allow from the on-premises network.

However, if you use BGP, additional configuration is required. Specifically, you must define a BGP peer IP address and an autonomous system number (ASN). You need not, however, define the IP address prefixes located in the on-premises network; BGP allows these IP ranges to be added to the route table in Azure automatically.

VPN gateway redundancy

Even when you deploy Azure VPN gateway without the active-active configuration, the service deploys two VPN instances in an active-standby configuration to facilitate any planned or unplanned events that might hamper the functioning of the active instance.

While the switchover to the standby instance is automatic, it does cause a brief interruption in service as all the S2S VPN tunnels are re-established. In a planned maintenance scenario, this can take up to 15 seconds, but might be longer if the outage is unplanned. In that scenario, it can take up to 3 minutes to bring the VPN services back online.

Be aware that any active P2S connections are dropped during such an event, and they are not reestablished automatically. Rather, the end client must initiate the reestablishment of the connection.

Deployment models

VPN gateway connections support different deployment models. You select a deployment model based on your organization’s security, redundancy, and connectivity requirements. To help you make a more-informed decision, the following sections review these deployment models.

Note

The following sections cover basic topologies for each scenario, but more complex configurations are possible. Use each of the topology diagrams in these sections as an initial reference point rather than as a set limitation for various use cases.

Site-to-site VPN gateway connections

You set up a site-to-site (S2S) VPN gateway connection over IPsec/IKE to connect on-premises gateway devices to Azure VPN gateway devices. Both the on-premises gateway device and the Azure gateway device must be associated with a public IP address. You can configure an Azure VPN gateway in active-standby mode or active-active mode, depending on your redundancy requirements and cost limitations.

Single-site active-standby mode

In an active-standby configuration, both tunnels are configured as online, but only one tunnel is active; the other is in standby mode. (See Figure 3-1.) If the active tunnel goes down, the standby tunnel becomes active and is then used to route traffic.

FIGURE 3-1 Single-site active-standby mode.

Multi-site active-Active mode

A variation on the S2S VPN gateway connection is a multi-site VPN connection in which a single active VPN gateway in Azure is connected to multiple on-premises devices in different sites. (See Figure 3-2.) This requires the use of a route-based VPN type, so it does not work with the Basic VPN gateway SKU. The overall throughput available to the gateway device (which is based on its SKU) is shared across all the established connections.

FIGURE 3-2 S2S VPN with multiple on-premises sites.

High Availability (HA) in active-standby mode

In this scenario, the Azure VPN gateway is simultaneously connected to two VPN devices in the same on-premises location. (See Figure 3-3.) The same routes are propagated over both connections, and traffic is routed to the on-premises network using both connections to increase the throughput to the on-premises network. (Note that both on-premises devices must support the use of BGP.) Throughput on the Azure end is restricted based on the gateway SKU selected.

FIGURE 3-3 HA in active-standby mode.

active-active mode

To set up active-active mode, you set the Azure VPN gateway to active-active mode. This results in multiple active connections to the Azure VPN gateway from each on-premises location, and traffic is routed through all of them. (See Figure 3-4.) If any tunnel goes offline, traffic is automatically switched to a tunnel that is still active. This must be set up on both the Azure end and on the on-premises end to ensure that routes involving the inactive tunnel are diverted and removed automatically. (Note that BGP is required for both the Azure gateways and the on-premises ones for route propagation.) This mode increases redundancy and resiliency on the Azure end and ensures there is no disruption in services during planned or unplanned maintenance activities in Azure.

FIGURE 3-4 Azure VPN Gateway in active-active mode.

HA in active-active mode

With this “full mesh” mode, two Azure gateways are connected to two on-premises gateways. Any failure in any device on either end will automatically result in the routing of traffic via devices that are still active. (Note that BGP is required for route propagation.) In the scenario shown in Figure 3-5, four S2S tunnels are used. It is important to take this into consideration when choosing gateway SKUs and the limits associated with each.

FIGURE 3-5 On-premises to Azure VPN gateway connectivity in HA.

Note

This is the recommended design to adopt if it meets your requirements. This design ensures maximum redundancy on both the Azure and on-premises network.

Point-to-site VPN gateway connections

P2S VPN gateway connections help organizations address work-from-home or remote-work scenarios in which employees must be able to securely connect and access internal resources hosted in Azure or on interconnected on-premises networks. With P2S connections, devices need not be directly connected over a public IP. Client devices simply require an active internet connection and the ability to connect to the Azure endpoint over SSL.

Supported protocols

The following protocols are supported for P2S connections:

OpenVPN Protocol The OpenVPN protocol is an SSL/TLS-based VPN protocol that works over most firewalls because it requires only port 443 (which most firewalls leave open). You can use the OpenVPN protocol to connect from Android, iOS (versions 11.0 and above), Windows, Linux, and Mac devices (macOS versions 10.13 and above).

Secure Socket Tunneling Protocol (SSTP) SSTP is a proprietary TLS-based VPN protocol. Like the OpenVPN protocol, SSTP works over most firewalls because it requires only port 443. The difference: Only Windows devices use SSTP. Azure supports all versions of Windows that have SSTP and support TLS 1.2 (Windows 8.1 and later).

IKEv2 VPN IKEv2 VPN is a standards-based IPsec VPN protocol that can be used to connect from Windows, Android, iOS, and Mac devices (macOS versions 10.11 and above).

Authentication

P2S VPN gateway connections (see Figure 3-6) support three types of authentication mechanisms:

Remote Authentication Dial-In User Service (RADIUS) authentication This requires integration with a RADIUS server for successful authentication.

Native Azure certificate authentication This involves the generation of an enterprise certificate or a self-signed certificate, deployed to the Azure device and to the various end clients to use as part of their connection request.

Native Azure AD authentication This requires the use of the OpenVPN protocol, Windows 10– and Windows 11–based clients, and the Azure VPN client.

FIGURE 3-6 P2S VPN Gateway tunnels.

vNET-to-vNET connections (IPsec/IKE VPN tunnel)

Connecting two Azure vNETs using a VPN gateway on either end establishes a vNET-to-vNET connection. This is similar to connecting an Azure VPN gateway to an on-premises network gateway device but enables you to connect Azure vNETs in the same or different regions, in the same or different subscriptions, and in the same or different deployment models (classic and ARM). (See Figure 3-7.)

FIGURE 3-7 Azure vNET-to-vNET connections using VPN gateway.

Highly Available vNET-to-vNET

Similar to the full-mesh S2S HA in active-active mode, the vNET-to-vNET design supports an active-active gateway between two vNETs. (See Figure 3-8.) This allows for the establishment of four tunnels between the two VPN gateways connected to two vNETs to provide higher availability and resiliency. (Note that BGP is optional in this setup unless transit routing is required.)

FIGURE 3-8 Highly available Azure vNET-to-vNET connections using VPN gateways.

ExpressRoute

This book does not discuss ExpressRoute in detail. Still, it is important to know that ExpressRoute is a connectivity option available for your environment, based on your use case. ExpressRoute allows you to extend your on-premises networks with the help of a connectivity provider directly into the Microsoft cloud over a private connection.

Note

Connections to Microsoft cloud services are not limited to Microsoft Azure. Connectivity to other Microsoft services such as Microsoft 365 and Dynamics 365 is also allowed.

With ExpressRoute, all connectivity occurs over a private network with the most stringent possible SLAs. This makes ExpressRoute connections more secure and reliable than S2S VPN connections. ExpressRoute also provides higher throughputs and lower latency, making it ideal for large organizations and for organizations whose security and compliance requirements call for its use.

ExpressRoute and site-to-site VPN gateways can co-exist on the same Azure vNET and can be implemented with an active-failover design, such that issues with ExpressRoute will result in an automated failback to the S2S VPN. The other option is to leverage S2S VPNs for sites that are not covered by ExpressRoute connections. It is important to be aware of this compatibility so that you can take it into account when designing for larger environments in which reliability and redundancy are critical for business.

Zonal and zone-redundant VPN gateways

Azure VPN gateway devices support deployment in Azure availability zones. This extends all the redundancy, scalability, and availability features of availability zones to the vNET gateway devices. When gateway devices are deployed in Azure availability zones, they are separated physically and logically within an Azure region to protect against zone-level failures.

There are two options for availability zones:

Zonal gateways When a VPN gateway is deployed in an availability zone and the availability zone configuration is specified, all instances of the gateway are deployed in that same availability zone. These are called zonal gateways.

Zone-redundant gateways If the availability zone configuration is set to automatic, the VPN gateway is deployed across availability zones, making them zone-redundant to provide higher resiliency.

Note

The two VPN gateway instances will be deployed in any two out of the three availability zones in a region.

Azure VPN gateway walkthrough

The following sections walk you through the process of creating an Azure VPN gateway using the Azure Portal, Azure PowerShell, and the Azure CLI. If you are following along, be sure to select resources and resource names based on your environment, including a unique Azure VPN gateway name for each of your deployments. Also be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft for these resources.

Using the Azure Portal

To create an Azure VPN gateway using the Azure Portal, follow these steps:

Log into the Azure Portal, type virtual network gateway in the search box to locate the service, and select it from the list that appears. (See Figure 3-9.)

FIGURE 3-9 Selecting the virtual network gateway in the Azure Portal.

Click Create or Create Virtual Network Gateway to start the Create Virtual Network Gateway wizard. (See Figure 3-10.)

FIGURE 3-10 Creating the virtual network gateway.

In the Basics tab of the Create Virtual Network Gateway wizard (see Figure 3-11), enter the following information and click Next:

Subscription Select the subscription to host the vNET gateway.

Name Type a name for the vNET gateway. If the name you type is already in use, the wizard will prompt you to enter a different name.

Region Select the Azure region in which you want to create the VPN gateway.

Note

Selecting an Azure region automatically populates the Resource Group setting.

Gateway Type Select the VPN option button.

VPN Type Select the Route-Based option button.

SKU Choose the VpnGw1 SKU. Alternatively, for higher throughput, choose a higher SKU.

Generation Select the SKU’s generation. (The options available will depend on the SKU you choose.)

Virtual Network Select the virtual network you want to use to host the VPN gateway. Alternatively, click the Create New link and follow the prompts to create a new vNET.

Gateway Subnet Address Range Enter an address range for the gateway subnet. This will be used to assign a private IP address to your VPN gateway.

Public IP Address Select whether to create a new public IP address or use an existing one. If you want to select an existing IP, you will have to ensure that it is a static public IP on the Standard SKU.

Note

If you select the Create New option button, you’ll need to add a unique name for the new public IP address in the Public IP Address Name box. If the name you type is already in use, the wizard will prompt you to enter a different one.

Enable Active-Active Mode Select the Disabled option button.

Configure BGP Select the Disabled option button (unless BGP is required for the on-premises firewall that you will integrate).

FIGURE 3-11 The Basics tab of the Create Virtual Network Gateway wizard.

In the Tags tab (see Figure 3-12), enter any tags required for the vNET gateway or leave the fields blank. Then click Next: Review + Create.

FIGURE 3-12 The Tags tab of the Create Virtual Network Gateway wizard.

On the Review + Create tab (see Figure 3-13), review your settings and click Create.

FIGURE 3-13 The Review + Create tab of the Create Virtual Network Gateway wizard in the Azure Portal.

Azure builds the new vNET gateway. Be aware that this can take 30 to 45 minutes.

After Azure builds the new vNET gateway, click Go to Resource.

In the left pane of the vNET gateway’s configuration blade, click Connections. (See Figure 3-14.)

FIGURE 3-14 Creating connections in the vNET gateway.

Click Add to create a new site-to-site VPN tunnel.

The Add Connection options open. (See Figure 3-15.)

FIGURE 3-15 The Add Connection options.

In the Name box, enter a unique name for the connection. If the name you type is already in use, the dialog box will prompt you to enter a different name.

Open the Connection Type drop-down list and select Site-to-Site (IPsec).

The Azure service automatically adds the vNET gateway. Now you need to create a new local network gateway to contain the details of your on-premises firewall.

In the Add Connection options, click Local Network Gateway.

Under Choose Local Network Gateway, click Create New. (See Figure 3-16.)

FIGURE 3-16 Creating a new local network gateway.

In the Create Local Network Gateway options (see Figure 3-17), enter the following information. Then click OK:

Name Enter a unique name for the local network gateway. If the name you type is already in use, you will be prompted to enter a different name.

Endpoint Choose IP Address or FQDN, depending on your on-premises firewall requirements.

IP Address Enter the IP address for the on-premises firewall that you will integrate with.

FIGURE 3-17 Creating a local network gateway.

Note

The IP address shown in Figure 3-18 is for illustrative purposes only. It is not available for integration.

Address Space Enter the address space for the on-premises networks that should be allowed to connect to Azure resources via this VPN connection.

Back in the Add Connection options, enter the following information and click OK:

Shared Key (PSK) Enter the shared key that will be used to connect with the on-premises firewall.

Use Azure Private IP Address Leave this unchecked.

Enable BGP Leave this unchecked unless your on-premises firewall supports BGP.

IKE Protocol Select the IKE protocol that is suitable for your on-premises firewall.

Ingress NAT Rules Leave this at the default setting.

Egress NAT Rules Leave this at the default setting.

After Azure creates the connection, click the Download Configuration button in the connection’s blade. (See Figure 3-18.) This downloads the instructions for setting up your on-premises firewall with the VPN gateway in Azure.

FIGURE 3-18 Downloading the instructions to set up the on-premises firewall with the VPN gateway in Azure.

Follow the instructions you just downloaded to configure the on-premises firewall.

After you configure the on-premises firewall, Azure changes the status of the connection to Connected. (See Figure 3-19.)

FIGURE 3-19 The status of the connection is Connected.

Using Azure PowerShell

You can create a vNET gateway and connection using Azure PowerShell with the New-AzVirtualNetworkGateway and New-AzVirtualNetworkGatewayConnection commands and various switches. The following code shows you how. Use this snippet to create the same VPN gateway and connection as you did in the Azure Portal. (Replace all the variables and on-premises firewall configuration as per your environment.) When you do, be sure to either delete the previous vNET gateway or give this new vNET gateway a different name:

Click here to view code image

#Define variables
$rg = "RG01"
$location = "East US"
$vpngwname = "TTL_MA-GW"
$vnet = "vNET01"
#Create GatewaySubnet
Add-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.0.1.0/24
-VirtualNetwork $vnet
#Create public IP for VPNGW
$gwpip= New-AzPublicIpAddress -Name TTL-MA-GW-PIP -ResourceGroupName $rg -Location
$location -AllocationMethod Dynamic
#Create VPNGW configuration
$subnet = Get-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -VirtualNetwork $vnet
$vpngwipconfig = New-AzVirtualNetworkGatewayIpConfig -Name vpngwipconfig1 -SubnetId
$subnet.Id -PublicIpAddressId $gwpip.Id
#Create the VPN GW
New-AzVirtualNetworkGateway -Name $vpngwname -ResourceGroupName $rg -Location $location
-IpConfigurations $gwipconfig -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1
#Create Local Network Gateway
$local = New-AzLocalNetworkGateway -Name DC1 -ResourceGroupName $rg -Location $location
-GatewayIpAddress 104.42.18.130 -AddressPrefix "10.104.0.0/24"
#Create site-to-site connection
New-AzVirtualNetworkGatewayConnection -Name MA-DC1 -ResourceGroupName $rg -Location
$location -VirtualNetworkGateway1 $vpngwname -LocalNetworkGateway2 $local -ConnectionType
Ipsec -RoutingWeight 10 -SharedKey 'abcde12345'

Using the Azure CLI

You can create a vNET gateway using the Azure CLI with the az network vnet-gateway create command and various switches to set the VPN gateway’s parameters. The following Bash script shows you how. Use this snippet to create the same VPN gateway as you did in the previous sections. (Replace all the variables and on-premises firewall configuration as per your environment.) When you do, be sure to either delete the previous vNET gateway or give this new vNET gateway a different name:

Click here to view code image

#Define variables
$rg = "RG01"
$location = "East US"
$vpngwname = "TTL_MA-GW"
$vnet = "vNET01"
#Create GatewaySubnet
az network vnet subnet create --vnet-name $vnet  -n GatewaySubnet -g $rg
--address-prefix 10.0.1.0/24
#Create public IP for VPNGW
az network public-ip create -n TTL-MA-GW-PIP -g $rg --allocation-method Dynamic
#Create VPNGW gateway
az network vnet-gateway create -n $vpngwname -l $location --public-ip-address
TTL-MA-GW-PIP -g $rg --vnet $vnet --gateway-type Vpn --sku VpnGw1 --vpn-type RouteBased
--no-wait
#Create Local Network Gateway
az network local-gateway create -g $rg -n DC1 --gateway-ip-address 104.42.18.130 --local-
address-prefixes 10.104.0.0/24
#Create site-to-site connection
az network vpn-connection create --name MA-DC1 --resource-group $rg --vnet-gateway1
$vpngwname -l $location --shared-key abcde12345 --local-gateway2 DC1

Best practices

Following are some best practices for maintaining and managing Azure VPN gateways:

Enable logging for VPN gateway routing activities VPN gateway logs all network traffic that it processes for customers. However, you should also activate NSG flow logging to capture and monitor this traffic for better visibility and management.

Set up resource logging Use Azure Security Center and Azure Monitor to capture all activity logs for the VPN gateway to assist in investigations when required.

Standardize with Azure Policy Azure Policy helps in standardizing the Azure environment to match company policies and standards for workload deployment and maintenance. Use Azure Policy to ensure that VPN gateways are deployed in line with those standards.

Perform penetration testing Conduct regular penetration-testing attacks against the VPN gateway to identify weaknesses or possible loopholes. These controlled simulations can help you proactively identify and address weaknesses and defend the company from breaches and attacks.

Integrate with Log Analytics for long-term log retention Integrate Azure VPN gateway devices with Azure Log Analytics workspaces to store VPN gateway logs for an extended duration to facilitate historical analysis of network patterns, trends, and planning.

Integrate with SIEM for security monitoring Azure VPN gateway has no built-in features to monitor or manage security. To monitor VPN gateway traffic logs for security breaches and threats, you need to forward those logs to a security information and event management (SIEM) solution, such as Azure Sentinel or a third-party provider.

Chapter 4

Azure Load Balancer

Overview

Azure provides a load balancer service that enables you to build scalable application architectures with multiple application or web servers where client traffic is distributed based on different algorithms suitable for your environment. The Azure Load Balancer service works on layer 4 of the OSI model to provide secure load balancing for internal applications from the public internet and internal networks.

You can deploy two types of load balancers in Azure (see Figure 4-1):

Public load balancer A public load balancer helps you securely publish internal applications or web servers or services to internet-based clients without exposing the back-end service or virtual machine (VM) directly. Clients connect to the public load balancer and, based on the load-balancing algorithm defined on the load balancer, traffic is routed to the appropriate back-end service.

Internal load balancer An internal load balancer helps you provide secure access to internal applications, web servers, or services to internal-only clients. The clients can be connected directly to the virtual network (vNET) in Azure or via hybrid-connectivity solutions such as a site-to-site (S2S) VPN, point-to-site (P2S) VPN, or ExpressRoute. Direct public access to the load balancer is not possible.

FIGURE 4-1 Public and internal load balancers.

Azure Load Balancer features

Following are some key concepts and benefits of using the Azure Load Balancer service:

Support for both public and internal load-balancing options Azure Load Balancer supports both public and internal-only load-balancing options, which enables it to address various application scenarios that may or may not require public exposure.

Highly scalable Azure Load Balancer is highly scalable. The service scales up automatically as connection requests to back-end services increase.

Support for availability zones The standard Azure Load Balancer supports the use of availability zones to enhance the service’s resiliency and availability.

Secure access by default The standard Azure Load Balancer is designed to block all incoming traffic by default unless traffic is explicitly allowed through the use of network security groups (NSGs). The basic Azure Load Balancer, on the other hand, is open to public networks by default and requires configuration to block incoming traffic.

Outbound traffic management You can use Azure Load Balancer to manage egress of all outbound traffic from VMs and to better control that traffic.

Support for multiple load-balancing algorithms There are multiple load-balancing algorithms available to define the most appropriate routing method for your application. You can switch from one load-balancing algorithm to another as the needs of your application evolve.

Support for IPv6 Azure Load Balancer supports IPv6 connectivity availability. So, you can set up Azure Load Balancer to accommodate applications that require IPv6 for client connectivity.

Support for multiple ports and IP addresses Azure Load Balancer supports the use of multiple IP addresses and ports to load-balance traffic for multiple application back ends.

Support for TCP and UDP flows Azure Load Balancer supports both TCP and UDP traffic load balancing.

Design concepts and deployment considerations

It is important to understand the different components that comprise Azure Load Balancer to appropriately design and deploy it for your various application requirements. The following sections review each of these components in more detail.

Note

Azure Load Balancer supports the use of the Azure Portal, Azure PowerShell, the Azure CLI, and ARM Templates for deployment and management.

Front-end IP address

As mentioned, Azure Load Balancer works with both public and internal-only access. To support these scenarios, you can set up the load balancer with either a public IP address or a private IP address. The IP address you assign dictates whether the load balancer is a public or an internal load balancer, as this is the ingress point for your clients to connect to the application or service.

Note

Both basic and standard load balancers support the use of public or private IP addresses. You determine which will work based on your application’s requirements.

Multiple front ends

A load balancer can support multiple front ends, but they have to all be of the same type. For example, if a load balancer has been set up as an internal load balancer, additional IP addresses assigned to it must be internal, too. The same applies to a public load balancer. Incoming traffic is routed based on defined load-balancing rules. In other words, the load balancer identifies the source, protocol, ports, and destination requirements of incoming traffic to select the appropriate back end.

Back-end pool

The back-end pool refers to the VM scale set (VMSS) or VMs that are hosting the web service or application that you want to route traffic. As you add more instances of VMs to the back-end pool, the load balancer automatically incorporates those into its algorithm and routes traffic to the new instances based on routing logic defined in the rules.

In the case of a VMSS, this routing recalculation is automatic, as the VMSS adds or removes instances dynamically. With VMs, the recalculation occurs when you add or remove a VM from the back-end pool.

Health probes

Health probes define parameters that Azure Load Balancer must use to determine the health status of instances in the back-end pool. Depending on the type of load balancer provisioned, the types of health probes supported are as follows:

Standard load balancer TCP, HTTP, and HTTPS

Basic load balancer TCP and HTTP

Health probe parameters include the frequency, expected responses, and thresholds to help the load balancer determine when a back-end instance is unhealthy. In such cases, the load balancer stops routing new traffic to the unhealthy instance until subsequent health probes confirm that the instance is once again in a healthy state.

Be aware that with a standard load balancer, any connections that already exist will continue to be routed to the unhealthy instance until the flow is disconnected, terminated, or times out. With a basic load balancer, however, when the instance is deemed unhealthy, TCP flows are disconnected regardless of the connection state.

Load-balancing rules

Load-balancing rules dictate how ingress traffic is managed based on the source IP, source port, destination IP, destination port, and IP protocol details in the connection flow. The rule connects a front-end IP address, public or private, and a port to multiple back-end IP addresses and ports. (See Figure 4-2.) The load-balancing algorithm selected is used thereafter to route the traffic to the back-end pool. Be aware that all load-balancer front-end and back-end endpoints must reside in the same Azure vNET. vNET spanning is not supported.

FIGURE 4-2 Public and internal load-balancer rules.

Note

ICMP is not a supported protocol.

High-availability (HA) ports load-balancing rule

The high-availability (HA) ports load-balancing rule instructs the Azure service that all traffic for all protocols on all ports must be routed in a load-balanced manner, regardless of the port number. This rule is configured when the protocol is set to all, and front-end and back-end ports are set to 0. With this rule, load-balancing decisions are still made per flow based on the five-tuple connection logic that includes the source IP address, source port, destination IP address, destination port, and protocol. (See Figure 4-3.)

FIGURE 4-3 Azure internal load balancer with HA rules.

Inbound network address translation (NAT) rules

You can set up inbound network address translation (NAT) rules to forward incoming traffic to a specific back-end VM based on the combination of the front-end IP address and the port. (See Figure 4-4.) Traffic can be routed to one or more VMs in a VMSS as part of a NAT pool setup.

FIGURE 4-4 Inbound NAT rules.

Outbound source network address translation (SNAT) rules

You can set up a standard public load balancer with outbound source network address translation (SNAT) rules for all back-end VM or VMSS resources for any internet-bound egress traffic as well as traffic to other endpoints. (See Figure 4-5.) This helps present the public IP of the load balancer to any external endpoint without exposing IP address information associated with the back-end instance itself.

FIGURE 4-5 Outbound SNAT rules.

You can set up a public IP prefix to provide the load balancer with a public IP pool. This can then be used to scale the number of outbound connections across all IPs and ports. You can also map back-end resources to individual public IP addresses or set them up to use any IP address in the pool to prevent port exhaustion. This improves redundancy and scalability.

Note

Basic load balancers do not support outbound SNAT rules. Standard internal load balancers do not support outbound SNAT rules for internet routing.

Load-balancing algorithms

There are two load-balancing algorithms to route incoming traffic to back-end resources. Each algorithm provides a different level of redundancy and session persistence. The algorithm you select will depend on your use case. The two load-balancing algorithms are as follows:

Hash-based This algorithm generates a unique hash based on a combination of the source IP, source port, destination IP, destination port, and protocol type. Any connection from the same source IP using a different source port to the same application back end will result in a new hash, which might route traffic to a different back-end endpoint each time. This type of routing is useful in scenarios where the application does not require stickiness for all sessions originating from a particular client. It can also help improve responsiveness, as a larger number of sessions from a smaller number of source clients will be evenly distributed across a back-end pool.

Source IP affinity With this algorithm, traffic from the same source IP to the same destination IP, using the same protocol type, is routed to the same endpoint each time. This helps ensure that a back-end endpoint that is already managing active client sessions responds to any additional incoming client sessions with the same source IP, destination IP, and protocol. You can set up the source IP affinity algorithm to check the source IP and destination IP of incoming requests, or to check the source IP, destination IP, and protocol type, before determining which back-end instance the connection should be routed to.

Note

There are different use cases for the source IP affinity algorithm. One is when Azure Load Balancer is used to handle incoming client connections to Remote Desktop Gateway servers. Another is when the client application requires all client traffic to be directed to a single back-end endpoint for the duration of the session.

Availability zones

The standard Azure Load Balancer supports the use of availability zones to increase redundancy and availability in the event of a zone failure. You can set up availability zones to route traffic across zones, and to failover to a different active zone if a zone you are using goes offline.

You can set up Azure Load Balancer to use availability zones for redundancy in three ways:

Zone redundant If the Azure region on which Azure Load Balancer is deployed supports availability zones, you can set the front-end IP address as zone redundant. That way, if there is a failure within a zone, the IP address will survive it, and will route new incoming requests to the back-end pool. (Of course, this assumes there are resources in the back-end pool that are set up in a similar zone-redundant manner and are online in case of a zone failure.) It is recommended that you use a zone-redundant Azure Load Balancer for your production workloads.

Zonal With zonal redundancy, the load balancer is redundant within a single zone. If that zone experiences a failure, the load balancer does not failover to another zone. It remains offline for the duration of the zone’s outage. You might use zonal redundancy in scenarios in which different IP addresses are set up in different zones within a region to expose an application and use a traffic-management service like Azure Traffic Manager. In this case, traffic is routed across all zones, depending on their availability. This enables you to monitor the health and availability of each zone independently, as each front end in a zone has its own unique public IP.

Non-zonal Here, the load balancer is set up in a “no-zone” front-end configuration with zero redundancy. This is not a recommended configuration for production workloads.

Caution

Public IP addresses upgraded from basic to standard are non-zonal by default. You must take this into consideration if you perform such an upgrade.

Azure Load Balancer walkthrough

The following sections walk you through the process of creating an Azure Load Balancer using the Azure Portal, Azure PowerShell, and the Azure CLI. If you are following along, be sure to select resources and resource names based on your environment, including unique Azure Load Balancer and VM names. Also be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft for these resources.

Using Azure Portal

To create a public Azure Load Balancer using the Azure Portal, follow these steps:

Log into the Azure Portal, type load balancer in the search box to locate the service, and select it from the list that appears. (See Figure 4-6.)

FIGURE 4-6 Creating an Azure Load Balancer in the Azure Portal.

Click Create or Create Load Balancer to start the Create Load Balancer wizard. (See Figure 4-7.)

FIGURE 4-7 Creating the load balancer.

In the Basics tab of the Create Load Balancer wizard (see Figure 4-8), enter the following information and click Next:

Subscription Select the subscription to host the Azure Load Balancer.

Resource Group Select the resource group you want to host the Azure Load Balancer. Alternatively, click the Create New link and follow the prompts to create a new resource group.

Name Type a name for the Azure Load Balancer. If the name you type is already in use, the wizard will prompt you to enter a different name.

Region Select the Azure region in which you want to host the Azure Load Balancer.

SKU Select the Standard option button.

Type Select the Public option button.

Tier Select the Regional option button.

FIGURE 4-8 The Basics tab of the Create Load Balancer wizard.

In the Frontend IP Configuration tab of the Create Load Balancer wizard (see Figure 4-9), click Add a Frontend IP Configuration to create a front-end IP address.

FIGURE 4-9 The Frontend IP Configuration Tab in the Create Load Balancer wizard.

In the Add Frontend IP Address options (see Figure 4-10), enter the following information:

Name Enter a name for the front-end IP address. If the name you type is already in use, you’ll be prompted to enter a different name.

IP Version Select the IPv4 option button.

IP Type Select the IP Address option button.

Public IP Address Select an existing public IP address from the drop-down list. Alternatively, click the Create New link.

FIGURE 4-10 Add front-end IP address.

Clicking the Create New link opens the Add a Public IP Address options.

In the Add a Public IP Address options (see Figure 4-11), enter the following information and click OK:

Name Enter a name for your public IP address. If the name you type is already in use, you’ll be prompted to enter a different name.

Availability Zone Specify whether you want to set up an availability zone and, if so, which kind—in this case, Zone-Redundant.

Routing Preference Select the option button for your routing preference—in this case, Microsoft Network.

FIGURE 4-11 Adding a public IP address.

In the Add Frontend IP Address options, click OK. Then click Next in the Frontend IP Configuration tab in the Create Load Balancer wizard.

In the Backend Pools tab of the Create Load Balancer wizard (see Figure 4-12), click Add a Backend Pool.

FIGURE 4-12 The Backend Pools tab of the Create Load Balancer wizard.

In the Add Backend Pool options (see Figure 4-13), enter the following information:

Name Enter a name for the back-end pool. If the name you type is already in use, you’ll be prompted to enter a different name.

Virtual Network Select the vNET on which you want to create the back-end pool.

Backend Pool Configuration Select the NIC option button.

IP Version Select the IPv4 option button.

FIGURE 4-13 The Add Backend Pool settings.

Under Virtual Machines, click the Add button.

In the Add Virtual Machines to Backend Pool settings (see Figure 4-14), select the VMs you want to set up in the back-end pool.

FIGURE 4-14 Add virtual machines to the back-end pool.

Confirm that the VMs you selected are listed in the Virtual Machines section of the Add Backend Pool settings. (See Figure 4-15.) Then click Next.

FIGURE 4-15 The Add Backend Pool settings with the selected VMs listed.

In the Inbound Rules tab of the Create Load Balancer wizard (see Figure 4-16), click Add a Load Balancing Rule.

FIGURE 4-16 Creating inbound load-balancing rules.

In the Add Load Balancing Rule settings (see Figure 4-17), enter the following information:

Name Enter a name for the load-balancing rule. If the name you type is already in use, you’ll be prompted to enter a different name.

IP Version Select the IPv4 option button.

Frontend IP Address Select the front-end IP you created earlier.

Backend Pool Select the back-end pool configuration you created earlier.

Protocol Select the appropriate protocol—in this example, TCP.

Port Enter the port to use for load-balancing—in this case, 80.

Backend Port Enter the back-end port to use for load-balancing—again, 80.

Health Probe Click the Create New link.

FIGURE 4-17 Add the load-balancing rule.

In the Add Health Probe settings (see Figure 4-18), enter the following information and click OK:

Name Enter a name for the health probe. If the name you type is already in use, you’ll be prompted to enter a different name.

Protocol Select the appropriate protocol—in this example, HTTP.

Port Enter the port to use for testing—here, 80.

Path Enter the path to use for testing—in this case, /.

Interval Enter the interval to use for testing—in this example, 5.

Unhealthy Threshold Enter the threshold to determine whether an instance is unhealthy—here, 2.

FIGURE 4-18 The Add Health Probe settings.

Back in the Add Load Balancing settings, open the Session Persistence drop-down list and select the persistence you want to use. (See Figure 4-19.)

FIGURE 4-19 Selecting a Session Persistence option in the Add Load Balancing Rule settings.

Leave the rest of the settings in the Add Load Balancing Rule options as is and click Add.

In the Outbound Rules tab of the Create Load Balancer wizard (see Figure 4-20), leave the default settings as is, and click Next.

FIGURE 4-20 The Outbound Rules tab in the Create Load Balancer wizard.

In the Tags tab of the Create Load Balancer wizard (see Figure 4-21), enter any tags required for the load balancer or leave the fields blank. Then click Next.

FIGURE 4-21 The Tags tab in the Create Load Balancer wizard.

On the Review + Create tab, review your settings, and click Create.

Azure creates the load balancer.

After Azure builds the new load balancer, click Go to Resource.

In the left pane of the load balancer’s blade, click Frontend IP Configuration.

Click the link for the front-end IP address you just created to test whether your application’s load-balancing is working as expected. (See Figure 4-22.)

FIGURE 4-22 Front-end IP configuration.

Using Azure PowerShell

You can create a load balancer using Azure PowerShell with the New-AzLoadBalancer command and various switches. The following code shows you how. Use this snippet to create the same load balancer configuration as you did in the Azure Portal. (Replace all variables and configuration as per your environment.) When you do, be sure to delete the previous load balancer or give this new load balancer a different name:

Click here to view code image

#Define variables
$Region = 'eastus'
$RG = 'RG01'
$LBName = 'PublicLoadBalancer01'
$LBPIP = 'FrontendPIP01'
$BEPool = 'BackendPool01'
#Create zone redundant Public IP
$LBpublicip = @{
    Name = '$LBPIP'
    ResourceGroupName = 'RG01'
    Location = $location
    Sku = 'Standard'
    AllocationMethod = 'static'
    Zone = 1,2,3
}
New-AzPublicIpAddress @LBpublicip
#Create public load balancer
# Place public IP into a variable
$azlbpublicIp = Get-AzPublicIpAddress -Name $LBPIP -ResourceGroupName $RG
# Create load balancer front-end configuration
$azLBfrontend = New-AzLoadBalancerFrontendIpConfig -Name $LBPIP -PublicIpAddress
$azlbpublicIp
# Create back-end address pool configuration
$azlbbepool = New-AzLoadBalancerBackendAddressPoolConfig -Name $BEPool
# Create the health probe
$healthprobe = @{
    Name = 'HealthProbe-Port80'
    Protocol = 'http'
    Port = '80'
    IntervalInSeconds = '360'
    ProbeCount = '5'
    RequestPath = '/'
}
$httphealthprobe = New-AzLoadBalancerProbeConfig @healthprobe
# Create the load-balancer rule
$azloadbalancingrule = @{
    Name = 'LBRule-HTTP-01'
    Protocol = 'tcp'
    FrontendPort = '80'
    BackendPort = '80'
    IdleTimeoutInMinutes = '15'
    FrontendIpConfiguration = $azlbfrontend
    BackendAddressPool = $azlbbepool
}
$lbhttprule = New-AzLoadBalancerRuleConfig @azloadbalancingrule -EnableTcpReset
-DisableOutboundSNAT
## Create the load balancer
$loadbalancer = @{
    ResourceGroupName = $RG
    Name = $LBName
    Location = $Region
    Sku = 'Standard'
    FrontendIpConfiguration = $frontend
    BackendAddressPool = $azlbbepool
    LoadBalancingRule = $lbhttprule
    Probe = $httphealthprobe
}
New-AzLoadBalancer @loadbalancer
## Add VM01 to the back-end pool
$lb = Get-AzLoadBalancer `
    -ResourceGroupName $RG `
    -Name $LBName
$nic1 = Get-AzNetworkInterface `
    -ResourceGroupName $RG `
    -Name "VM01*"
$nic1.IpConfigurations[0].LoadBalancerBackendAddressPools=$lb.BackendAddressPools[0]
Set-AzNetworkInterface -NetworkInterface $nic1
## Add VM02 to the back-end pool
$nic2 = Get-AzNetworkInterface `
    -ResourceGroupName $RG `
    -Name "VM02*"
$nic2.IpConfigurations[0].LoadBalancerBackendAddressPools=$lb.BackendAddressPools[1]
Set-AzNetworkInterface -NetworkInterface $nic2

Using the Azure CLI

You can create a load balancer using the Azure CLI with the az network lb create command and various switches to set its parameters. The following Bash script shows you how. Use this snippet to create the same load balancer as you did in the previous sections. (Replace all variables and configuration as per your environment.) Be sure to either delete the previous load balancer or give this new one a different name:

Click here to view code image

#Define variables
region='eastus'
rg='RG01'
publicip='FrontendPIP01'
lbname='PublicLoadBalancer01'
#Create public IP address
az network public-ip create \
    --resource-group $rg \
    --name $publicip \
    --sku Standard \
    --zone {1,2,3} \
    --tier Regional \
    --location $region
#Create load balancer
az network lb create \
    --resource-group $rg \
    --name $lbname \
    --sku Standard \
    --public-ip-address FrontendPIP01 \
    --frontend-ip-name Frontend \
    --backend-pool-name BackEndPool01 \
    --location $region
#Create health probe
az network lb probe create \
    --resource-group $rg \
    --lb-name $lbname \
    --name HealthProbe-Port80 \
    --protocol tcp \
    --port 80
#Create load balancing rule
az network lb rule create \
    --resource-group $rg \
    --lb-name $lbname \
    --name LBRule-HTTP \
    --protocol tcp \
    --frontend-port 80 \
    --backend-port 80 \
    --frontend-ip-name Frontend \
    --backend-pool-name BackEndPool01 \
    --probe-name HealthProbe-Port80 \
    --disable-outbound-snat true \
    --idle-timeout 15
## Add VM01 and VM02 network cards to the back-end pool
array=(VMNIC01 VMNIC02)
  for vmnic in "${array[@]}"
  do
    az network nic ip-config address-pool add \
     --address-pool BackEndPool01 \
     --ip-config-name ipconfig1 \
     --nic-name $vmnic \
     --resource-group $rg \
     --lb-name $lbname
  done

Best practices

Following are some best practices recommended for Azure Load Balancer that can help you better deploy and manage the service in your environment:

Upgrade to standard It is highly recommended that you upgrade from the basic Azure Load Balancer to the standard Azure Load Balancer as soon as possible. The standard option provides a number of benefits compared to the basic option. These include the following:

99.99% SLA

Support for multiple inbound and outbound front ends

Support for availability zones

Support for health probes for the HTTPS protocol

Large number of front-end configurations

Larger back-end pool sizes

Use multiple front ends Using multiple front ends can help you scale the number of connections supported for load balancing on specific ports or IP addresses. In addition, this feature offers more benefits, such as zone redundancy, by setting up your front ends in separate zones for higher resiliency.

Integrate with Azure Firewall You can integrate Azure Load Balancer with Azure Firewall. This enables you to use Azure Firewall’s threat intelligence feature to protect web applications in the back-end pool. If your web application is used to manage critical business data, it is highly recommended that you use this feature to protect against known and evolving threats.

Setup Network Watcher Network Watcher is an Azure service that enables you to identify, analyze, and monitor any issues on the network level to or from an Azure service. It is a good practice to set up Network Watcher in the regions where load balancers are created and to set up alerts to flag anomalous activities on the network.

Use service tags in NSG rules You can use NSG rules to block inbound traffic to back-end pool resources—except inbound traffic that originates from a load balancer. Load balancers can still connect with back-end pool resources to monitor health and route traffic. However, any changes to the load balancer’s IP address can break this connectivity if the corresponding rules are not updated in the NSG. To resolve this, you can use service tags. These Microsoft-managed tags contain all the address prefixes associated with an Azure service. In this case, Microsoft manages the AzureLoadBalancer service tag and keeps it up to date. It is a good practice to use service tags in place of IP addresses in NSG rules to ease management overhead.

Use Azure Activity log to identify and track service changes Azure Activity log keeps track of changes to the Azure Load Balancer configuration. Logs are stored for 90 days. It is a good practice to set up Azure Activity log to monitor for critical changes and alert you when they occur. This enables you to proactively address unplanned or unauthorized changes.

Configure central security log management To keep Azure Activity logs for longer than 90 days (for example, for compliance, analytics, or reference purposes), integrate these logs with Azure Monitor and export them to a Log Analytics workspace to perform analytics. You can also integrate with a security information and event management (SIEM) solution such as Microsoft Sentinel for automated analytics and alerting on security incidents.

Set up monitoring and alerts for load balancer metrics The standard load balancer provides numerous key metrics that you can use to monitor the health of the load balancer and to set up alerts when the situation calls for a proactive response. Some key metrics include the following:

Data path availability

Health probe status

SNAT connection count

Allocated SNAT ports

Used SNAT ports

Packet count

Byte count

It is a good idea to integrate the load balancer with Azure Monitor and Log Analytics to track these metrics over time. This enables you to identify issues with the service response or setup.

Along with the load balancer, it is a good practice to set up monitoring and alerting for back-end resources used by the load balancer so you can address any service issues on the back-end pool.

Azure provides a dashboard for Azure Load Balancer called Load Balancer Insights. This dashboard provides detailed insights into the load balancer’s health and performance. The dashboard consists of the following:

Functional dependency view

Metrics dashboard

Overview tab

Frontend and Backend Availability tab

Data Throughput tab

Flow distribution

Connection monitors

Metric definitions

Chapter 5

Azure Firewall

Overview

Azure Firewall is a fully managed, highly available, highly scalable, stateful firewall provided as an Azure service. It enables you to centrally define network and application logging and to enforce policies to protect Azure virtual network (vNET) resources across multiple subscriptions. (See Figure 5-1.) The service complies with most international standards, including service organization controls (SOCs), International Organization for Standardization (ISO) standards, Payment Card Industry Data Security Standard (PCI DSS), the Health Information Trust Alliance Common Security Framework (HITRUST CSF), and others.

FIGURE 5-1 Azure Firewall features.

Azure Firewall features

Some key features and concepts of Azure Firewall include the following:

High availability by design Azure Firewall is highly available by design. The service uptime standard is 99.95%. Organizations need not perform additional setup or configuration to achieve high availability.

Unlimited scaling capabilities Azure Firewall has unlimited scaling capabilities to handle higher volumes of traffic as needed. So, organizations need not plan for or manually scale the firewall to handle peak loads.

Support for availability zones Azure Firewall supports deployment across multiple availability zones, allowing for 99.99% uptime. Azure Firewall costs remain the same regardless of the availability zone configuration. If a firewall spans multiple availability zones, there are additional charges associated with inbound and outbound data transfers between availability zones.

Fully stateful service Azure Firewall is a fully stateful service that provides layer 3 and 4 monitoring and filtering capabilities. Defining rules for what traffic should be allowed or denied based on source, destination IPs, protocols, or ports protects resources spread across multiple Azure subscriptions and vNETs.

Centralized management Azure Firewall allows for centralized management using Azure Firewall Manager. This makes it easy to configure and manage multiple Azure Firewalls from a single location.

Threat Intelligence Azure Firewall supports the automatic blocking of traffic from known malicious IPs and sources based on Microsoft Threat Intelligence feeds. You can easily enable this functionality if your organization requires it.

NAT support Azure Firewall service provides both inbound and outbound network address translation (NAT) capabilities, allowing traffic to be securely routed to and from internal resources without requiring public exposure for critical services.

Support for multiple IP addresses As many as 250 IP addresses can be assigned to Azure Firewall. So, you can configure inbound and outbound NAT for multiple virtual resources on the same ports using different IP addresses.

Centralized logging Azure Firewall supports centralized logging to Azure Monitor, enabling long-term retention of firewall and traffic logs for analysis and alerting.

Multiple deployment methods You can deploy and manage Azure Firewall using the Azure Portal and Azure PowerShell. You can also deploy Azure Firewall using ARM templates.

Design concepts and deployment considerations

It’s important to gain a better understanding of the various features of Azure Firewall to design and deploy the service most effectively for your environment. The following sections discuss several firewall features in detail.

Support for availability zones

An availability zone is a unique physical location encompassing one or more datacenters. Multiple availability zones comprise each Azure region.

You can deploy Azure Firewall across multiple availability zones in a region when you create the firewall, but not after it has been created. Any firewall you’ve already created that needs to be part of an availability zone must be deleted and re-created in the availability zone.

The cost of the firewall is the same, whether it’s within an availability zone or not. However, if a firewall spans multiple availability zones, additional charges apply for inbound and outbound data transfers across the availability zones.

Note

If you create an Azure Firewall that spans two or more availability zones, the service SLA jumps from 99.95% uptime to 99.99% uptime.

Inbound DNAT

Azure Firewall supports destination network address translation (DNAT). This allows the firewall to route incoming traffic for a specific public IP associated with the firewall, to an internal service. This allows secure publishing of internal services over the public internet.

DNAT allows traffic to be routed from standard public ports to non-standard internal ports, thereby obscuring the internal application ports. Internal applications can be securely exposed without fear of exposing the application front end to malicious attacks.

You can set up as many as 250 public IP addresses on Azure Firewall, making it possible to associate different public IPs with different internal services. This makes it easier to use the same ports for multiple internal applications if required.

Outbound SNAT

Azure Firewall also supports source network address translation (SNAT) for outbound traffic that originates from resources inside the network. With SNAT, traffic going to the public internet can be masked with a specific public IP or a set of public IPs. This makes it possible for people (such as remote employees) to access resources over the public internet. It also makes it possible to set up routing rules to enable specific SNAT configurations access to known-partner or third-party networks that require static IP associations.

Note

If the destination IP is a private IP range, as per IANA RFC 1918, Azure Firewall does not perform a SNAT. SNAT traffic can be monitored using the metrics provided by the firewall.

SNAT can take advantage of Azure Firewall’s multi-IP support, using multiple public IPs to limit the impact of port exhaustion for a single public IP. All public IPs associated with the firewall are randomly chosen at the time of the SNAT. Hence, any filtering performed downstream will require that all associated public IPs or the public IP prefix be allowed for any services that rely on this filtering.

Traffic filtering

With Azure Firewall, you can create different types of traffic-filtering rules to protect your environment and back-end services. You can perform traffic filtering in different ways:

Network traffic-filtering rules using incoming network packet details

Web-traffic filtering rules using web categories

Application FQDN traffic-filtering rules to protect outbound traffic to pre-defined Microsoft-managed application FQDNs

Network traffic filtering

Azure Firewall can filter network traffic through the creation of rules that allow or deny traffic based on source IPs, destination IPs, port, or protocol. Because Azure Firewall is a fully stateful service, capable of monitoring and filtering layer 3 and layer 4 traffic, it can constantly analyze the context of traffic and data packets traversing the firewall. This enables it to filter based on not just source and destination IPs but also by port and protocol, providing more control over the network traffic allowed in and out of the network.

Web-traffic filtering

Azure Firewall also supports web-traffic filtering, allowing or restricting traffic based on pre-defined categories such as social media, search engine, religion, sports, and so on.

The standard Azure Firewall supports categorization and filtering up to the primary domain level of a web request only. For example, web requests for www.bing.com and www.bing.com/news would be categorized under search engine because the primary domain in both cases (bing.com) is a search engine.

Note

If required, you can set up exceptions to allow or deny specific sites or sets of sites within a category.

Application FQDN traffic filtering

Azure Firewall enables you to limit outbound HTTP, HTTPS, and Azure SQL traffic to a pre-defined set of fully qualified domain names (FQDNs). This includes the ability to allow traffic based on wildcards to these FQDNs that are managed by Microsoft.

Groupings

Azure provides various methods to simplify grouping well-known services. These are frequently used for IP ranges, infrastructure services, and website categories, to enable them to be used effectively in filtering rules.

Tags

Tags make it easier to group resources, services, or objects to apply specific actions on them. There are two different types of tags available for use with Azure Firewall service: fully qualified domain name (FQDN) tags and service tags.

FQDN tags

An FQDN tag is applied to a pre-defined set of well-known Azure services to easily allow traffic to them. For example, the Windows Diagnostics FQDN tag is applied to all Windows Diagnostics endpoints. You can enable this tag to allow traffic to the Windows Diagnostics service instead of setting up all the IPs associated with this service to allow traffic.

Note

FQDN tags are managed and maintained by Microsoft. You cannot make changes to FQDN tags, nor can you create new ones.

The FQDN tags currently available in Azure include the following (Microsoft will add more FQDN tags in the future as the need arises):

Windows Update This FQDN tag allows access to all Microsoft Update endpoints.

Windows Diagnostics This FQDN tag allows access to all Windows Diagnostics endpoints.

Microsoft Active Protection Service (MAPS) This FQDN tag allows access to all MAPS endpoints.

App Service Environment (ASE) This FQDN tag allows access to ASE platform traffic. This tag, however, does not cover customer-specific storage and SQL endpoints created by ASE. Those need to be enabled via service endpoints or added manually.

Note

Applying these tags allows the corresponding access associated with each endpoint or service.

Service tags

Service tags are created by Microsoft to manage groups of IP address prefixes associated with specific Azure services. For example, the AppService service tag applies to the Azure App Service, and any rules set up to use this tag would apply to all instances of that Service.

Other service tags include the following:

Storage This applies to the Azure Storage service.

SQL This applies to the Azure SQL service.

AzureActiveDirectory This applies to the Azure Active Directory service.

Note

Only Microsoft can create and manage service tags. New services tags are typically created when new services are brought online.

Infrastructure FQDNs

Every Azure Firewall instance contains a built-in collection of rules for infrastructure FQDNs that are set up to allow traffic for different Azure services and enabled by default. The following services are included in these FQDNs, are specifically for the Azure platform, and cannot be used for any other reason:

Compute access to the storage Platform Image Repository (PIR)

Managed disks status storage access

Azure Diagnostics and Logging (MDS)

Note

You can override this collection of built-in rules by adding a Deny All Application Rules collection at the end of the list of firewall rules.

IP groups

You can use IP groups to assemble different IP addresses or IP ranges for use in Azure Firewall rules. An IP group could be used as a source address or destination address in network traffic rules, or as a source address in DNAT or application rules.

The same IP group can be used in multiple rules. This makes it easier to maintain and manage them and reduces management overhead. Each IP group can contain a single IP address, multiple IP addresses, or a range of IP addresses.

Web categories

Web categories are pre-defined sets of categories that contain a list of websites that are related based on their content or purpose. These categories make it easy for administrators to allow or deny traffic based on organizational policies. You can set up exceptions or exclusions for specific websites in a category to override your organization’s policy for that category.

Forced tunneling

Forced tunneling involves routing all outbound internet traffic through a designated edge device or network virtual appliance instead of through the default internet gateway. This helps organizations process outbound traffic for compliance, audit, or security reasons before sending it to the internet.

You can set up forced tunneling only when you create an Azure Firewall instance. If you want to configure an existing Azure Firewall instance to use forced tunneling, you must delete that instance and re-create it with forced tunneling enabled. Similarly, if you want to disable forced tunneling for an Azure Firewall instance, you must delete the instance and re-create it with that setting disabled.

Traffic to manage the firewall service must be separated from client traffic to allow operational activities for the service to continue uninterrupted. You must use a dedicated subnet, AzureFirewallManagementSubnet, with a minimum subnet size of /26. This subnet requires a dedicated public IP address. Once this configuration is in place, you can set the AzureFirewallSubnet to route all traffic to any on-premises or dedicated appliance for processing as required.

Threat intelligence

Threat intelligence–based filtering is an advanced security feature available with Azure Firewall that sources information about malicious IPs and domains from the Microsoft Threat Intelligence feed. This feature is enabled by default in alert-only mode, although you can set it to alert-and-deny mode to alert you to a potential threat and block that threat when necessary.

When alert-and-deny mode is enabled, other network or application-filtering rules are ignored. This is because if this setting is enabled, Azure Firewall always analyzes Threat Intelligence rules for incoming or outgoing traffic first. Note that this order of operations cannot be changed.

In contrast, in alert mode, Azure Firewall also analyzes the traffic first, but because the service need only raise an alert, the rest of the network and application traffic-filtering rules continue to be applied for that traffic.

Azure Firewall Manager

Azure Firewall Manager is a management layer service that can be used to centrally configure policies and to route and manage instances of Azure Firewall deployed in multiple subscriptions and vNETs. For enterprises accustomed to employing a central console for firewall management, Azure Firewall Manager is the ideal solution for managing Azure Firewall instances. It can be used to centrally create, deploy, and manage network and application filtering rules across multiple Azure Firewall instances using firewall policies (discussed next).

Classic rules versus firewall policies

There are two ways to set up Azure Firewall rules:

Classic rules Classic rules are standard application or network rules that are set up for individual Azure Firewall instances. These are available only on the standard SKU. Newer Azure Firewall features do not support classic rules.

Firewall policies Firewall policies are collections of NAT rules, network traffic rules, application filtering rules, and Threat Intelligence settings that are stored on a global level and can be deployed across multiple Azure Firewall instances. This makes it easier to apply standards across an organization using policy inheritance and enforcement. New firewall policies can be created based on existing policies. In addition, you can create local policies for specific scenarios and apply them to individual Azure Firewall instances. To create and manage firewall policies, you use Azure Firewall Manager, Azure PowerShell, the Azure CLI, REST API, or ARM templates.

Note

Microsoft does not charge for firewall policies associated with zero or one firewall. Fixed-rate charges are levied only if there are multiple firewall associations.

It is highly recommended to migrate away from classic rules to firewall policies. One easy way to do this is to select the Migrate to Firewall Policy option in the Azure Portal.

Firewall rule processing

Now that you know all the different ways Azure Firewall can manage traffic—Threat Intelligence, inbound and outbound NAT rules, network and application rules—it is important to grasp the order in which they are processed.

Note

Azure Firewall will deny all traffic until some rules are defined to specify what traffic should be allowed in and out.

Incoming traffic

For incoming traffic, the order in which rules are processed depends on the type of firewall management in place.

For a firewall set up with classic rules, the order is as follows:

Threat Intelligence rules.

NAT rules.

Network rules, in order of priority (from the lowest number to the highest number).

For a firewall set up with firewall policies, the order is as follows:

Threat Intelligence rules.

NAT rules.

Rule collections or rule-collection groups, in order of priority (from the lowest number to the highest number). Inside each rule collection or rule collection group, network rules are processed using the same logic (from the lowest number to the highest number).

Note

There is one exception to this logic: Rule-collection groups inherited from a parent policy are always applied first, regardless of the priority set on the child rule collection or child rule-collection groups.

Note

Application rules do not apply to incoming traffic because Azure Firewall does not support this functionality. For application rule filtering, you should use Azure Web Application Firewall or Azure Front Door.

Outbound traffic

Like inbound traffic, the order in which rules for outbound traffic are applied depends on the type of firewall management in place. On each level, if there is a match to deny traffic, no further rules are applied. In addition:

Application rules are analyzed only if there is no match for network rules.

Infrastructure rules are analyzed only if there is no match for application rules.

If there is no match for infrastructure rules, traffic is denied.

For a firewall set up with classic rules, the order is as follows:

Threat Intelligence rules.

NAT rules.

Network rules, in order of priority (from the lowest number to the highest number).

Application rules in order of priority (from the lowest number to the highest number).

Infrastructure rule collections.

For a firewall set up with Firewall Policy, the order is as follows:

Threat Intelligence rules.

NAT rules.

Rule collections or rule-collection groups in order of priority (from the lowest number to the highest number). Inside each rule collection or rule-collection group, network and application rules are processed using the same logic (from the lowest number to the highest number).

Infrastructure rule collections.

Note

There is one exception to this logic: Rule-collection groups inherited from a parent policy are always applied first, regardless of the priority set on the child rule collection or child rule-collection groups. In addition, application rules are processed only if the traffic uses the HTTP, HTTPS, or MSSQL protocol.

DNS proxy

You can configure Azure Firewall as a DNS proxy to resolve client DNS requests as an intermediary, with the help of an authorized DNS server.

Active FTP support

Azure Firewall supports active FTP. Support for active FTP is disabled by default to protect against FTP bounce attacks, but you can enable it if the firewall is deployed using Azure PowerShell, the Azure CLI, or an ARM template.

Azure Monitor logging

You can integrate Azure Firewall with Azure Monitor. This integration also provides support for logging events, archiving logs to a storage account for long-term retention, sending logs to Log Analytics, and event streaming to Event Hub.

Microsoft provides a pre-built template for Azure Monitor called Azure Firewall Workbook that you can use to analyze firewall data and create visualizations for reporting purposes. There are also numerous firewall metrics, activity logs, and diagnostic logs that you can incorporate into your monitoring solution for deeper analysis of firewall performance and ongoing issues.

Firewall metrics

Azure Monitor provides numerous metrics for various Azure services that you can use to monitor specific aspects of the service. These metrics enable you to detect related performance issues and other problems related to the service better than generic metrics alone.

Azure Monitor includes Azure Firewall–specific metrics to collect service-related information and raise alerts if issues are detected. Key metrics include the following:

Firewall Health State Gauges the health of the firewall based on SNAT port availability.

Data Processed Tracks the total amount of data traversing the firewall at various periods of time.

Throughput Indicates the rate per second at which data is traversing the firewall.

Application Rules Hit Count Gauges the number of times an application rule has been triggered by a request.

Network Rules Hit Count Tracks the number of times a network rule has been triggered by a request.

SNAT Port Utilization Indicates the percentage of SNAT ports currently in use by the firewall.

Azure Activity logs

Azure automatically collects Activity logs for all deployed services. These logs contain operational and audit data that records all changes and actions performed on a service for a given period of time. You can collect and analyze these logs to track change-management activities or administrative actions over time.

Diagnostic logs

There are various types of diagnostic logs available for Azure Firewall to monitor various features of the service to identify ongoing issues. These include the following:

Application Rule log This records all connection requests that match an application rule.

Network Rule log This records all connection requests that match a network rule.

DNS Proxy log This records all DNS messages sent to a DNS server using the DNS proxy service configured on the firewall.

Each of these log types can be configured to store logs in one of three ways:

Store them in an Azure Storage account

Send them to Azure Monitor

Stream them to Event Hubs

Azure Firewall deployment walkthrough

The following sections walk you through the process of creating an Azure Firewall using the Azure Portal and Azure PowerShell. (The functionality needed to use the Azure CLI to complete this task is under development, so it is not covered here.) If you are following along, be sure to select resources and resource names based on your environment, including a unique Azure Firewall name for each deployment. Also be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft for these resources.

Using Azure Portal

To create an Azure Firewall using the Azure Portal, follow these steps:

Log into the Azure Portal, type firewall in the search box to locate the service, and select it from the list that appears.

Click Create or Create Firewall to start the Create a Firewall wizard. (See Figure 5-2.)

FIGURE 5-2 Create a firewall.

In the Basics tab of the Create a Firewall wizard (see Figure 5-3), enter the following information and click Next:

Subscription Select the subscription to host the Azure Firewall instance.

Resource Group Select the resource group you want to host the firewall. Alternatively, click the Create New link and follow the prompts to create a new resource group.

Name Type a name for the firewall. If the name you type is already in use, the wizard will prompt you to enter a different name.

Region Select the Azure region in which you want to host the Azure Firewall instance.

Availability Zone Select an availability zone for the firewall.

Firewall Tier Select the Standard option button.

Firewall Management Select the Use a Firewall Policy to Manage This Firewall option button.

Firewall Policy Select the policy you want to associate with the firewall. Alternatively, click the Create New link and follow the prompts to create a new firewall policy.

Choose a Virtual Network Select an existing vNET on which to deploy the firewall. Alternatively, click the Create New link and follow the prompts to create a new vNET.

Public IP Address Select the public IP address you want to use. Alternatively, click the Add New link and follow the prompts (see Figure 5-4) to create a new IP address.

Forced Tunneling Leave this set to Disabled.

FIGURE 5-3 The Basics tab of the Create a Firewall wizard.

FIGURE 5-4 Adding a new public IP.

In the Tags tab of the Create a Firewall wizard (see Figure 5-5), enter any tags required for the firewall. Then click Next.

FIGURE 5-5 The Tags tab of the Create a Firewall wizard.

On the Review + Create tab, review your settings. Then click Create.

Now you need to create a default route and attach it to the required subnets to route traffic from resources in those subnets through the firewall.

In the Azure Portal, type route tables in the search box to locate the service and select it from the list that appears.

Click Create or Create Route Table to start the Create Route Table wizard. (See Figure 5-6.)

FIGURE 5-6 Create route table.

In the Basics tab of the Create Route Table wizard (see Figure 5-7), enter the following information and click Next:

Subscription Select the subscription to host the route table.

Resource Group Select the resource group in which you want to create the route table. Alternatively, click the Create New link and follow the prompts to create a new resource group.

Region Select the Azure region in which you want to create the route table.

Name Type a name for the route table. If the name you type is already in use, the wizard will prompt you to enter a different name.

Propagate Gateway Routes Select the Yes option button.

FIGURE 5-7 The Basics tab of the Create Route Table wizard.

In the Tags tab of the Create Route Table wizard (see Figure 5-8), enter any tags required for the route table. Then click Next.

FIGURE 5-8 Enter the tags.

On the Review + Create tab, review your settings. Then click Create.

When the route table has been created, click Go to Resource.

In the left pane of the new route table’s configuration blade, click Subnets. Then click the Associate button in the right pane. (See Figure 5-9.)

FIGURE 5-9 Associating the subnet in the route table.

In the Associate Subnet settings (see Figure 5-10), enter the following information. Then click OK:

Virtual Network Select the appropriate vNET.

Subnet Select the subnet you want to associate with the route table.

FIGURE 5-10 The Associate Subnet options.

After the subnet has been associated with the route table, click Routes on the left side of the route table’s configuration blade. Then click Add on the right side of the blade. (See Figure 5-11.)

FIGURE 5-11 The Routes options.

In the Add Route settings, enter the following information and click Add:

Route Name Enter a unique name for the route. If the name you type is already in use, you’ll be prompted to enter a different name.

Address Prefix Type 0.0.0.0/0 to set it as the default gateway.

Next Hop Type Select Virtual Appliance.

Next Hop Address Enter the firewall’s private IP.

FIGURE 5-12 The Add Route options.

Type firewall policies in the Azure Portal search box. Then select FirewallPolicy01 (created earlier in this walkthrough) from the list that appears.

On the left side of the configuration blade for FirewallPolicy01, click Application Rules. Then click Add a Rule Collection on the right side of the blade. (See Figure 5-13.)

FIGURE 5-13 The Application Rules options for the firewall policy.

In the Add a Rule Collection dialog box (look ahead to Figure 5-14), enter the following information:

Name Enter a unique name for the rule collection—here, AppRule01. If the name you type is already in use, you’ll be prompted to enter a different name.

Rule Collection Type Select Application.

Priority Enter a priority for the rule collection type—in this example, 100.

Rule Collection Action Select Allow.

Rule Collection Group Leave this set to the default rule-collection group or select a different rule-collection group.

In the Rules section of the Add a Rule Collection dialog box (see Figure 5-14), enter the following information. When you’re finished, click Add:

Name Type a name for the first rule in the rule collection—here, AllowWebBrowsing.

Source Type Choose IP Address.

Source Enter the source’s IP address.

Protocol Enter the supported protocols in the Protocol box.

Destination Type Select the destination type—in this case, Web Categories.

Destination Select the destination. (You will see a list of destinations based on the destination type selected earlier.)

FIGURE 5-14 Adding an application rule collection.

On the left side of the FirewallPolicy01 blade, click Network Rules. Then click Add a Rule Collection on the right. (See Figure 5-15.)

FIGURE 5-15 The Network Rules options for the firewall policy.

In the Add a Rule Collection dialog box (look ahead to Figure 5-16), enter the following information:

Name Enter a unique name for the rule collection. If the name you type is already in use, you’ll be prompted to enter a different name.

Rule Collection Type Select Network.

Priority Enter a priority for the rule collection type—in this example, 100.

Rule Collection Action Select Allow.

Rule Collection Group Leave this set to the default rule-collection group or select a different rule-collection group.

In the Rules section of the Add a Rule Collection dialog box (see Figure 5-16), enter the following information. When you’re finished, click Add:

Name Type a name for the first rule in the rule collection—here, AllowDomainNameResolution.

Source Type Choose IP Address.

Source Enter the source’s IP address.

Protocol Enter the supported protocols in the Protocol box.

Destination Type Select the destination type—in this case, IP Address.

Destination Select the destination.

FIGURE 5-16 Adding a network rule collection.

On the left side of the FirewallPolicy01 blade, click DNAT Rules. Then click Add a Rule Collection on the right. (See Figure 5-17.)

FIGURE 5-17 The DNAT Rules for the firewall policy.

In the Add a Rule Collection dialog box (look ahead to Figure 5-18), enter the following information:

Name Enter a unique name for the rule collection—here, DNAT-AllowRDP-VM. If the name you type is already in use, you’ll be prompted to enter a different name.

Rule Collection Type Select DNAT.

Priority Enter a priority for the rule collection type—in this example, 100.

Rule Collection Type This is automatically set to Destination Network Address Translation (DNAT) and cannot be changed.

Rule Collection Group Leave this set to the default rule-collection group or select a different rule-collection group.

In the Rules section of the Add a Rule Collection dialog box (see Figure 5-18), enter the following information. When you’re finished, click Add:

Name Type a name for the first rule in the rule collection—here, AllowRDP-VM.

Source Type Choose IP Address.

Source Enter the source IP. (I typed * to choose all IPs.)

Protocol Enter the supported protocols in the Protocol box.

Destination Ports Enter the destination port.

Destination Type Select the destination type—in this case, IP Address.

Destination Select the destination.

Translated Address Enter the translated address of the destination address. I entered 10.0.0.4 (partially visible in Figure 5-18).

Translated Port Enter the translated address of the destination port. In my case, it was 3389 (not visible in Figure 5-18).

FIGURE 5-18 Adding a DNAT rule collection.

On the left side of the FirewallPolicy01 blade, click Rule Collections. Then, on the right, verify that the rule collections you created are listed and reflect your requirements. (See Figure 5-19.)

FIGURE 5-19 Rule collections listed in the FirewallPolicy01 blade.

Note

You can edit any of the rule collections. Simply click the link for the collection and change its settings as needed.

On the left side of the FirewallPolicy01 blade, click Threat Intelligence.

Enter the following information on the right side of the blade (see Figure 5-20) and click Save:

Threat Intelligence Mode Choose between Off, Alert Only, and Alert and Deny, depending on your requirements.

Allow List Addresses In the IP Address, Range, or Subnet box under Allow List Addresses, enter any IP address, range, or subnet whose traffic you want to allow-list or allow to pass through your firewall.

FQDNs In the FQDNs box under FQDNs, enter any FQDNs you want to allow-list.

FIGURE 5-20 Applying Threat Intelligence settings.

Using Azure PowerShell

You can create an Azure Firewall instance using Azure PowerShell with the New-AzFirewall command and various switches. The following code shows you how. Use this snippet to create the same Azure Firewall instance as you did in the Azure Portal. (Replace all variables and configuration as per your environment.) When you do, be sure to either delete the previous firewall or give this firewall a different name:

Click here to view code image

#Define variables
$RG="RG01"
$Region="EastUS2"
#Create new Firewall Policy
$AzFirewallpolicy = New-AzFirewallPolicy -Name FirewallPolicy -ResourceGroupName $RG
-Location $Region
#Create and Configure a firewall policy application rule
$FWAppRuleGroup = New-AzFirewallPolicyRuleCollectionGroup -Name DefaultApplicationRuleCollectionGroup
-Priority 100 -FirewallPolicyObject $AzFirewallPolicy
$FWApprule01 = New-AzFirewallPolicyApplicationRule -Name AllowWebBrowsing -SourceAddress
10.0.1.0/24 -Protocol http, https -WebCategory "Business"
$FWAppCollection01 = New-AzFirewallPolicyFilterRuleCollection -Name AppRuleCollection01
-Priority 100 -Rule $FWAppRule01 -ActionType "Allow"
Set-AzFirewallPolicyRuleCollectionGroup -Name $FWAppRuleGroup.Name -Priority 100
-RuleCollection $FWAppcollection01 -FirewallPolicyObject $AzFirewallpolicy
#Create and configure a firewall policy network rule
$FWNWRuleGroup = New-AzFirewallPolicyRuleCollectionGroup -Name DefaultNetworkRuleCollectionGroup
-Priority 200 -FirewallPolicyObject $AzFirewallPolicy
$FWNetRule01 = New-AzFirewallPolicyNetworkRule -name CloudFlareDNS -protocol UDP
-sourceaddress 10.0.1.0/24 -destinationaddress 1.1.1.1,1.0.0.1 -destinationport 53
$FWNetCollection = New-AzFirewallPolicyFilterRuleCollection -Name AllowDomainNameResolution
-Priority 100 -Rule $FWNetRule01 -ActionType "Allow"
Set-AzFirewallPolicyRuleCollectionGroup -Name $FWNWRuleGroup.Name -Priority 200
-RuleCollection $FWNetCollection -FirewallPolicyObject $AzFirewallPolicy
#Deploy the Azure Firewall
# Create a Public IP for the firewall
$AzFWPubIP = New-AzPublicIpAddress -Name "AzFWPIP01" -ResourceGroupName $RG -Location
$Region -AllocationMethod Static -Sku Standard
# Create the firewall
$vnet = Get-AzVirtualNetwork -ResourceGroupName $RG -Name "vNET01"
$Azfirewall = New-AzFirewall -Name Firewall -ResourceGroupName $RG -Location $Region
-VirtualNetwork $vnet -PublicIpAddress $AzFWPubIP -FirewallPolicyId $AzFirewallpolicy.Id
$AzFWPrivIP = $AzFirewall.IpConfigurations.privateipaddress
#Create and configure DNAT policy
$FWNATRuleGroup = New-AzFirewallPolicyRuleCollectionGroup -Name DefaultDNATRuleCollectionGroup
-Priority 300 -FirewallPolicyObject $AzFirewallPolicy
$FWNATRule01 = New-AzFirewallPolicyNatRule -Name DNAT-AllowRDP-VM -SourceAddress * -Protocol
TCP -DestinationAddress $AzFWPubIP -DestinationPort 3389 -TranslatedAddress 10.0.0.4
-TranslatedPort 3389
$FWDNATCollection = New-AzFirewallPolicyNatRuleCollection -Name DNAT-Rules -Priority 100
-Rule $FWNATRule01 -ActionType "Dnat"
Set-AzFirewallPolicyRuleCollectionGroup -Name $FWNATRuleGroup.Name -Priority 300
-RuleCollection $FWDNATCollection -FirewallPolicyObject $AzFirewallPolicy
#Create route table
$RouteTbl = New-AzRouteTable -Name RouteTable -ResourceGroupName $RG -location $Region `
#Create the default route
 Add-AzRouteConfig -Name "DefaultRoute" `
  -RouteTable $RouteTbl `
  -AddressPrefix 0.0.0.0/0 `
  -NextHopType "VirtualAppliance" `
  -NextHopIpAddress $AzFWPrivIP
#Set route table
Set-AzRouteTable -routetable $RouteTbl
#Associate the route table to the subnet
Set-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet `
  -Name 'Servers' `
  -AddressPrefix 10.0.1.0/24 `
  -RouteTable $RouteTbl

Best practices

Following are several recommended best practices for Azure Firewall to help you better deploy and manage the service in your environment:

Integrate Azure Firewall with Azure Monitor As discussed, you can integrate Azure Firewall with Azure Monitor to store and analyze firewall logs. Doing so is highly recommended to monitor the firewall metrics to gauge its performance and identify issues. You can store your logs in a storage account, send them to Log Analytics, or stream them to Event Hub. Then, you can use tools like Log Analytics, Microsoft Excel, and Microsoft Power BI to analyze them. You can also set up alerts for various metrics to automatically identify attacks or performance issues.

Set priority of rules in increments of 100 When you create a new rule, it’s a good practice to set its priority to 100. That way, as you add more rules over time, you can easily insert them between existing rules without having to modify the priority of those rules.

Avoid wildcards as sources for DNATs It is better to specify source IPs for incoming DNATs, if possible, instead of using wildcards. That way, only traffic from the sources you specify is allowed in and routed to the internal application.

Consider global peering Azure Firewall is typically deployed using a hub-and-spoke model, in which the firewall is deployed in a central vNET, with all other vNETs in the region peered with the central network. This allows for centralized control of traffic for all peered vNETs without requiring the deployment of a firewall in each one. This works well for vNETs that spread globally, but if traffic traverses different Azure regions before reaching its final destination, performance or latency issues might crop up. To rectify this, consider using global peering for firewalls only. Just be sure to test it first to ensure it meets the latency and performance requirements of the application and your organization.

Use Azure Firewall side-by-side with network security groups (NSGs) Azure Firewall and NSGs work together in a complementary way to provide in-depth network security. Even if you are deploying Azure Firewall to protect resources across all subscriptions and vNETs, be sure to take advantage of the distributed network layer traffic filtering provided by NSGs to limit traffic to resources within vNETs.

Use Azure Security Center Azure Security Center provides better management of your security posture management as well as protection from specific threats. Consider following the network-protection recommendations provided by Security Center to secure network resources related to Azure Firewall. When combined with a Log Analytics Workspace, you can set up monitoring and alerting for anomalous activity so you can respond to threats in a timely manner.

Enable Threat Intelligence As noted, Threat Intelligence–based filtering can alert you to and block traffic from and to well-known malicious IP addresses and domains. Consider using this functionality to enhance protection for your environment.

Reduce administrative overhead, where possible Where possible, use service tags, IP groups, and FQDN tags instead of IP addresses or IP ranges when setting up network security rules. This reduces management and maintenance of the network configuration as well as administrative overhead.

Standardize security configurations Standardize the configuration of your organization’s security policies. Then, set up Azure services to ensure they are effectively maintained. Azure Firewall Manager and Azure Blueprints can help you achieve this objective. Azure Firewall Manager can help you standardize the security configuration, but Azure Blueprints goes much further by packaging all artifacts such as ARM templates, Azure RBAC controls, and policies in a single definition that, when deployed, can monitor and maintain your security policy standards.

Use automated tools to monitor network resource configurations and detect changes Azure Activity log keeps track of all configuration changes to an Azure resource. You can (and should) set up alerts in Azure Monitor to trigger if there are changes to critical resources.

Consider Azure Sentinel for advanced monitoring needs If your organization needs to monitor all security, diagnostic, and activity logs in a centralized repository—perhaps for monitoring and analyzing change-management efforts or to troubleshoot some future problem—consider using Azure Sentinel or a third-party SIEM solution. You can use these to capture all required logs for centralized storage, analysis, and review.

Configure security log storage retention as per organizational compliance requirements It is important to identify your organization’s compliance requirements regarding the retention of log data and ensure that the design of your environment takes them into consideration. With Log Analytics, you can store data for up to two years. However, you have two other options for storing logs for longer: storage accounts and SIEM solutions. You can use these to store logs for much longer durations if your organization requirements exceed the capabilities of Log Analytics. Furthermore, SIEM solutions can be customized to meet your organization’s needs.

Ensure regular automated backups Azure Firewall has no backup feature. However, you can ensure regular automated backups by using Azure Automation to export the firewall and related resources in a JSON template. You can also use the Export Template feature in the Azure Portal to manually export the Azure Firewall configuration in before change-management activities.

Enable locks You can enable locks on Azure Firewall and policy resources to ensure that they aren’t deleted accidentally or otherwise. Considering that a firewall is a critical resource in any environment—and that if it experiences an outage, it can bring the entire environment offline—it is advisable to protect it as best as you can.

Chapter 6

Azure DNS

Overview

Azure DNS is a domain name hosting and resolution service provided in Microsoft Azure. Customers can add public domain names that they own to Azure DNS and use Azure DNS to manage their DNS records using their Azure AD credentials.

Azure DNS is a completely managed service hosted across the Azure global network of DNS servers, providing an SLA of 100%. It uses AnyCast networking. This enables clients to obtain name-resolution services from the closest available Azure DNS server, reducing latency on DNS queries.

You can manage the Azure DNS service using the Azure Portal, Azure PowerShell, the Azure the CLI, the REST API, and SDKs, allowing integration with applications that require automated DNS-management functionality.

Azure DNS features

Azure DNS provides a number of key features that make it a compelling service to use for most environments. These key features include the following:

Global scale and reduced latency Azure DNS stores customer DNS domains in its global DNS name server network. This ensures that an outage in a single region does not take public DNS services for customers offline. Azure DNS uses AnyCast networking, reducing latency for DNS queries and improving performance for client connections.

Unbeatable SLA Because of the global redundancy of the DNS domains, outage in one region does not bring the DNS domain offline on a global level. Azure DNS guarantees a valid DNS request response from at least one of its DNS servers 100% of the time.

Seamless access management and monitoring Azure’s role-based access control (RBAC) provides access to Azure DNS for complete management or specific actions. Any changes in the DNS service configuration or DNS records are monitored and tracked to detect unwanted changes.

Easy billing management Azure DNS billing is integrated with the billing for all other Azure services, making it easier to keep track of expenses related to your public domain infrastructure. Service charges are based on the number of hosted domains and the number of DNS queries received, providing pay-as-you-go functionality. Using other third-party DNS-hosting services can add overhead with respect to monitoring and managing for service availability, contract renewals, and billing.

Support for private domains One of the key features provided by Azure DNS is the support for private DNS domain hosting. This makes it possible to integrate private virtual networks and use the DNS services to host private custom domains through the integration.

Alias records Alias record sets help to create references to Azure resources such as Traffic Manager profiles, Azure CDN endpoints, and Public IP addresses hosted in Azure. Alias record sets can be set up using Azure DNS, and the integration supports automatic updates to any IP address changes occurring for each of the services.

Management and integration You can manage Azure DNS using the Azure Portal, Azure PowerShell, and the Azure CLI. In addition, Azure DNS has integration capabilities using REST APIs and SDKs for automated DNS management.

Private DNS Azure DNS allows integration with Azure virtual networks to host private DNS zones, which you can use to provide name-resolution services in the virtual network. In addition, VMs can automatically register and update their DNS records, providing name-resolution services within the environment without requiring the use of other DNS services.

Azure DNS limitations

As of this writing, Azure DNS has a few limitations. Some key limitations are listed here:

DNSSEC Azure DNS does not currently support DNSSEC. The current guidance for organizations that require DNSSEC is to use a third-party DNS hosting service instead of Azure DNS.

Domain name procurement You cannot use Azure DNS to buy new domain names. Customers must procure domain names from a third-party domain name registrar, using Azure DNS only for the hosting services and record management.

Zone transfers Azure DNS does not support zone transfers, which enable the migration of DNS services from one DNS hosting provider to another using REST APIs. You can use the Azure CLI to import DNS records into Azure DNS or make entries using Azure Portal or Azure PowerShell, however.

URL redirection Some third-party DNS providers offer URL redirection as part of their DNS services. This enables companies to set up HTTP redirections for their web applications. Although many organizations find this to be a useful service, because the redirection is on the HTTP traffic layer instead of the DNS, it is not considered a real DNS feature. So, at this stage, URL redirection is not offered as part of the Azure DNS feature set.

Design and configuration considerations

You’ll want to consider a few features provided by Azure DNS when setting up the service. The following sections discuss these in more detail.

Types of DNS zones

Azure DNS provides two types of DNS zone services: public and private. Both zone types address specific use cases, and both could be used in the same Azure environment to host the same DNS zone.

Public DNS zones allow for the hosting of publicly available domain names—for example, contoso.com. This type of zone generally contains DNS records for public-facing services, such as web servers, mail servers, and so on. Public DNS zones allow access over the public internet for name resolution of DNS records hosted by an organization for external consumption by customers or vendors and for internal consumption by employees. Examples of scenarios in which DNS records might be set up in public DNS zones might be as follows:

An organization hosting a public-facing website could set up its WWW DNS address (A) record in a public DNS zone.

To provide access to its email services, an organization could host its mail server A records in a public DNS zone.

All organizations would set up their mail exchange (MX) records in a public DNS zone for other DNS servers to identify and route emails to their mail servers.

Private DNS zones allow for the hosting of internal DNS zones required for name resolution between Azure VM resources. A private zone can contain the following types of DNS records:

WWW A DNS records with internal IPs of web servers and web applications

A DNS records with internal IPs (if available) for mail servers

A records for VMs hosted within the virtual network

Pointer (PTR) records for VMs hosted within the virtual network

The zones are interlinked to virtual networks, and name resolution works only for those networks in which the link is in place. No internet-based name resolution of private DNS zones is possible. This provides a secure and reliable way to provide DNS services for VMs hosted in a virtual network without requiring the setup of other DNS solutions to host those custom private zones.

A few notes to keep in mind:

The same domain can be hosted as a public DNS zone and a private DNS zone. This supports split-horizon DNS scenarios for name resolution of the same services with varying internal and external records to enable them to talk efficiently via internal and public networks.

Azure DNS does not support single-labeled private DNS zones. All zones must have two labels separated by a dot (contoso.com), with a maximum of 34 labels.

You must create child domains as separate private DNS zones, as zone delegation is currently not supported.

DNS zone walkthrough

The following sections walk you through the process of creating a DNS zone using the Azure Portal, Azure PowerShell, and the Azure CLI. If you are following along, be sure to select resources and unique resource names based on your environment for each of your deployments. Also, be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft for these resources.

The steps for creating a public DNS zone in the Azure Portal are nearly identical to those for creating a private one. The difference is that you use the DNS Service to create a public DNS zone, and you use the Private DNS Zones service to create a private one. (See Figure 6-1.) Because the following sections cover more private DNS zone features than public DNS zone ones, the subsequent sections focus on creating private DNS zones.

FIGURE 6-1 DNS services in Azure.

Using the Azure Portal

To create a private DNS zone using Azure Private DNS service using the Azure Portal, follow these steps:

Log in to the Azure Portal, type private DNS zone in the search box to locate the service, and select it from the list that appears.

Click the Create Private DNS Zone button to start the Create Private DNS Zone wizard. (See Figure 6-2.)

FIGURE 6-2 Initiate the creation of a private DNS zone.

In the Basics tab of the Create Private DNS Zone wizard, enter the following information (see Figure 6-3), and click Next:

Subscription Select the subscription that will host the private DNS zone.

Resource Group Select the resource group you want to use to host the private DNS zone. Alternatively, to create a new resource group, click the Create New link and follow the prompts.

Name Type a name for the private DNS zone.

Resource Group Location This will be populated automatically based on the location of the resource group you just selected.

FIGURE 6-3 The Basics tab of the Create Private DNS Zone wizard.

In the Tags tab, enter any tags required for the private DNS zone or leave the fields blank (see Figure 6-4), and click Next.

FIGURE 6-4 Set up tags.

In the Review + Create tab (see Figure 6-5), review your settings and click Create.

FIGURE 6-5 Review and create a private DNS zone.

Using Azure PowerShell

You can create a private DNS zone with Azure PowerShell using the New-AzPrivateDNSZone command with various switches to set the zone’s parameters. For example, to create the same private DNS zone as you did in the preceding section, you use the first two lines of code below. If you want to create a public DNS zone instead, use the second two lines of code, and replace the domain name with one that you own:

Click here to view code image

#Create private DNS zone
New-AzPrivateDnsZone -Name privatedomain.com -ResourceGroupName RG01

#Create public DNS zone
New-AzDnsZone –Name publicdomain.com –ResourceGroupName RG01

Using the Azure CLI

You can create a private DNS zone with the Azure CLI using the az network private-dns zone create command with various switches to set the zone’s parameters. The first two lines of code below show you how to set up the same zone you created in the preceding sections with the Azure CLI. If you want to create a public DNS zone instead, use the second two lines of code, and replace the domain name with one that you own:

Click here to view code image

#Create private DNS zone
az network private-dns zone create --resource-group RG01 --name privatedomain.com

#Create public DNS zone
Az network dns zone create –-resource-group RG01 –-name publicdomain.com

Linking with Azure virtual networks

You can link a private DNS zone to one or more Azure virtual networks. This enables VMs hosted in the virtual network(s) to use Azure DNS to resolve the names of any private DNS zones hosted in the service. (See Figure 6-6.)

FIGURE 6-6 DNS name resolution after linking with a virtual network.

Note

There is no explicit requirement to set up virtual network peering for multiple virtual networks linked to the same private DNS zone.

Virtual network link walkthrough

The following sections walk you through the process of linking the private DNS zone you created in the “DNS zone walkthrough” section to a virtual network using the Azure Portal, Azure PowerShell, and the Azure CLI.

Using the Azure Portal

To set up the virtual network link using the Azure Portal, follow these steps:

In the left pane of the private DNS zone’s configuration page, under Settings, click Virtual Network Links. Then, in the right pane, click the Add button to start the Add Virtual Network Link wizard. (See Figure 6-7.)

In the Add Virtual Network Link wizard, enter the following information (see Figure 6-8) and click OK:

Link Name Enter a unique name to identify the virtual network link.

Subscription Select the subscription for which the link will be created.

Virtual Network Select the virtual network you want to link to the private DNS zone.

FIGURE 6-7 Add a virtual network.

FIGURE 6-8 The Add Virtual Network Link wizard.

Repeat these steps for any other virtual networks you want to link to the DNS zone.

Using Azure PowerShell

You can link a virtual network to a private DNS zone using Azure PowerShell with the New-AzPrivateDNSVirtualNetworkLink command and various switches to set the link’s parameters. The following code shows you how:

Click here to view code image

#Define variables
$rg = "RG01"
$name = "Link-To-vNET01"
$vnet = "vNET-01"
#Create the virtual network link
New-AzPrivateDNSVirtualNetworkLink -ZoneName privatedomain.com -ResourceGroupName $rg
-Name $name -VirtualNetworkId $vnet.id

Using the Azure CLI

You can link a virtual network to a private DNS zone using the Azure CLI with the az network private-dns link create command and various switches to set the link’s parameters. The following Bash script shows you how:

Click here to view code image

#Define variables
rg = "RG01"
name = "Link-To-vNET01"
vnet = "vNET-01"
#Create the virtual network link
az network private-dns link vnet create --resource-group $rg --name $rg --zone-name
privatedomain.com --virtual-network $vnet

Auto registration

Private DNS zones support the use of auto registration to automatically register and update VM DNS records for accurate name resolution between different VMs running on the same virtual network. This involves setting up an A and a PTR record for each VM that already exists or is newly created on the virtual network for which the feature is enabled. When a VM is deleted, the service also deletes the corresponding A and PTR records for the VM.

You can set up multiple virtual networks to use auto registration to the same private DNS zone. However, every virtual network can be connected to only a single private DNS zone if auto-registration is enabled. Here are a few other limitations to this feature to consider:

Auto registration works only for the primary network card on a VM. The remaining network cards require manual DNS record creation and management.

Auto registration will not work if a VM is set to a static IP. Only VMs using DHCP on their primary network card are supported.

Auto registration supports only VMs. Any other Azure service, such as an internal load balancer, requires manual DNS record creation and management.

IPv6 (AAAA) DNS records are not supported.

Auto-registration walkthrough

The following sections walk you through the process of using the Azure Portal, Azure PowerShell, and the Azure CLI to enable auto-registration for the private DNS zone you created in the “DNS zone walkthrough” section when linking it to a virtual network.

Note

Recall that you can link a private DNS zone to multiple virtual networks. You’ve already linked the private DNS zone you created to one virtual network; here, you will link it to a different one.

Using the Azure Portal

To set up auto registration using the Azure Portal, follow these steps:

In the left pane of the private DNS zone’s configuration page, under Settings, click Virtual Network Links. Then, in the right pane, click the Add button to start the Add Virtual Network Link wizard.

In the Add Virtual Network Link wizard, type a name for the link, select your subscription, and select the virtual network to which you want to link, as you did earlier in the “Virtual network link walkthrough” section.

Under Configuration, select the Enable Auto Registration check box (see Figure 6-9). Then click OK.

FIGURE 6-9 Enable auto registration.

Using Azure PowerShell

You can enable auto registration during the virtual network link–creation process using Azure PowerShell with the New-AzPrivateDNSVirtualNetworkLink command and the –EnableRegistration switch. The following code shows you how:

Click here to view code image

#Define variables
$rg = "RG01"
$name = "Link-To-vNET01"
$vnet = "vNET-01"
#Create the virtual network link
New-AzPrivateDnsVirtualNetworkLink -ZoneName privatedomain.com -ResourceGroupName $rg
-Name $name -VirtualNetworkId $vnet.id -EnableRegistration

Using the Azure CLI

You can enable auto registration during the virtual network link–creation process using the Azure CLI with the az network private-dns link create command and the --registration-enabled parameter. The following code shows you how:

Click here to view code image

#Define variables
rg = "RG01"
name = "Link-To-vNET01"
vnet = "vNET-01"
#Create the virtual network link
az network private-dns link vnet create --resource-group $rg --name $rg --zone-name
privatedomain.com --virtual-network $vnet --registration-enabled true

Alias record sets

Alias record sets are references created in Azure Public DNS zones to public IPs associated with Azure services such as Azure Traffic Manager, Azure CDN, Azure Front Door, Azure App Service with Static IP, and Azure Public IP Address. You can associate an alias record set with any of these resources. Then, during the name-resolution process, the alias record will query and return the current IP address of the associated service.

The DNS record set changes automatically as the public IP of the service changes. This helps to ensure that DNS records are always up-to-date and that no stale or incorrect records can result in unplanned downtimes.

Azure DNS currently supports the following DNS record types:

A

AAAA

CNAME

Alias record sets walkthrough

The following section walks you through the process of creating a public DNS zone and alias record set using the Azure Portal.

Using the Azure Portal

To create an alias record set, you first create a public DNS for the DNS domain you own. To do both these things using the Azure Portal, follow these steps:

Log in to the Azure Portal, type DNS zone in the search box to locate the service, and select it from the list that appears.

Click the Create DNS Zone button to start the Create DNS Zone wizard. (See Figure 6-10.)

FIGURE 6-10 Create a reverse DNS lookup zone.

In the Basics tab of the Create DNS Zone wizard, enter the following information (see Figure 6-11), and click Next:

Subscription Select the subscription to host the DNS zone.

Resource Group Select the resource group you want to use to host the reverse lookup DNS zone. Alternatively, to create a new resource group, click the Create New link and follow the prompts.

Name Enter a name for the DNS domain that you own.

Resource Group Location This will be populated automatically based on the location of the resource group you just selected.

FIGURE 6-11 The Basics tab of the Create DNS Zone wizard.

In the Tags tab, enter any tags required for the DNS zone or leave the fields blank (see Figure 6-12). Then click Next.

FIGURE 6-12 Set up tags.

In the Review + Create tab, review your settings and click Create.

After the zone has been created, open its blade in the Azure Portal. Then, in the Overview tab, click the Record Set button. (See Figure 6-13.)

FIGURE 6-13 The Record Set button in the Overview tab.

In the Add Alias Record Set dialog box, enter the following information, and click OK. (See Figure 6-14.)

Name Enter a name for the record set.

Type Select the type of DNS record you want to create—in this case, A – Alias Record to IPv4 Address.

Alias Record Set Select the Yes option button to create an alias record set.

Alias Type Select Azure Resource option button.

Subscription Select the subscription in which to create the alias record set.

Azure Resource Select the Azure resource to associate with the alias record set.

TTL Enter the time to live (TTL) for the record set. (I typed 1.)

TTL Unit Select the TTL unit from the drop-down list. (I selected Hours.)

FIGURE 6-14 Create an alias record set.

Reverse DNS lookup

Azure private DNS zones support reverse DNS lookups using reverse DNS lookup zones for private IP addresses associated with VMs hosted in linked virtual networks. This can help in scenarios where applications require reverse lookups for verification purposes.

Reverse DNS lookups, which use Reverse DNS zones, return two FQDNs:

The FQDN containing the name of the VM with a default suffix of internal.cloudapp.net.

If auto-registration is enabled, an additional FQDN with the name of the VM and the suffix for the private DNS domain name.

Reverse DNS lookup zone walkthrough

The following section walks you through the process of creating a reverse DNS lookup zone using the Azure Portal, Azure PowerShell, and the Azure CLI.

Using the Azure Portal

To create a reserve DNS lookup zone using the Azure Portal, follow the steps as detailed here:

Log in to the Azure Portal, type DNS zone in the search box to locate the service, and select it from the list that appears.

Click the Create DNS Zone button to start the Create DNS Zone wizard. (See Figure 6-15.)

FIGURE 6-15 Create a reverse DNS lookup zone.

In the Basics tab of the Create DNS Zone wizard, enter the following information (see Figure 6-16), and click Next:

Subscription Select the subscription to host the DNS zone.

Resource Group Select the resource group you want to use to host the reverse lookup DNS zone. Alternatively, to create a new resource group, click the Create New link and follow the prompts.

Name Enter a name for the reverse DNS lookup zone in the format <IPv4 network prefix in reverse order>.in-addr.arpa.

Resource Group Location This will be populated automatically based on the location of the resource group you just selected.

FIGURE 6-16 The Basics tab of the Create DNS Zone wizard.

In the Tags tab, enter any tags required for the reverse DNS lookup zone or leave the fields blank (see Figure 6-17), and click Next.

FIGURE 6-17 Set up tags.

In the Review + Create tab (see Figure 6-18), review your settings and click Create.

FIGURE 6-18 Review and create a reverse DNS lookup zone.

Using Azure PowerShell

You can create a reverse DNS lookup zone with Azure PowerShell using the New-AzDNSZone command with various switches to set the zone’s parameters. For example, to create the same reverse DNS lookup zone as you did in the preceding section, you use the following code:

Click here to view code image

#Create reverse DNS zone
New-AzDNSZone -Name 4.168.192.in-addr.arpa -ResourceGroupName RG01

Using the Azure CLI

You can create a reverse DNS lookup zone with the Azure CLI using the az network dns zone create command with various switches to set the zone’s parameters. The following script shows you how to set up the same zone you created in the preceding sections with the Azure CLI:

Click here to view code image

#Create reverse DNS zone
az network dns zone create --resource-group RG01 --name 4.168.192.in-addr.arpa

Zone delegation

With Azure DNS, you can only host domains authoritatively. Azure DNS does not provide recursive DNS services. An authoritative DNS server is responsible for responding to all DNS queries related to the DNS records only in the zones hosted on it. A recursive DNS server does not host any DNS zones. It uses authoritative servers to respond to all DNS queries it receives.

To better understand this, consider a couple different scenarios. Imagine an environment in which the Azure DNS service hosts the domain contoso.com and receives different DNS queries:

DNS query for name resolution of www.contoso.com In this scenario, Azure DNS hosts the domain contoso.com, so it checks its record sets to identify whether there is a record for www. If so, it responds with the value for that record. If the record does not exist, it responds by stating no such record exists for that domain.

DNS query for name resolution of www.fabrikam.com In this scenario, Azure DNS does not host the DNS zone fabrikam.com. Hence, it is not able to respond to DNS queries, and the queries will fail.

Considering this, if name resolution for other non-authoritative domains is required for the VMs in an environment, you would have to set recursive DNS servers on the Azure VMs.

Best practices

Following are some best practices for the Azure DNS service that can help secure the service against attacks or unwarranted modifications:

Use Azure role-based access control (RBAC) Azure DNS supports Azure RBAC to control access to the DNS service. Use RBAC to limit access to the DNS service on the service, zone, or record level based on the access control requirements of the organization. Incorrect DNS records can result in application outages, so controlling access to avoid unwarranted changes to the DNS service is critical.

Use the DNS Zone Contributor role Azure provides a built-in role called DNS Zone Contributor. Users with this role can manage DNS resources—but that’s all. Use this role if there are individuals in the organization who require access to the DNS service only for management purposes.

Use custom roles In addition to the DNS Zone Contributor role, you can create custom roles to limit access to specific DNS functions—for example, creating and modifying A records but not managing other record types. After you identify or create the required roles, you can ensure that access is assigned only on the required level. The available levels are as follows:

Service-level Azure RBAC Permissions are assigned on the Azure DNS service level, enabling the user to manage all zones hosted in the service.

Zone-level Azure RBAC Permissions are granted on the zone level, enabling the user to manage all records in that zone.

Record-set level Azure RBAC Permissions are assigned on the record set level, enabling the user to manage specific record sets.

You manage all these permissions using the Azure Portal, Azure PowerShell, or the Azure CLI.

Use resource locks Use the resource locks feature to prevent access for making changes to the DNS zones or protect them for deletion. Your options are as follows:

Prevent all changes Creating a read-only lock prevents any changes from being made to the DNS zone. This makes it possible to respond to DNS queries but prevents further changes to the records until the lock is modified or removed. (See Figure 6-19.)

FIGURE 6-19 Create a read-only resource lock.

Prevent individual records deletion You can set resource locks on the record-set level to prevent changes to or deletions of individual DNS records. You can currently configure record set–level resource locks using Azure PowerShell only—not the Azure Portal or the Azure CLI. The following PowerShell snippet shows how to set up a lock on an individual DNS record:

Click here to view code image

#Define the required variables
$locklevel = "Read-only"
$lockname = "Read-only"
$dnsresource = "contoso.com/www"
$type = "Microsoft.Network/DNSZones/A"
$rg = "RG01"
# Lock a DNS record set
New-AzResourceLock -LockLevel $locklevel -LockName $lockname -ResourceName
$dnsresource -ResourceType $type -ResourceGroupName $rg

Prevent complete zone deletion Creating a no-delete lock prevents the accidental or malicious deletion of a DNS zone. (See Figure 6-20.)

FIGURE 6-20 Create a no-delete resource lock.

Set up monitoring and alerting Azure DNS provides metrics to monitor the performance of hosted DNS zones. In addition, you can integrate with Azure DNS with Azure Monitor to monitor key metrics to gauge performance and identify bottlenecks. Some key metrics include the following:

QueryVolume

RecordSetCount

RecordSetCapacityUtilization

At a minimum, it is recommended that you set up alerting for performance parameters and critical administrative actions.

Integrate with other Azure services If required, you can use Azure DNS to publish custom domain records for other Azure services in use in the environment. This includes Azure Application Gateway, Azure Load Balancer, Azure Traffic Manager, Azure App Service, Azure Resource Manager VMs, and Azure Cloud Services. For each service, based on its IP address configuration, you can create a corresponding DNS A or CNAME record. You can create DNS CNAME records for services with dynamically allocated IP addresses. For services using a static IP address, you can create DNS A records.

Chapter 7

Azure Traffic Manager

Overview

Azure Traffic Manager is a service that performs DNS-based load balancing of incoming traffic to internet-facing endpoints. Traffic Manager service facilitates the distribution of traffic globally across applications hosted in various Azure regions or external endpoints hosted in client environments or other cloud services.

One of the most important aspects of Azure Traffic Manager is that it performs DNS-based redirects based on traffic-routing policies defined in the service. It does not act as a front-end gateway or proxy for application traffic. This implies that no application traffic passes through the service; it is simply redirected to designated endpoint(s), after which the client connects to the designated application endpoint directly. It also shows that Traffic Manager works on layer 7 (the application layer) of the OSI model.

You can define different types of endpoints for use with Traffic Manager. You can also deploy different routing algorithms to handle the incoming traffic based on your organization’s unique availability requirements and application design. This is covered in more detail later in this chapter.

Note

Microsoft designed Traffic Manager to be extremely resilient. Even an Azure region failure will not bring the service offline, because Microsoft built redundancy into the service to handle these types of scenarios.

Traffic Manager features

Traffic Manager has a number of key features to improve the availability, resiliency, and redundancy of client applications. These include the following:

Multiple routing algorithms to meet complex requirements Traffic Manager provides different traffic-routing algorithms that can be used in isolation or in combination based on the needs of the client environment. Each type of algorithm improves the redundancy and availability of the application in different ways. Combining routing methods can help address even the most complex scenarios.

Increased application resiliency and availability Traffic Manager continuously monitors application endpoints and automatically routes traffic based on endpoint availability. Traffic to offline endpoints is automatically paused until the endpoints come back online.

Enhanced application performance You can set up Traffic Manager to route traffic to endpoints that offer the lowest latency to the end client to improve the user experience.

Support for non–Azure-based endpoints Traffic Manager supports the use of public-facing endpoints hosted both inside and outside Azure (on-premises environments, other cloud services, etc.). A single Traffic Manager routing profile can contain endpoints from different sources to address different scenarios, such as on-premises to Azure cloud migration, IaaS to PaaS migration, disaster recovery to Azure, and so on.

Improved application scalability Traffic Manager can help organizations provide scaling capabilities to their applications by bursting to use Azure cloud capacity in the event of resource crunch issues in their primary hosting locations.

Reduced maintenance windows Traffic Manager can help reduce or eliminate maintenance windows for application upgrades or security updates by routing traffic to endpoints that are not under maintenance.

Design concepts and deployment considerations

The Traffic Manager service can be integrated into your environment in different ways, depending on your workloads, redundancy requirements, and routing requirements. To identify the right strategy for your workloads, it is important to understand the different components that make up the Traffic Manager service, as well as how they function. This will help you to identify all the different factors to consider when designing and deploying this service in your Azure environment.

Traffic Manager endpoints

Traffic Manager allows the use of different endpoint types for traffic distribution. Based on the routing method defined in the Traffic Manager profile, Traffic Manager assesses endpoint availability and applies the routing algorithm to determine which endpoint to route traffic to.

Traffic Manager supports three types of endpoints:

Azure endpoints These are services hosted inside Azure—for example, using App Services or virtual machines (VMs) running a public-facing application.

External endpoints These are referred to services hosted outside Azure, either on-premises or by another hosting provider (including other cloud providers). Traffic Manager refers to these using either their IPv4/IPv6 address or FQDN.

Nested endpoints These combine multiple Traffic Manager profiles to create more complex traffic routing configuration. This helps to address the requirements of larger deployments.

Note

When setting up a Traffic Manager profile, be aware that there are no limits on the number of endpoints that can be configured in each Traffic Manager profile. Also keep in mind that each Traffic Manager profile can contain a mix of different endpoint types.

The following sections discuss each endpoint type in more detail.

Azure endpoints

Azure-hosted services are set up as Azure endpoints in Traffic Manager. A number of Azure services are supported for use with Traffic Manager, including the following:

Web apps

Web app slots

VM-connected public IP addresses

Load balancer–connected public IP addresses

PaaS cloud services

The main benefit of using Azure endpoints is that Azure can detect the state of services, such as Azure Web Application service, to confirm whether it is running or stopped. Azure can then automatically stop billing for Traffic Manager while the back-end endpoint is stopped and resume once it’s back online. This feature is not supported for public IP address–based endpoints, as no detection of the actual resource is possible in that instance.

Note

Only web apps on the Standard SKU are supported. Any change to an unsupported SKU results in traffic to that web app being discontinued.

External endpoints

External endpoints are services referenced only using public IPv4/IPv6 addresses or FQDNs, or hosted outside Azure. These include applications hosted in on-premises environments and in other hosted or non-Microsoft cloud environments. They also include applications hosted in Azure that must be published using only their IPv4/IPv6 addresses.

For some Azure services, such as Azure Web Application service, the Traffic Manager profile can reference only one endpoint per region as an Azure endpoint. However, if added as an external endpoint using the web app’s FQDN, this limitation can be overcome.

With Azure endpoints, billing can be automatically turned off for offline or deactivated Azure-hosted services. The same does not apply to external endpoints, however. The only way to turn off billing for an external endpoint is to disable or delete the endpoint.

You can combine external and Azure endpoints in the same Traffic Manager profile. For example, an application’s FQDN could be routed to endpoints hosted in an on-premises datacenter and an Azure VM. This does not apply for endpoints that are specified using IPv4 or IPv6 addresses, however. These can only be set up individually as external endpoints.

When Azure and external endpoints are combined in a single Traffic Manager profile, various design scenarios become viable. These include the following:

Increased resiliency through the provision of active-active or active-passive failover options for applications hosted between Azure and on-premises or Azure and other hosting provider–managed environments.

Resource-burst capabilities for on-premises applications through the provision of capacity in the Azure cloud to scale as and when required.

Improve application performance through the hosting of applications closer to the user’s region and through the use of performance-based routing to make on-premises applications available with reduced latency.

Nested endpoints

Nested endpoints are a combination of multiple Traffic Manager profiles consisting of different endpoints. A “parent” profile is set up with an endpoint pointing to a “child” profile that contains different endpoints than the parent profile. Such a combination creates complex routing logic that can help provide global scale and redundancy for an application. The endpoints in the parent and child profile can be different and can even be other nested Traffic Manager profiles (discussed in the next section).

Nested Traffic Manager profiles

Nested Traffic Manager profiles combine multiple profiles to enable complex traffic-routing capabilities. This works well for larger application-deployment scenarios that call for a mixture of routing capabilities to address the complex needs of the organization.

In general, a single Traffic Manager profile can use a single traffic-routing method. With nested profiles, you can define a “child” Traffic Manager profile inside a “parent” profile to serve as an endpoint. This allows multiple profiles with different routing policies and endpoint types to work together in a single nested profile to address complex routing requirements.

Figure 7-1 shows how a parent profile is set up to use the performance-traffic routing method (discussed in a moment) and how one of its endpoints is a child profile set up to use the weighted-traffic routing method (again, discussed in a moment) and its own set of endpoints. This build allows for a small subset of traffic to be routed to the “trial” endpoint to test application upgrades or patches without affecting the majority of the environment.

FIGURE 7-1 Azure Traffic Manager service overview.

Traffic routing methods

One of the most important aspects of Traffic Manager is to understand the different traffic-routing methods and algorithms it provides. There are various routing methods available, each with different capabilities, that can be used individually or combined in nested profiles to address various complex requirements. Four of these methods are as follows:

Priority traffic routing

Weighted traffic routing

Performance traffic routing

Geographic traffic routing

Note

Each of these methods includes the capability to monitor and automatically failover to the next available endpoint per the profile configuration.

You can configure any of these traffic-routing methods as part of a Traffic Manager profile and apply it to a set of endpoints. The routing method you set up can be swapped out at any time and the changes applied with zero downtime. However, as mentioned, to address more complex scenarios, you can nest Traffic Manager profiles to apply multiple routing methods in combination. The following sections discuss these traffic-routing methods in more detail.

Multi-value and subnet-based traffic routing

In addition to priority, weighted, performance, and geographic traffic routing, Traffic Manager supports two other types: multi-value traffic routing and subnet-based traffic routing.

In scenarios in which all active endpoint addresses must be returned to the end client, you can use multi-value traffic routing to define all the different IPv4/IPv6 endpoints. By default, two active endpoints are returned as part of any reply, but this number can be increased if required. If an endpoint is dual-homed—that is, it uses both IPv4 and IPv6 addresses—multi-value traffic routing will provide both addresses to the end client, so the end client can decide which one to use when initiating the connection.

In contrast, subnet-based traffic routing maps different client subnets to different application endpoints. Requests originating from a specific subnet are then routed based on the endpoint map associated with that subnet.

Priority traffic routing

Suppose your organization has designed an application such that a single primary server runs the application and one or more backup servers handle application traffic in the event that the primary server fails. This might be because application limitations prevent it from supporting more than one active server at a time. Or it could be meant to address disaster-recovery scenarios in which the secondary endpoint cannot be used until the primary endpoint is offline.

In such instances, the most effective traffic-routing method is the priority method. Priority traffic routing defines the primary endpoint to route any client traffic to, and one or more backup endpoints, organized by priority, to failover to in case of a problem. The highest-priority endpoint receives traffic until it becomes unavailable, at which stage the traffic is redirected to the second-highest-priority endpoint. (See Figure 7-2.)

FIGURE 7-2 Priority traffic routing.

With this method, all endpoints have a unique priority; that is, no two endpoints can have the same priority. Unless an endpoint has been taken offline or disabled—for example, for maintenance purposes—or experiences an outage, it will automatically receive traffic if the endpoint that is prioritized immediately above it experiences a problem. If no priority has been defined for an endpoint, it is automatically assigned one based on the order in which it was added to the service.

Weighted traffic routing

In scenarios in which traffic must be distributed evenly across a set of endpoints, weighted traffic routing is often the most suitable method. With this method, you can define a weight for each application endpoint; endpoints with higher weights receive more traffic. Put another way, the higher the endpoint’s weight, the higher its priority. (See Figure 7-3.)

FIGURE 7-3 Weighted traffic routing.

Note

If no weight is assigned to an endpoint, Traffic Manager assigns a weight of 1 by default.

You can assign the same weight to multiple endpoints to distribute traffic evenly across them. This approach is effective in scenarios in which traffic must be routed first to multiple active endpoints in a primary location and second to multiple active endpoints in a failback or disaster-recovery site.

Be aware that DNS responses are cached by end clients and by recursive DNS servers servicing those clients. This can result in traffic being distributed unevenly, as DNS caching behavior cannot be centrally controlled across all possible access points. You should take this into account when deciding whether this is the right routing method for your environment.

Performance traffic routing

With performance traffic routing, Traffic Manager routes traffic based on which endpoint will provide the lowest latency. Sometimes this will be the endpoint that is closest to the client IP address, but not always. To determine whether another endpoint might offer lower latency, Traffic Manager refers to an internet latency table, which it generates and maintains by tracking round-trip times between source IP ranges and various Azure regions. (See Figure 7-4.) If the Azure region identified by Traffic Manager as offering the lowest latency contains multiple active endpoints, Traffic Manager automatically distributes traffic to that region evenly across all the available endpoints.

FIGURE 7-4 Performance traffic routing.

Note

Traffic Manager does not monitor the actual performance or availability of an endpoint itself to determine if it will offer the lowest latency. It assesses latency performance based only on the internet latency table. This latency table may be updated due to changes in the global internet routing infrastructure or performance, or new Azure regions coming online.

Performance traffic routing supports the use of external endpoints hosted outside Azure and of nested endpoints. In these cases, you must define the location of the endpoint by selecting the Azure region closest to that endpoint. If the endpoints in the closest Azure region are offline or degraded, Traffic Manager will move traffic to active endpoints in the next-closest Azure region.

The source IP of the endpoint performing the DNS query also helps gauge latency. In most cases, this will be a recursive DNS server; therefore, the Azure region returned in the DNS response will be the one closest to the DNS server. If an organization uses a centralized DNS server for all clients hosted in its datacenter, traveling employees may have to connect to the Azure region closest to the organization’s datacenter, even if they themselves are connecting from the other side of the globe. You’ll need to factor this in when choosing which traffic-routing method to use.

Geographic traffic routing

Geographic traffic routing defines the endpoints to which traffic should be routed based on the origin of the request. For example, you might route traffic from different locales to different endpoints based on data-sovereignty, content-localization, or compliance requirements.

You can define multiple endpoints to address traffic from different regions by redirecting them to specific external or nested endpoints hosted in Azure. You must assign each endpoint a set of geographic regions so that Traffic Manager understands how traffic must be routed after it determines the source geography of the DNS request. You can use different levels of granularity to define the geographic region:

World Any region.

Region A specific region—for example, Asia, Africa, North America, Australia/Pacific, and so on.

Country A specific country—for example, India, France, United States, Canada, and so on.

State/Province A specific state or province—for example, Australia-Victoria, Canada-Victoria, Canada-Ontario, USA-Florida, and so on (currently applicable only to Australia, Canada, and the US).

Depending on the regions associated with an endpoint, traffic is routed only to endpoints located in those regions. Routing occurs in the following order, based on the endpoint’s configuration (see Figure 7-5):

State/Province

Country

Region

World

FIGURE 7-5 Geographic traffic routing.

There are a few key points to note about this traffic-routing method:

Each geographic region can be associated with only one endpoint.

Traffic Manager does not check the health of the endpoint. It returns that endpoint as a response, even if the endpoint is in an unhealthy state.

If a request matches the geographic mapping of multiple endpoints, the one that is defined with granularity closest to the request’s region is returned.

The use of nested endpoints is recommended to define a geographic mapping to cover unknown sources or scenarios in which endpoints are offline, as multiple endpoints can be defined in a nested endpoint.

It’s a best practice to use geographic traffic routing with nested Traffic Manager profiles so you can configure multiple endpoints to address all unknown traffic sources.

Disabled endpoints are excluded from any response.

Endpoint monitoring

One of the most important features of Traffic Manager is its ability to automatically failover traffic away from non-functional endpoints. This requires continuous monitoring to ensure that information about the health of every active endpoint is up to date. Any change in status that identifies an endpoint as offline, deactivated, or disabled leads to an action based on the routing method and endpoint configuration in place. Fortunately, Azure Traffic Manager has a built-in endpoint-monitoring feature that you can set up to monitor the health of endpoints and perform automated failover to other active or passive endpoints. This involves selecting a monitoring protocol and other critical settings. (You’ll learn how to configure this feature in the next section.)

Endpoint failover and recovery

Traffic Manager periodically checks the health of every endpoint, including unhealthy endpoints. Traffic Manager detects when a previously unhealthy endpoint becomes healthy and brings it back into rotation. An endpoint is deemed unhealthy in the following scenarios:

If the monitoring protocol is HTTP or HTTPS A non-200 response or a response that doesn't include the status range specified in the Expected Status Code Ranges setting is received. (This includes a different 2XXcode or a 301/302 redirect.)

If the monitoring protocol is TCP A response other than ACK or SYN-ACK is received in response to the SYN request sent by Traffic Manager to attempt to establish a connection.

Timeout Any other connection issue results in the endpoint being not reachable.

When such a scenario occurs, traffic is failed over to remaining online endpoints based on the routing policies defined in the Traffic Manager profile.

Traffic Manager walkthrough

The following sections walk you through the process of setting up Azure Traffic Manager using the Azure Portal, Azure PowerShell, and the Azure CLI.

Important

Before beginning this walkthrough, you should provision two VMs with public IPs in the Azure environment. Be sure to set up the DNS name for both VMs to enable them for use as Azure endpoints. You can set up IIS on both VMs so you can query each one while testing the Traffic Manager service. Book 1 in this series, Microsoft Azure Compute: The Definitive Guide, explains how to create VMs; see Chapter 1, “Azure virtual machines,” for help.

Using the Azure Portal

To set up Traffic Manager using the Azure Portal, follow these steps:

Log in to the Azure Portal, type Traffic Manager in the search box to locate the service, and select it from the list that appears. (See Figure 7-6.)

Click Create or Create Traffic Manager Profile to start the Create a Traffic Manager wizard. (See Figure 7-7.)

FIGURE 7-6 Searching for the Traffic Manager service.

FIGURE 7-7 Click Create Traffic Manager Profile.

In the Create Traffic Manager Profile wizard (see Figure 7-8), enter the following information and click Create:

Name Type a unique name for the profile.

Routing Method Select the desired routing method—in this case, Performance.

Subscription Select the subscription to host the profile.

Resource Group Select the resource group you want to host the profile. Alternatively, click the Create New link and follow the prompts to create a new profile.

Resource Group Location This value is automatically populated based on the resource group you select.

FIGURE 7-8 Set up profile settings.

After the Traffic Manager profile is created, open its service configuration blade.

In the left pane, click Endpoints. Then click Add. (See Figure 7-9.)

FIGURE 7-9 Add a Traffic Manager endpoint.

The Add Endpoint wizard starts (see Figure 7-10). Enter the following information and click Add:

Type Select the type of endpoint you want to use.

Name Enter a unique name for the endpoint.

Target Resource Type Select the type of resource you want to add—in this case, Public IP address.

Public IP Address Select the public IP address you want to associate with the profile.

Custom Header Settings Add the host header information using the tags host: and customheader:.

Add as Disabled Select this check box if you want to add the endpoint now, but not make it live.

Repeat step 6 to add all necessary endpoints. Then verify they’ve been added correctly. (See Figure 7-11.)

FIGURE 7-10 Add endpoint.

FIGURE 7-11 Endpoints in Traffic Manager.

In the left pane of the Traffic Manager profile’s service configuration blade, click Configuration. Then enter the following configuration information in the right pane of the blade (see Figure 7-12):

Protocol Select the protocol you want to use (HTTP, HTTPS, or TCP) to monitor application health.

Port Specify the application port to be queried by Traffic Manager to verify endpoint health.

Path Specify a path to identify which endpoint should be monitored. This can be a relative path, such as a forward slash (/); a relative path, such as a forward slash (/) and the name of the web page; or a relative path, such as a forward slash (/) and the name of a file.

FIGURE 7-12 Configure endpoint monitoring.

Note

This setting applies only when HTTP or HTTPS is selected for the Protocol parameter.

Custom Header Settings Set the custom HTTP header to use to connect to the endpoint. This header can be defined at a profile level (to apply to all endpoints) or at an individual endpoint level (to apply only to that endpoint). The header can also be applied at both the profile and endpoint level to accommodate custom endpoint requirements.

Note

The custom header can help in tagging traffic originating from Traffic Manager so it can be processed differently on the receiving application end.

Expected Status Code Ranges Set the status codes to confirm successful connectivity. Success code responses appear in the format 200–299, 301–301.

Note

This setting is relevant only for the HTTP and HTTPS protocols and is set up only at the Traffic Manager profile level.

Probing Interval Specify a probing interval to define how often an endpoint’s health check should be performed. There are options: 30 (seconds), which is the default, and 10 (seconds), which is referred to as fast probing. (Note that additional service charges apply when you select the fast probing option.)

Tolerated Number of Failures Specify the total number of failures to tolerate before initiating failover. This parameter can be set to any value between 0 and 9, with 0 implying that a single failure will result in the endpoint being moved out of service. (The default value is 3.)

Probe Timeout Specify a response timeout value appropriate for your environment. This setting defines the total time the probing agent must wait for a response before assuming a health probe check has failed. This value depends on the Probing Interval setting. If Probing Interval is set to 30 (seconds), Probe Timeout must be set between 5 and 10 (seconds). (The default value is 10.) If Probing Interval is set to 10, Probe Timeout must be set between 5 and 9. (The default value is 9.)

Click the Overview tab and browse to the DNS name shown in the right pane to test whether you are connecting to one of the two VMs you provisioned as the endpoints. If so, turn off that Azure VM and repeat the process to validate that you are now connected to the other VM. (See Figure 7-13.)

FIGURE 7-13 Traffic Manager Overview tab.

Using Azure PowerShell

You can create a Traffic Manager profile using Azure PowerShell with the New-AzTrafficManagerProfile command and various switches to set the profile’s parameters. The following code shows you how:

Click here to view code image

#Query Resource ID for the endpoints. Record these for use later in the script.
Get-AzResource -Name "VM01-PIP01" | select ResourceID
Get-AzResource -Name "VM02-PIP01" | select ResourceID
#Define required variables
$AzureRegion="EastUS2"
$RG="RG01"
$TrafficMgrprofile="TrafficManager-MSBP-01"
#Create Traffic Manager Profile
New-AzTrafficManagerProfile `
-Name $TrafficMgrProfile `
-ResourceGroupName $RG `
-TrafficRoutingMethod Performance `
-ProfileStatus Enabled `
-MonitorPath '/' `
-MonitorProtocol "HTTP" `
-RelativeDnsName $TrafficMgrProfile `
-Ttl 30 `
-MonitorPort 80
#Create Traffic Manager Endpoint-01
#Replace the value for TargetResourceID with the one you gathered earlier for "VM01-PIP01"
New-AzTrafficManagerEndpoint -Name "Endpoint01" `
-ResourceGroupName $RG `
-ProfileName "$TrafficMgrProfile" `
-Type AzureEndpoints `
-TargetResourceId /subscriptions/7719ec11-92dd-457c-b393-5adc483e4c79/resourceGroups/RG01/
providers/Microsoft.Network/publicIPAddresses/PublicIP-01 `
-EndpointStatus "Enabled"
#Create Traffic Manager Endpoint-02
#Replace the value for TargetResourceID with the one you gathered earlier for "VM02-PIP01"
New-AzTrafficManagerEndpoint -Name "Endpoint02" `
-ResourceGroupName $RG `
-ProfileName "$TrafficMgrProfile" `
-Type AzureEndpoints `
-TargetResourceId "/subscriptions/7719ec11-92dd-457c-b393-5adc483e4c79/resourceGroups/RG01/
providers/Microsoft.Network/publicIPAddresses/publicip-02" `
-EndpointStatus "Enabled"

Using theAzure CLI

You can create a Traffic Manager profile using the Azure CLI with the az network traffic-manager profile create command and various switches to set the profile’s parameters. The following code shows you how:

Click here to view code image

#Query Resource ID for the endpoints. Record these for use later in the script.
az resource list --name "VM01-PIP01"
az resource list --name "VM02-PIP01"
#Define required variables
rg="RG01"
azureregion="eastus2"
trafficmgrprofile="TrafficManager-MSBP-02"
endpoint01name="endpoint01"
endpoint02name="endpoint02"
#Create Traffic Manager Profile
az network traffic-manager profile create \
                      --name $trafficmgrprofile \
                      --resource-group $rg \
                      --routing-method Performance \
                      --path "/" \
                      --protocol HTTP \
                      --unique-dns-name $trafficmgrprofile \
                      --ttl 30 \
                      --port 80
#Create Traffic Manager Endpoint-01
#Replace the value for TargetResourceID with the one you gathered earlier for "VM01-PIP01"
az network traffic-manager endpoint create \
    --name $endpoint01name \
    --resource-group $rg \
    --profile-name $trafficmgrprofile \
    --type azureEndpoints \
    --target-resource-id '/subscriptions/7719ec11-92dd-457c-b393-5adc483e4c79/resourceGroups
/RG01/providers/Microsoft.Network/publicIPAddresses/PublicIP-01' \
    --endpoint-status Enabled
#Create Traffic Manager Endpoint-02
#Replace the value for TargetResourceID with the one you gathered earlier for "VM02-PIP01"
az network traffic-manager endpoint create \
    --name $endpoint02name \
    --resource-group $rg \
    --profile-name $trafficmgrprofile \
    --type azureEndpoints \
    --target-resource-id '/subscriptions/7719ec11-92dd-457c-b393-5adc483e4c79/resourceGroups
/RG01/providers/Microsoft.Network/publicIPAddresses/PublicIP-02' \
    --endpoint-status Enabled

Best practices

Traffic Manager can be a critical component in your application design and is generally used for enabling complex application routing scenarios. It is recommended that you set up the service taking the following best practices into consideration:

Use RBAC to control access Limit access to Traffic Manager to required administrators. Making unauthorized changes to the service can result in outages. Generally, Traffic Manager is used for applications that require high levels of redundancy and availability; hence it is imperative that you keep the access to the service restricted. You can add admins who require access to manage Traffic Manager configuration to the Traffic Manager Contributor role in Azure instead of providing them with Subscription Owner or other extended access. This role limits access to managing profiles.

Set up Real User Measurements When using the performance-based routing algorithm, Traffic Manager must direct traffic based on the latency between the incoming client endpoint and the different Azure regions where the application is hosted and online. To achieve this, Traffic Manager maintains an internet latency table that monitors and records the latency between different client networks to active Azure regions for that application. You can obtain more accurate measurements at the application level to fine-tune this logic by enabling a feature called Real User Measurements. This feature embeds a piece of code in the application, which is used by end-user devices to test latency from those devices to the various active Azure regions hosting the application. This information is then shared with the web application, which forwards it to Traffic Manager. Because this information is collected over and over again, it helps Traffic Manager perform a deeper analysis of latency from those networks and redirect incoming traffic more accurately.

Enable Real User Measurements using the Azure Portal

Log in to the Azure Portal and browse to the Traffic Manager profile you created in the walkthrough earlier in this chapter.

In the left pane, click Real User Measurements. (See Figure 7-14.)

FIGURE 7-14 Real User Measurements.

In the right-pane, click Generate Key (see Figure 7-15) to create a unique key and measurement script to be embedded into the web application.

FIGURE 7-15 Generate a key.

Copy the measurement script and paste it into an HTML page that your end users consistently visit when accessing the web application—for example, the home page. (See Figure 7-16.)

FIGURE 7-16 Real User Measurements key and JavaScript code.

Note

It is important that you use the code as provided. Any changes to this code can result in unpredictable behavior.

Enable Traffic View Traffic View is an add-on service in Traffic Manager that enables you to monitor and gain deeper insights into the traffic to the Traffic Manager service. Using Traffic View, you can gain a better understanding of the following:

Where the source traffic for an application is generated from

The volume of traffic from different source client regions

Latency experienced by users in different source client regions

Traffic patterns between the source client regions and the Azure regions hosting their endpoints

These insights can help you make better decisions about which regions to scale in to address latency or performance issues, or in which to invest further for growth based on the volume of traffic currently being generated.

Use Azure Activity and Azure Monitor to centralize security logs Azure Activity log captures all information related to any operations performed on any Traffic Manager resources on the control plane level. You can monitor these logs in the Activity Log section of the service or ingest them into a central repository via Azure Monitor for data aggregation and analysis.

Enable threat detection All Traffic Manager logs can be forwarded and centralized using a SIEM such as Azure Sentinel or a third-party SIEM solution. You can use this to perform analysis and automate actions for any threats and breaches recorded in the logs.

Use Azure Policy to standardize configuration You can use Azure Policy to monitor the configuration of Traffic Manager resources to ensure they are in line with organizational standards. Azure Policy can detect whether Traffic Manager resource logging is enabled to ensure all operations on the control plane are recorded and centrally stored for security and compliance.

Enable monitoring and alerts using Azure Monitor Traffic Manager provides a couple of key service-specific metrics that can be monitored and can generate alerts using Azure Monitor:

Endpoint status by endpoint This metric monitors and confirms the health status of all endpoints in a Traffic Manager profile. It records whether an endpoint is up or down, and the value can be monitored by Azure Monitor to raise alerts as needed.

Queries by endpoint returned This metric monitors the load on different endpoints based on the number of queries received by the Traffic Manager profile and individual endpoints for a specific period of time. You can set up alerts to flag when there is an imbalance in query distribution, and you can address application capacity if alerts persist for a given period of time.

Chapter 8

Azure Front Door

Overview

Azure Front Door is a fully managed scalable global service that provides a secure front end for any web application. It uses Microsoft’s global edge network to improve speed of access and to provide better security and enhanced scalability for consumer-facing or internal web applications.

Organizations that have a global audience for their web applications can benefit from the proximity of the web application to the end user’s region. To provide such an audience with a consistent experience, organizations can use content delivery networks (CDNs). The Azure Front Door service provides CDN capabilities along with security and routing features that are part of a Web Application Firewall (WAF) and Azure Traffic Manager services.

The Front Door service works on layer 7 (the application layer) of the OSI model. It uses the anycast protocol with split TCP; this provides the traditional CDN as well as security features such as distributed denial-of-service (DDoS) protection. The Front Door service’s traffic-routing functionality provides global load balancing and automated failover capabilities to any public-facing services hosted in or external to Azure. Regional failure-handling capabilities are built into the service, ensuring it remains online in disaster scenarios.

Key features

Azure Front Door service provides a number of key features and benefits:

Improved application performance The Front Door service accelerates application performance using the split TCP–based anycast protocol.

Global scalability The Front Door service provides global scalability for web applications to allow access by users via edge locations closest to them.

Intelligent traffic routing The Front Door service can perform intelligent traffic routing to back-end services hosted inside or outside of Azure. Different routing algorithms support complex routing requirements.

Monitoring and automated failover Front Door provides health probes to monitor back-end resources and trigger automated failover actions.

WAF features The Front Door service provides all the features provided by WAF, such as URL-based routing, URL rewrites, session affinity, SSL offloading, custom domain and certificate management, and application security.

Multiple website hosting The Front Door service supports multiple websites at the same time, allowing for efficient use of the application infrastructure.

Native support for advanced features The Front Door service natively supports dynamic site acceleration (DSA), TLS/SSL offloading, end-to-end IPv6 connectivity, and the HTTP/2 protocol.

Figure 8-1 shows how the Front Door service can support different scenarios, including the following:

Failover between Azure regions

Traffic routing–based URL paths

Different back-end host types

FIGURE 8-1 Azure Front Door service.

Design concepts and deployment considerations

Azure Front Door service provides different components and features that can be applied in combination to make full use of the service’s CDN, WAF, and other security features. Before incorporating these features into your design, it helps to understand them in more detail so you can identify how best to apply them in any given environment to meet your organization’s application, security, and compliance needs. The following sections review various components and features of Azure Front Door service.

Back ends

Back ends are web-based applications deployed inside or outside of Azure. Back end refers to the server or service hosting the application front end. Front Door service supports applications hosted on any on-premises infrastructure or hosting or cloud infrastructure provider. Back ends can be referenced using their host name or public IP address.

Front Door service supports a variety of Azure services for use as back ends, including the following:

App Service

Cloud Service

Azure Storage

Public IP address

For any other Azure or non-Azure services, custom hosts can be defined.

A back end can contain multiple instances of the same web application hosted in the same or different Azure regions or in a hybrid setup. You can assign priorities and weight to the different back-end endpoints to define which ones should be used as the primary endpoints and which should be used as backup.

Back-end pools

Multiple back-end endpoints can be combined into a back-end pool, which receives traffic for the web application. These endpoints can serve a web application hosted in the same or different Azure regions or in a hybrid setup between on-premises, Azure, and other cloud-hosting services.

A back-end pool in the Front Door service describes the set of back ends that receive similar traffic for an app. In other words, it's a logical grouping of app instances across the world that receive the same traffic and respond with expected behavior. These back ends are deployed across different regions or within the same region. All back ends can be in Active/Active Deployment mode or in Active/Passive configuration.

Note

You configure monitoring and load balancing for the back-end endpoint on the back-end pool.

Health probes

The Front Door service can monitor the health of back-end endpoints using health probes. Health probes help the Front Door service identify the back ends that are currently available to handle incoming client requests. A health probe is a synthetic request from the Front Door service to each of the back ends over HTTP/HTTPS, defined during the configuration phase. The response from the endpoints helps the Front Door service determine the best back end to route the incoming traffic.

The service takes into account different parameters to determine the back end that is best-suited for a given request. This includes the following:

Identifying enabled endpoints and ignoring disabled ones

Identifying endpoints that have no existing health probe errors and ignoring endpoints that do

Accounting for the latency for each healthy back end in its calculations

Note

If the Front Door service determines that all back ends are offline, it assumes they are all healthy and continuously routes traffic between all of them until at least one healthy back end is back online.

Load balancing

The back-end pool holds the configuration for a web application’s load-balancing policies. These settings define how the health probe responses are evaluated to determine whether a back end is healthy or not, based on the following parameters:

Sample size This establishes how many samples of health probes should be considered for health evaluation.

Successful sample size This defines how many successful samples out of the collected samples based on the sample size qualify an endpoint to be deemed healthy.

Latency sensitivity This defines how the endpoints’ latency will be considered when making routing decisions.

Traffic routing

The Front Door service supports different traffic-routing algorithms that define how to identify the most appropriate back-end endpoint for incoming application traffic. When the Front Door service receives HTTP/HTTPS traffic matching a host header, the traffic-routing algorithm helps identify the most appropriate back-end endpoint to connect to based on the active endpoints associated with it. All methods support automated monitoring and failover to active endpoints, but the basis of endpoint selection changes for each.

The four different traffic routing methods are as follows:

Latency-based routing This method identifies the endpoint with the least latency to the end user and routes traffic to that endpoint if it is available for use.

Priority-based routing This method identifies the primary endpoint that should receive application traffic and backup endpoints in case the primary is offline.

Weight-based routing This method identifies the different weights for each endpoint for traffic distribution. Traffic is evenly distributed among all endpoints that share the highest weight. If those back ends are unavailable, traffic is automatically routed to the next set of endpoints. Based on the acceptable latency range defined for the pool, traffic is evenly distributed when the endpoint is deemed to be within acceptable limits.

Session affinity This method ensures that incoming client requests from the same end client are sent to the same back-end instance. This is useful for applications that require session affinity to function correctly.

Note

You can combine multiple routing methods to address complex routing requirements and achieve faster and more efficient failovers.

URL rewrite

URL rewrite enables you to set up custom forwarding rules when constructing the URL request to route the request to the back end. This helps in scenarios in which traffic must be routed to a custom path for specific incoming requests due to page changes or masking.

Note

If you do not define a custom forwarding path for an application, traffic is always routed to the path defined in the incoming request.

In the example shown in Figure 8-2, a request to /path1 is forwarded to the custom path /path2 with a wildcard at the end to denote that it applies to all segments below that path. This results in all incoming requests for path1 being redirected to path2.

FIGURE 8-2 Set up URL rewrite.

URL redirect

The Front Door service supports URL redirect. This allows rules to be defined for traffic redirection based on protocol, app hostname, app path, and query string. Because this redirection is granular and works even on the path level, it can be configured for individual microservices as well as global redirections, thereby optimizing service usage.

Figure 8-3 shows the parameters in the Azure Portal for URL redirection. These include the following settings:

Route Type Set this to Redirect to make the redirection configuration options available.

Redirect Type This indicates the purpose of the redirect, which helps end clients correctly interpret the response from the service.

Redirect Protocol This indicates whether traffic is to be allowed only over HTTP or HTTPS or retained as is.

Destination host Destination host indicates whether the traffic must be redirected to a different hostname instead of the one indicated in the incoming request. This can help to redirect traffic to internal URLs. For example, traffic for https://www.fabrikam.com/* can be set to redirect to https://www.contoso.com/*.

Destination Path Set this to Replace if the path segment of a URL must be replaced with a different path. For example, traffic to https://www.fabrikam.com/* can be set to redirect to https://www.fabrikam.com/redirected-path.

Query String Set this to Replace to replace query string parameters in the redirected URL.

Destination Fragment This indicates a fragment of a URL to redirect to. This fragment is part of the URL after # character that helps a browser land on a specific section of a web page. You can use this setting to set up the redirected URL to use destination fragments.

FIGURE 8-3 Set up URL redirect.

Wildcard domains

The Front Door service supports the use of wildcard domains for mapping front-end endpoints in a profile. Using wildcard domains provides multiple benefits, such as the following:

It reduces the need to set up individual child domains in the Front Door service profile and facilitates HTTPS certificate binding for each domain.

You can simplify traffic-routing behavior for multiple subdomains using a single routing rule. For example, a single rule for *.domain.com can be used to define routing policies for subdomain1.domain.com, subdomain2.domain.com, subdomain3.domain.com, and so on.

You can easily bring new subdomains online without requiring changes to the Front Door service configuration. Policies that have already been defined are automatically applied to the new subdomain.

Rules Engine

The Rules Engines provided with the Front Door service give you the ability to define rules and control how incoming HTTP and HTTPS requests are handled at the edge. You can use this feature to address various requirements such as the following:

Enforce HTTP-to-HTTPS redirection so that all end-user traffic occurs only over a secure connection.

Prevent exploitation of browser-based vulnerabilities in HTTP Strict-Transport-Security (HSTS), X-XSS-Protection, Content-Security-Policy, X-Frame-Options, and Access-Control-Allow-Origin headers for Cross-Origin Resource Sharing (CORS) scenarios. You can also define security-based attributes with cookies.

Route requests to mobile or desktop versions of the application based on patterns in request header contents, cookies, or query strings.

Use redirect capabilities to return 301, 302, 307, and 308 redirects to the client to direct to new hostnames, paths, or protocols.

Dynamically modify the caching configuration of your route based on incoming requests.

Rewrite the request URL path and forward the request to the appropriate back end in your configured back-end pool.

Caching

The Front Door service has caching capabilities similar to those provided by CDNs, except the Front Door service also provides dynamic site acceleration and load-balancing features. The caching functionality helps to reduce the load on the back ends—for example, due to high demand for the service or to traffic generated by a DDoS attack. In these cases, caching results in the Front Door service edge nodes responding to client requests to prevent the attack or to prevent the requests from reaching the back-end nodes.

Cache-related features available in the Front Door service include the following:

Support for large file chunking The Front Door service can cache and deliver large files by splitting them into smaller (8 MB) chunks during ingestion from the back end. As one chunk is cached and delivered to the user, the Front Door service immediately initiates the retrieval of the next chunk. That way, it is available for delivery when the delivery of the previous chunk is complete. This continues until either the entire file is delivered or the client connection is terminated.

Note

The back end must support byte-range requests for large file chunking to work.

Dynamic content compression The Front Door service supports dynamic content compression on edge nodes to reduce file sizes. This results in faster delivery to end clients. Content must be of specific supported MIME types for compression to work, and the file sizes currently supported range from 1 KB to 8 MB. Compression is carried out using either Brotli- or gzip-based compression methods, with Brotli preferred over gzip if both are supported.

Query string behavior The Front Door service can manage caching behavior based on the query string contained in a web request. A query string is the section of the web request that comes after the question mark (?) in the request string. Management options are as follows:

Ignore query strings This ensures that the Front Door service passes any query strings in an initial request to the back end and caches the content that is retrieved. In subsequent requests, the query string is ignored, and cached content is returned to the requestor until that content expires.

Cache every unique URL In this case, the Front Door service caches the content associated with every unique URL—including the query string. All content is retained in cache and returned when requested until expiry.

Purging the cache Any files cached on the Front Door service edge nodes have an associated time-to-live (TTL) value. This value indicates when the file expires, after which the Front Door service removes it from its cache. If the Front Door service receives any subsequent requests for that file or content, it will retrieve it again from the back end and cache it with a new TTL value. Depending on the content served and the frequency of refresh required, files or content can be published with version numbers and as new URLs to force updates at the time of the next request. You can purge all cached content as well, if you have a need to do so.

Cache expiration You can set the expiration period for cached files using the response headers for a request. Specifically, you can set Cache-Control response headers to indicate how long the content should be stored in the cache. If this header is missing, the content is randomly cached between 1 to 3 days.

Request headers When caching is enabled, there are two request headers—Content-Length and Transfer-Encoding—that are not forwarded to a back-end node.

Cache duration This is the minimum amount of time content will be kept in cache. This can be set using Front Door Designer or a Rules Engine. If you set the cache duration using Front Door Designer, the minimum cache duration is defined on the global level. Unless a cache control header contains a higher cache duration, this will be the minimum TTL value. However, if you set the cache duration using the Rules Engine, that is accepted as the true cache value, regardless of it being higher or lower than the value in a cache control header.

Network and security

The Front Door service has a number of built-in security features as well as integrations with other Azure services to provide high levels of security and prevent large-scale DDoS attacks that can disrupt applications. Some of these features are unique to the Front Door service, while others overlap with services such as WAF. The following sections discuss these security features in more detail.

Azure DDoS Protection Basic

The Front Door service is integrated with Azure DDoS Protection Basic by default, meaning the service is automatically protected from commonly occurring DDoS attacks such as layer 3 and layer 4 attacks on public endpoints with high traffic volume and layer 7 attacks that involve overloading DNS with massive numbers of queries. Microsoft uses Azure Front Door to protect several of their public-facing consumer services, such as Office365, Dynamics365, and so on, proving the strength of this service against such attacks.

Note

Azure DDoS Protection Basic is provided free of charge for all Front Door service users.

Protection against unwanted protocols

The Front Door service accepts traffic only on HTTP and HTTPS for requests with known host headers. This helps prevent a number of known DDoS attack types, such as DNS amplification attacks, TCP poisoning attacks, and volumetric attacks. Because this is a built-in feature of the Front Door service, no additional configuration is required to achieve this level of security.

Handling large volumes of traffic

As mentioned, Microsoft uses the Front Door service for its consumer-facing cloud services, which handle traffic from millions of clients globally. The global scaling, caching, and security capabilities built into the Front Door service help it handle large volumes of traffic and attacks without issues.

WAF security features

The Front Door service has a number of security features that overlap with the Azure WAF service. These provide a number of key benefits, such as the following:

You can filter or redirect traffic based on the source geographic region using geo-filtering. This helps restrict traffic from unwanted locales to the application.

You can prevent known malicious public IP addresses and IP ranges from connecting.

You can define rule sets to protect against common and known attack vectors.

You can prevent DDoS attacks by applying rate limits to the number of connections allowed from each IP address.

Front Door service walkthrough

The following sections walk you through the process of setting up a Front Door service using the Azure Portal, Azure PowerShell, and the Azure CLI. If you are following along, provision two web apps in the Azure environment, to be used during the setup process.

Using the Azure Portal

To set up Front Door using the Azure Portal, follow these steps:

Log in to the Azure Portal, type Front Door in the search box to locate the service, and select it from the list that appears. (See Figure 8-4.)

FIGURE 8-4 Searching for the Front Door service.

Click the Create or Create Front Door button to start the Create a Front Door wizard. (See Figure 8-5.)

FIGURE 8-5 Click Create Front Door.

In the Basics tab of the Create a Front Door wizard (see Figure 8-6), enter the following information and click Next:

Subscription Select the subscription to host the Front Door service.

Resource Group Select the resource group you want to host the Front Door service. Alternatively, click the Create New link and follow the prompts to create a new resource group.

Resource Group Location This box is automatically populated based on the resource group you select.

FIGURE 8-6 The Basics tab of the Create a Front Door wizard.

In the Configuration tab of the Create a Front Door wizard (see Figure 8-7), under Frontend/Domains, click the Add a Frontend Host button (marked with a plus sign).

FIGURE 8-7 The Configuration tab of the Create a Front Door wizard.

In the Add a Frontend Host settings (see Figure 8-8), enter the following information and click Add:

Host Name Type a unique host name for the front-end host.

Session Affinity Status Specify whether session affinity should be enabled or disabled.

Web Application Firewall Status Specify whether WAF should be enabled or disabled.

FIGURE 8-8 Add a frontend host.

In the Configuration pane of the Create a Front Door wizard (see Figure 8-9), under Backend Pools, click the Add a Backend Pool button (marked with a plus sign).

FIGURE 8-9 Add a backend pool.

In the Add a Backend Pool settings, in the Name box, type a unique name for the back-end pool. (See Figure 8-10.)

FIGURE 8-10 Add a backend pool.

Click the Add a Backend link.

In the Add a Backend settings (see Figure 8-11), enter the following information and click Add:

Backend Host Type Select Custom Host to set up web applications hosted outside Azure as back-end hosts.

Backend Host Name Enter the host name associated with the back-end host. (I typed mbsp-webapp-01.azurewebsites.net.)

Backend Host Header Enter the host header associated with the back-end host. (Again, I typed mbsp-webapp-01.azurewebsites.net.)

HTTP Port Enter the HTTP port associated with the back-end host—here, 80.

HTTPS Port Enter the HTTPS port associated with the back-end host—in this case, 443.

Priority Enter the priority for this back-end host. (I entered 1.)

Weight Assign a weight to this back-end host. (I entered 50.)

Status Specify whether the host is enabled or disabled—in this case, Enabled.

FIGURE 8-11 Set up the backend host.

Repeat steps 8 and 9 to add another custom back-end host, named mbsp-webapp-02.azurewebsites.net. Figure 8-12 shows the result.

FIGURE 8-12 Summary of backend pools.

Let’s create a health probe for the back-end pool. In the Add a Backend Pool settings, under Health Probes (see Figure 8-13), enter the following information:

Path Enter the path you want the health probe to check.

Protocol Choose either HTTP or HTTPS based on your application setup.

Probe Method Choose either HEAD or GET.

Interval (Seconds) Specify how frequently, in seconds, you want the probe to perform health checks. The default is set to 30 (seconds).

FIGURE 8-13 Create a health probe.

Next, enter the load-balancing settings. In the Add a Backend Pool settings, under Load Balancing (see Figure 8-14), enter the following information. Then click Add:

Sample Size Set the sample size to take into consideration—for example, 4.

Successful Samples Required Set the minimum successful samples required to consider a host to be healthy—in this case, 2.

Latency Sensitivity Set the expected latency for a response from a healthy endpoint—here, 0.

FIGURE 8-14 Set up load balancing.

In the Configuration pane of the Create a Front Door wizard (see Figure 8-15), under Routing Rules, click the Add a Rule button (marked with a plus sign).

FIGURE 8-15 Set up routing rules.

In the Add a Rule settings (see Figure 8-20), enter the following information:

Name Enter a unique name for the routing rule that reflects the rule’s purpose. I typed ForwardingRule.

Accepted Protocol Select the protocol the rule will support, especially if you want to enforce the use of HTTP/HTTPS. I chose HTTPS Only.

Frontends/Domains Specify the front ends or domains you want to associate with the rule. In this case, choose the front end you created earlier (Frontend-MBPS-01.azurefd.net).

FIGURE 8-16 Adding a routing rule.

In the Add a Rule settings, under Patterns to Match (look ahead to Figure 8-17), enter the pattern that incoming requests must match to trigger the rule—in this case, /path.

In the Add a Rule settings, under Route Details (see Figure 8-17), enter the following information. Then click Next:

Route Type Specify the route type—in this example, Forward.

Backend pool Select the back-end pool to associate the rule with—here, Backend-01.

Forwarding Protocol Select the protocol to use when forwarding the request to the back-end pool. I chose HTTPS Only.

URL Rewrite Specify whether URL rewrite should be enabled or disabled. I chose Disabled.

Caching Specify whether caching should be enabled or disabled. I chose Disabled.

FIGURE 8-17 Set up a routing rule.

In the Tags tab, enter any tags required for the Front Door service or leave the fields blank (see Figure 8-18). Then click Next.

FIGURE 8-18 The Tags tab of the Create a Front Door wizard.

In the Review + Create tab of the Create a Front Door wizard (see Figure 8-19), review your settings and click Create.

FIGURE 8-19 The Review + Create tab of the Create a Front Door wizard.

Using Azure PowerShell

You can create a Front Door service using Azure PowerShell with the New-AzFrontDoor command and various switches to set its parameters. The following code shows you how. Use this snippet to create the same Front Door service as you did in the Azure Portal. Be sure you delete the service you created earlier or modify its variables as appropriate before you use the following code before testing:

Click here to view code image

#Define required variables
$Azureregion1="EastUS2"
$Azureregion2="EastUS"
$RG="RG01"
$AppServicePlan01="MBSP-ASP-01"
$AppServicePlan02="MBSP-ASP-02"
$frontend="MBSP-Frontend-01"
$BackendPool="MBSP-Backendpool-01"
$frontdoorname="MBSP-Frontdoor-01"
# Create first web app in East US 2 region.
$app01 = New-AzWebApp -Name "WebApp-MBSP-01" `
-Location $azureregion1 `
-ResourceGroupName $RG `
-AppServicePlan $AppServicePlan01
# Create second web app in East US region.
$app02 = New-AzWebApp -Name "WebApp-MBSP-02" `
-Location $azureregion2 `
-ResourceGroupName $RG `
-AppServicePlan $AppServicePlan02
#Create the front-end object
$FrontendObject01 = New-AzFrontDoorFrontendEndpointObject -Name $frontend -HostName
$frontdoorname".azurefd.net"
# Create back-end objects that point to the hostname of the web apps
$backend01 = New-AzFrontDoorBackendObject -Address $app01.DefaultHostName
$backend02 = New-AzFrontDoorBackendObject -Address $app02.DefaultHostName
# Create a health probe
$HealthProbe = New-AzFrontDoorHealthProbeSettingObject -Name "HealthProbe"
# Create load balancing settings
$LoadBalancing = New-AzFrontDoorLoadBalancingSettingObject -Name "Loadbalancing" `
-SampleSize "4" `
-SuccessfulSamplesRequired "2" `
-AdditionalLatencyInMilliseconds "0"
# Create a back-end pool
$BackendPool01 = New-AzFrontDoorBackendPoolObject -Name "$BackendPool" `
-FrontDoorName $frontdoorname `
-ResourceGroupName $RG `
-Backend $backend01,$backend02 `
-HealthProbeSettingsName "HealthProbe" `
-LoadBalancingSettingsName "Loadbalancing"
# Create Routing rule connecting the front end to the back-end pool
$RoutingRule = New-AzFrontDoorRoutingRuleObject `
-Name RoutingRule `
-FrontDoorName $frontdoorname `
-ResourceGroupName $RG `
-FrontendEndpointName $frontend `
-BackendPoolName $BackendPool `
-PatternToMatch "/*"
# Creates Azure Front Door
New-AzFrontDoor `
-Name $frontdoorname `
-ResourceGroupName $RG `
-RoutingRule $RoutingRule `
-BackendPool $BackendPool01 `
-FrontendEndpoint $FrontendObject01 `
-LoadBalancingSetting $LoadBalancing `
-HealthProbeSetting $HealthProbe

Using the Azure CLI

You can create a Front Door service using the Azure CLI with the az network front-door create command and various switches to set its parameters. The preceding Front Door configuration can be created using the following PowerShell script in Azure CLI. The following code shows you how. Use this snippet to create the same Front Door service as you did earlier. Be sure you delete the service you created earlier or modify its variables as appropriate before you use this code before testing:

Click here to view code image

#Define required variables
azureregion1="EastUS2"
azureregion2="EastUS"
rg="RG01"
appserviceplan01="MBSP-ASP-01"
appserviceplan02="MBSP-ASP-02"
frontend="MBSP-Frontend-01"
backendpool="MBSP-Backendpool-01"
frontdoorname="MBSP-Frontdoor-01"
app01="WebApp-MBSP-01"
app01="WebApp-MBSP-02"
#Create test app service plans and webapps in different regions
az appservice plan create \
--name $appserviceplan01 \
--resource-group $rg \
--location $azureregion1
az appservice plan create \
--name $appserviceplan02 \
--resource-group $rg \
--location $azureregion2
az webapp create \
--name MBSP-WebApp-03 \
--resource-group $rg \
--plan $appserviceplan01
az webapp create \
--name MBSP-WebApp-04 \
--resource-group $rg \
--plan $appserviceplan02
#Create Azure Front Door Service
az network front-door create --backend-address $app01.azurewebsites.net\
                                                     --name $frontdoorname \
                                                     --resource-group $rg
#Create Front Door Health Probe
az network front-door probe create --front-door-name  $frontdoorname \
                                                     --interval 30 \
                                                     --name "Healthprobe" \
                                                     --resource-group $rg \
                                                     --path "/"
#Create Load Balancing Rule
az network front-door load-balancing create --resource-group $rg \
                                                     --front-door-name $frontdoorname \
                                                     --name "LoadBalancingSetting" \
                                                     --sample-size 4 \
                                                     --successful-samples-required 2 \
                                                     --additional-latency 0
#Create Back-end Pool
az network front-door backend-pool create --address $app01.azurewebsites.net \
                                                     --front-door-name $frontdoorname \
                                                     --load-balancing "LoadBalancing
                                                       Setting" \
                                                     --name $backendpool \
                                                     --probe "HealthProbe" \
                                                     --resource-group $rg
az network front-door backend-pool backend add --resource-group $rg \
                                                     --front-door-name $frontdoorname \
                                                     --pool-name $backendpool \
                                                     --address $app02.azurewebsites.net \
                                                     --disabled false
#Create Routing Rule
az network front-door routing-rule create --front-door-name  $frontdoorname \
                                                     --frontend-endpoints  $frontend \
                                                     --name RoutingRule \
                                                     --resource-group $rg \
                                                     --route-type Forward \
                                                     --backend-pool $backendpool \
                                                      --accepted-protocols "HTTPSOnly"

Best practices

Following are some best practices associated with the Azure Front Door service:

Use Azure Monitor to monitor and alert You can integrate the Azure Front Door service with Azure Monitor to monitor key Front Door metrics. These include Front Door performance counters such as the following:

RequestCount

RequestSize

ResponseSize

TotalLatency

BackendRequestCount

BackendRequestLatency

BackendHealthPercentage

WebApplicationFirewallRequestCount

Use activity and diagnostic logs You can use activity logs to identify, monitor, and alert on any administrative actions performed on the Front Door service. You can use diagnostic logs to monitor, analyze, and alert on operations performed by the Front Door service.

Use geo-filtering when applicable With geo-filtering, you can allow traffic only from specified regions or block traffic from unwanted regions. If applicable, use geo-filtering for a client environment based on its location and on the countries from which you expect it to be used to limit the application’s attack surface.

Use virtual network service tags Virtual network service tags define network access controls on network security groups (NSGs) applied to back-end resources. It’s easier to use, manage, and maintain these service tags than to use specific IP addresses in security rules.

Restrict administrative access You can use Azure role-based access control (RBAC) to restrict access to the Front Door service only to required administrative accounts. Ensure that this access is restricted as needed and reviewed on a regular basis to prevent unwanted access as early as possible.

Encrypt sensitive information in transit The Front Door service supports TLS and HTTPS protocols for communication between services and back ends. Use encryption where possible to limit the risk of traffic snooping on that environment.

Use Azure Policy to restrict Azure service usage Azure Policy helps audit and restrict the usage of Azure services in an environment. Use Azure Policy to restrict the deployment of the Front Door service only to required administrators. You can use Azure Monitor to trigger alerts when a deviation is detected.

Enable network traffic logging You can set up network flow logs to monitor network traffic passing through the Front Door service. You can retain these logs in an Azure storage account based on the organization’s long-term retention and auditing requirements.

Restrict access to back ends only via Front Door You can set up back-end resources to accept traffic only from the Front Door service, thereby limiting the attack surface on these services. You can also set up rules on back-end services to monitor for the X-Azure-FDID header value in incoming traffic to identify traffic originating from the Front Door service.

Use HTTPS as the forwarding protocol Connections between the Front Door service and the back end happen over public IP. Therefore, it’s a good idea to configure the Front Door service to use HTTPS only to forward traffic to back ends. This will restrict malicious activity if traffic is intercepted.

Chapter 9

Azure Bastion

Overview

Azure Bastion is a fully managed platform as a service (PaaS) provided by Microsoft that helps users securely access Windows and Linux virtual machines (VMs) hosted in Azure with any HTML5-based web browser. As a fully managed secure service, Azure Bastion eliminates the need for public exposure of any VMs in Azure.

Azure Bastion provides secure access directly from the Azure Portal over TLS via RDP or SSH protocols to VMs hosted in Azure. The VMs do not require the installation of any agents or custom software for RDP/SSH access to work.

Setting up and using Azure Bastion is extremely easy. Doing so can reduce the direct public exposure of critical infrastructure components—that is, VMs—and thereby improve overall network security.

Azure Bastion features

Some key features and benefits of using Azure Bastion are as follows:

Direct RDP/SSH access via the Azure Portal Azure Bastion enables access to Windows and Linux VMs using the Azure Portal directly within an HTML5-based web browser without requiring those VMs to be publicly exposed.

Reduced public exposure of Azure VMs Azure Bastion enables you to remove public IPs from VMs set up for remote access. The service provides the required RDP/SSH connectivity for administrative purposes over the VM’s internal IP, making it the sole entry point to the network for management.

Compatible with most networks Azure Bastion works securely over port 443, making it accessible over most corporate firewalls. It eliminates the need to redirect RDP/SSH sessions to custom ports to provide additional security and expose additional ports on the network firewalls for secure access.

No file data transfer from VMs Azure Bastion prevents files from being copied or transferred from the VMs over the RDP/SSH session. Only copying and pasting of text is supported. This removes the risk of unwanted data loss.

Customer data management Azure Bastion ensures that no client data is stored or moved out of the region in which the service is deployed, providing additional data security for organizations that must adhere to strict data-localization rules.

No special software or agent for access Azure Bastion does not require the installation of agents or custom software, or custom configuration on either the VM or the client end.

Works with any HTML5-based browser Azure Bastion supports the use of HTML5-based web browsers such as Microsoft Edge and Google Chrome for access via any operating system, including Windows and macOS.

Removes the need for complex NSGs By eliminating the need for public exposure of VMs for administrative purposes, Azure Bastion also eliminates the need for complex NSGs to gain secure access to VMs from specific IP ranges, over custom ports, and so on. Azure Bastion only needs RDP/SSH access from its subnet to be open and available.

Reduced network exposure Because VMs are not exposed directly to the internet, attackers cannot perform malicious activities such as port scanning from external networks to identify ports open for administrative purposes.

Reduced exposure to zero-day attacks As a fully managed PaaS, Bastion provides perimeter security. Microsoft secures back-end components through service-hardening and patching to keep them up-to-date.

Works across the virtual network and peered networks Azure Bastion provides secure access to all VMs hosted by the virtual network on which it is deployed. It also provides secure access into any peered virtual networks, removing the need to create multiple instances of the service for different networks.

Ideal for remote IT management scenarios Azure Bastion gives IT administrators secure access to Azure-based VMs from anywhere, making secure remote administration possible. It also allows remote access without having to procure licensing for Remote Desktop Services as long as the access is for administrative purposes only.

Azure Bastion limitations

Now that we have covered some key features and benefits of Azure Bastion, let’s address some of the service’s limitations:

You cannot copy files to and from VMs. Depending on your organization’s requirements, this can be both a benefit and a limitation of the service, as it’s not a configurable setting.

Azure Bastion is not supported for VMs that are Azure AD–joined.

The Azure Bastion subnet does not support user-defined routing.

Azure Bastion does not currently support the use of IPv6.

The subnet that hosts the Azure Bastion service cannot be used for the deployment of any other service.

Even though Azure Bastion provides RDP to the VM in Azure, the redirection of the time zone supported over RDP is not supported over Azure Bastion. The time zone will be set to the one defined on the VM.

Azure Bastion VMs support only the US English QWERTY keyboard layout. (Support for other locales is ongoing.)

Design concepts and deployment considerations

The following sections cover design concepts and deployment considerations, starting with the architecture of the Azure Bastion service. You’ll want to account for these when deploying to ensure Azure Bastion is a highly available redundant service.

Architecture

In most environments, remote management activities require the use of management networks, jump servers, and/or publicly exposed VMs. This exposes the network to unnecessary risks and malicious attacks. As a result, exposed VMs must be patched regularly and hardened to reduce the attack surface. As the number of VMs in the environment increases and more virtual networks are interconnected, the complexity of the network architecture and the time required to securely maintain and manage it increases.

Azure Bastion reduces the complexity of the VM management network architecture by allowing for the deployment of a secure, centralized managed service layer. This layer provides RDP/SSH connectivity to the VMs while ensuring that the underlying layer is hardened by default and kept secure and up to date.

Using Azure Bastion to access VMs across peered networks in Azure simplifies the design of the management network layer, reducing the attack surface while also allowing for redundancy to manage outages in an Azure region. Figure 9-1 shows how client sessions via the Azure Portal using the Azure Bastion service enables VM access.

FIGURE 9-1 Azure Bastion client access.

SKUs

Azure Bastion provides two SKUs: Basic and Standard. Both currently provide the same functionality, except that the Basic SKU supports only two hosts (discussed next). The Standard SKU is currently in preview; hence, it is not covered in detail in this book.

High-availability hosts

By default, when provisioned, Azure Bastion creates two secure instances that provide redundancy in case of an instance failure. Each Azure Bastion instance supports between 10 and 12 concurrent RDP/SSH connections, depending on the overall load generated by a connection. Scaling beyond two hosts is supported with the Standard SKU. (As mentioned, the Standard SKU is currently in preview, and thus is not covered in detail in this book.)

Virtual network peering

If different virtual networks are peered together, you can deploy Azure Bastion in only one of them to access VMs across different virtual networks. For this to work, the user or administrator needs reader permissions on the virtual network (at a minimum).

Azure Bastion supports two types of peering, as follows:

Regional peering This allows Azure Bastion hosts in one of the peered virtual networks to connect to VMs in all peered networks in the same Azure region.

Global peering This allows Azure Bastion hosts in one of the peered virtual networks to connect to VMs in all globally peered networks.

Disaster recovery

You must manage disaster recovery for the Azure Bastion service. Although Azure Bastion is redundantly deployed in the Azure region in which it is created, if there is an outage in that region, the service will be unavailable for use.

There are two ways to address this:

Deploy Azure Bastion in advance on one other virtual network in another Azure region where VMs resources are running Because Azure Bastion supports a full-mesh design, you can divert to the Azure Bastion host in the closest available Azure region if the primary region experiences an outage.

Deploy Azure Bastion in another Azure region after the failure of the Azure Bastion service in the primary region Setting up Azure Bastion does not take long—meaning you can do it quickly in a different region after the primary region experiences an outage. This approach is the more cost-effective, as you need not run an additional Azure Bastion host at all times.

Service requirements

There are a few service requirements you need to consider before setting up the Azure Bastion service. These requirements are as follows:

Dedicated subnet to host the Azure Bastion service You must set up a dedicated subnet before deploying the Azure Bastion service on a virtual network. This subnet must meet the following requirements:

The subnet should be in the same resource group and virtual network as your Azure Bastion deployment.

The subnet should be named AzureBastionSubnet; otherwise, it will not be recognized by the Create a Bastion wizard when you create the Azure Bastion service.

The subnet octet must be /27 or larger (/26, /25, etc.).

The subnet must be used exclusively to host Azure Bastion. It cannot host any other resources.

Public IP address A dedicated public IP address must be assigned to the Azure Bastion service. This public IP address must meet the following requirements:

The public IP address must be set to static allocation (not dynamic allocation).

The public IP address must be the Standard SKU.

You can use any existing unused public IP that meets these criteria when you create the Azure Bastion service.

Access permissions Users or administrators who use the Azure Bastion service to connect to a VM must have the following permissions in the Azure environment (at minimum):

Reader role on the VM

Reader role on the NIC with the VM’s private IP

Reader role on the Azure Bastion resource

Reader role on the virtual network if that virtual network is peered

Azure Bastion walkthrough

The following sections walk you through the process of creating an Azure Bastion service using the Azure Portal, Azure PowerShell, and the Azure CLI.

Using the Azure Portal

To create an Azure Bastion service using the Azure Portal, follow these steps:

Log in to the Azure Portal, type bastion in the search box to locate the Azure Bastion service, and select Bastions in the list that appears. (See Figure 9-2.)

FIGURE 9-2 Search for the Azure Bastion service.

Click the Create Bastion button to start the Create a Bastion wizard. (See Figure 9-3.)

FIGURE 9-3 Create an Azure Bastion service.

In Basics tab of the Create a Bastion wizard, in the Project Details and Instance Details sections, enter the following information (see Figure 9-4):

Subscription Select the subscription that will host the Azure Bastion service.

Resource Group Select the resource group you want to use to host the Azure Bastion service. Alternatively, to create a new resource group, click the Create New link and follow the prompts.

Name Type a unique name for the service.

Region Select the Azure region in which you want to host the Azure Bastion service.

Tier Select Basic.

Instance Count Because you selected the Basic tier, this is automatically set to 2 and grayed out. (Recall that the Basic SKU supports only two instances.)

FIGURE 9-4 The Basics tab of the Create a Bastion wizard.

Still in the Basics tab of the Create a Bastion wizard, in the Configure Virtual Networks section (see Figure 9-5), open the Virtual Network drop-down list and select the virtual network on which you want to create the Azure Bastion service.

FIGURE 9-5 Configure virtual networks.

Under the Subnet drop-down list, click the Manage Subnet Configuration link to create a new subnet.

In the Add Subnet dialog box, in the Name box, type AzureBastionSubnet. (The subnet must have exactly this name.)

In the Subnet Address Range box, enter an address range for the subnet. (Recall that the subnet must be /27 or larger.) Leave the other settings in this dialog box as is and click Save. (See Figure 9-6.)

FIGURE 9-6 Set up the subnet.

Back in the Basics tab of the Create a Bastion wizard, in the Configure Virtual Networks section, open the Subnet drop-down list and choose the subnet you just created (AzureBastionSubnet).

Still in the Basics tab, in the Public IP address section, enter the following information (see Figure 9-7). Then click Next:

Public IP Address Select the Use Existing option button if a public IP address has already been created for the Azure Bastion service. Alternatively, you can select Create New and follow the prompts. In this case, select Create New.

Public IP Address Name Type a unique name for the public IP address.

Public IP Address SKU By default, this will be set to Standard and grayed out.

Assignment By default, this will be set to Static and grayed out.

FIGURE 9-7 Set up a public IP for the Azure Bastion service.

In the Tags tab, enter any tags required for the Azure Bastion service or leave the fields blank (see Figure 9-8), and click Next.

FIGURE 9-8 Set up tags.

In the Review + Create tab (see Figure 9-9), review your settings and click Create.

FIGURE 9-9 Review and create the Azure Bastion service.

Using Azure PowerShell

You can create an Azure Bastion service with Azure PowerShell using the New-AzBastion command with various switches to set the service’s parameters. For example, to create the same Azure Bastion service as you did in the preceding section, you use the following code:

Click here to view code image

#Define required variables
$subnetName = "AzureBastionSubnet"
$rg = "RG01"
$location = "eastus"
#Create subnet and public IP for Azure Bastion
$subnet = New-AzVirtualNetworkSubnetConfig -Name $subnetName -AddressPrefix 10.2.1.0/27
$vnet = New-AzVirtualNetwork -Name "vNET-01" -ResourceGroupName "RG01" -Location
$location -AddressPrefix 10.2.0.0/16 -Subnet $subnet
$bastionpublicip = New-AzPublicIpAddress -ResourceGroupName $rg -name "Bastion-
vNET01-PIP" -location $location -AllocationMethod Static -Sku Standard
#Create Bastion service
New-AzBastion -ResourceGroupName $rg -Name "Bastion" -PublicIpAddress $bastionpublicip
-VirtualNetwork $vnet

Using the Azure CLI

You can create an Azure Bastion service with the Azure CLI using the az network bastion command with various switches to set the service’s parameters. The following script shows you how to set up the same Azure Bastion service you created in the preceding sections with the Azure CLI:

Click here to view code image

#Define required variables
vnet="vNET-01"
resourcegroup="RG01"
location="eastus"
publicip="Bastion-vNET01-PIP"
#Create Azure Bastion service
az network bastion create --location $location --name Bastion --public-ip-address
$publicip --resource-group $resourcegroup --vnet-name $vnet

Connect to a VM walkthrough

The following section walks you through using Azure Bastion to connect to Windows and Linux VMs via the Azure Portal.

Using the Azure Portal

To use Azure Bastion to connect to Windows or Linux VMs using the Azure Portal, follow these steps:

Log in to the Azure Portal and navigate to the configuration page for the Windows or Linux VM that you want to access using Azure Bastion.

In the left pane of the VM’s configuration page, under Settings, click Connect.

The pane on the right displays three tabs, one for each connection type: RDP, SSH, and Bastion. (See Figure 9-10.)

FIGURE 9-10 Connect to VM.

Click the Bastion tab.

In the Bastion tab, click the Use Bastion button. (See Figure 9-11.)

FIGURE 9-11 Connect to the VM using the Azure Bastion service.

In the Connect Using Azure Bastion dialog box, do one of the following, depending on whether you are using Windows or Linux:

Windows VM Type the username and password required to log in to the VM and click Connect. (See Figure 9-12.)

FIGURE 9-12 Log in to the Windows VM.

Linux VM Enter the username. Then enter the password, SSH private key, SSH private key from local file, or SSH private key from Azure Key Vault (depending on what option button you select under Authentication Type) and click Connect. (See Figure 9-13.)

FIGURE 9-13 Log in to the Linux VM.

A new tab opens in your web browser, showing the main page for the Windows VM (see Figure 9-14) or Linux VM (see Figure 9-15).

FIGURE 9-14 Windows Server console.

FIGURE 9-15 Linux Server console.

Note

If a new tab does not open, disable the setting you use to block pop-ups, and try again.

Best practices

Following are a few best practices related to deploying, securing, monitoring, and managing the Azure Bastion service. This is not an exhaustive list, but it provides a good starting point for most organizations using this service:

Allow only for required network ports Azure Bastion requires a limited number of ports to allow ingress and egress traffic from end-users to VMs hosted in Azure. The port requirements are as follows:

Ingress traffic from clients/administrators Only port 443 is required from the internet to the Azure Bastion public IP. No other ports are needed.

Egress traffic to Azure VMs Only ports for RDP (3389) and SSH (22) are required between the Azure Bastion subnet and the subnets hosting the VMs.

Egress traffic to other Azure services Azure Bastion uses port 443 to connect to other Azure services, such as Azure Storage for storing logs. Enable outbound access to port 443 for the AzureCloud service tag to allow this to work correctly across all Azure resources from Azure Bastion.

Use Azure Active Directory for access authentication and authorization Azure Active Directory (AD) is the default identity and access-management service in Azure. By default, Azure Bastion is integrated with Azure AD, and you can use Azure AD to control user access to the Azure Bastion service. Limiting access either in Azure AD on the user level, or using Azure AD on the resource level, can help restrict access to resources.

Use Key Vault to store SSH keys Consider storing SSH keys as Key Vault secrets and allowing access to these secrets only for required administrators to log in to VMs using Azure Bastion. This can help centralize the storing, management, and sharing of these SSH keys.

Use multi-factor authentication Access to the Azure Portal is integrated with Azure AD. To add another layer of security to protect logins to the Azure Portal, you can enable multi-factor authentication (MFA). You should do this as soon as possible to increase security for user logins.

Set up monitoring and alerting Use diagnostic logging to monitor remote sessions and keep track of user logins. You can configure alerts based on criteria related to time of access, location of access, etc., to implement additional restrictions to limit access from approved networks or certain timeframes based on suspicious access patterns.

Use conditional access policies Conditional access policies allow you to put restrictions in place to allow access to the Azure Portal only from specific networks, specific countries, using MFA, and other criteria. Depending on your organization’s security requirements, you can also use conditional access policies for suspicious logins and monitoring alerts for additional security.

Restrict administrative access to business-critical systems Azure Bastion uses Azure role-based access control (Azure RBAC) to specify which accounts should be granted access to VMs that host business-critical systems. You should adhere to the principle of least privilege to ensure that users have only the permissions they need to perform their specific tasks. Also be sure to restrict access to the management, identity, and security tools that have administrative access to your business-critical systems, such as Active Directory Domain Controllers (DCs), security tools, and system-management tools. Attackers who compromise these security systems can easily weaponize them to compromise critical business assets!

Regularly review user access Implement processes to extract, review, and eliminate unwanted access in Azure AD and on the resource level to ensure that only required administrators have access to the Azure Bastion service to connect to VMs.

Use Azure Privileged Identity Management This can alert you if too many administrator accounts have been created in the environment and can identify and monitor unused administrator accounts for cleanup.

Use privileged access workstations Privileged access workstations (PAWs) are isolated workstations that are hardened to protect against breaches on devices. These are then set up as the only devices to access the Azure Portal and other sensitive resources. Consider using PAWs to prevent access from unsecured and untrusted devices to the Azure environment for management purposes.

Use Azure Policy Azure Policy audits, detects, and restricts unwanted deployments of Azure Bastion resources, and monitors the service’s network configuration. This can prevent unwanted deployments from enabling additional entry points in the Azure network.

Remove access once not required It is a good practice to remove access to a particular VM if a specific administrator no longer needs it. Implement processes to automate this removal when a change in permission requirements is detected.

Enable long-term logging for Azure network activities You can set up Azure Bastion to store diagnostic service logs in a storage account for monitoring, alerting, and review. Consider setting up retention configuration for logs, taking into account any compliance requirements for your organization.

Chapter 10

Azure Private Link

Overview

Azure Private Link supports secure private connectivity for access to Azure PaaS Services such as Azure Storage, Azure App Services, and Azure SQL Database, among others. A private endpoint provides connectivity between the PaaS and the client’s Azure virtual network.

With Azure Private Link, all network traffic traverses the Microsoft Azure global backbone that connects its massive enterprise and consumer services. This eliminates the need for exposure of PaaS services to the public internet for user consumption, keeping access private and easier to control.

You can use Azure Private Link for your internal users or for partners, customers, or clients to provide access to Azure-hosted services.

Azure Private Link features

Azure Private Link provides the following features and benefits:

Enhanced security By enabling private access to Azure PaaS offerings, Private Link enhances the security posture on the access layer for services hosted in Azure.

Improved routing Private Link enables better routing to Azure-hosted services, as the traffic traverses the Microsoft backbone instead of the public internet (which can be unreliable).

Secure access from on-premises or peered networks Access can be from resources on-premises or in peered virtual networks. You can set up ExpressRoute and VPN tunnels with on-premises environments to provide connectivity to Azure.

Restricted access You can connect private endpoints to specific PaaS resources to allow users access to just those resources instead of the entire Azure back end. This reduces the risk of exposure for other services hosted in Azure not exposed via Private Link or the public internet.

Global interconnectivity You can use Private Link to connect to Azure services hosted in any Azure region, regardless of the source region requiring private access.

Secure access for multiple customers Private Link enables customers to access Azure-hosted services privately. Customers can set up a private endpoint in their own virtual network and use that to connect to services.

Consistent experience Whether a service is an Azure PaaS, customer-owned, or partner-owned, using Azure Private Link provides a consistent end-user access experience.

Design concepts and deployment considerations

The following sections cover key considerations when planning the design and deployment of Azure Private Link.

Private endpoints

A private endpoint is a network interface connected to an Azure virtual network and is assigned a private IP address from that virtual network. Private endpoints allow private and secure access to the following services:

Azure PaaS offerings You can associate a private endpoint with an Azure PaaS such as Azure Storage. This effectively enables access over the private IP address assigned to the private endpoint.

Customer-owned services You can associate a private endpoint with a standard Azure load balancer to provide secure internal access to customer-hosted workloads.

Integration with Azure PaaS offerings

An Azure PaaS offering that is the destination target of a private endpoint is called a Private Link resource. Table 10-1 contains examples of Azure PaaS offerings that can currently act as Private Link resources.

TABLE 10-1 Examples of Private Link resources

Azure Application Insights

Azure Database for MySQL

Azure Log Analytics

Azure App Service

Azure Database for PostgreSQL – Single Server

Azure Machine Learning

Azure Backup

Azure Managed Disks

Azure Monitor

Azure Batch

Azure Event Grid

Azure Search

Azure Container Registry

Azure Event Hub

Azure Service Bus

Azure Cosmos DB

Azure IoT Hub

Azure SQL Database

Azure Data Factory

Azure Key Vault

Azure Storage (Blob, File, Queue, and Table)

Azure Database for MariaDB

Azure Kubernetes Service

Azure Synapse Analytics

Note

This list is constantly evolving, as more services are either under preview or under development for integration with Azure Private Link.

Integration with customer-owned services

Azure Private Link can be connected with a standard Azure load balancer. Using an internal Azure load balancer, access can be provided to a service or application hosted on other services, such as Azure virtual machines.

Private endpoint features

Here are a few key features of private endpoints that you should take into consideration:

Connectivity across different networks Private endpoints allow access to connected virtual networks, peered virtual networks, and on-premises networks connected using ExpressRoute or VPN.

Integration across Azure regions You can host Private Link resources in one Azure region and integrate with a private endpoint hosted in another Azure region.

Read-only private IP Every private endpoint has an associated read-only network interface that is configured and managed by the service. The network interface is assigned an IP address based on the private virtual network and subnet assigned during service creation. This IP stays with the network interface until the private endpoint is deleted.

Integration with Azure private DNS You can integrate private endpoints with Azure private DNS for automatic DNS record registration and management.

Support for multi-endpoint interconnects You can associate a single Private Link resource with multiple private endpoints. This allows for connection to the resource over different IP networks if such segregation is required—for example, in multi-tenant scenarios.

Support for multiple private endpoints on the same virtual network Every virtual network and subnet can support multiple private endpoints. Currently, as many as 1,000 private endpoints are supported per virtual network.

No dedicated subnet required Private endpoints do not require a dedicated subnet in the virtual network. Any subnet can be selected to host some or all private endpoints.

Private endpoint limitations

Here are a few limitations or requirements to keep in mind when designing and deploying private endpoints:

All connections to the private endpoint must be incoming—that is, clients must connect to the private endpoint to access a resource. Outgoing connections from an Azure resource to on-premises or endpoint-connected resources are not supported.

You must deploy a private endpoint using the same region and subscription as the virtual network. Using a different Azure region or subscription is not currently supported.

Employing user-defined routing for a private endpoint can result in asymmetric routing. It is best to set up a SourceNAT (SNAT) for such traffic at the network virtual appliance to ensure symmetric routing takes place.

The subscription hosting the Private Link resource must be registered with the Microsoft.Network resource provider for the integration to work.

Enhanced network security

A private endpoint maps to a single Private Link resource and provides access only to that resource. This ensures that you can securely control and manage network communication. If users require access to multiple resources, you will need to deploy multiple private endpoints. You can restrict or curtail access to public endpoints for Azure resources to ensure access to only the private endpoint.

DNS configuration

To access a resource over Private Link using the resource’s fully qualified domain name (FQDN), you need to keep two points in mind:

You should update the DNS record(s) for the private endpoint to reflect the correct private IP address.

You should set up the DNS services employed to connect to the private endpoint to use the private DNS records. Otherwise, connectivity will continue over the public endpoint. (These can be DNS services referenced in Azure virtual networks or customer-managed DNS services used by on-premises resources.)

There are different ways to set up DNS for accessing resources over private endpoints:

Using HOSTS files You can manually set up HOSTS files to contain a reference for the private endpoint. This approach is suitable during testing. However, using it on a large scale would be impractical, especially when rolling out or changing the configuration—for example, if the IP changes in a disaster-recovery scenario.

Using an Azure private DNS zone You can integrate an Azure private DNS zone to manage the DNS name resolution for private endpoints. All virtual networks that need to connect using the private endpoint can then be set up to use the private DNS zone for custom name resolution.

Using customer-managed DNS forwarders You can set up DNS forwarders to route requests for the private endpoint domain to DNS servers that have the private IP reference for the service.

Disaster recovery

By default, private endpoints come with 99.99% SLA. However, in the event of a regional outage, services would be unavailable. To handle such a scenario, it’s recommended that you do the following:

Set up multiple private endpoints that point to the same Private Link resource in different Azure regions.

Set up redundancy for the Private Link resource if it is in the same region as the private endpoint and account for resource failover in your disaster-recovery plan.

This approach will provide redundancy in the event of a large disaster in any Azure region impacting customer workloads that use private endpoints.

Private endpoint walkthrough

The following sections walk you through the process of setting up a private endpoint using the Azure Portal, Azure PowerShell, and the Azure CLI.

Before you proceed with the walkthrough, you need to complete these prerequisites:

Set up an Azure web app using the App Service Plan – Premium_v2.

Set up or identify the virtual network and subnet where the private endpoint will be hosted.

Using the Azure Portal

To create a private endpoint using the Azure Portal, follow these steps:

Log in to the Azure Portal, type Private Link in the search box to locate the service, and select it from the list that appears. (See Figure 10-1.)

FIGURE 10-1 Search for the Private Link service.

Click the Create Private Endpoint button to start the Create a Private Endpoint wizard. (See Figure 10-2.)

FIGURE 10-2 Create a private endpoint.

In the Basics tab of the Create a Private Endpoint wizard, enter the following information (see Figure 10-3) and click Next:

Subscription Select the subscription that will host the private endpoint.

Resource Group Select the resource group you want to use to host the private endpoint. Alternatively, to create a new resource group, click the Create New link and follow the prompts.

Name Type a unique name for the private endpoint.

Region Choose the Azure region in which you want to host the private endpoint.

FIGURE 10-3 The Basic tab of the Create a Private Endpoint wizard.

In the Resource tab, enter the following information (see Figure 10-4) and click Next:

Connection Method Specify what connection method to use to identify the Azure resource to connect the private endpoint.

Subscription Select the subscription in which the Azure resource is located.

Resource Type Select the type of Azure resource you want to connect the private endpoint to.

Resource Select the specific resource from your subscription to connect the private endpoint to.

Target Sub-Resource Select the resource sub-type to connect. The options here will automatically change based on the resource type and resource you selected earlier.

FIGURE 10-4 The Resource tab of the Create a Private Endpoint wizard.

In the Configuration tab, enter the following information (see Figure 10-5) and click Next:

Virtual Network Select the virtual network on which you want to create the private endpoint.

Subnet Select the subnet to associate with the private endpoint. The endpoint NIC will pick up an IP address based on this subnet IP range.

Integrate with Private DNS Zone Specify whether the private endpoint should integrate with a private DNS zone.

Private DNS Zone Configuration If you enable integration, specify what private DNS zone you want to integrate with the private endpoint.

FIGURE 10-5 The Configuration tab of the Create a Private Endpoint wizard.

In the Tags tab, enter any tags required for the private endpoint service or leave the fields blank (see Figure 10-6), and click Next.

FIGURE 10-6 The Tags tab of the Create a Private Endpoint wizard.

In the Review + Create tab (see Figure 10-7), review your settings and click Create.

FIGURE 10-7 Review and create a private endpoint.

Using Azure PowerShell

You can create a private endpoint with Azure PowerShell using the New-AzVirtualNetworkLink command with various switches to set its parameters. For example, to create the same private endpoint as you did in the preceding section, you use the following code:

Click here to view code image

#Define required variables
$rg = "RG01"
$vnet = "vNET-01"
$subnetName = "Subnet01"
$webapp = "WebApp-MBSP-01"
$endpointname = "PrivateEndpoint"
$location = "East US"
#Configure the private endpoint
$PrivEndPointConn = New-AzPrivateLinkServiceConnection -Name "myPrivateEndpointconnection"
-PrivateLinkServiceID $webApp.Id -GroupId sites
$privateEndpoint = New-AzPrivateEndpoint -Name "myPrivateEndpoint" `
-ResourceGroupName $resourcegroupname `
-Location $location `
-Subnet $subnet `
-PrivateLinkServiceConnection $privEndPointConn
#Create the private DNS zone
$PrivdnsZone = New-AzPrivateDnsZone -Name "privatelink.azurewebsites.net"
-ResourceGroupName $rg
#Create the private DNS link
$dnsLink = New-AzPrivateDnsVirtualNetworkLink -Name "privateendpointlink" `
-ResourceGroupName $rg `
-ZoneName "privatelink.azurewebsites.net" `
-VirtualNetworkId $vnet.Id
#Create the private DNS config
$dnsConfig = New-AzPrivateDnsZoneConfig -Name "privatelink.azurewebsites.net" `
-PrivateDnsZoneId $privdnsZone.ResourceId
$dnsZoneGroup = New-AzPrivateDnsZoneGroup -Name "PrivDNSZoneGroup" `
-ResourceGroupName $rg `
-PrivateEndpointName $privateEndpoint.Name `
-PrivateDnsZoneConfig $dnsConfig

Using the Azure CLI

You can create a private endpoint with the Azure CLI using the az network private-endpoint create command with various switches to set its parameters. For example, to create the same private endpoint as you did in the preceding sections, you use the following code:

Click here to view code image

#Define required variables
rg="RG01"
vnet="vNET-01"
subnetName="Subnet01"
webapp="WebApp-MBSP-01"
endpointname="PrivateEndpoint"
location="East US"
#Find the web app resource ID
id=$(az webapp list \
    --resource-group $rg \
    --query '[].[id]' \
    --output tsv)
#Create and configure the private endpoint
az network private-endpoint create \
    --name PrivateEndpoint \
    --resource-group $rg \
    --vnet-name $vnet --subnet $subnet \
    --private-connection-resource-id $id \
    --group-id sites \
    --connection-name PrivEndpointConnection
#Create the private DNS zone
az network private-dns zone create \
    --resource-group $rg \
    --name "privatelink.azurewebsites.net"
#Create the private DNS link
az network private-dns link vnet create \
    --resource-group $rg \
    --zone-name "privatelink.azurewebsites.net" \
    --name privateendpointlink \
    --virtual-network $vnet \
    --registration-enabled false
#Create the private DNS config
az network private-endpoint dns-zone-group create \
   --resource-group $rg \
   --endpoint-name PrivateEndpoint \
   --name PrivDNSZoneGroup \
   --private-dns-zone "privatelink.azurewebsites.net" \
   --zone-name webapp

Azure Private Link service

If a service provider needs to provide its customers with secure private connectivity to Azure-hosted services, they can do so using the Azure Private Link service. The Azure Private Link service provides a reference to service provider–hosted services that customers can connect to using Azure Private Link.

For this to work, customers need to create a private endpoint inside their Azure virtual network and map it to the Azure Private Link service alias or a resource URI provided by the service provider. Once this mapping is complete on the customer end, the service provider can either auto-approve or manually approve the connection request before traffic is allowed over the Microsoft backbone. Figure 10-8 shows how such an integration can be performed.

FIGURE 10-8 Private Link service integration with a private endpoint.

Notice the following points in Figure 10-8:

A customer has created a private endpoint in their Azure virtual network and associated it with the Private Link service.

The Private Link service is mapped to a standard Azure load balancer that front-ends all traffic to the back-end service resources hosted on virtual machines and virtual machine scale sets.

The customer has connected their on-premises network to the Azure environment using ExpressRoute. This allows traffic from on-premises and Azure-hosted virtual machines to securely and privately route to the service provider’s Azure tenant over the Microsoft backbone.

Private Link service does not require a dedicated subnet. It can be deployed in any subnet in the same Azure virtual network where the Private Link resource is deployed.

Note

Each individual Private Link service can receive connections from multiple private endpoints. However, a private endpoint can only connect to one Private Link service.

Connect to the Private Link resource

Azure allows you to map to a Private Link service using two methods:

Resource URI The resource URI is a unique reference to the Azure Private Link service hosted in the service provider tenant. The format of this is quite complex and unique. For example:

Click here to view code image

/subscriptions/<Subscriptionid>/resourceGroups/<resourcegroupname>/providers/
Microsoft.Network/privateLinkServices/{serviceName}

Service alias When a Private Link service is created, a unique alias is generated automatically for the service. This alias can be used by customers instead of the resource URI to connect to the Private Link service. The alias consists of multiple parts:

Prefix This is provided by the service provider when the Private Link service is created.

GUID This is a unique GUID provided by Azure.

Region This is the Azure region in which the Private Link service was created.

Azure.privatelinkservice Suffix This is an automated standardized suffix that is added to the alias.

Once combined, the complete alias would be as follows, making it unique across the entire global Azure network:

Click here to view code image

-Prefix.{GUID}.region.azure.privatelinkservice

Service visibility

There are three visibility options to control the exposure of the Private Link service. Each setting controls how customers can connect to the service:

Role-Based Access Control Only (None) RBAC helps control service visibility across virtual networks sharing the same Azure AD tenant. Although you can set up cross-tenant visibility, it is not the ideal method and can result in excessive permission delegation if performed incorrectly.

Subscription Restriction (Restrictive) You can define trusted subscriptions to provide access to and set up auto-approvals for connection requests received from the private endpoints hosted in trusted subscriptions.

Anyone with Service Alias (All) For services that are designed for public consumption, you choose this visibility option so anyone can request to connect. Manual approvals would still be required to approve the connection request.

Service access approvals

You can control access to the Private Link service in one of two ways:

Automated approval When the service provider predefines a set of trusted subscriptions or is hosting the private endpoint, any connection requests are automatically approved.

Manual approval In cases where the service provider wants to control access to the Private Link service before traffic is allowed through, manual approval can be set up. In this scenario, connection requests are kept in a pending state until the manual approval is performed.

High availability

Private Link service supports up to eight IPs per service. This can be used to provide high availability in case connectivity issues occur over a single IP. In addition, you can add multiple Private Link services standard load balancers to provide redundancy in case of service failure. Currently, each standard load balancer supports up to eight Private Link services.

Limitations

The Private Link service has a few limitations that you should consider when deciding on its use:

Private Link service requires the use of a standard load balancer. The basic load balancer is not supported.

The back-end pool on the standard load balancer should be configured to point to VMs or a VMSS.

Private Link supports IPv4 TCP and UDP traffic only.

Private Link service walkthrough

The following sections walk you through the process of setting up an Azure Private Link service using the Azure Portal, Azure PowerShell, and the Azure CLI.

Before you proceed with the walkthrough, you need to complete these prerequisites:

Set up an Azure standard load balancer and assign at least one VM to the back-end pool.

Set up or identify the virtual network and subnet where the Private Link service will be created.

Using the Azure Portal

To create a Private Link service using the Azure Portal, follow these steps:

Log in to the Azure Portal, type Private Link in the search box to locate the service, and select it from the list that appears. (See Figure 10-9.)

FIGURE 10-9 Search for the Private Link service.

Click the Create Private Link Service button to start the Create Private Link Service wizard. (See Figure 10-10.)

FIGURE 10-10 Create a Private Link service.

In the Basics tab of the Create Private Link Service wizard, enter the following information (see Figure 10-11) and click Next:

Subscription Select the subscription that will host the Private Link service.

Resource Group Select the resource group you want to use to host the Private Link Service. Alternatively, to create a new resource group, click the Create New link and follow the prompts.

Name Type a unique name for the Private Link service.

Region Choose the Azure region in which you want to host the Private Link service.

FIGURE 10-11 The Basics tab of the Create Private Link Service wizard.

In the Outbound settings tab, enter the following information (see Figure 10-12) and click Next:

Load Balancer Select the load balancer to associate with the Private Link service.

Load Balancer Frontend IP Address Select the front-end IP address to use for the load balancer.

Source NAT Virtual Network This is set automatically based on the load balancer’s virtual network.

Source NAT Subnet Select the subnet to associate with the Private Link service.

Enable TCP Proxy V2 Specify whether TCP proxy V2 should be enabled. Leave this at the default value of No unless required.

Private IP Address Settings Specify whether the private IP address should be dynamic or static. Leave this at the default value of Dynamic.

FIGURE 10-12 The Outbound Settings tab of the Create Private Link Service wizard.

In the Access Security tab, next to Who Can Request Access to Your Service, select the Role-Based Access Control Only option button and click Next. (See Figure 10-13.)

FIGURE 10-13 The Access Security tab of the Create Private Link Service wizard.

In the Tags tab, enter any tags required for the Private Link service or leave the fields blank (see Figure 10-14), and click Next.

FIGURE 10-14 The Tags tab of the Create Private Link Service wizard.

In the Review + Create tab (see Figure 10-15), review your settings and click Create.

FIGURE 10-15 Review and create a Private Link service.

Using Azure PowerShell

You can create a Private Link service with Azure PowerShell using the New-AzVirtualNetworkLink command with various switches to set its parameters. For example, to create the same Private Link service as you did in the preceding section, you use the following code:

Click here to view code image

#Define required variables
$rg = "RG01"
$vnet = "vNET-01"
$subnet = "Subnet01"
$loadbalancer = "LoadBalancer"
$lb-ip = "lb-frontend-ip"
$location = "East US"
#Create Private Link private IP
$IPConf = New-AzPrivateLinkServiceIpConfig -Name 'PrivLink-IPConfig' -Subnet $subnet
-PrivateIpAddress '10.2.0.5'
#Create Private Link service
New-AzPrivateLinkService -Name ‘PrivateLinkService' -ResourceGroupName = $rg -Location =
$location -LoadBalancerFrontendIpConfiguration $lb-ip -IpConfiguration $IPConf

Using the Azure CLI

You can create a Private Link endpoint with the Azure CLI using the az network private-endpoint create command with various switches to set its parameters. For example, to create the same Private Link service as you did in the preceding sections, you use the following code:

Click here to view code image

#Define required variables
rg="RG01"
vnet="vNET-01"
subnetName="Subnet01"
loadbalancer="LoadBalancer"
lb-ip="lb-frontend-ip"
location="eastus"
#Create Private Link service
az network private-link-service create \
    --resource-group $rg \
    --name PrivateLinkService \
    --vnet-name $vnet \
    --subnet $subnetname \
    --lb-name $loadbalancer \
    --lb-frontend-ip-configs $lb-ip \
    --location $location

Best practices

Following are some best practices for private endpoint and Private Link service setup, management, monitoring, and security. Although this list is not exhaustive, it is a great starting point, and covers most of the important areas to consider:

Control access using custom groups If you must delegate permissions for deploying Private Link resources, use custom roles to granularly define the required permissions instead of providing access to built-in role groups such as Owner, Contributor, or Network Contributor. Microsoft provides detailed templates for role permissions to create custom role groups to limit access.

Use one private endpoint for a shared DNS You can create multiple private endpoints for every Private Link resource. However, if the DNS service is common across all the endpoints, it’s best to deploy a single private endpoint to avoid DNS record duplication or conflicts resulting in service outages.

Use activity logs and alerts Use Azure activity logs to monitor changes to Private Link resources. Set up alerts for unwanted activities so you can take effective rollback actions in a timely manner.

Use Azure Monitor To monitor logs generated by Private Link resources in a centralized manner, ingest them into Azure Monitor for easier analysis. You can also use Log Analytics workspaces to analyze the data, derive actionable insights, and set up effective alerts related to activity logs and security logs generated by the service.

Configure long-term log retention If organizational compliance demands the storage of activity and security logs for extended periods of time, set up retention policies on the log analytics storage to ensure data is stored for the required period.

Perform regular service backups Azure Private Link does not integrate with Azure Backup for service backups. However, Azure provides the ability to export the Private Link service configuration as a template, which you can use to restore Private Link endpoints and related resources. In addition, you should perform regular backups using Azure Automation and REST APIs.

Index

A

access approvals, Private Link service, 195

active FTP, Azure Firewall and, 86

active-active mode, Azure VPN gateway, 41–42

Activity logs, 87

address space, 2, 12

algorithms, load balancing, 60–61

alias record sets, 113–116

AnyCast networking, 103

application FQDN traffic filtering, 81

architecture, Azure Bastion, 169–170

authentication

multi-factor, 180

point-to-site VPN gateway connections, 43–44

auto registration, 111–112

using Azure CLI, 112

using Azure Portal, 112

using Azure PowerShell, 112

autoscaling, 23. See also scaling

availability zones, 6, 17, 36

Azure Firewall and, 79

Azure Load Balancer and, 61–62

az network front-door create command, 163–165

az network lb create command, 72–73

az network private-dns link create command, 111

az network private-endpoint create command, 191–192, 199

az network traffic-manager profile create command, 140–141

az network vnet command, 12

Azure Activity Logs, 14

Azure AD (Active Directory), 179

Azure Application Gateway, 15–16

best practices, 33–34

components

back-end pools, 20

front-end IP addresses, 19–20

health probes, 23

HTTP settings, 22

listeners, 20–21

request routing rules, 21–22

creating

using Azure CLI, 32–33

using Azure Portal, 24–30

using Azure PowerShell, 31–32

deployment options, 16

features, 16–18

sizing and scaling, 23

TLS policy, 23–24

Azure Bastion, 167

architecture, 169–170

best practices, 179–181

connecting to a VM using Azure Portal, 176–179

creating

using Azure CLI, 175–176

using Azure Portal, 172–175

using Azure PowerShell, 175–176

disaster recovery, 171

features, 167–168

limitations, 168–169

peering, 171

permissions, 172

redundancy, 171

service requirements, 172

SKUs, 171

Azure CLI. See also commands

application gateway, creating, 32–33

Azure Bastion service, creating, 175–176

Azure Front Door service, setting up, 163–165

Azure Load Balancer, creating, 72–73

Azure Traffic Manager, setting up, 140–141

Azure VPN gateway, creating, 53

creating a vNET, 12

DNS zones, creating, 108

linking a private DNS zone to a vNET, 111

private endpoints, creating, 191–192

Private Link service, creating, 199

reverse DNS lookups, creating, 118

setting up auto registration, 112

Azure DNS, 103. See also DNS zones

best practices, 119–121

DNS zones, 105

private, 105

public, 105

features, 103–104

limitations, 104

queries, 119

RBAC and, 119–120

resource locks, 120–121

reverse DNS lookups, creating, 116

using Azure CLI, 118

using Azure Portal, 116–118

using Azure PowerShell, 118

zone delegation, 119

Azure endpoints, 125. See also endpoints

Azure Firewall, 13, 77

active FTP support, 86

best practices, 100–102

classic rules, 84

creating

using Azure Portal, 87–99

using Azure PowerShell, 99–100

DNAT (destination NAT), 79

DNS proxy, 86

features, 78

forced tunneling, 83

infrastructure FQDNs, 82

IP groups, 82

logging, 86

Activity logs, 87

diagnostic logs, 87

firewall metrics, 86

Manager, 83

policies, 84

rule processing

for incoming traffic, 84–85

for outbound traffic, 85

SNAT (source NAT), 79–80

tags, 81

FQDN, 81

service, 82

Threat Intelligence, 83

traffic filtering, 80

application FQDN, 81

network, 80

web, 80

web categories, 82

Azure Front Door, 145

back ends, 147

back-end pools, 147

best practices, 165–166

caching, 151–153

dynamic content compression, 152

features, 145–146

handling large volumes of traffic, 153

health probes, 148

integration with Azure DDoS Protection Basic, 153

logging, 165

performance counters, 165

protection against unwanted protocols, 153

query strings, 152

Rules Engine, 151

setting up

using Azure CLI, 163–165

using Azure Portal, 154–162

using Azure PowerShell, 162–163

traffic routing, 148–149

URL redirect, 149–150

URL rewrite, 149

WAF security features, 154

wildcard domains, 151

Azure Load Balancer, 55

algorithms, 60–61

availability zones, 61–62

best practices, 74–75

components

back-end pool, 57

front-end IP addresses, 57

health probes, 57–58

creating

using Azure CLI, 72–73

using Azure Portal, 62–70

using Azure PowerShell, 71–72

deployment considerations, 56

features, 56

rules, 58

HA ports, 59

inbound NAT, 59

outbound SNAT, 60

Azure Log Analytics, 13

Azure Monitor, 14, 143–144

Azure Front Door and, 165

logging, 86

Activity logs, 87

diagnostic logs, 87

firewall metrics, 86

Azure Policy, 14, 143, 166, 181

Azure Portal

alias record sets, creating, 113–116

application gateway, creating, 24–30

Azure Bastion service, creating, 172–175

Azure Firewall, creating, 87–99

Azure Front Door service, setting up, 154–162

Azure Load Balancer, creating, 62–70

Azure Traffic Manager, setting up, 134–139

Azure VPN gateway, creating, 46–52

creating a vNET, 8–11

DNS zones, creating, 106–108

linking a private DNS zone to a vNET, 110

private endpoints, creating, 187–190

Private Link service, creating, 195–198

Real User Measurements, enabling, 141–143

reverse DNS lookups, creating, 116–118

setting up auto registration, 112

using Azure Bastion to connect to a VM, 176–179

Azure PowerShell

application gateway, creating, 31–32

Azure Bastion service, creating, 175–176

Azure Front Door service, setting up, 162–163

Azure Load Balancer, creating, 71–72

Azure Traffic Manager, setting up, 139–140

Azure VPN gateway, creating, 52–53

commands

New-AzBastion, 175–176

New-AzDNSZone, 118

New-AzFirewall, 99–100

New-AzFrontDoor, 162–163

New-AzLoad Balancer, 71–72

New-AzPrivateDNSVirtual NetworkLink, 112

New-AzPrivateDNSZone, 108

New-AzTrafficManager Profile, 139–140

NewAzVirtualNetwork, 12

New-AzVirtualNetwork Gateway, 31–32, 52–53

New-AzVirtualNetworkGatewayConnection, 52–53

New-AzVirtual NetworkLink, 190–191, 199

creating a vNET, 12

DNS zones, creating, 108

linking a private DNS zone to a vNET, 111

private endpoints, creating, 190–191

Private Link service, creating, 199

reverse DNS lookups, creating, 118

setting up auto registration, 112

Azure Private Link, 7, 183. See also Private Link service

best practices, 200

DNS configuration, 186

features, 183–184

private endpoints, 184

features, 185

integration with Azure PaaS offerings, 184

integration with customer-owned services, 185

limitations, 185–186

security and, 186

Azure Traffic Manager, 123

best practices, 141–144

endpoints, 124–125

Azure, 125

external, 125–126

failover and recovery, 134

monitoring, 133

nested, 126

features, 123–124

nested profiles, 126–127

RBAC and, 141

Real User Measurements, enabling, 141–143

setting up

using Azure CLI, 140–141

using Azure Portal, 134–139

using Azure PowerShell, 139–140

traffic routing, 127–128

geographic, 132

multi-value, 128

performance, 130–131

priority, 128–129

subnet-based, 128

weighted, 129–130

Azure VPN gateway, 35

availability zone support, 79

best practices, 54

BGP and, 38

connection types, 37–38

creating

using Azure CLI, 53

using Azure Portal, 46–52

using Azure PowerShell, 52–53

deployment considerations, 36–37

design concepts, 36–37

ExpressRoute and, 45–46

features, 35–36

gateway SKUs, 37

gateway subnet, 38

local network gateways, 38

point-to-site VPN gateway connections, 43

authentication, 43–44

Highly Available vNET-to-vNET, 45

supported protocols, 43

vNET-to-vNET connections, 44

redundancy, 39

site-to-site VPN gateway connections

active-active mode, 41–42

HA in active-active mode, 42

High Availability in active-standby mode, 41

multi-site active-Active mode, 40

single-site active standby mode, 39–40

zonal gateways, 46

zone-redundant gateways, 46

AzureActiveDirectory service tag, 7

B

back ends, 147

back-end pools, 1, 20, 57, 147

basic listener, 21

basic request routing rule, 21

Basic SKU, 37

best practices

application gateway, 33–34

Azure Bastion, 179–181

Azure DNS, 119–121

Azure Firewall, 100–102

Azure Front Door, 165–166

Azure Load Balancer, 74–75

Azure Private Link, 200

Azure Traffic Manager, 141–144

Azure VPN gateway, 54

for designing and securing vNETs, 12–14

BGP (Border Gateway Protocol), 6, 38

C

caching, Azure Front Door, 151–153

CDNs (content delivery networks), 145

classic rules, 84

commands

az network front-door create, 163–165

az network lb create, 72–73

az network private-dns link create, 111

az network private-endpoint create, 191–192, 199

az network traffic-manager profile create, 140–141

az network vnet, 12

Azure PowerShell

New-AzBastion, 175–176

New-AzDNSZone, 118

New-AzFirewall, 99–100

New-AzFrontDoor, 162–163

New-AzLoad Balancer, 71–72

New-AzPrivateDNS VirtualNetworkLink, 112

New-AzPrivateDNSZone, 108

New-AzTrafficManagerProfile, 139–140

New-AzVirtualNetwork Gateway, 31–32, 52–53

New-AzVirtualNetworkGatewayConnection, 31–32

New-AzVirtualNetworkLink, 190–191, 199

conditional access policies, 180

connection types, VPN gateway, 37–38

creating

alias record sets, 113–116

application gateway

using Azure CLI, 32–33

using Azure Portal, 24–30

using Azure PowerShell, 31–32

Azure Bastion

using Azure CLI, 175–176

using Azure Portal, 172–175

using Azure PowerShell, 175–176

Azure Firewall

using Azure Portal, 87–99

using Azure PowerShell, 99–100

Azure Load Balancer

using Azure CLI, 72–73

using Azure Portal, 62–70

using Azure PowerShell, 71–72

Azure VPN gateway

using Azure CLI, 53

using Azure Portal, 46–52

using Azure PowerShell, 52–53

DNS zones

using Azure CLI, 108

using Azure Portal, 106–108

using Azure PowerShell, 108

private endpoints

using Azure CLI, 191–192

using Azure Portal, 187–190

using Azure PowerShell, 190–191

Private Link service

using Azure CLI, 199

using Azure Portal, 195–198

using Azure PowerShell, 199

reverse DNS lookups, 116

using Azure CLI, 118

using Azure Portal, 116–118

using Azure PowerShell, 118

vNET

using Azure CLI, 12

using Azure Portal, 8–11

using Azure PowerShell, 12

custom routes

BGP routes, 6

user-defined routes, 5

D

DDoS (distributed denial of service) attacks, 13

default system routes, 3–4

deployment considerations

Azure Load Balancer, 56

Azure VPN gateway, 36–37

vNET(s), 2–3

diagnostic logs, 87

disaster recovery, 8

Azure Bastion, 171

private endpoints and, 186–187

DNAT (destination NAT), Azure Firewall and, 79

DNS proxy, 86

DNS zones, 106, 186. See also private DNS zones; public DNS zones

auto registration, 111–112

using Azure CLI, 112

using Azure Portal, 112

using Azure PowerShell, 112

creating

using Azure CLI, 108

using Azure Portal, 106–108

using Azure PowerShell, 108

linking to vNETs, 109

using Azure CLI, 111

using Azure Portal, 110

using Azure PowerShell, 111

private, 105

public, 105

reverse DNS lookups, creating, 116

using Azure CLI, 118

using Azure Portal, 116–118

using Azure PowerShell, 118

zone delegation, 119

dynamic content compression, 152

E

endpoints, 123, 124–125. See also private endpoints

Azure, 125

external, 125–126

failover and recovery, 134

monitoring, 133

nested, 126

private, 7, 184

disaster recovery and, 186–187

features, 185

integration with Azure PaaS offerings, 184

integration with customer-owned services, 185

limitations, 185–186

security and, 186

service, 7

ExpressRoute, 35, 45–46

external endpoints, 125–126

F

features

Azure Application Gateway, 16–18

Azure Bastion, 167–168

Azure DNS, 103–104

Azure Firewall, 78

Azure Front Door, 145–146

Azure Load Balancer, 56

Azure Private Link, 183–184

Azure Traffic Manager, 123–124

Azure vNET (virtual network), 1–2

Azure VPN gateway, 35–36

private endpoint, 185

file chunking, 152

filtering, threat intelligence-based, 83

forced tunneling, 83

FQDN tags, 81

front-end IP addresses, 19–20

Azure Application Gateway, 19–20

Azure Load Balancer, 57

G

gateway SKUs, 37

gateway subnet, 38

geo-filtering, 34, 165

geographic traffic routing, 132

global peering, 171

groupings, 81

infrastructure FQDNs, 82

IP groups, 82

tags, 81

FQDN, 81

service, 82

web categories, 82

H

hash-based algorithm, 60–61

health probes, 23

Azure Application Gateway, 23

Azure Front Door, 148

Azure Load Balancer, 57–58

High Availability in active-standby mode, Azure VPN gateway, 41

high-availability ports load-balancing rule, 59

HTTP, 22

HTTP/2 protocols, 18

I

IKEv2 VPN, 43

inbound NAT rules, 59

infrastructure FQDNs, 82

internal load balancer, 55

IP addresses

Azure Bastion, 172

front-end, 19–20

IP groups, 82

J-K-L

Key Vault, 180

latency-based traffic routing, 148

listeners, 20–21

load balancers, 15–16, 148. See also Azure Application Gateway

algorithms, 60–61

internal, 55

public, 55

rules, 58

HA ports, 59

inbound NAT, 59

outbound SNAT, 60

local network gateways, 38

logging, 86

Activity logs, 87

Azure Front Door, 165

diagnostic logs, 87

firewall metrics, 86

network traffic, 166

M

MFA (multi-factor authentication), 180

monitoring, endpoints, 133

multi-site active-Active mode, 40

multi-site listener, 21

multi-value traffic routing, 128

N

NAT (network address translation), 7, 59

nested endpoints, 126

nested profiles, 126–127

network traffic filtering, 80

New-AzBastion command, 175–176

New-AzDNSZone command, 118

New-AzFirewall command, 99–100

New-AzFrontDoor command, 162–163

New-AzLoad Balancer command, 71–72

New-AzPrivateDNSV irtualNetworkLink command, 112

New-AzPrivateDNSZone command, 108

New-AzTrafficManagerProfile command, 139–140

NewAzVirtualNetwork command, 12

New-AzVirtualNetworkGateway command, 31–32, 52–53

New-AzVirtualNetworkGatewayConnection command, 31–32

New-AzVirtualNetworkLink command, 190–191, 199

next-hop types, 3–5

non-zonal redundancy, 61

NSGs (network security groups), 6, 13

O

OpenVPN protocol, 43

optional system routes, 4–5

outbound SNAT rules, 60

P

path-based request routing rule, 21

path-based routing, 18

PAWs (privileged access workstations), 180

peering, 5

Azure Bastion, 171

vNET deployment and, 2–3

performance traffic routing, 130–131

permissions, Azure Bastion, 172

point-to-site VPN gateway connections

authentication, 43–44

Highly Available vNET-to-vNET, 45

vNET-to-vNET connections, 44

policy(ies)

Azure Firewall, 84

-based VPNs, 37

conditional access, 180

TLS, 23–24, 34

priority traffic routing, 128–129, 149

private DNS zones, 105. See also DNS zones

auto registration, 111–112

using Azure Portal, 112

using Azure PowerShell, 112

creating

using Azure CLI, 108

using Azure Portal, 106–108

using Azure PowerShell, 108

reverse DNS lookups, creating, 116

using Azure CLI, 118

using Azure Portal, 116–118

using Azure PowerShell, 118

private endpoints, 7, 184

creating

using Azure CLI, 191–192

using Azure Portal, 187–190

using Azure PowerShell, 190–191

disaster recovery and, 186–187

features, 185

integration

with Azure PaaS offerings, 184

with customer-owned services, 185

limitations, 185–186

security and, 186

Private Link service, 192–194

access approvals, 195

connecting to, 194

creating

using Azure CLI, 199

using Azure Portal, 195–198

using Azure PowerShell, 199

High Availability, 195

limitations, 195

visibility options, 194–195

profiles, nested, 126–127

public DNS zones, 105, 113–116. See also alias record sets

public load balancer, 55

Q-R

query

DNS, 119

strings, 152

RBAC (role-based access control), 166

Azure DNS and, 119–120

Azure Traffic Manager and, 141

Real User Measurements, 141–143

redundancy

Azure Bastion, 171

non-zonal, 62

VPN gateway, 39

zonal, 61

zone, 61

regional peering, 171

request routing rules

redirection support, 22

rewriting of HTTP headers and URLs, 22

reverse DNS lookups, creating, 116

using Azure CLI, 118

using Azure Portal, 116–118

using Azure PowerShell, 118

route-based VPNs, 37

routing, 3

BGP routes, 6

default system routes, 3–4

NAT (network address translation), 7

next-hop types, 3–4

optional system routes, 4–5

path-based, 18

route selection, 6

user-defined routes, 5

rules

Azure Firewall, order of processing, 84–85

classic, 84

load balancing, 58

HA ports, 59

inbound NAT, 59

outbound SNAT, 60

request routing, 21–22

redirection support, 22

rewriting of HTTP headers and URLs, 22

Threat Intelligence, 83

URL redirect, 149–150

URL rewrite, 149

WAF (web application firewall), 17

Rules Engine, Azure Front Door, 151

S

scaling, 23, 171

security

Azure Front Door

integration with Azure DDoS Protection Basic, 153

protection against unwanted protocols, 153

WAF (web application firewall), 154

private endpoints and, 186

vNET, 7

segmentation, 7

service endpoints, 7

service tags, 7–8, 13, 82

services, Private Link, 7, 192–194

access approvals, 195

connecting to a VM using Azure Portal, 194

High Availability, 195

limitations, 195

visibility options, 194–195

session affinity, 149

setting up Azure Traffic Manager

using Azure CLI, 140–141

using Azure Portal, 134–139

using Azure PowerShell, 139–140

site-to-site VPN gateway connections

active-active mode, 41–42

HA in active-active mode, 42

High Availability in active-standby mode, 41

multi-site active-Active mode, 40

single-site active standby mode, 39–40

sizing, 34

SKUs

Azure Bastion, 171

gateway, 37

sizing and scaling, 23

v2, 34

SNAT (source NAT), Azure Firewall and, 79–80

source IP affinity algorithm, 61

SSTP (Secure Socket Tunneling Protocol (SSTP), 43

static VIP (virtual IP) assignment, 17

subnet-based traffic routing, 128

subnets, vNET deployment and, 2

T

tags, 81

FQDN, 81

service, 82

Threat Intelligence, 83

TLS policy, 23–24, 34

traffic filtering, 80

application FQDN, 81

network, 80

web, 80

traffic redirection

Azure Application Gateway, 17

Azure DNS and, 104

request routing rules and, 22

traffic routing

Azure Front Door, 148–149

geographic, 132

latency-based, 148

multi-value, 128

performance, 130–131

priority, 128–129, 149

session affinity, 149

subnet-based, 128

weighted, 129–130, 149

U

URL redirect, 149–150

URL rewrite, 149

user-defined routes, 5

V

v2 SKU, 34

virtual network service tags, 166

VirtualNetwork service tag, 8

visibility options, Private Link service, 194–195

VMs (virtual machines), 1, 176–179

VMSS (virtual machine scale sets), 1

vNETs

availability zones, 6

best practices, 12–14

creating

using Azure CLI, 12

using Azure Portal, 8–11

using Azure PowerShell, 12

deployment considerations

address space, 2

peering, 2–3

subnets, 2

disaster recovery, 8

features, 1–2

gateway, 4

integrations for enhanced security, 7

linking to DNS zones, 109

using Azure CLI, 111

using Azure Portal, 110

using Azure PowerShell, 111

NAT (network address translation), 7

NSGs (network security groups), 6

peering, 5

routing, 3

BGP routes, 6

custom routes, 5

default system routes, 3–4

optional system routes, 4–5

user-defined routes, 5

security, 7

service tags, 7–8

VPN (virtual private network), 1, 37

W

WAF (web application firewall), 16, 154

web categories, 82

web-traffic filtering, 80

weighted traffic routing, 129–130, 149

wildcard domains, 151

X-Y-Z

zonal

gateways, 46

redundancy, 61

zone

delegation, 119

redundancy, 46, 61

Code Snippets

Many titles include programming code or configuration examples. To optimize the presentation of these elements, view the eBook in single-column, landscape mode and adjust the font size to the smallest setting. In addition to presenting code and configurations in the reflowable text format, we have included images of the code that mimic the presentation found in the print book; therefore, where the reflowable format may compromise the presentation of the code listing, you will see a “Click here to view code image” link. Click the link to view the print-fidelity code image. To return to the previous page viewed, click the Back button on your device or app.