Az 700

Microsoft
Official
Course
AZ-700T00
Designing and
Implementing Microsoft
Azure Networking
Solutions
AZ-700T00
Designing and Implementing
Microsoft Azure Networking
Solutions
II Disclaimer
Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names,
e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with
any real company, organization, product, domain name, e-mail address, logo, person, place or event is
intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the
user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in
or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written permission of
Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
The names of manufacturers, products, or URLs are provided for informational purposes only and
Microsoft makes no representations and warranties, either expressed, implied, or statutory, regarding
these manufacturers or the use of the products with any Microsoft technologies. The inclusion of a
manufacturer or product does not imply endorsement of Microsoft of the manufacturer or product. Links
may be provided to third party sites. Such sites are not under the control of Microsoft and Microsoft is
not responsible for the contents of any linked site or any link contained in a linked site, or any changes or
updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission
received from any linked site. Microsoft is providing these links to you only as a convenience, and the
inclusion of any link does not imply endorsement of Microsoft of the site or the products contained
therein.
© 2019 Microsoft Corporation. All rights reserved.
Microsoft and the trademarks listed at http://www.microsoft.com/trademarks 1are trademarks of the

Microsoft group of companies. All other trademarks are property of their respective owners.
1 http://www.microsoft.com/trademarks
EULA III
MICROSOFT LICENSE TERMS

MICROSOFT INSTRUCTOR-LED COURSEWARE
These license terms are an agreement between Microsoft Corporation (or based on where you live, one
of its affiliates) and you. Please read them. They apply to your use of the content accompanying this
agreement which includes the media on which you received it, if any. These license terms also apply to
Trainer Content and any updates and supplements for the Licensed Content unless other terms accompa-
ny those items. If so, those terms apply.
BY ACCESSING, DOWNLOADING OR USING THE LICENSED CONTENT, YOU ACCEPT THESE TERMS.
IF YOU DO NOT ACCEPT THEM, DO NOT ACCESS, DOWNLOAD OR USE THE LICENSED CONTENT.
If you comply with these license terms, you have the rights below for each license you acquire.
1. DEFINITIONS.
1. “Authorized Learning Center” means a Microsoft Imagine Academy (MSIA) Program Member,
Microsoft Learning Competency Member, or such other entity as Microsoft may designate from
time to time.
2. “Authorized Training Session” means the instructor-led training class using Microsoft Instruc-
tor-Led Courseware conducted by a Trainer at or through an Authorized Learning Center.
3. “Classroom Device” means one (1) dedicated, secure computer that an Authorized Learning Center
owns or controls that is located at an Authorized Learning Center’s training facilities that meets or
exceeds the hardware level specified for the particular Microsoft Instructor-Led Courseware.
4. “End User” means an individual who is (i) duly enrolled in and attending an Authorized Training
Session or Private Training Session, (ii) an employee of an MPN Member (defined below), or (iii) a
Microsoft full-time employee, a Microsoft Imagine Academy (MSIA) Program Member, or a
Microsoft Learn for Educators – Validated Educator.
5. “Licensed Content” means the content accompanying this agreement which may include the
Microsoft Instructor-Led Courseware or Trainer Content.
6. “Microsoft Certified Trainer” or “MCT” means an individual who is (i) engaged to teach a training
session to End Users on behalf of an Authorized Learning Center or MPN Member, and (ii) current-
ly certified as a Microsoft Certified Trainer under the Microsoft Certification Program.
7. “Microsoft Instructor-Led Courseware” means the Microsoft-branded instructor-led training course
that educates IT professionals, developers, students at an academic institution, and other learners
on Microsoft technologies. A Microsoft Instructor-Led Courseware title may be branded as MOC,
Microsoft Dynamics, or Microsoft Business Group courseware.
8. “Microsoft Imagine Academy (MSIA) Program Member” means an active member of the Microsoft
Imagine Academy Program.
9. “Microsoft Learn for Educators – Validated Educator” means an educator who has been validated
through the Microsoft Learn for Educators program as an active educator at a college, university,
community college, polytechnic or K-12 institution.
10. “Microsoft Learning Competency Member” means an active member of the Microsoft Partner
Network program in good standing that currently holds the Learning Competency status.
11. “MOC” means the “Official Microsoft Learning Product” instructor-led courseware known as
Microsoft Official Course that educates IT professionals, developers, students at an academic
institution, and other learners on Microsoft technologies.
12. “MPN Member” means an active Microsoft Partner Network program member in good standing.
IV EULA
13. “Personal Device” means one (1) personal computer, device, workstation or other digital electronic
device that you personally own or control that meets or exceeds the hardware level specified for
the particular Microsoft Instructor-Led Courseware.
14. “Private Training Session” means the instructor-led training classes provided by MPN Members for
corporate customers to teach a predefined learning objective using Microsoft Instructor-Led
Courseware. These classes are not advertised or promoted to the general public and class attend-
ance is restricted to individuals employed by or contracted by the corporate customer.
15. “Trainer” means (i) an academically accredited educator engaged by a Microsoft Imagine Academy
Program Member to teach an Authorized Training Session, (ii) an academically accredited educator
validated as a Microsoft Learn for Educators – Validated Educator, and/or (iii) a MCT.
16. “Trainer Content” means the trainer version of the Microsoft Instructor-Led Courseware and
additional supplemental content designated solely for Trainers’ use to teach a training session
using the Microsoft Instructor-Led Courseware. Trainer Content may include Microsoft PowerPoint
presentations, trainer preparation guide, train the trainer materials, Microsoft One Note packs,
classroom setup guide and Pre-release course feedback form. To clarify, Trainer Content does not
include any software, virtual hard disks or virtual machines.
2. USE RIGHTS. The Licensed Content is licensed, not sold. The Licensed Content is licensed on a one
copy per user basis, such that you must acquire a license for each individual that accesses or uses the
Licensed Content.
●● 2.1 Below are five separate sets of use rights. Only one set of rights apply to you.
1. If you are a Microsoft Imagine Academy (MSIA) Program Member:
1. Each license acquired on behalf of yourself may only be used to review one (1) copy of the
Microsoft Instructor-Led Courseware in the form provided to you. If the Microsoft Instruc-
tor-Led Courseware is in digital format, you may install one (1) copy on up to three (3)
Personal Devices. You may not install the Microsoft Instructor-Led Courseware on a device
you do not own or control.
2. For each license you acquire on behalf of an End User or Trainer, you may either:
1. distribute one (1) hard copy version of the Microsoft Instructor-Led Courseware to one
(1) End User who is enrolled in the Authorized Training Session, and only immediately
prior to the commencement of the Authorized Training Session that is the subject matter
of the Microsoft Instructor-Led Courseware being provided, or
2. provide one (1) End User with the unique redemption code and instructions on how they
can access one (1) digital version of the Microsoft Instructor-Led Courseware, or
3. provide one (1) Trainer with the unique redemption code and instructions on how they
can access one (1) Trainer Content.
3. For each license you acquire, you must comply with the following:
1. you will only provide access to the Licensed Content to those individuals who have
acquired a valid license to the Licensed Content,
2. you will ensure each End User attending an Authorized Training Session has their own
valid licensed copy of the Microsoft Instructor-Led Courseware that is the subject of the
Authorized Training Session,
3. you will ensure that each End User provided with the hard-copy version of the Microsoft
Instructor-Led Courseware will be presented with a copy of this agreement and each End
EULA V
User will agree that their use of the Microsoft Instructor-Led Courseware will be subject
to the terms in this agreement prior to providing them with the Microsoft Instructor-Led
Courseware. Each individual will be required to denote their acceptance of this agree-
ment in a manner that is enforceable under local law prior to their accessing the Micro-
soft Instructor-Led Courseware,
4. you will ensure that each Trainer teaching an Authorized Training Session has their own
valid licensed copy of the Trainer Content that is the subject of the Authorized Training
Session,
5. you will only use qualified Trainers who have in-depth knowledge of and experience with
the Microsoft technology that is the subject of the Microsoft Instructor-Led Courseware
being taught for all your Authorized Training Sessions,
6. you will only deliver a maximum of 15 hours of training per week for each Authorized
Training Session that uses a MOC title, and
7. you acknowledge that Trainers that are not MCTs will not have access to all of the trainer
resources for the Microsoft Instructor-Led Courseware.
2. If you are a Microsoft Learning Competency Member:
1. Each license acquire may only be used to review one (1) copy of the Microsoft Instruc-
tor-Led Courseware in the form provided to you. If the Microsoft Instructor-Led Course-
ware is in digital format, you may install one (1) copy on up to three (3) Personal Devices.
You may not install the Microsoft Instructor-Led Courseware on a device you do not own or
control.
2. For each license you acquire on behalf of an End User or MCT, you may either:
(1) End User attending the Authorized Training Session and only immediately prior to
the commencement of the Authorized Training Session that is the subject matter of the
Microsoft Instructor-Led Courseware provided, or
2. provide one (1) End User attending the Authorized Training Session with the unique
redemption code and instructions on how they can access one (1) digital version of the
Microsoft Instructor-Led Courseware, or
3. you will provide one (1) MCT with the unique redemption code and instructions on how
they can access one (1) Trainer Content.
2. you will ensure that each End User attending an Authorized Training Session has their
own valid licensed copy of the Microsoft Instructor-Led Courseware that is the subject of
the Authorized Training Session,
3. you will ensure that each End User provided with a hard-copy version of the Microsoft
VI EULA
4. you will ensure that each MCT teaching an Authorized Training Session has their own
valid licensed copy of the Trainer Content that is the subject of the Authorized Training
Session,
5. you will only use qualified MCTs who also hold the applicable Microsoft Certification
credential that is the subject of the MOC title being taught for all your Authorized
Training Sessions using MOC,
6. you will only provide access to the Microsoft Instructor-Led Courseware to End Users,
and
7. you will only provide access to the Trainer Content to MCTs.
3. If you are a MPN Member:
1. Each license acquired on behalf of yourself may only be used to review one (1) copy of the
Microsoft Instructor-Led Courseware in the form provided to you. If the Microsoft Instruc-
tor-Led Courseware is in digital format, you may install one (1) copy on up to three (3)
Personal Devices. You may not install the Microsoft Instructor-Led Courseware on a device
you do not own or control.
2. For each license you acquire on behalf of an End User or Trainer, you may either:
(1) End User attending the Private Training Session, and only immediately prior to the
commencement of the Private Training Session that is the subject matter of the Micro-
soft Instructor-Led Courseware being provided, or
2. provide one (1) End User who is attending the Private Training Session with the unique
redemption code and instructions on how they can access one (1) digital version of the
Microsoft Instructor-Led Courseware, or
3. you will provide one (1) Trainer who is teaching the Private Training Session with the
unique redemption code and instructions on how they can access one (1) Trainer
Content.
2. you will ensure that each End User attending an Private Training Session has their own
valid licensed copy of the Microsoft Instructor-Led Courseware that is the subject of the
Private Training Session,
3. you will ensure that each End User provided with a hard copy version of the Microsoft
4. you will ensure that each Trainer teaching an Private Training Session has their own valid
licensed copy of the Trainer Content that is the subject of the Private Training Session,
EULA VII
5. you will only use qualified Trainers who hold the applicable Microsoft Certification
credential that is the subject of the Microsoft Instructor-Led Courseware being taught
for all your Private Training Sessions,
6. you will only use qualified MCTs who hold the applicable Microsoft Certification creden-
tial that is the subject of the MOC title being taught for all your Private Training Sessions
using MOC,
7. you will only provide access to the Microsoft Instructor-Led Courseware to End Users,
and
8. you will only provide access to the Trainer Content to Trainers.
4. If you are an End User:
For each license you acquire, you may use the Microsoft Instructor-Led Courseware solely for
your personal training use. If the Microsoft Instructor-Led Courseware is in digital format, you
may access the Microsoft Instructor-Led Courseware online using the unique redemption code
provided to you by the training provider and install and use one (1) copy of the Microsoft
Instructor-Led Courseware on up to three (3) Personal Devices. You may also print one (1) copy
of the Microsoft Instructor-Led Courseware. You may not install the Microsoft Instructor-Led
Courseware on a device you do not own or control.
5. If you are a Trainer.
1. For each license you acquire, you may install and use one (1) copy of the Trainer Content in
the form provided to you on one (1) Personal Device solely to prepare and deliver an
Authorized Training Session or Private Training Session, and install one (1) additional copy
on another Personal Device as a backup copy, which may be used only to reinstall the
Trainer Content. You may not install or use a copy of the Trainer Content on a device you do
not own or control. You may also print one (1) copy of the Trainer Content solely to prepare
for and deliver an Authorized Training Session or Private Training Session.
2. If you are an MCT, you may customize the written portions of the Trainer Content that are
logically associated with instruction of a training session in accordance with the most recent
version of the MCT agreement.
3. If you elect to exercise the foregoing rights, you agree to comply with the following: (i)
customizations may only be used for teaching Authorized Training Sessions and Private
Training Sessions, and (ii) all customizations will comply with this agreement. For clarity, any
use of “customize” refers only to changing the order of slides and content, and/or not using
all the slides or content, it does not mean changing or modifying any slide or content.
●● 2.2 Separation of Components. The Licensed Content is licensed as a single unit and you
may not separate their components and install them on different devices.
●● 2.3 Redistribution of Licensed Content. Except as expressly provided in the use rights
above, you may not distribute any Licensed Content or any portion thereof (including any permit-
ted modifications) to any third parties without the express written permission of Microsoft.
●● 2.4 Third Party Notices. The Licensed Content may include third party code that Micro-
soft, not the third party, licenses to you under this agreement. Notices, if any, for the third party
code are included for your information only.
●● 2.5 Additional Terms. Some Licensed Content may contain components with additional
terms, conditions, and licenses regarding its use. Any non-conflicting terms in those conditions
and licenses also apply to your use of that respective component and supplements the terms
described in this agreement.
VIII EULA
3. LICENSED CONTENT BASED ON PRE-RELEASE TECHNOLOGY. If the Licensed Content’s subject

matter is based on a pre-release version of Microsoft technology (“Pre-release”), then in addition to
the other provisions in this agreement, these terms also apply:
1. Pre-Release Licensed Content. This Licensed Content subject matter is on the Pre-release
version of the Microsoft technology. The technology may not work the way a final version of the
technology will and we may change the technology for the final version. We also may not release a
final version. Licensed Content based on the final version of the technology may not contain the
same information as the Licensed Content based on the Pre-release version. Microsoft is under no
obligation to provide you with any further content, including any Licensed Content based on the
final version of the technology.
2. Feedback. If you agree to give feedback about the Licensed Content to Microsoft, either directly
or through its third party designee, you give to Microsoft without charge, the right to use, share
and commercialize your feedback in any way and for any purpose. You also give to third parties,
without charge, any patent rights needed for their products, technologies and services to use or
interface with any specific parts of a Microsoft technology, Microsoft product, or service that
includes the feedback. You will not give feedback that is subject to a license that requires Micro-
soft to license its technology, technologies, or products to third parties because we include your
feedback in them. These rights survive this agreement.
3. Pre-release Term. If you are an Microsoft Imagine Academy Program Member, Microsoft Learn-
ing Competency Member, MPN Member, Microsoft Learn for Educators – Validated Educator, or
Trainer, you will cease using all copies of the Licensed Content on the Pre-release technology upon
(i) the date which Microsoft informs you is the end date for using the Licensed Content on the
Pre-release technology, or (ii) sixty (60) days after the commercial release of the technology that is
the subject of the Licensed Content, whichever is earliest (“Pre-release term”). Upon expiration or
termination of the Pre-release term, you will irretrievably delete and destroy all copies of the
Licensed Content in your possession or under your control.
4. SCOPE OF LICENSE. The Licensed Content is licensed, not sold. This agreement only gives you some
rights to use the Licensed Content. Microsoft reserves all other rights. Unless applicable law gives you
more rights despite this limitation, you may use the Licensed Content only as expressly permitted in
this agreement. In doing so, you must comply with any technical limitations in the Licensed Content
that only allows you to use it in certain ways. Except as expressly permitted in this agreement, you
may not:
●● access or allow any individual to access the Licensed Content if they have not acquired a valid
license for the Licensed Content,
●● alter, remove or obscure any copyright or other protective notices (including watermarks), brand-
ing or identifications contained in the Licensed Content,
●● modify or create a derivative work of any Licensed Content,
●● publicly display, or make the Licensed Content available for others to access or use,
●● copy, print, install, sell, publish, transmit, lend, adapt, reuse, link to or post, make available or
distribute the Licensed Content to any third party,
●● work around any technical limitations in the Licensed Content, or
●● reverse engineer, decompile, remove or otherwise thwart any protections or disassemble the
Licensed Content except and only to the extent that applicable law expressly permits, despite this
limitation.
5. RESERVATION OF RIGHTS AND OWNERSHIP. Microsoft reserves all rights not expressly granted to
you in this agreement. The Licensed Content is protected by copyright and other intellectual property
EULA IX
laws and treaties. Microsoft or its suppliers own the title, copyright, and other intellectual property
rights in the Licensed Content.
6. EXPORT RESTRICTIONS. The Licensed Content is subject to United States export laws and regula-
tions. You must comply with all domestic and international export laws and regulations that apply to
the Licensed Content. These laws include restrictions on destinations, end users and end use. For
additional information, see www.microsoft.com/exporting.
7. SUPPORT SERVICES. Because the Licensed Content is provided “as is”, we are not obligated to
provide support services for it.
8. TERMINATION. Without prejudice to any other rights, Microsoft may terminate this agreement if you
fail to comply with the terms and conditions of this agreement. Upon termination of this agreement
for any reason, you will immediately stop all use of and delete and destroy all copies of the Licensed
Content in your possession or under your control.
9. LINKS TO THIRD PARTY SITES. You may link to third party sites through the use of the Licensed
Content. The third party sites are not under the control of Microsoft, and Microsoft is not responsible
for the contents of any third party sites, any links contained in third party sites, or any changes or
updates to third party sites. Microsoft is not responsible for webcasting or any other form of trans-
mission received from any third party sites. Microsoft is providing these links to third party sites to
you only as a convenience, and the inclusion of any link does not imply an endorsement by Microsoft
of the third party site.
10. ENTIRE AGREEMENT. This agreement, and any additional terms for the Trainer Content, updates and
supplements are the entire agreement for the Licensed Content, updates and supplements.
11. APPLICABLE LAW.
1. United States. If you acquired the Licensed Content in the United States, Washington state law
governs the interpretation of this agreement and applies to claims for breach of it, regardless of
conflict of laws principles. The laws of the state where you live govern all other claims, including
claims under state consumer protection laws, unfair competition laws, and in tort.
2. Outside the United States. If you acquired the Licensed Content in any other country, the laws of
that country apply.
12. LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the
laws of your country. You may also have rights with respect to the party from whom you acquired the
Licensed Content. This agreement does not change your rights under the laws of your country if the
laws of your country do not permit it to do so.
13. DISCLAIMER OF WARRANTY. THE LICENSED CONTENT IS LICENSED "AS-IS" AND "AS AVAILA-
BLE." YOU BEAR THE RISK OF USING IT. MICROSOFT AND ITS RESPECTIVE AFFILIATES GIVES NO
EXPRESS WARRANTIES, GUARANTEES, OR CONDITIONS. YOU MAY HAVE ADDITIONAL CON-
SUMER RIGHTS UNDER YOUR LOCAL LAWS WHICH THIS AGREEMENT CANNOT CHANGE. TO
THE EXTENT PERMITTED UNDER YOUR LOCAL LAWS, MICROSOFT AND ITS RESPECTIVE AFFILI-
ATES EXCLUDES ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICU-
LAR PURPOSE AND NON-INFRINGEMENT.
14. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. YOU CAN RECOVER FROM
MICROSOFT, ITS RESPECTIVE AFFILIATES AND ITS SUPPLIERS ONLY DIRECT DAMAGES UP TO
US$5.00. YOU CANNOT RECOVER ANY OTHER DAMAGES, INCLUDING CONSEQUENTIAL, LOST
PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES.
X EULA
This limitation applies to

●● anything related to the Licensed Content, services, content (including code) on third party Internet
sites or third-party programs; and
●● claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence,
or other tort to the extent permitted by applicable law.
It also applies even if Microsoft knew or should have known about the possibility of the damages. The
above limitation or exclusion may not apply to you because your country may not allow the exclusion
or limitation of incidental, consequential, or other damages.
Please note: As this Licensed Content is distributed in Quebec, Canada, some of the clauses in this
agreement are provided below in French.
Remarque : Ce le contenu sous licence étant distribué au Québec, Canada, certaines des clauses
dans ce contrat sont fournies ci-dessous en français.
EXONÉRATION DE GARANTIE. Le contenu sous licence visé par une licence est offert « tel quel ». Toute
utilisation de ce contenu sous licence est à votre seule risque et péril. Microsoft n’accorde aucune autre
garantie expresse. Vous pouvez bénéficier de droits additionnels en vertu du droit local sur la protection
dues consommateurs, que ce contrat ne peut modifier. La ou elles sont permises par le droit locale, les
garanties implicites de qualité marchande, d’adéquation à un usage particulier et d’absence de contre-
façon sont exclues.
LIMITATION DES DOMMAGES-INTÉRÊTS ET EXCLUSION DE RESPONSABILITÉ POUR LES DOMMAG-
ES. Vous pouvez obtenir de Microsoft et de ses fournisseurs une indemnisation en cas de dommages
directs uniquement à hauteur de 5,00 $ US. Vous ne pouvez prétendre à aucune indemnisation pour les
autres dommages, y compris les dommages spéciaux, indirects ou accessoires et pertes de bénéfices.
Cette limitation concerne:
●● tout ce qui est relié au le contenu sous licence, aux services ou au contenu (y compris le code)
figurant sur des sites Internet tiers ou dans des programmes tiers; et.
●● les réclamations au titre de violation de contrat ou de garantie, ou au titre de responsabilité stricte, de
négligence ou d’une autre faute dans la limite autorisée par la loi en vigueur.
Elle s’applique également, même si Microsoft connaissait ou devrait connaître l’éventualité d’un tel
dommage. Si votre pays n’autorise pas l’exclusion ou la limitation de responsabilité pour les dommages
indirects, accessoires ou de quelque nature que ce soit, il se peut que la limitation ou l’exclusion ci-dessus
ne s’appliquera pas à votre égard.
EFFET JURIDIQUE. Le présent contrat décrit certains droits juridiques. Vous pourriez avoir d’autres droits
prévus par les lois de votre pays. Le présent contrat ne modifie pas les droits que vous confèrent les lois
de votre pays si celles-ci ne le permettent pas.
Revised April 2019
Contents
■■ Module 0 Course introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Start Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
■■ Module 1 Introduction to Azure Virtual Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Introduction to Azure virtual networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
■■ Module 2 Design and implement hybrid networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Design and implement hybrid networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
■■ Module 3 Design and implement Azure ExpressRoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Design and implement Azure ExpressRoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
■■ Module 4 Load balance non-HTTP(S) traffic in Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Load balance non-HTTP(S) traffic in Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
■■ Module 5 Load balance HTTP(S) traffic in Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Load balance HTTP(S) traffic in Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
■■ Module 6 Design and implement network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Design and implement network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
■■ Module 7 Design and implement private access to Azure services . . . . . . . . . . . . . . . . . . . . . . . 369
Design and implement private access to Azure Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
■■ Module 8 Design and implement network monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Design and implement network monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Module 0 Course introduction
Start Here
About this Course
Course Description
This course teaches Network Engineers how to design, implement, and maintain Azure networking
solutions. This course covers the process of designing, implementing, and managing core Azure network-
ing infrastructure, Hybrid Networking connections, load balancing traffic, network routing, private access
to Azure services, network security and monitoring. Learn how to design and implement a secure, reliable,
network infrastructure in Azure and how to establish hybrid connectivity, routing, private access to Azure
services, and monitoring in Azure.
Level: Intermediate
Audience
This course is for Network Engineers looking to specialize in Azure networking solutions. An Azure
Network engineer designs and implements core Azure networking infrastructure, hybrid networking
connections, load balance traffic, network routing, private access to Azure services, network security and
monitoring. The azure network engineer will manage networking solutions for optimal performance,
resiliency, scale, and security.
Prerequisites
Successful Azure Network Engineers start this role with experience in enterprise networking, on-premises
or cloud infrastructure, and network security.
●● Understanding on-premises virtualization technologies, including: VMs, virtual networking, and virtual
hard disks.
●● Understanding of network configurations, including TCP/IP, Domain Name System (DNS), virtual
private networks (VPNs), firewalls, and encryption technologies.
●● Understanding of software defined networking
●● Understanding hybrid network connectivity methods, such as VPN
2
●● Understanding resilience and disaster recovery, including high availability, and restore operations
regarding networking.
You can gain the prerequisites and a better understanding of Azure by reviewing these Learn Modules:
●● Azure Fundamentals part 1: Describe core Azure concepts1
●● Azure Fundamentals part 2: Describe core Azure services2
●● Azure Fundamentals part 3: Describe core solutions and management tools on Azure3
●● Azure Fundamentals part 4: Describe general security and network security features4
●● AZ-104: Configure and manage virtual networks for Azure administrators5
Expected learning
●● Design, implement and manage hybrid network connections such as S2S, P2S, and ExpressRoute
●● Design and implement core Azure networking infrastructure such as VNets, DNS, Public IPs, and Vnet
Peering
●● Design and implement routing and load balancing in Azure using VNet routing, Load balancers, Appli-
cation Gateway, Front Door, Traffic Manager, and Azure Virtual Network NAT
●● Secure and monitor networks with Firewall, NSGs, Web Application Firewall, and Azure monitor
●● Design and implement private access to Azure Services
Syllabus
The course content includes a mix of content, demonstrations, hands-on labs, reference links, and
knowledge check questions.
Module 01 - Introduction to Azure virtual networks
In this module you will learn how to design and implement fundamental Azure Networking resources
such as virtual networks, public and private IPs, DNS, virtual network peering, routing, and Azure Virtual
NAT.
●● Explore Azure virtual networks
●● Configure public IP services
●● Exercise: design and implement a virtual network in Azure
●● Design name resolution for your virtual network
●● Exercise: configure DNS settings in Azure
●● Enable cross-VNet connectivity with peering
●● Exercise: connect two Azure virtual networks using global virtual network peering
●● Implement virtual network traffic routing
●● Configure internet access with Azure Virtual NAT
Module 02 - Design and implement Hybrid Networking
1 https://docs.microsoft.com/en-us/learn/paths/az-900-describe-cloud-concepts/
2 https://docs.microsoft.com/en-us/learn/paths/az-900-describe-core-azure-services/
3 https://docs.microsoft.com/en-us/learn/paths/az-900-describe-core-solutions-management-tools-azure/
4 https://docs.microsoft.com/en-us/learn/paths/az-900-describe-general-security-network-security-features/
5 https://docs.microsoft.com/en-us/learn/paths/az-104-manage-virtual-networks/
3
In this module you will learn how to design and implement hybrid networking solutions such as Site-to-
Site VPN connections, Point-to-Site VPN connections, Azure Virtual WAN and Virtual WAN hubs.
●● Design and implement Azure VPN Gateway
●● Exercise: create and configure a virtual network gateway
●● Connect networks with Site-to-site VPN connections
●● Connect devices to networks with Point-to-site VPN connections
●● Connect remote resources by using Azure Virtual WANs
●● Exercise: create a Virtual WAN by using Azure portal
●● Create a network virtual appliance (NVA) in a virtual hub
Module 03 - Design and implement Azure ExpressRoute
In this module you will learn how to design and implement Azure ExpressRoute, ExpressRoute Global
Reach, ExpressRoute FastPath and ExpressRoute peering options.
●● Explore Azure ExpressRoute
●● Design an ExpressRoute deployment
●● Exercise: configure an ExpressRoute gateway
●● Exercise: provision an ExpressRoute circuit
●● Configure peering for an ExpressRoute deployment
●● Connect an ExpressRoute circuit to a VNet
●● Connect geographically dispersed networks with ExpressRoute Global Reach
●● Improve data path performance between networks with ExpressRoute FastPath
●● Troubleshoot ExpressRoute connection issues
Module 04 - load balance non-HTTP(S) traffic in Azure
In this module you will learn how to design and implement load balancing solutions for non-HTTP(S)
traffic in Azure with Azure Load balancer and Traffic Manager.
●● Explore load balancing
●● Design and implement Azure load balancer using the Azure portal
●● Exercise: create and configure an Azure load balancer
●● Explore Azure Traffic Manager
●● Exercise: create a Traffic Manager profile using the Azure portal
Module 05 - load balance HTTP(S) traffic in Azure
In this module you will learn how to design and implement load balancing solutions for HTTP(S) traffic in
Azure with Azure Application gateway and Azure Front Door.
●● Design Azure application gateway
●● Configure Azure application gateway
●● Exercise: deploy Azure application gateway
●● Design and configure Azure front door
●● Exercise: create a front door for a highly available web application
4
Module 06 - Design and Implement network security

In this module you will learn to design and imponent network security solutions such as Azure DDoS,
Azure Firewalls, Network Security Groups, and Web Application Firewall. Secure your virtual networks with
Azure Security Benchmark
●● Secure your virtual networks in the Azure portal
●● Deploy Azure DDoS Protection by using the Azure portal
●● Exercise: configure DDoS Protection on a virtual network using the Azure portal
●● Deploy Network Security Groups by using the Azure portal
●● Design and implement Azure Firewall
●● Exercise: deploy and configure Azure Firewall using the Azure portal
●● Working with Azure Firewall Manager
●● Exercise: secure your virtual hub using Azure Firewall Manager
●● Implement a Web Application Firewall on Azure Front Door
Module 07 - Design and implement private access to Azure Services
In this module you will learn to design and implement private access to Azure Services with Azure Private
Endpoints and Service Endpoints.
●● Define Private Link Service and private endpoint
●● Exercise: create an Azure private endpoint using Azure PowerShell
●● Explain virtual network service endpoints
●● Exercise: restrict network access to PaaS resources with virtual network service endpoints
●● Integrate Private Link with DNS
●● Integrate your App Service with Azure virtual networks
Module 08 - Design and implement network monitoring
In this module you will learn to design and implement network monitoring solutions such as Azure
Monitor and Network watcher.
●● Monitor your networks with Azure Monitor
●● Exercise: Monitor a load balancer resource by using Azure Monitor
●● Monitor your networks with Azure Network Watcher
AZ-700 Certification Exam

The AZ-700, Designing and Implementing Microsoft Azure Networking Solutions6, certification exam
is geared towards Azure Network Engineers candidates who recommend, plan, and implement Azure
networking solutions. Professionals in this role manage the solution for performance, resiliency, scale, and
security. They deploy networking solutions by using the Azure Portal and other methods, including
PowerShell, Azure Command-Line Interface (CLI), and Azure Resource Manager templates (ARM tem-
plates).
The Azure Network Engineer works with solution architects, cloud administrators, security engineers,
application developers, and DevOps engineers to deliver Azure solutions.
6 https://docs.microsoft.com/learn/certifications/exams/az-700
5
Candidates for this exam should have expert Azure administration skills, in addition to extensive experi-
ence and knowledge of networking, hybrid connections, and network security.
The exam includes five study areas. The percentages indicate the relative weight of each area on the
exam. The higher the percentage, the more questions the exam will contain.
AZ-700 Study Areas Weights

Design, Implement, and Manage Hybrid Network- 10-15%
ing
Design and Implement Core Networking Infra- 20-25%
structure
Design and Implement Routing 25-30%
Secure and Monitor Networks 15-20%
Design and Implement Private Access to Azure 10-15%
Services
Additional Study Resources

There are a lot of additional resources to help you learn about Azure. We recommend you bookmark
these pages.
●● Learn - AZ-104: Configure and manage virtual networks for Azure administrators7
●● Azure Community Support8
●● Azure Documentation9
●● Microsoft Azure Blog10
●● Microsoft Learn Blog11
7 https://docs.microsoft.com/learn/paths/az-104-manage-virtual-networks/
8 https://azure.microsoft.com/support/community/
9 https://docs.microsoft.com/azure/
10 https://azure.microsoft.com/blog/
11 https://techcommunity.microsoft.com/t5/microsoft-learn-blog/bg-p/MicrosoftLearnBlog
Module 1 Introduction to Azure Virtual Net-
works
Introduction to Azure virtual networks

1-Introduction
Imagine yourself in the role of a network engineer at an organization that is in the process of migrating
infrastructure and applications to Azure. As the network engineer you need users to be able to access
resources such as file storage, databases, and applications on-premises and in Azure. Azure virtual
networks enable you to provide secure, reliable access to your Azure infrastructure and resources, and
on-premises resources.
Learning objectives
In this module, you will:
●● Implement virtual networks
●● Design and implement name resolution
●● Design and implement cross-VNET connectivity
●● Design and implement an Azure Virtual Network NAT
●● Implement virtual network routing
Prerequisites
●● You should have experience with networking concepts, such as IP addressing, Domain Name System
(DNS), and routing
●● You should have experience with network connectivity methods, such as VPN or WAN
●● You should have experience with the Azure portal and Azure PowerShell
8
2-Explore Azure Virtual Networks

Azure Virtual Networks (VNets) are the fundamental building block of your private network in Azure.
VNets enable you to build complex virtual networks that are similar to an on-premises network, with
additional benefits of Azure infrastructure such as scale, availability, and isolation. A VNet is a representa-
tion of your own network in the cloud. It is a logical isolation of the Azure cloud dedicated to your
subscription. You can use VNets to provision and manage virtual private networks (VPNs) in Azure and,
optionally, link the VNets with other VNets in Azure, or with your on-premises IT infrastructure to create
hybrid or cross-premises solutions. Each VNet you create has its own CIDR block and can be linked to
other VNets and on-premises networks as long as the CIDR blocks do not overlap. You also have control
of DNS server settings for VNets, and segmentation of the VNet into subnets.
Capabilities of Azure Virtual Networks

Azure VNets enable resources in Azure to securely communicate with each other, the internet, and
on-premises networks.
●● Communication with the internet. All resources in a VNet can communicate outbound to the
internet, by default. You can communicate inbound to a resource by assigning a public IP address or a
public Load Balancer. You can also use public IP or public Load Balancer to manage your outbound
connections.
●● Communication between Azure resources. There are three key mechanisms through which Azure
resource can communicate: VNets, VNet service endpoints and VNet peering. Virtual Networks can
connect not only VMs, but other Azure Resources, such as the App Service Environment, Azure
Kubernetes Service, and Azure virtual machine scale sets. You can use service endpoints to connect to
other Azure resource types, such as Azure SQL databases and storage accounts. When you create a
VNet, your services and VMs within your VNet can communication directly and securely with each
other in the cloud.
●● Communication between on-premises resources. Securely extend your data center. You can
connect your on-premises computers and networks to a virtual network using any of the following
options: Point-to-site virtual private network (VPN), Site-to-site VPN, Azure ExpressRoute.
●● Filtering network traffic. You can filter network traffic between subnets using any combination of
network security groups and network virtual appliances like firewalls, gateways, proxies, and Network
Address Translation (NAT) services.
●● Routing network traffic. Azure routes traffic between subnets, connected virtual networks, on-prem-
ises networks, and the Internet, by default. You can implement route tables or border gateway
protocol (BGP) routes to override the default routes Azure creates.
Design considerations for Azure Virtual Networks

With some knowledge and planning, you will be able to deploy virtual networks and connect the resourc-
es you need effectively.
Address space and subnets

You can create multiple virtual networks per region per subscription. You can create multiple subnets
within each virtual network.
Virtual Networks
9
When creating a VNet, it is recommended that you use the address ranges enumerated in RFC 1918,
which have been set aside by the IETF for private, non-routable address spaces:
●● 10.0.0.0 - 10.255.255.255 (10/8 prefix)
●● 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
●● 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
In addition, you cannot add the following address ranges:
●● 224.0.0.0/4 (Multicast)
●● 255.255.255.255/32 (Broadcast)
●● 127.0.0.0/8 (Loopback)
●● 169.254.0.0/16 (Link-local)
●● 168.63.129.16/32 (Internal DNS)
Azure assigns resources in a virtual network a private IP address from the address space that you provi-
sion. For example, if you deploy a VM in a VNet with address space 10.0.0.0/16, the VM will be assigned a
private IP like 10.0.0.4. it is important to note that Azure reserves 5 IP addresses within each subnet. These
are x.x.x.0-x.x.x.3 and the last address of the subnet. x.x.x.1-x.x.x.3 is reserved in each subnet for Azure
services.
●● x.x.x.0: Network address
●● x.x.x.1: Reserved by Azure for the default gateway
●● x.x.x.2, x.x.x.3: Reserved by Azure to map the Azure DNS IPs to the VNet space
●● x.x.x.255: Network broadcast address
When planning to implement virtual networks, you need to consider the following:
●● Ensure non-overlapping address spaces. Make sure your VNet address space (CIDR block) does not
overlap with your organization's other network ranges.
●● Is any security isolation required?
●● Do you need to mitigate any IP addressing limitations?
●● Will there be connections between Azure VNets and on-premises networks?
●● Is there any isolation required for administrative purposes?
●● Are you using any Azure services that create their own VNets?
Subnets
A subnet is a range of IP address in the VNet. You can segment VNets into different size subnets, creating
as many subnets as you require for organization and security within the subscription limit. You can then
deploy Azure resources in a specific subnet. Just like in a traditional network, subnets allow you to
segment your VNet address space into segments that are appropriate for the organization's internal
network. This also improves address allocation efficiency. The smallest supported IPv4 subnet is /29, and
the largest is /8 (using CIDR subnet definitions). IPv6 subnets must be exactly /64 in size. When planning
to implement subnets, you need to consider the following:
●● Each subnet must have a unique address range, specified in Classless Inter-Domain Routing (CIDR)
format.
●● Certain Azure services require their own subnet.
10
●● Subnets can be used for traffic management. For example, you can create subnets to route traffic
through a network virtual appliance.
●● You can limit access to Azure resources to specific subnets with a virtual network service endpoint.
You can create multiple subnets, and enable a service endpoint for some subnets, but not others.
Micro-segmentation
Although subnets are the smallest unit you can create based on IP addressing, you can further segment
your network by using Network Security Groups (NSGs) to control access to the subnet. Each network
security group contains rules, which allow or deny traffic to and from sources and destinations.
You can associate zero or one NSG to each subnet in a virtual network. You can associate the same, or a
different, network security group to each subnet.
Determine a naming convention

As part of your Azure network design, it is important to plan your naming convention for your resources.
An effective naming convention composes resource names from important information about each
resource. A well-chosen name helps you quickly identify the resource's type, its associated workload, its
deployment environment, and the Azure region hosting it. For example, a public IP resource for a produc-
tion SharePoint workload residing in the West US region might be pip-sharepoint-prod-westus-001
All Azure resource types have a scope that defines the level that resource names must be unique. A
resource must have a unique name within its scope. There are four levels you can specify a scope:
management group1, subscription, resource group2, and resource. Scopes are hierarchical, with each
level of hierarchy making the scope more specific.
For example, a virtual network has a resource group scope, which means that there can be only one
network named vnet-prod-westus-001 in each resource group. Other resource groups could have their
own virtual network named vnet-prod-westus-001. Subnets are scoped to virtual networks, so each
subnet within a virtual network must have a distinct name.
Understand Regions and Subscriptions

All Azure resources are created in an Azure region and subscription. A resource can only be created in a
virtual network that exists in the same region and subscription as the resource. You can, however, connect
virtual networks that exist in different subscriptions and regions. Azure regions are important to consider
as you design your Azure network in relation to your infrastructure, data, applications, and end users.
You can deploy as many virtual networks as you need within each subscription, up to the subscription
limit. Some larger organizations with global deployments have multiple virtual networks that are connect-
ed between regions, for example.
1 https://docs.microsoft.com/en-us/azure/governance/management-groups/overview
2 https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/overview
11
Azure Availability Zones

An Azure Availability Zone enables you to define unique physical locations within a region. Each zone is
made up of one or more datacenters equipped with independent power, cooling, and networking.
Designed to ensure high-availability of your Azure services, the physical separation of Availability Zones
within a region protects applications and data from datacenter failures.
You should consider availability zones when designing your Azure network, and plan for services that
support availability zones.
Azure services that support Availability Zones fall into three categories:
●● Zonal services: Resources can be pinned to a specific zone. For example, virtual machines, managed
disks, or standard IP addresses can be pinned to a specific zone, which allows for increased resilience
by having one or more instances of resources spread across zones.
12
●● Zone-redundant services: Resources are replicated or distributed across zones automatically. Azure
replicates the data across three zones so that a zone failure does not impact its availability.
●● Non-regional services: Services are always available from Azure geographies and are resilient to
zone-wide outages as well as region-wide outages.
Create a Virtual Network in Azure

You can create an Azure VNet directly through the Azure portal, by using PowerShell, or the Azure CLI.
Before you can create a VNet, you must create a resource group. A resource group is a container that
holds related resources for an Azure solution. The resource group can include all the resources for the
solution, or only those resources that you want to manage as a group.
Create a Virtual Network by using the portal

Log in to the Azure portal, and then click Create a resource:
In the search box, enter Virtual Network. Select Virtual Network in the search results.
13
On the Virtual Network page, select Create.
In Create virtual network, enter or select this information in the Basics tab:
Setting Value
Project details
Subscription Select your subscription.
14
Resource group Select an existing resource group or Create a new

resource group.
Instance details
Name Enter a descriptive name for your new VNet.
Region Select the region closest to you.
In the IP Addresses tab, you can add IPv4 and IPv6 address spaces, and define IPv4 subnets.
Address space
When you set up a virtual network, you define the internal address space in Classless Inter-Domain
Routing (CIDR) format. This address space needs to be unique within your subscription and any other
networks that you connect to.
Let's assume you choose an address space of 10.0.0.0/24 for your first virtual network. The addresses
defined in this address space ranges from 10.0.0.1 - 10.0.0.254. You then create a second virtual network
and choose an address space of 10.0.0.0/8. The address in this address space ranges from 10.0.0.1 -
10.255.255.254. Some of the address overlap and can't be used if you plan to connect the two virtual
networks together.
However, you can use 10.0.0.0/16, with addresses ranging from 10.0.0.1 - 10.0.255.254, and 10.1.0.0/16,
with addresses ranging from 10.1.0.1 - 10.1.255.254. You can assign these address spaces to your virtual
networks because there's no address overlap.
[!NOTE]
You can add address spaces after creating the virtual network.
Subnet
Within each virtual network address range, you can create one or more subnets that partition the virtual
network's address space. Routing between subnets will then depend on the default traffic routes, or you
can define custom routes. Alternatively, you can define one subnet that encompasses all the virtual
networks' address ranges.
[!NOTE]
Subnet names must begin with a letter or number, end with a letter, number or underscore, and may
contain only letters, numbers, underscores, periods, or hyphens.
15
In the Create virtual network tab, you can enable security features like BastionHost, DDoS Protection
Standard, and Firewall.
BastionHost
‎The Azure Bastion service is a new fully platform-managed PaaS service that you provision inside your
virtual network. It provides secure and seamless RDP/SSH connectivity to your virtual machines directly in
the Azure portal over SSL. When you connect via Azure Bastion, your virtual machines do not need a
public IP address.
Distributed Denial of Service (DDoS) protection
You can select to enable Standard DDoS protection. Standard DDoS Protection is a plan is a paid service
that offers enhanced DDoS mitigation capabilities via adaptive tuning, attack notification, and telemetry
to protect against the impacts of a DDoS attack for all protected resources within this virtual network.
Basic DDoS protection is integrated into the Azure platform by default and at no additional cost.
Firewall
Azure Firewall is a managed cloud-based network security service that protects your Azure Virtual
Network resources.
16
In the Review + create tab, you can define tags, which can help you to organize and manage your Azure
resources.
17
Click Create to create your virtual network.
3-Configure public IP services
Public networks like the Internet communicate by using public IP addresses. Private networks like your
Azure Virtual Network use private IP addresses, which are not routable on public networks. To support a
network that exists both in Azure and on-premises, you must configure IP addressing for both types of
networks.
Public IP addresses enable Internet resources to communicate with Azure resources and enable Azure
resources to communicate outbound with Internet and public-facing Azure services. A public IP address
in Azure is dedicated to a specific resource, until it's unassigned by a network engineer. A resource
without a public IP assigned can communicate outbound through network address translation services,
where Azure dynamically assigns an available IP address that isn't dedicated to the resource.
As an example, public resources like web servers must be accessible from the internet. You want to
ensure that you plan IP addresses that support these requirements.
18
In this unit, you will learn about requirements for IP addressing when integrating an Azure network with
on-premises networks, and you'll explore the constraints and limitations for public and private IP ad-
dresses in Azure. You also will look at the capabilities that are available in Azure to reassign IP addresses
in your network.
Use dynamic and static public IP addresses

In Azure Resource Manager, a public IP3 address is a resource that has its own properties. Some of the
resources you can associate a public IP address resource with:
●● Virtual machine network interfaces
●● Internet-facing load balancers
●● VPN gateways
●● Application gateways
●● Azure Firewall
Public IP addresses are created with an IPv4 or IPv6 address, which can be either static or dynamic.
A dynamic public IP address is an assigned address that can change over the lifespan of the Azure
resource. The dynamic IP address is allocated when you create or start a VM. The IP address is released
when you stop or delete the VM. In each Azure region, public IP addresses are assigned from a unique
pool of addresses. The default allocation method is dynamic.
A static public IP address is an assigned address that will not change over the lifespan of the Azure
resource. To ensure that the IP address for the resource remains the same, set the allocation method
explicitly to static. In this case, an IP address is assigned immediately. It is released only when you delete
the resource or change the IP allocation method to dynamic.
Choose the appropriate SKU for a public IP address

For public IP addresses, there are two types of SKUs to choose from: Basic and Standard. All public IP
addresses created before the introduction of SKUs are Basic SKU public IP addresses. With the introduc-
tion of SKUs, you have the option to specify which SKU you would like the public IP address to be.
Basic SKU
Basic SKU public IPs can be assigned by using static or dynamic allocation methods. Basic IPs have an
adjustable inbound originated flow idle timeout of 4-30 minutes, with a default of 4 minutes, and a fixed
outbound originated flow idle timeout of 4 minutes. Basic IPs are open by default, so the use of Network
security groups is recommended but optional for restricting inbound or outbound traffic.
Basic public IPs can be assigned to any Azure resource that can be assigned a public IP address, such as
network interfaces, VPN gateways, application gateways, and internet-facing load balancers. They do not
support availability zone scenarios. You must use a Standard SKU public IP for an availability zone
scenario.
3 https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-public-ip-address
19
Standard SKU
Standard SKU public IP addresses always use the static allocation method. They have an adjustable
inbound originated flow idle timeout of 4-30 minutes, with a default of 4 minutes, and a fixed outbound
originated flow idle timeout of 4 minutes.
Standard IPs are secure by default and closed to inbound traffic. You must explicitly allow inbound traffic
by using a network security group.
Standard IPs can be assigned to network interfaces, Standard public load balancers, application gateways,
or VPN gateways. Standard IPs are zone-redundant by default and optionally zonal (they can be created
zonal and guaranteed in a specific availability zone).
Create a public IP address prefix

You can't bring your own public IP addresses from on-premises networks into Azure. Instead, an IP
address is assigned from a pool of available addresses, based on the location of the resource. Public IP
addresses are allocated from a range that's unique to each region in each Azure cloud. Public IP address-
es can't be moved between regions; all IP addresses are region-specific. If your business needs to have
datacenters in different regions, you will have a different public IP address range for each region. You can
use technology like Azure Traffic Manager to balance traffic between region-specific instances.
To ensure a static range of public IP addresses, you can create a public IP address prefix. You can't specify
the addresses when you create the prefix, but after the prefix is created, the addresses will be fixed. The
IP addresses will be a contiguous range. The advantage of a public IP address prefix is that you can
specify firewall rules for these IP addresses with the knowledge that they will not change. You can assign
the addresses from a public IP address prefix to any resource in Azure that supports public IP addresses.
Check your knowledge

Choose the best response for each of the questions below. When you're done, select Check your
answers.
quiz title:
Multiple choice
Which of the following statements about Azure VNets is correct?
Outbound communication with the internet must be configured for each resource on the VNet.
{{Incorrect. All resources in a VNet can communicate outbound to the internet, by default.}}
Azure VNets enable communication between Azure resources. {{Correct. Virtual Networks can connect
Azure resources including VMs, the App Service Environment, Azure Kubernetes Service, and Azure
virtual machine scale sets. You can use service endpoints to connect to other Azure resource types,
such as Azure SQL databases and storage accounts.}}
Azure VNets cannot be configured to communicate with on-premises resources. {{Incorrect. You can
options: Point-to-site virtual private network (VPN), Site-to-site VPN, Azure ExpressRoute.}}
20
Multiple choice
Which of the following statements about subnets is NOT correct?
You can assign the same IP address range to multiple subnets within the same VNet. {{That is correct.
Each subnet must have a unique address range, specified in Classless Inter-Domain Routing (CIDR)
format.}}
You can create multiple subnets within one VNet. {{That is incorrect. You can create multiple virtual
networks per subscription and per region, and multiple subnets within each virtual network.}}
You can use Network Security Groups (NSGs) to control access to a subnet and the resources on it.
{{That is incorrect. You can associate zero or one NSG to each subnet to control access to the subnet
and the resources on it.}}
4-Exercise: Design and implement a virtual net-

work in Azure
[!NOTE] To complete this exercise, you will need a Microsoft Azure subscription. If you don't already have
one, you can sign up for a free trial at https://azure.com/free.
Exercise scenario
Now you're ready to deploy virtual networks in the Azure portal.
Consider the fictional organization Contoso Ltd, which is in the process of migrating infrastructure and
applications to Azure. In your role as network engineer, you must plan and implement three virtual
networks and subnets to support resources in those virtual networks.
The CoreServicesVnet virtual network is deployed in the US West region. This virtual network will have
the largest number of resources. It will have connectivity to on-premises networks through a VPN
connection. This network will have web services, databases, and other systems that are key to the opera-
tions of the business. Shared services, such as domain controllers and DNS also will be located here. A
large amount of growth is anticipated, so a large address space is necessary for this virtual network.
The ManufacturingVnet virtual network is deployed in the North Europe region, near the location of
your organization's manufacturing facilities. This virtual network will contain systems for the operations of
the manufacturing facilities. The organization is anticipating a large number of internal connected devices
for their systems to retrieve data from, such as temperature, and will need an IP address space that it can
expand into.
The ResearchVnet virtual network is deployed in the West India region, near the location of the organi-
zation's research and development team. The research and development team uses this virtual network.
The team has a small, stable set of resources that is not expected to grow. The team needs a small
number of IP addresses for a few virtual machines for their work.
21
You will create the following resources:
Virtual Network Region Virtual network Subnet Subnet

address space
CoreServicesVnet West US 10.20.0.0/16
GatewaySubnet 10.20.0.0/27
SharedServices- 10.20.10.0/24
Subnet
DatabaseSubnet 10.20.20.0/24
PublicWebService- 10.20.30.0/24
Subnet
ManufacturingVnet North Europe 10.30.0.0/16
ManufacturingSys- 10.30.10.0/24
temSubnet
SensorSubnet1 10.30.20.0/24
ResearchVnet West India 10.40.0.0/16
ResearchSystem- 10.40.0.0/24
Subnet
These virtual networks and subnets are structured in a way that accommodates existing resources yet
allows for projected growth. Let's create these virtual networks and subnets to lay the foundation for our
networking infrastructure.
In this exercise, you will:
●● Task 1: Create the Contoso resource group
22
●● Task 2: Create the CoreServicesVnet virtual network and subnets

●● Task 3: Create the ManufacturingVnet virtual network and subnets
●● Task 4: Create the ResearchVnet virtual network and subnets
●● Task 5: Verify the creation of VNets and Subnets
Task 1: Create the Contoso resource group

1. Go to Azure portal4.
2. On the home page, under Azure services, select Resource groups.
3. In Resource groups, select + Create.

4. Use the information in the following table to create the resource group.
Tab Option Value

Basics Resource group ContosoResourceGroup
Region (US) West US
Tags No changes required
Review + create Review your settings and select
Create
5. In Resource groups, verify that ContosoResourceGroup appears in the list.
Task 2: Create the CoreServicesVnet virtual network and

subnets
1. On the Azure portal home page, select Create a resource.
4 https://portal.azure.com/
23
2. In Search services and marketplace, enter virtual network.
3. In Marketplace, in Virtual Network, select Create > Virtual network.

24
4. Use the information in the following table to create the CoreServicesVnet virtual network.
‎Remove or overwrite the default IP Address space
Tab Option Value

Basics Resource Group ContosoResourceGroup
Name CoreServicesVnet
Region (US) West US
IP Addresses IPv4 address space 10.20.0.0/16
5. Use the information in the following table to create the CoreServicesVnet subnets.
6. To begin creating each subnet, select + Add subnet. To finish creating each subnet, select Add.
Subnet Option Value

GatewaySubnet Subnet name GatewaySubnet
Subnet address range 10.20.0.0/27
SharedServicesSubnet Subnet name SharedServicesSubnet
DatabaseSubnet Subnet name DatabaseSubnet
PublicWebServiceSubnet Subnet name PublicWebServiceSubnet
7. To finish creating the CoreServicesVnet and its associated subnets, select Review + create.
8. Verify your configuration passed validation, and then select Create.
9. Repeat steps 1 -8 for each VNet based on the tables below
Task 3: Create the ManufacturingVnet virtual network and

subnets
Tab Option Value
Name ManufacturingVnet
Region (Europe) North Europe
Subnet Option Value

ManufacturingSystemSubnet Subnet name ManufacturingSystemSubnet
25
SensorSubnet1 Subnet name SensorSubnet1

Task 4: Create the ResearchVnet virtual network and sub-

nets
Tab Option Value
Name ResearchVnet
Region West India
Subnet Option Value

ResearchSystemSubnet Subnet name ResearchSystemSubnet
Task 5: Verify the creation of VNets and Subnets

1. On the Azure portal home page, select All resources.
2. Verify that the CoreServicesVnet, ManufacturingVnet, and ResearchVnet are listed. Your list should
look like this:
26
3. Note that Azure creates NetworkWatchers for each region that you use.
4. Select CoreServicesVnet.
5. In CoreServicesVnet, under Settings, select Subnets.
6. In CoreServicesVnet | Subnets, verify that the subnets you created are listed, and that the IP address
ranges are correct.
7. Repeat steps 4 - 6 for each VNet.

Congratulations! You have successfully created a resource group, three VNets, and their associated
subnets.
27
5-Design name resolution for your virtual net-

work
Depending on how you use Azure to host IaaS, PaaS, and hybrid solutions, you might need to allow the
virtual machines (VMs), and other resources deployed in a virtual network to communicate with each
other. Although you can enable communication by using IP addresses, it is much simpler to use names
that can be easily remembered, and do not change.
DNS is split into two areas: Public, and Private DNS for resources accessible from your own internal
networks.
Public DNS services

Public DNS services resolve names and IP addresses for resources and services accessible over the
internet such as web servers. Azure DNS is a hosting service for DNS domain that provides name resolu-
tion by using Microsoft Azure infrastructure. DNS domains in Azure DNS are hosted on Azure's global
network of DNS name servers. Azure DNS uses anycast networking. Each DNS query is answered by the
closest available DNS server to provide fast performance and high availability for your domain.
In Azure DNS, you can create address records manually within relevant zones. The records most frequent-
ly used will be:
●● Host records: A/AAAA (IPv4/IPv6)
●● Alias records: CNAME
Azure DNS provides a reliable, secure DNS service to manage and resolve domain names in a virtual
network without needing to add a custom DNS solution.
A DNS zone hosts the DNS records for a domain. So, to start hosting your domain in Azure DNS, you
need to create a DNS zone for that domain name. Each DNS record for your domain is then created
inside this DNS zone.
Considerations
●● The name of the zone must be unique within the resource group, and the zone must not exist already.
●● The same zone name can be reused in a different resource group or a different Azure subscription.
●● Where multiple zones share the same name, each instance is assigned different name server address-
es.
●● Root/Parent domain is registered at the registrar and pointed to Azure NS.
●● Child domains are registered in AzureDNS directly.
[!NOTE]
You do not have to own a domain name to create a DNS zone with that domain name in Azure DNS.
However, you do need to own the domain to configure the domain.
28
Delegate DNS Domains

To delegate your domain to Azure DNS, you first need to know the name server names for your zone.
Each time a DNS zone is created Azure DNS allocates name servers from a pool. Once the Name Servers
are assigned, Azure DNS automatically creates authoritative NS records in your zone.
Once the DNS zone is created, and you have the name servers, you need to update the parent domain.
Each registrar has their own DNS management tools to change the name server records for a domain. In
the registrar’s DNS management page, edit the NS records and replace the NS records with the ones
Azure DNS created.
[!NOTE]
When delegating a domain to Azure DNS, you must use the name server names provided by Azure DNS.
You should always use all four name server names, regardless of the name of your domain.
Child Domains
If you want to set up a separate child zone, you can delegate a subdomain in Azure DNS. For example,
after configuring contoso.com in Azure DNS, you could configure a separate child zone for partners.
contoso.com.
Setting up a subdomain follows the same process as typical delegation. The only difference is that NS
records must be created in the parent zone contoso.com in Azure DNS, rather than in the domain
registrar.
[!NOTE]
The parent and child zones can be in the same or different resource group. Notice that the record set
name in the parent zone matches the child zone name, in this case partners.
It's important to understand the difference between DNS record sets and individual DNS records. A
record set is a collection of records in a zone that have the same name and are the same type.
A record set cannot contain two identical records. Empty record sets (with zero records) can be created,
but do not appear on the Azure DNS name servers. Record sets of type CNAME can contain one record at
most.
29
The Add record set page will change depending on the type of record you select. For an A record, you
will need the TTL (Time to Live) and IP address. The time to live, or TTL, specifies how long each record is
cached by clients before being requeried.
Private DNS services

Private DNS services resolve names and IP addresses for resources and services
When resources deployed in virtual networks need to resolve domain names to internal IP addresses,
they can use one the three methods:
●● Azure DNS Private Zones
●● Azure-provided name resolution
●● Name resolution that uses your own DNS server
The type of name resolution you use depends on how your resources need to communicate with each
other.
Your name resolution needs might go beyond the features provided by Azure. For example, you might
need to use Microsoft Windows Server Active Directory domains, resolve DNS names between virtual net-
works. To cover these scenarios, Azure provides the ability for you to use your own DNS servers.
DNS servers within a virtual network can forward DNS queries to the recursive resolvers in Azure. This
enables you to resolve host names within that virtual network. For example, a domain controller (DC)
running in Azure can respond to DNS queries for its domains and forward all other queries to Azure.
Forwarding queries allows VMs to see both your on-premises resources (via the DC) and Azure-provided
30
host names (via the forwarder). Access to the recursive resolvers in Azure is provided via the virtual IP
168.63.129.16.
DNS forwarding also enables DNS resolution between virtual networks and allows your on-premises
machines to resolve Azure-provided host names. In order to resolve a VM's host name, the DNS server
VM must reside in the same virtual network and be configured to forward host name queries to Azure.
Because the DNS suffix is different in each virtual network, you can use conditional forwarding rules to
send DNS queries to the correct virtual network for resolution. The following image shows two virtual
networks and an on-premises network doing DNS resolution between virtual networks, by using this
method.
Azure provided DNS

Azure provides its own default internal DNS. It provides an internal DNS zone that always exists, supports
automatic registration, requires no manual record creation, and is created when the VNet is created. And
it's a free service. Azure provided name resolution provides only basic authoritative DNS capabilities. If
you use this option, the DNS zone names and records will be automatically managed by Azure, and you
will not be able to control the DNS zone names or the life cycle of DNS records.
Internal DNS defines a namespace as follows: .internal.cloudapp.net.
Any VM created in the VNet is registered in the internal DNS zone and gets a DNS domain name like
myVM.internal.cloudapp.net. It's important to recognize that it's the Azure Resource name that is regis-
tered, not the name of the guest OS on the VM.
Limitations of Internal DNS
●● Can't resolve across different VNets.
●● Registers resource names, not guest OS names.
●● Does not allow manual record creation.
31
Azure Private DNS Zones

Private DNS zones in Azure are available to internal resources only. They are global in scope, so you can
access them from any region, any subscription, any VNet, and any tenant. If you have permission to read
the zone, you can use it for name resolution. Private DNS zones are highly resilient, being replicated to
regions all throughout the world. They are not available to resources on the internet.
For scenarios which require more flexibility than Internal DNS allows, you can create your own private
DNS zones. These zones enable you to:
●● Configure a specific DNS name for a zone.
●● Create records manually when necessary.
●● Resolve names and IP addresses across different zones.
●● Resolve names and IP addresses across different VNets.
Create a private DNS zone by using the portal
You can create a private DNS zone using the Azure portal, Azure PowerShell, or Azure CLI.
When the new DNS zone is deployed, you can manually create resource records, or use auto-registration,
which will create resource records based on the Azure resource name.
Private DNS zones support the full range of records including pointers, MX, SOA, service, and text
records.
Link VNets to private DNS zones

In Azure, a VNet represents a group of 1 or more subnets, as defined by a CIDR range. Resources such as
VMs are added to subnets.
At the VNet level, default DNS configuration is part of the DHCP assignments made by Azure, specifying
the special address 168.63.129.16 to use Azure DNS services.
If necessary, you can override the default configuration by configuring an alternate DNS server at the VM
NIC.
32
Two ways to link VNets to a private zone:

●● Registration: Each VNet can link to one private DNS zone for registration. However, up to 100 VNets
can link to the same private DNS zone for registration.
●● Resolution: There may be many other private DNS zones for different namespaces. You can link a
VNet to each of those zones for name resolution. Each VNet can link to up to 1000 private DNS Zones
for name resolution.
33
Integrating on-premises DNS with Azure VNets

If you have an external DNS server, for example an on-premises server, you can use custom DNS configu-
ration on your VNet to integrate the two.
Your external DNS can run on any DNS server: BIND on UNIX, Active Directory Domain Services DNS, and
so on. If you want to use and external DNS server and not the default Azure DNS service, you must
configure the desired DNS servers.
Organizations often use an internal Azure private DNS zone for auto registration, and then use a custom
configuration to forward queries external zones from an external DNS server.
Forwarding takes two forms:
●● Forwarding - specifies another DNS server (SOA for a zone) to resolve the query if the initial server
cannot.
●● Conditional forwarding - specifies a DNS server for a named zone, so that all queries for that zone are
routed to the specified DNS server.
[!NOTE] If the DNS server is outside Azure, it doesn't have access to Azure DNS on 168.63.129.16. In this
scenario, setup a DNS resolver inside your VNet, forward queries for to it, and then have it forward
queries to 168.63.129.16 (Azure DNS). Essentially, you're using forwarding because 168.63.129.16 is not
routable, and therefore not accessible to external clients.
34

answers.
quiz title:
Multiple choice
What is the difference between a static public IP address and a dynamic public IP address?
A dynamic IP address remains the same over the lifespan of the resource to which it is assigned.{{That
is incorrect. A dynamic public IP address is an assigned address that can change over the lifespan of
the Azure resource. The dynamic IP address is allocated when you create or start a VM.}}
A static IP address can use an IPv4 address only.{{That is incorrect. Static IP addresses are created with
either an IPv4 or an IPv6 address.}}
A static IP address remains the same over the lifespan of the resource to which it is assigned. {{That is
correct. A static public IP address is an assigned address that will not change over the lifespan of the
Azure resource. To configure a static IP address, set the allocation method explicitly to static.}}
Multiple choice
Application owners need to use dynamic IP addresses for specific resources on their VNet. Which SKU must
they choose?
Basic SKU {{That is correct. Basic SKU public IPs can be assigned by using static or dynamic allocation
methods.}}
Standard SKU{{That is incorrect. Standard SKU public IP addresses always use the static allocation
method.}}
Either Basic or Standard SKU{{That is incorrect. Standard SKU public IP addresses always use the static
allocation method. Basic SKU public IPs can be assigned by using static or dynamic allocation meth-
ods.}}
6-Exercise: Configure domain name servers set-

tings in Azure
35
Exercise scenario
In this unit, you will configure DNS name resolution for Contoso Ltd. You will create a private DNS zone
named contoso.com, link the VNets for registration and resolution, and then create two virtual machines
and test the configuration.
●● Task 1: Create a private DNS Zone
●● Task 2: Link subnet for auto registration
●● Task 3: Create Virtual Machines to test the configuration
●● Task 4: Verify records are present in the DNS zone
Task 1: Create a private DNS Zone

1. Go to Azure portal5.
2. On the Azure home page, in the search bar, type dns, and then select Private DNS zones.
3. In Private DNS zones, select + Create.
4. Use the information in the following table to create the private DNS zone.
Tab Option Value

Name Contoso.com
36

Create
5. Wait until the deployment is complete, and then select Go to resource.
6. Verify that the zone has been created.
Task 2: Link subnet for auto registration

1. In Contoso.com, under Settings, select Virtual network links.
2. On Contoso.com | Virtual network links, select + Add.
3. Use the information in the following table to add the virtual network link.
Option Value
Link name CoreServicesVnetLink
Subscription No changes required
Virtual Network CoreServicesVnet (ContosoResourceGroup)
Enable auto registration Selected
Review your settings and select OK.
4. Select Refresh.
5. Verify that the CoreServicesVnetLink has been created, and that auto-registration is enabled.
6. Repeat steps 2 - 5 for the ManufacturingVnet, using the information in the following table:
37
Option Value
Link name ManufacturingVnetLink
Virtual Network ManufacturingVnet (ContosoResourceGroup)
7. Select Refresh.
8. Verify that the ManufacturingVnetLink has been created, and that auto-registration is enabled.
9. Repeat steps 2 - 5 for the ResearchVnet, using the information in the following table:
Option Value
Link name ResearchVnetLink
Virtual Network ResearchVnet (ContosoResourceGroup)
10. Select Refresh.
11. Verify that the ResearchVnetLink has been created, and that auto-registration is enabled.
Task 3: Create Virtual Machines to test the configuration

In this section, you will create two test VMs to test the Private DNS zone configuration.
Create TestVM1
1. On the Azure home page, select Virtual Machines.
2. In Virtual Machines, select + Add > + Start with a preset configuration.
38
3. In Choose recommended defaults that match your workload, under Select a workload environment,
select Dev/Test.
4. Under Select a workload type, select General purpose (D-Series), and then select Continue to
create a VM.
5. Use the information in the following table to create your first VM.
Tab Option Value

Virtual machine name TestVM1
Region (US) West US
Availability options No infrastructure redundancy
required
Image Windows 10 Pro, Version 20H2
- Gen 1
Azure Spot instance Not selected
Size Standard_D2_v3 - 2vcpus, 8GiB
memory
Username TestUser
Password TestPa$$w0rd!
Public inbound ports Allow selected ports
Select inbound ports RDP (3389)
I confirm I have an eligible Selected
Windows 10 license with mul-
ti-tenant hosting rights.
Disks No changes required
Networking Virtual network CoreServicesVnet
Subnet DatabaseSubnet (10.20.20.0/24)
39
Public IP (new) TestVM1-ip

NIC network security group Basic
Load balancing Not selected
Management No changes required
Advanced No changes required
Create
6. While the deployment is in progress, you can proceed with creating TestVM2.
Create TestVM2
select Dev/Test.
create a VM.
5. Use the information in the following table to create your second VM.
Tab Option Value

Virtual machine name TestVM2
Region (US) West US
40

required
- Gen 1
memory
Username TestUser
Public IP (new) TestVM2-ip
Create
6. When the deployment is complete, go to the Azure portal home page, and then select Virtual
Machines.
7. Verify that both virtual machines have been created.
Task 4: Verify records are present in the DNS zone

1. On the Azure portal home page, select Private DNS zones.
2. In Private DNS zones, select contoso.com.
3. Verify that host (A) records are listed for both VMs, as shown:
41
4. Make a note of the names and IP addresses of the VMs.
Connect to the Test VMs using RDP

1. On the Azure portal home page, select Virtual Machines.
2. Select TestVM1.
3. In TestVM1, select Connect > RDP.
4. In TestVM1 | Connect, select Download RDP file.

5. Save the RDP file to your desktop.
7. Select TestVM2.
42

11. Connect to TestVM1 using the RDP file, and the username and password you specified when you
created the VM.
created the VM.
13. On both VMs, in Choose privacy settings for your device, select Accept.
14. On both VMs, in Networks, select Yes.
15. On TestVM1, open a command prompt and enter the command ipconfig /all.
16. Verify that the IP address is the same as the one you noted in the DNS zone.
17. Enter the command ping TestVM2.contoso.com.
18. Verify that you receive four replies from TestVM2.
Congratulations! You have created a private DNS Zone, added a name resolution and auto-registration
link, and tested name resolution in your configuration.
7-Enable cross-virtual network connectivity with

peering
Organizations with large scale operations will often need to create connections between different parts of
their virtual network infrastructure. Virtual network peering enables you to seamlessly connect separate
VNets with optimal network performance, whether they are in the same Azure region (VNet peering) or in
different regions (Global VNet peering). Network traffic between peered virtual networks is private. The
virtual networks appear as one for connectivity purposes. The traffic between virtual machines in peered
virtual networks uses the Microsoft backbone infrastructure, and no public Internet, gateways, or encryp-
tion is required in the communication between the virtual networks.
Virtual network peering enables you to seamlessly connect two Azure virtual networks. Once peered, the
virtual networks appear as one, for connectivity purposes. There are two types of VNet peering.
●● Regional VNet peering connects Azure virtual networks in the same region.
●● Global VNet peering connects Azure virtual networks in different regions. When creating a global
peering, the peered virtual networks can exist in any Azure public cloud region or China cloud regions,
but not in Government cloud regions. You can only peer virtual networks in the same region in Azure
Government cloud regions.
43
The benefits of using virtual network peering, whether local or global, include:
●● A low-latency, high-bandwidth connection between resources in different virtual networks.
●● The ability to apply network security groups in either virtual network to block access to other virtual
networks or subnets.
●● The ability to transfer data between virtual networks across Azure subscriptions, Azure Active Directo-
ry tenants, deployment models, and Azure regions.
●● The ability to peer virtual networks created through the Azure Resource Manager.
●● The ability to peer a virtual network created through Resource Manager to one created through the
classic deployment model.
●● No downtime to resources in either virtual network is required when creating the peering, or after the
peering is created.
The following diagram shows a scenario where resources on the Contoso VNet and resources on the
Fabrikam VNet need to communicate. The Contoso subscription in the US West region, is connected to
the Fabrikam subscription in the US West region.
44
The routing tables show the routes known to the resources in each subscription. The following routing
table shows the routes known to Contoso, with the final entry being the Global VNet peering entry to the
Fabrikam 10.10.26.0/24 subnet.

The following routing table shows the routes known to Fabrikam. Again, the final entry is the Global VNet
peering entry, this time to the Contoso 10.1.26.0/25 subnet.
Configure VNet Peering

Here are the steps to configure VNet peering. Notice you will need two virtual networks. To test the
peering, you will need a virtual machine in each network. Initially, the VMs will not be able to communi-
cate, but after configuration the communication will work. The step that is new is configuring the peering
of the virtual networks.
1. Create two virtual networks.
2. Peer the virtual networks.
3. Create virtual machines in each virtual network.
4. Test the communication between the virtual machines.
45
To configure the peering use the Add peering page. There are only a few optional configuration parame-
ters to consider.
[!NOTE]
When you add a peering on one virtual network, the second virtual network configuration is automatical-
ly added.
Gateway Transit and Connectivity

When virtual networks are peered, you configure a VPN gateway in the peered virtual network as a transit
point. In this case, a peered virtual network uses the remote gateway to gain access to other resources. A
virtual network can have only one gateway. Gateway transit is supported for both VNet Peering and Glob-
al VNet Peering.
When you Allow Gateway Transit the virtual network can communicate to resources outside the peering.
For example, the subnet gateway could:
●● Use a site-to-site VPN to connect to an on-premises network.
●● Use a VNet-to-VNet connection to another virtual network.
●● Use a point-to-site VPN to connect to a client.
In these scenarios, gateway transit allows peered virtual networks to share the gateway and get access to
resources. This means you do not need to deploy a VPN gateway in the peer virtual network.
[!NOTE]
Network security groups can be applied in either virtual network to block access to other virtual networks
or subnets. When configuring virtual network peering, you can either open or close the network security
group rules between the virtual networks.
Use service chaining to direct traffic to a gateway

Suppose you want to direct traffic from the Contoso VNet to a specific network virtual appliance (NVA).
Create user-defined routes to direct traffic from the Contoso VNet to the NVA in the Fabrikam VNet. This
technique is known as service chaining.
46
To enable service chaining, add user-defined routes pointing to virtual machines in the peered virtual
network as the next hop IP address. User-defined routes can also point to virtual network gateways.
Azure virtual networks can be deployed in a hub-and-spoke topology, with the hub VNet acting as a
central point of connectivity to all the spoke VNets. The hub virtual network hosts infrastructure compo-
nents such as an NVA, virtual machines and a VPN gateway. All the spoke virtual networks peer with the
hub virtual network. Traffic flows through network virtual appliances or VPN gateways in the hub virtual
network. The benefits of using a hub and spoke configuration include cost savings, overcoming subscrip-
tion limits, and workload isolation.
The following diagram shows a scenario in which hub VNet hosts a VPN gateway that manages traffic to
the on-premises network, enabling controlled communication between the on-premises network and the
peered Azure VNets.

answers.
47
quiz title:
Multiple choice
When one needs the resources in one VNet to communicate with resources in a subnet in a different VNet.
Which Azure network feature should be used?
Internal DNS. {{That is incorrect, internal DNS is a service provided by Azure.}}
Azure Availability Zones. {{That is incorrect, Azure Availability Zones are a high availability feature.
Each zone is made up of one or more datacenters equipped with independent power, cooling, and
networking.}}
VNet peering. {{That is correct, virtual network peering enables you to seamlessly connect separate
VNets with optimal network performance, whether they are in the same Azure region (VNet peering)
or in different regions (Global VNet peering).}}
Multiple choice
When configure global peering, what changes will see in the peered VNets?
A peering entry is added to the routing table in the source VNet only. {{That is incorrect, the VNets
communicate as peers, so resources in each VNet must be able to communicate with each other.
Adding a single peering entry only allows traffic to be routed one way.}}
All traffic on the Vnet must be routed through a Gateway. {{That is incorrect, resources on each VNet
can communicate seamlessly with one another.}}
A peering entry is added to the routing table in each VNet. {{That is correct, VNet Global Peering
entries are added to the routing tables in each VNet to direct traffic to the peered VNet.}}
8-Exercise: Connect two Azure virtual networks

using global virtual network peering
Exercise scenario
In this unit, you will configure connectivity between the CoreServicesVnet and the ManufacturingVnet by
adding peerings to allow traffic flow.
In this unit, you will:
●● Task 1: Create a Virtual Machine to test the configuration
●● Task 2: Connect to the Test VMs using RDP
●● Task 3: Test the connection between the VMs
●● Task 4: Create VNet peerings between CoreServicesVnet and ManufacturingVnet
●● Task 6: Clean up resources
48
Task 1: Create a Virtual Machine to test the configuration

In this section, you will create a test VM on the Manufacturing VNet to test if you can access resources
inside another Azure virtual network from your ManufacturingVnet.
Create ManufacturingVM

select Dev/Test.
create a VM.
5. Use the information in the following table to create your VM.
Tab Option Value

Virtual machine name ManufacturingVM
required
- Gen 1
memory
Username TestUser
49

Networking Virtual network ManufacturingVnet
Subnet ManufacturingSystemSubnet
(10.30.10.0/24)
Public IP (new) ManufacturingVM-ip
Create
6. When the deployment is complete, select Go to resource.
Task 2: Connect to the Test VMs using RDP

2. Select ManufacturingVM.
3. In ManufacturingVM, select Connect > RDP.
4. In ManufacturingVM | Connect, select Download RDP file.
6. Connect to ManufacturingVM using the RDP file, and the username and password you specified when
you created the VM.
8. Select TestVM1.
created the VM.
15. On TestVM1, open a PowerShell prompt, and run the following command: ipconfig
16. Note the IPv4 address.
50
Task 3: Test the connection between the VMs

1. On the ManufacturingVM, open a PowerShell prompt.
2. Use the following command to verify that there is no connection to TestVM1 on CoreServicesVnet. Be
sure to use the IPv4 address for TestVM1.
PowerShell
Test-NetConnection 10.20.20.4 -port 3389
3. The test connection should fail, and you will see a result similar to the following:
Task 4: Create VNet peerings between CoreServicesVnet

and ManufacturingVnet
1. On the Azure home page, select Virtual Networks, and then select CoreServicesVnet.
51
2. In CoreServicesVnet, under Settings, select Peerings.

3. On CoreServicesVnet | Peerings, select + Add.
4. Use the information in the following table to create the peering.
Section Option Value

This virtual network
Peering link name CoreServicesVnet-to-Manufac-
turingVnet
Traffic to remote virtual network Allow (default)
Traffic forwarded from remote Allow (default)
virtual network
Virtual network gateway or None (default)
Route Server
Remote virtual network
52
Peering link name ManufacturingVnet-to-CoreSer-

vicesVnet
Virtual network deployment Resource Manager
model
I know my resource ID Not selected
Subscription MOC Subscription-lodxxxxxxxx
Virtual network ManufacturingVnet
Traffic to remote virtual network Allow (default)
Traffic forwarded from remote Allow (default)
virtual network
Virtual network gateway or None (default)
Route Server
Review your settings and select
Add.
5. In CoreServicesVnet | Peerings, verify that the CoreServicesVnet-to-ManufacturingVnet peering is

listed.
6. Under Virtual networks, select ManufacturingVnet, and verify the ManufacturingVnet-to-CoreSer-
vicesVnet peering is listed.

1. On the ManufacturingVM, open a PowerShell prompt.
2. Use the following command to verify that there is now a connection to TestVM1 on CoreServicesVnet.
PowerShell
3. The test connection should succeed, and you will see a result similar to the following:
Congratulations! You have successful configured connectivity between VNets by adding peerings.
Task 6: Clean up resources

[!NOTE] Remember to remove any newly created Azure resources that you no longer use. Removing
unused resources ensures you will not see unexpected charges.
1. In the Azure portal, open the PowerShell session within the Cloud Shell pane.
2. Delete all resource groups you created throughout the labs of this module by running the following
command:
53
Remove-AzResourceGroup -Name 'NAME OF THE RG' -Force -AsJob
[!NOTE] The command executes asynchronously (as determined by the -AsJob parameter), so while you
will be able to run another PowerShell command immediately afterwards within the same PowerShell
session, it will take a few minutes before the resource groups are actually removed.
9-Implement virtual network traffic routing

Azure automatically creates a route table for each subnet within an Azure virtual network and adds
system default routes to the table. You can override some of Azure's system routes with custom routes6,
and add additional custom routes to route tables. Azure routes outbound traffic from a subnet based on
the routes in a subnet's route table.
System routes
Azure automatically creates system routes and assigns the routes to each subnet in a virtual network. You
can't create system or remove routes, but you can override some system routes with custom routes.
Azure creates default system routes for each subnet, and adds additional optional default routes to
specific subnets, or every subnet, when you use specific Azure capabilities.
Default routes
Each route contains an address prefix and next hop type. When traffic leaving a subnet is sent to an IP
address within the address prefix of a route, the route that contains the prefix is the route Azure uses.
Whenever a virtual network is created, Azure automatically creates the following default system routes for
each subnet within the virtual network:
Source Address prefixes Next hop type

Default Unique to the virtual network Virtual network
Default 0.0.0.0/0 Internet
Default 10.0.0.0/8 None
In routing terms, a hop is a waypoint on the overall route. Therefore, the next hop is the next waypoint
that the traffic is directed to on its journey to its ultimate destination. The next hop types listed in the
previous table represent how Azure routes traffic destined for the address prefix listed. The next hop
types are defined as follows:
●● Virtual network: Routes traffic between address ranges within the address space of a virtual network.
Azure creates a route with an address prefix that corresponds to each address range defined within
the address space of a virtual network. Azure automatically routes traffic between subnets using the
routes created for each address range.
●● Internet: Routes traffic specified by the address prefix to the Internet. The system default route
specifies the 0.0.0.0/0 address prefix. Azure routes traffic for any address not specified by an address
range within a virtual network to the Internet, unless the destination address is for an Azure service.
Azure routes any traffic destined for its service directly to the service over the backbone network,
6 https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview
54
rather than routing the traffic to the Internet. You can override Azure's default system route for the
0.0.0.0/0 address prefix with a custom route.
●● None: Traffic routed to the None next hop type is dropped, rather than routed outside the subnet.
Azure automatically creates default routes for the following address prefixes:
●● 10.0.0.0/8 and 192.168.0.0/16: Reserved for private use in RFC 1918.
●● 100.64.0.0/10: Reserved in RFC 6598.
If you assign any of the previous address ranges within the address space of a virtual network, Azure
automatically changes the next hop type for the route from None to Virtual network. If you assign an
address range to the address space of a virtual network that includes, but isn't the same as, one of the
four reserved address prefixes, Azure removes the route for the prefix and adds a route for the address
prefix you added, with Virtual network as the next hop type.
Optional default routes

Azure adds default system routes for any Azure capabilities that you enable. Depending on the capability,
Azure adds optional default routes to either specific subnets within the virtual network, or to all subnets
within a virtual network. The additional system routes and next hop types that Azure may add when you
enable different capabilities are:
Source Address prefixes Next hop type Subnet within virtual

network that route is
added to
Default Unique to the virtual VNet peering All
network, for example:
10.1.0.0/16
Virtual network gateway Prefixes advertised from Virtual network gateway All
on-premises via BGP, or
configured in the local
network gateway
Default Multiple VirtualNetworkServi- Only the subnet a
ceEndpoint service endpoint is
enabled for
●● Virtual network (VNet) peering: When you create a virtual network peering between two virtual
networks, a route is added for each address range within the address space of each virtual network.
●● Virtual network gateway: When you add a virtual network gateway to a virtual network, Azure adds
one or more routes with Virtual network gateway as the next hop type. The source is listed as virtual
network gateway because the gateway adds the routes to the subnet.
●● If your on-premises network gateway exchanges border gateway protocol (BGP7) routes with an
Azure virtual network gateway, a route is added for each route propagated from the on-premises
network gateway. There are limits to the number of routes you can propagate to an Azure virtual
network gateway, so you should summarize on-premises routes to the largest address ranges
possible. For more information on the number of routes you can propagate, see Networking
limits8.
7 https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview
8 https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits?toc=/azure/virtual-
network/toc.json
55
VirtualNetworkServiceEndpoint: Azure adds the public IP addresses for certain services to the route
table when you enable a service endpoint to the service. Service endpoints are enabled for individual
subnets within a virtual network, so the route is only added to the route table of a subnet a service
endpoint is enabled for. The public IP addresses of Azure services change periodically, and Azure manag-
es the updates to the routing tables when necessary.
The VNet peering and VirtualNetworkServiceEndpoint next hop types are only added to route tables
of subnets within virtual networks created through the Azure Resource Manager deployment model. The
next hop types are not added to route tables that are associated to virtual network subnets created
through the classic deployment model.
Custom routes
To control the way network traffic is routed more precisely, you can override the default routes that Azure
creates by using your own user-defined routes (UDR). This technique can be useful when you want to
ensure that traffic between two subnets passes through a firewall appliance, or if you want to ensure that
no traffic from a VNet could be routed to the internet.
User-defined routes
You can create custom, or user-defined(static), routes in Azure to override Azure's default system routes,
or to add additional routes to a subnet's route table.
In Azure, each subnet can have zero or one associated route table. When you create a route table and
associate it to a subnet, the routes within it are combined with, or override, the default routes Azure adds
to a subnet.
You can specify the following next hop types when creating a user-defined route:
Virtual appliance: A virtual appliance is a virtual machine that typically runs a network application, such
as a firewall. When you create a route with the virtual appliance hop type, you also specify a next hop IP
address. The IP address can be:
●● The private IP address of a network interface attached to a virtual machine.
●● The private IP address of an Azure internal load balancer.
Virtual network gateway: Specify when you want traffic destined for specific address prefixes routed to
a virtual network gateway. The virtual network gateway must be created with type VPN.
None: Specify when you want to drop traffic to an address prefix, rather than forwarding the traffic to a
destination.
Virtual network: Specify when you want to override the default routing within a virtual network.
Internet: Specify when you want to explicitly route traffic destined to an address prefix to the Internet, or
if you want traffic destined for Azure services with public IP addresses kept within the Azure backbone
network.
Configure User-defined routes

Here is an example where you have a virtual network that includes three subnets.
●● The subnets are Private, DMZ, and Public. In the DMZ subnet, there is a network virtual appliance
(NVA). NVAs are VMs that help with network functions like routing and firewall optimization.
●● You want to ensure all traffic from the Public subnet goes through the NVA to the Private subnet.
56
Create a Routing Table

Creating a routing table is straightforward. You provide Name, Subscription, Resource Group, and
Location. You also decide to use Virtual network gateway route propagation.
Routes are automatically added to the route table for all subnets with Virtual network gateway propaga-
tion enabled. When you are using ExpressRoute, propagation ensures all subnets get the routing infor-
mation.
Create a Custom Route

For our example,
●● The new route is named ToPrivateSubnet.
●● The Private subnet is at 10.0.1.0/24.
●● The route uses a virtual appliance. Notice the other choices for Next hop type: virtual network gate-
way, virtual network, internet, and none.
57
●● The virtual appliance is located at 10.0.2.4.
In summary, this route applies to any address prefixes in 10.0.1.0/24 (private subnet). Traffic headed to
these addresses will be sent to the virtual appliance with a 10.0.2.4 address.
Associate the Route Table

The last step in our example is to associate the Public subnet with the new routing table. Each subnet can
have zero or one route table associated to it.
[!NOTE] By default, using system routes traffic would go directly to the private subnet. However, with a
user-defined route you can force the traffic through the virtual appliance.
[!NOTE] In this example, the virtual appliance shouldn't have a public IP address and IP forwarding should
be enabled.
58
Diagnose a routing problem

Imagine your attempts to connect to a specific virtual machine (VM) in your Azure virtual network fail
persistently. You can diagnose a routing problem by viewing the routes that are effective for a network
interface in a VM. The effective routes for all network interfaces in a subnet are the combination of routes
you create, Azure's default routes, and any routes propagated from your on-premises network through
an Azure VPN gateway via the border gateway protocol (BGP).
You can view the effective routes for each network interface by using the Azure portal, Azure PowerShell,
or Azure CLI. The following steps show examples of each technique. In each case, output is only returned
if the VM is in the running state. If there are multiple network interfaces attached to the VM, you can
review the effective routes for each network interface. Since each network interface can be in a different
subnet, each network interface can have different effective routes.
View effective routes in Azure portal

1. Log into the Azure portal with an Azure account that has the necessary permissions9.
2. In the search box, enter the name of the VM that you want to investigate.
3. Select the VM from the search results.
4. Under Settings, select Networking, and navigate to the network interface resource by selecting its
name.
9 https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface
59
5. Under Support + troubleshooting, select Effective routes. The effective routes for a network
interface named myVMNic1 are shown, in the following image:
View effective routes by using Azure PowerShell

You can view the effective routes for a network interface with the Get-AzEffectiveRouteTable command.
The following example gets the effective routes for a network interface named myVMNic1, that is in a
resource group named myResourceGroup:
Get-AzEffectiveRouteTable `
-NetworkInterfaceName myVMNic1 `
-ResourceGroupName myResourceGroup `
Resolve the routing issue

Steps you might take to resolve the routing problem might include:
1. Add a custom route to override a default route. Learn how to add a custom route10.
2. Change or remove a custom route that causes traffic to be routed to an undesired location. Learn how
to change11 or delete12 a custom route.
3. Ensure that the route table is associated to the correct subnet (the one that contains the network
interface). Learn how to associate a route table to a subnet13.
4. Ensure that devices such as Azure VPN gateway or network virtual appliances you've deployed are
operating as intended.
10 https://docs.microsoft.com/en-us/azure/virtual-network/manage-route-table
60
Secure a VNet by using forced tunneling

Forced tunneling lets you redirect or “force” all Internet-bound traffic back to your on-premises location
via a Site-to-Site VPN tunnel for inspection and auditing. This is a critical security requirement for most
enterprise IT policies. If you don't configure forced tunneling, Internet-bound traffic from your VMs in
Azure always traverses from the Azure network infrastructure directly out to the Internet, without the
option to allow you to inspect or audit the traffic. Unauthorized Internet access can potentially lead to
information disclosure or other types of security breaches. Forced tunneling can be configured by using
Azure PowerShell. It can't be configured using the Azure portal.
In the following example, the Frontend subnet is not force tunneled. The workloads in the Frontend
subnet can continue to accept and respond to customer requests from the Internet directly. The Mid-tier
and Backend subnets are forced tunneled. Any outbound connections from these two subnets to the
Internet will be forced or redirected back to an on-premises site via one of the Site-to-site (S2S) VPN
tunnels.
Configure forced tunneling

Forced tunneling in Azure is configured using virtual network custom user-defined routes.
●● Each virtual network subnet has a built-in, system routing table. The system routing table has the
following three groups of routes:
●● Local VNet routes: Route directly to the destination VMs in the same virtual network.
●● On-premises routes: Route to the Azure VPN gateway.
●● Default route: Route directly to the Internet. Packets destined to the private IP addresses not
covered by the previous two routes are dropped.
●● To configure forced tunneling, you must:
●● Create a routing table.
●● Add a user-defined default route to the VPN Gateway.
●● Associate the routing table to the appropriate VNet subnet(s).
61
●● Forced tunneling must be associated with a VNet that has a route-based VPN gateway.
●● You must set a default site connection among the cross-premises local sites connected to the
virtual network.
●● The on-premises VPN device must be configured using 0.0.0.0/0 as traffic selectors.
Using forced tunneling allows you to restrict and inspect Internet access from your VMs and cloud
services in Azure, while continuing to enable your multi-tier service architecture the Internet access it
requires.
10-Configure internet access with Azure Virtual

NAT
Globally, IPv4 address ranges are in very short supply, and can be an expensive way to grant access to
Internet resources. Network Address Translation (NAT) arose out of this need for internal resources on a
private network to share routable IPv4 addresses to gain access to external resources on a public net-
work. Rather than purchasing an IPv4 address for each resource that requires internet access, you can use
a NAT service to map outgoing requests from internal resources to an external IP address, so that
communication can take place.
NAT services provide mappings for a single IP address, a range of IP addresses defined by an IP Prefix,
and a range of ports associated with an IP address. NAT is compatible with standard SKU public IP
address resources or public IP prefix resources or a combination of both. You can use a public IP prefix
directly or distribute the public IP addresses of the prefix across multiple NAT gateway resources. NAT will
map all traffic to the range of IP addresses of the prefix. NAT allows flows to be created from the virtual
network to the Internet. Return traffic from the Internet is only allowed in response to an active flow.
The following diagram shows outbound traffic flow from Subnet 1 through the NAT gateway to be
mapped to a Public IP address or a Public IP prefix.
You define the NAT configuration for each subnet within a VNet to enable outbound connectivity by
specifying which NAT gateway resource to use. After NAT is configured, all UDP and TCP outbound flows
62
from any virtual machine instance will use NAT for internet connectivity. No further configuration is
necessary, and you don’t need to create any user-defined routes. NAT takes precedence over other
outbound scenarios and replaces the default Internet destination of a subnet.
Support dynamic workloads by scaling NAT

With NAT, you don't need to do extensive pre-planning or pre-allocate addresses because NAT scales to
support dynamic workloads. By using port network address translation (PNAT or PAT), NAT provides up to
64,000 concurrent flows for UDP and TCP respectively, for each attached public IP address. NAT can
support up to 16 public IP addresses.
How to deploy NAT

Configuring and using NAT gateway is a straightforward process:
NAT gateway resource:
1. Create regional or zonal (zone-isolated) NAT gateway resource,
2. Assign IP addresses,
3. If necessary, modify TCP idle timeout (optional).
Virtual network:
●● Configure virtual network subnet to use a NAT gateway.
●● User-defined routes are not necessary.
Coexistence of inbound and outbound

NAT is compatible with the following standard SKU resources:
●● Load balancer
●● Public IP address
●● Public IP prefix
NAT and compatible Standard SKU features are aware of the direction the flow was started. Inbound and
outbound scenarios can coexist. These scenarios will receive the correct network address translations
because these features are aware of the flow direction. When used together with NAT, these resources
provide inbound Internet connectivity to your subnet(s).
63
Limitations of NAT
●● NAT is compatible with standard SKU public IP, public IP prefix, and load balancer resources. Basic
resources (for example basic load balancer) and any products derived from them aren't compatible
with NAT. Basic resources must be placed on a subnet not configured with NAT.
●● IPv4 address family is supported. NAT doesn't interact with IPv6 address family. NAT can't be deployed
on a subnet with an IPv6 prefix.
●● NAT can't span multiple virtual networks.
●● IP fragmentation is not supported.

answers.
64
quiz title:
Multiple choice
What is the purpose of NAT?
NAT enables you to share a single public IPv4 address among multiple internal resources. {{Correct,
NAT enables internal resources to share an IP address for communication with Internet resources.}}
NAT allows you to assign multiple private IPv4 addresses to a single virtual machine. {{Incorrect, you
can assign multiple IPv4 addresses to a single virtual machine, but the NAT service is not used for
this.}}
NAT enables you to configure an external IPv4 address on each individual virtual machine. {{Incorrect,
the NAT service is configured as a gateway, providing shared IPv4 address(es) for internal resources. It
is not configured on individual virtual machines.}}
Multiple choice
How does NAT scale to support dynamic workloads?
NAT supports up to 16 public IP addresses, and for each of those, uses port network address transla-
tion (PNAT or PAT) to provide up to 64,000 concurrent traffic flows. {{ Correct, NAT supports up to 16
public IP addresses. Using port network address translation (PNAT or PAT), NAT provides up to 64,000
concurrent flows for UDP and TCP respectively, for each attached public IP address.}}
NAT supports up to 4 public IP addresses. {{ Incorrect, NAT supports up to 16 public IP addresses.
Additionally, by using port network address translation (PNAT or PAT), NAT provides up to 64,000
NAT does not scale dynamically. You must configure NAT to scale manually, by adding additional NAT
Gateways. {{ Incorrect, NAT scales automatically to support dynamic workloads. You do not need to
add extra NAT gateways.}}
11-Summary
As your organization moves to Azure, you must design a secure virtual networking environment that
provides connectivity and name resolution for both virtual and on-premises resources. Users must be
able to access the resources they need smoothly and securely, regardless of where they are accessing the
network from.
In this module you saw a broad overview of some of the most crucial aspects of designing and planning
an Azure virtual network, including planning VNets, subnets and micro-segmentation, assigning appro-
priate IP addresses to resources and configuring DNS name resolution.
You now have the fundamental knowledge required to design and implement virtual networking in Azure.
Summary
Now that you have reviewed this module, you should be able to:
●● Implement virtual networks
●● Design and implement name resolution
65
●● Design and implement cross-VNET connectivity

●● Implement virtual network routing
●● Design and implement an Azure Virtual Network NAT
Resources
Use these resources to discover more.
●● What is Azure Virtual Network?14
●● Azure networking services overview15
●● Azure for network engineers16
14 https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview
15 https://docs.microsoft.com/en-us/azure/networking/fundamentals/networking-overview
16 https://docs.microsoft.com/en-us/azure/networking/azure-for-network-engineers
66
Answers
Multiple choice
Which of the following statements about Azure VNets is correct?
Outbound communication with the internet must be configured for each resource on the VNet.
{{Incorrect. All resources in a VNet can communicate outbound to the internet, by default.}}
■■ Azure VNets enable communication between Azure resources. {{Correct. Virtual Networks can connect
Azure resources including VMs, the App Service Environment, Azure Kubernetes Service, and Azure
virtual machine scale sets. You can use service endpoints to connect to other Azure resource types,
such as Azure SQL databases and storage accounts.}}
Azure VNets cannot be configured to communicate with on-premises resources. {{Incorrect. You can
options: Point-to-site virtual private network (VPN), Site-to-site VPN, Azure ExpressRoute.}}
Explanation
Multiple choice
Which of the following statements about subnets is NOT correct?
■■ You can assign the same IP address range to multiple subnets within the same VNet. {{That is correct.
Each subnet must have a unique address range, specified in Classless Inter-Domain Routing (CIDR)
format.}}
You can create multiple subnets within one VNet. {{That is incorrect. You can create multiple virtual
networks per subscription and per region, and multiple subnets within each virtual network.}}
You can use Network Security Groups (NSGs) to control access to a subnet and the resources on it.
{{That is incorrect. You can associate zero or one NSG to each subnet to control access to the subnet
and the resources on it.}}
Explanation
Multiple choice
What is the difference between a static public IP address and a dynamic public IP address?
A dynamic IP address remains the same over the lifespan of the resource to which it is assigned.{{That
is incorrect. A dynamic public IP address is an assigned address that can change over the lifespan of
the Azure resource. The dynamic IP address is allocated when you create or start a VM.}}
A static IP address can use an IPv4 address only.{{That is incorrect. Static IP addresses are created with
either an IPv4 or an IPv6 address.}}
■■ A static IP address remains the same over the lifespan of the resource to which it is assigned. {{That is
correct. A static public IP address is an assigned address that will not change over the lifespan of the
Azure resource. To configure a static IP address, set the allocation method explicitly to static.}}
Explanation
67
Multiple choice
Application owners need to use dynamic IP addresses for specific resources on their VNet. Which SKU
must they choose?
■■ Basic SKU {{That is correct. Basic SKU public IPs can be assigned by using static or dynamic allocation
methods.}}
Standard SKU{{That is incorrect. Standard SKU public IP addresses always use the static allocation
method.}}
Either Basic or Standard SKU{{That is incorrect. Standard SKU public IP addresses always use the static
allocation method. Basic SKU public IPs can be assigned by using static or dynamic allocation meth-
ods.}}
Explanation
Multiple choice
When one needs the resources in one VNet to communicate with resources in a subnet in a different
VNet. Which Azure network feature should be used?
Internal DNS. {{That is incorrect, internal DNS is a service provided by Azure.}}
Azure Availability Zones. {{That is incorrect, Azure Availability Zones are a high availability feature.
Each zone is made up of one or more datacenters equipped with independent power, cooling, and
networking.}}
■■ VNet peering. {{That is correct, virtual network peering enables you to seamlessly connect separate
VNets with optimal network performance, whether they are in the same Azure region (VNet peering)
or in different regions (Global VNet peering).}}
Explanation
Multiple choice
When configure global peering, what changes will see in the peered VNets?
A peering entry is added to the routing table in the source VNet only. {{That is incorrect, the VNets
communicate as peers, so resources in each VNet must be able to communicate with each other.
Adding a single peering entry only allows traffic to be routed one way.}}
All traffic on the Vnet must be routed through a Gateway. {{That is incorrect, resources on each VNet
can communicate seamlessly with one another.}}
■■ A peering entry is added to the routing table in each VNet. {{That is correct, VNet Global Peering
entries are added to the routing tables in each VNet to direct traffic to the peered VNet.}}
Explanation
68
Multiple choice
What is the purpose of NAT?
■■ NAT enables you to share a single public IPv4 address among multiple internal resources. {{Correct,
NAT enables internal resources to share an IP address for communication with Internet resources.}}
NAT allows you to assign multiple private IPv4 addresses to a single virtual machine. {{Incorrect, you
can assign multiple IPv4 addresses to a single virtual machine, but the NAT service is not used for
this.}}
NAT enables you to configure an external IPv4 address on each individual virtual machine. {{Incorrect,
the NAT service is configured as a gateway, providing shared IPv4 address(es) for internal resources. It
is not configured on individual virtual machines.}}
Explanation
Multiple choice
How does NAT scale to support dynamic workloads?
■■ NAT supports up to 16 public IP addresses, and for each of those, uses port network address transla-
tion (PNAT or PAT) to provide up to 64,000 concurrent traffic flows. {{ Correct, NAT supports up to 16
public IP addresses. Using port network address translation (PNAT or PAT), NAT provides up to 64,000
NAT supports up to 4 public IP addresses. {{ Incorrect, NAT supports up to 16 public IP addresses.
Additionally, by using port network address translation (PNAT or PAT), NAT provides up to 64,000
NAT does not scale dynamically. You must configure NAT to scale manually, by adding additional NAT
Gateways. {{ Incorrect, NAT scales automatically to support dynamic workloads. You do not need to
add extra NAT gateways.}}
Explanation
Module 2 Design and implement hybrid net-
working
Design and implement hybrid networking

1-Introduction
Imagine yourself in the role of a network engineer at an organization that is in the process of migrating
to Azure and evaluating the adoption of a global transit network architecture. This network would be
used to connect their growing number of distributed offices. It would also address the work from home
initiatives, and control their cloud-centric modern, global enterprise IT footprint. As the network engineer
you need users to be able to access resources such as file storage, databases, and applications on-prem-
ises and in Azure. You need to design and implement a hybrid connectivity solution that will address the
short term and long-term goals of the organization's global enterprise IT footprint.
When an organization migrates resources and services to Azure, network architects and engineers must
ensure that communication between the on-premises environment and Azure workloads is both secure
and reliable.
Learning objectives
●● Design and implement a site-to-site VPN connection
●● Design and implement a point-to-site VPN connection
●● Design and implement authentication for point-to-site VPN connections
●● Design and implement Azure Virtual WAN
Prerequisites
(DNS), and routing
70
2-Design and implement Azure VPN Gateway
Networks that connect on-premises resources and virtual resources are known as hybrid networks. One
option for connecting an on-premises network to an Azure VNET is a VPN connection. A virtual private
network (VPN) is a type of private interconnected network. VPNs use an encrypted tunnel within another
network. They are typically deployed to connect two or more trusted private networks to one another
over an untrusted network, usually the public Internet. Traffic is encrypted while traveling over the
untrusted network to prevent eavesdropping or other attacks.
To integrate your on-premises environment with Azure, you need the ability to create an encrypted
connection. You can connect over the internet, or over a dedicated link. Here, we'll look at Azure VPN
Gateway, which provides an endpoint for incoming connections from on-premises environments.
When you're working toward integrating your on-premises network with Azure, there needs to be a
bridge between them. VPN Gateway is an Azure service that provides this functionality. A VPN gateway
can send encrypted traffic between the two networks. VPN gateways support multiple connections, which
enable them to route VPN tunnels that use any available bandwidth. Each virtual network can have only
one VPN gateway. All connections to that VPN gateway share the available network bandwidth. VPN
gateways can also be used for connections between virtual networks in Azure.
Azure VPN Gateways

Within each virtual network gateway there are two or more virtual machines (VMs). These VMs have been
deployed to a special subnet that you specify, called the gateway subnet. They contain routing tables for
connections to other networks, along with specific gateway services. These VMs and the gateway subnet
are similar to a hardened network device. You don't need to configure these VMs directly and should not
deploy any additional resources into the gateway subnet.
Creating a virtual network gateway can take some time to complete, so it's vital that you plan appropri-
ately. When you create a virtual network gateway, the provisioning process generates the gateway VMs
and deploys them to the gateway subnet. These VMs will have the settings that you configure on the
gateway.
Now, let's look at the factors you need to consider for planning your VPN gateway.
Plan a VPN gateway

When you're planning a VPN gateway, there are three architectures to consider:
●● Point to site over the internet
●● Site to site over the internet
●● Site to site over a dedicated network, such as Azure ExpressRoute
Planning factors
Factors that you need to cover during your planning process include:
●● Throughput - Mbps or Gbps
71
●● Backbone - Internet or private?

●● Availability of a public (static) IP address
●● VPN device compatibility
●● Multiple client connections or a site-to-site link?
●● VPN gateway type
●● Azure VPN Gateway SKU
Choose the appropriate Gateway SKU and Generation

When you create a virtual network gateway, you need to specify the gateway SKU that you want to use.
Select the SKU that satisfies your requirements based on the types of workloads, throughputs, features,
and SLAs. The table below shows the available SKUs and what S2S and P2S configurations they support.
VPN SKU S2S/ P2S SSTP P2S Aggregate BGP Zone-re-

Gateway VNet-to- Connec- IKEv2/ Through- dundant
Genera- Vnet tions OpenVPN put
tion Tunnels Connec- Bench-
tions mark
Genera- Basic Max. 10 Max. 128 Not 100 Mbps Not No
tion1 Supported Supported
Genera- VpnGw1 Max. 30* Max. 128 Max. 250 650 Mbps Supported No
tion1
Genera- VpnGw2 Max. 30* Max. 128 Max. 500 1 Gbps Supported No
tion1
Genera- VpnGw3 Max. 30* Max. 128 Max. 1000 1.25 Gbps Supported No
tion1
Genera- VpnGw1AZ Max. 30* Max. 128 Max. 250 650 Mbps Supported Yes
tion1
Genera- VpnGw2AZ Max. 30* Max. 128 Max. 500 1 Gbps Supported Yes
tion1
Genera- VpnGw3AZ Max. 30* Max. 128 Max. 1000 1.25 Gbps Supported Yes
tion1
tion2
tion2
Genera- VpnGw4 Max. 30* Max. 128 Max. 5000 5 Gbps Supported No
tion2
Genera- VpnGw5 Max. 30* Max. 128 Max. 10 Gbps Supported No
tion2 10000
tion2
tion2
Genera- VpnGw4AZ Max. 30* Max. 128 Max. 5000 5 Gbps Supported Yes
tion2
72
Genera- VpnGw5AZ Max. 30* Max. 128 Max. 10 Gbps Supported Yes
tion2 10000
(*) Use Virtual WAN if you need more than 30 S2S VPN tunnels.
●● The resizing of VpnGw SKUs is allowed within the same generation, except resizing of the Basic SKU.
The Basic SKU is a legacy SKU and has feature limitations. To move from Basic to another VpnGw SKU,
you must delete the Basic SKU VPN gateway and create a new gateway with the desired Generation
and SKU size combination.
●● These connection limits are separate. For example, you can have 128 SSTP connections and 250 IKEv2
connections on a VpnGw1 SKU.
●● On a single tunnel a maximum of 1 Gbps throughput can be achieved. Aggregate Throughput
Benchmark in the above table is based on measurements of multiple tunnels aggregated through a
single gateway. The Aggregate Throughput Benchmark for a VPN Gateway is S2S + P2S combined. If
you have a lot of P2S connections, it can negatively impact a S2S connection due to throughput
limitations. The Aggregate Throughput Benchmark is not a guaranteed throughput due to Internet
traffic conditions and your application behaviors.
VPN types
When you create the virtual network gateway for a VPN gateway configuration, you must specify a VPN
type. The VPN type that you choose depends on the connection topology that you want to create. For
example, a P2S connection requires a RouteBased VPN type. A VPN type can also depend on the hard-
ware that you are using. S2S configurations require a VPN device. Some VPN devices only support a
certain VPN type.
The VPN type you select must satisfy all the connection requirements for the solution you want to create.
For example, if you want to create a S2S VPN gateway connection and a P2S VPN gateway connection for
the same virtual network, use VPN type RouteBased because P2S requires a RouteBased VPN type. You
would also need to verify that your VPN device supported a RouteBased VPN connection.
Once a virtual network gateway has been created, you can't change the VPN type. You must delete the
virtual network gateway and create a new one. There are two VPN types:
PolicyBased
PolicyBased VPNs were previously called static routing gateways in the classic deployment model.
Policy-based VPNs encrypt and direct packets through IPsec tunnels based on the IPsec policies config-
ured with the combinations of address prefixes between your on-premises network and the Azure VNet.
The policy (or traffic selector) is usually defined as an access list in the VPN device configuration. The
value for a PolicyBased VPN type is PolicyBased. When using a PolicyBased VPN, keep in mind the
following limitations:
PolicyBased VPNs can only be used on the Basic gateway SKU. This VPN type is not compatible with other
gateway SKUs.
You can have only 1 tunnel when using a PolicyBased VPN.
You can only use PolicyBased VPNs for S2S connections, and only for certain configurations. Most VPN
Gateway configurations require a RouteBased VPN.
73
RouteBased
RouteBased VPNs were previously called dynamic routing gateways in the classic deployment model.
RouteBased VPNs use “routes” in the IP forwarding or routing table to direct packets into their corre-
sponding tunnel interfaces. The tunnel interfaces then encrypt or decrypt the packets in and out of the
tunnels. The policy (or traffic selector) for RouteBased VPNs are configured as any-to-any (or wild cards).
The value for a RouteBased VPN type is RouteBased.
VPN Gateway configuration requirements

The following table lists the requirements for PolicyBased and RouteBased VPN gateways. This table
applies to both the Resource Manager and classic deployment models. For the classic model, PolicyBased
VPN gateways are the same as Static gateways, and Route-based gateways are the same as Dynamic
gateways.
Features PolicyBased Basic RouteBased Basic RouteBased RouteBased High

VPN Gateway VPN Gateway Standard VPN Performance VPN
Gateway Gateway
Site-to-Site PolicyBased VPN RouteBased VPN RouteBased VPN RouteBased VPN
connectivity (S2S) configuration configuration configuration configuration
Point-to-Site Not supported Supported (Can Supported (Can Supported (Can
connectivity (P2S) coexist with S2S) coexist with S2S) coexist with S2S)
Authentication Pre-shared key Pre-shared key for Pre-shared key for Pre-shared key for
method S2S connectivity, S2S connectivity, S2S connectivity,
Certificates for P2S Certificates for P2S Certificates for P2S
connectivity connectivity connectivity
Maximum number 1 10 10 30
of S2S connections
Maximum number Not supported 128 128 128
of P2S connections
Active routing Not supported Not supported Supported Supported
support (BGP) (*)
(*) BGP is not supported for the classic deployment model.
74
Create the VPN Gateway
The VPN gateway settings that you chose are critical to creating a successful connection.
●● Gateway type. VPN or ExpressRoute.
●● VPN Type. Route based or Policy based. Most VPN types are Route-based. The type of VPN you
choose depends on the make and model of your VPN device, and the kind of VPN connection you
intend to create. Typical route-based gateway scenarios include point-to-site, inter-virtual network, or
multiple site-to-site connections. Route-based is also selected when you coexist with an ExpressRoute
gateway or if you need to use IKEv2. Policy-based gateways support only IKEv1.
●● SKU. Use the drop-down to select a gateway SKU. Your choice will affect the number of tunnels you
can have and the aggregate throughput benchmark. The benchmark is based on measurements of
multiple tunnels aggregated through a single gateway. It is not a guaranteed throughput due to
Internet traffic conditions and your application behaviors.
●● Generation. Generation1 or Generation2. You cannot change generations or SKUs across generations.
Basic and VpnGw1 SKUs are only supported in Generation1. VpnGw4 and VpnGw5 SKUs are only
supported in Generation2.
●● Virtual Networks. The virtual network that will be able to send and receive traffic through the virtual
network gateway. A virtual network cannot be associated with more than one gateway.
Note: You can view the IP address assigned to the gateway. The gateway should appear as a connected
device.
Gateway subnet
VPN Gateways require a gateway subnet. You can create a Gateway subnet before you create a VPN
gateway, or you can create it during the creation of the VPN Gateway. The gateway subnet contains the
IP addresses that the virtual network gateway VMs and services use. When you create your virtual
network gateway, gateway VMs are deployed to the gateway subnet and configured with the required
VPN gateway settings. Never deploy anything else (for example, additional VMs) to the gateway subnet.
The gateway subnet must be named GatewaySubnet to work properly. Naming the gateway subnet
GatewaySubnet tells Azure know that this is the subnet to deploy the virtual network gateway VMs and
services to.
75
When you create the gateway subnet, you specify the number of IP addresses that the subnet contains.
The IP addresses in the gateway subnet are allocated to the gateway VMs and gateway services. Some
configurations require more IP addresses than others.
When you are planning your gateway subnet size, refer to the documentation for the configuration that
you are planning to create. For example, the ExpressRoute/VPN Gateway coexist configuration requires a
larger gateway subnet than most other configurations. Additionally, you may want to make sure your
gateway subnet contains enough IP addresses to accommodate possible future additional configurations.
While you can create a gateway subnet as small as /29, we recommend that you create a gateway subnet
of /27 or larger (/27, /26 etc.) if you have the available address space to do so. This will accommodate
most configurations.
Create the Local Network Gateway

The local network gateway typically refers to the on-premises location. You give the site a name by which
Azure can refer to it, then specify the IP address or FQDN of the on-premises VPN device for the connec-
tion. You also specify the IP address prefixes that will be routed through the VPN gateway to the VPN
device. The address prefixes you specify are the prefixes located in the on-premises network.
IP Address. The public IP address of the local gateway.

Address Space. One or more IP address ranges (in CIDR notation) that define your local network's
address space. If you plan to use this local network gateway in a BGP-enabled connection, then the
minimum prefix you need to declare is the host address of your BGP Peer IP address on your VPN device.
Configure the on-premises VPN device

There is a validated list of standard VPN devices that work well with the VPN gateway. This list was
created in partnership with device manufacturers like Cisco, Juniper, Ubiquiti, and Barracuda Networks.
When your device is not listed in the validated VPN devices table, the device may still work. Contact your
device manufacturer for support and configuration instructions.
To configure your VPN device, you will need:
76
A shared key. The same shared key that you specify when creating the VPN connection.
The public IP address of your VPN gateway. The IP address can be new or existing.
[!NOTE]
Depending on the VPN device that you have, you may be able to download a VPN device configura-
tion script1 .
Create the VPN Connection

Once your VPN gateways are created, you can create the connection between them. If your VNets are in
the same subscription, you can use the portal.
Name. Enter a name for your connection.

Connection type. Select Site-to-Site (IPSec) from the drop-down.
Shared key (PSK). In this field, enter a shared key for your connection. You can generate or create this
key yourself. In a site-to-site connection, the key you use is the same for your on-premises device and
your virtual network gateway connection.
Verify the VPN Connection

After you have configured all the Site-to-Site components, it is time to verify that everything is working.
You can verify the connections either in the portal, or by using PowerShell.
High availability options for VPN connections

To provide better availability for your VPN connections, there are a few options available:
●● VPN Gateway redundancy (Active-standby)
●● Multiple on-premises VPN devices
●● Active-active Azure VPN gateway
●● Combination of both
1 https://docs.microsoft.com/azure/vpn-gateway/vpn-gateway-download-vpndevicescript
77
VPN Gateway redundancy

Every Azure VPN gateway consists of two instances in an active-standby configuration. For any planned
maintenance or unplanned disruption that happens to the active instance, the standby instance would
take over (failover) automatically and resume the S2S VPN or VNet-to-VNet connections. The switch over
will cause a brief interruption. For planned maintenance, the connectivity should be restored within 10 to
15 seconds. For unplanned issues, the connection recovery will be longer, about 1 to 3 minutes in the
worst case. For P2S VPN client connections to the gateway, the P2S connections will be disconnected,
and the users will need to reconnect from the client machines.
Multiple on-premises VPN devices

You can use multiple VPN devices from your on-premises network to connect to your Azure VPN gate-
way, as shown in the following diagram:
This configuration provides multiple active tunnels from the same Azure VPN gateway to your on-premis-
es devices in the same location. There are some requirements and constraints:
1. You need to create multiple S2S VPN connections from your VPN devices to Azure. When you connect
multiple VPN devices from the same on-premises network to Azure, you need to create one local
network gateway for each VPN device, and one connection from your Azure VPN gateway to each
local network gateway.
2. The local network gateways corresponding to your VPN devices must have unique public IP addresses
in the GatewayIpAddress property.
3. BGP is required for this configuration. Each local network gateway representing a VPN device must
have a unique BGP peer IP address specified in the BgpPeerIpAddress property.
4. You should use BGP to advertise the same prefixes of the same on-premises network prefixes to your
Azure VPN gateway, and the traffic will be forwarded through these tunnels simultaneously.
5. You must use Equal-cost multi-path routing (ECMP).
6. Each connection is counted against the maximum number of tunnels for your Azure VPN gateway, 10
for Basic and Standard SKUs, and 30 for HighPerformance SKU.
78
In this configuration, the Azure VPN gateway is still in active-standby mode, so the same failover behavior
and brief interruption will still happen as described above. But this setup guards against failures or
interruptions on your on-premises network and VPN devices.
Active-active VPN gateways

You can create an Azure VPN gateway in an active-active configuration, where both instances of the
gateway VMs will establish S2S VPN tunnels to your on-premises VPN device, as shown the following
diagram:
In this configuration, each Azure gateway instance will have a unique public IP address, and each will
establish an IPsec/IKE S2S VPN tunnel to your on-premises VPN device specified in your local network
gateway and connection. Note that both VPN tunnels are part of the same connection. You will still need
to configure your on-premises VPN device to accept or establish two S2S VPN tunnels to those two Azure
VPN gateway public IP addresses.
Because the Azure gateway instances are in active-active configuration, the traffic from your Azure virtual
network to your on-premises network will be routed through both tunnels simultaneously, even if your
on-premises VPN device may favor one tunnel over the other. For a single TCP or UDP flow, Azure
attempts to use the same tunnel when sending packets to your on-premises network. However, your
on-premises network could use a different tunnel to send packets to Azure.
When a planned maintenance or unplanned event happens to one gateway instance, the IPsec tunnel
from that instance to your on-premises VPN device will be disconnected. The corresponding routes on
your VPN devices should be removed or withdrawn automatically so that the traffic will be switched over
to the other active IPsec tunnel. On the Azure side, the switch over will happen automatically from the
affected instance to the active instance.
Dual-redundancy: active-active VPN gateways for both Az-

ure and on-premises networks
The most reliable option is to combine the active-active gateways on both your network and Azure, as
shown in the diagram below.
Here you create and set up the Azure VPN gateway in an active-active configuration and create two local
network gateways and two connections for your two on-premises VPN devices as described above. The
79
result is a full mesh connectivity of 4 IPsec tunnels between your Azure virtual network and your
on-premises network.
All gateways and tunnels are active from the Azure side, so the traffic will be spread among all 4 tunnels
simultaneously, although each TCP or UDP flow will again follow the same tunnel or path from the Azure
side. Even though by spreading the traffic, you may see slightly better throughput over the IPsec tunnels,
the primary goal of this configuration is for high availability. And due to the statistical nature of the
spreading, it is difficult to provide the measurement on how different application traffic conditions will
affect the aggregate throughput.
This topology will require two local network gateways and two connections to support the pair of
on-premises VPN devices, and BGP is required to allow the two connections to the same on-premises
network. These requirements are the same as the above.
Highly Available VNet-to-VNet

The same active-active configuration can also apply to Azure VNet-to-VNet connections. You can create
active-active VPN gateways for both virtual networks, and connect them together to form the same full
mesh connectivity of 4 tunnels between the two VNets, as shown in the diagram below:
This ensures there are always a pair of tunnels between the two virtual networks for any planned mainte-
nance events, providing even better availability. Even though the same topology for cross-premises
connectivity requires two connections, the VNet-to-VNet topology shown above will need only one
connection for each gateway. Additionally, BGP is optional unless transit routing over the VNet-to-VNet
connection is required.
Troubleshoot Azure VPN Gateway

VPN Gateway connections can fail for a variety of reasons. Although a network engineer will be able to
troubleshoot many connectivity issues from experience, the following Microsoft documentation provides
help and guidance for resolving many common problems.
Validate VPN throughput to a VNet
A VPN gateway connection enables you to establish secure, cross-premises connectivity between your
Virtual Network within Azure and your on-premises IT infrastructure. This article shows how to validate
network throughput from the on-premises resources to an Azure virtual machine (VM). It also provides
troubleshooting guidance. See Validate VPN throughput to a virtual network - Azure VPN Gateway2.
Point-to-Site connections
This article lists common point-to-site connection problems that you might experience. It also discusses
possible causes and solutions for these problems. See Troubleshoot Azure point-to-site connection
problems - Azure VPN Gateway3.
2 https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-validate-throughput-to-vnet
3 https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-troubleshoot-vpn-point-to-site-connection-problems
80
Site-to-Site connections
After you configure a site-to-site VPN connection between an on-premises network and an Azure virtual
network, the VPN connection suddenly stops working and cannot be reconnected. This article provides
troubleshooting steps to help you resolve this problem. See Troubleshoot an Azure site-to-site VPN
connection that cannot connect - Azure VPN Gateway4.
VPN and Firewall device settings
This article provides several suggested solutions for third-party VPN or firewall devices that are used with
VPN Gateway. Technical support for third-party VPN or firewall devices is provided by the device vendor.
See Community-suggested third-party VPN or firewall device settings for Azure VPN Gateway5.
Troubleshoot Azure VPN Gateway using diagnostic logs

Using diagnostic logs, you can troubleshoot multiple VPN gateway related events including configuration
activity, VPN Tunnel connectivity, IPsec logging, BGP route exchanges, Point to Site advanced logging.
There are several diagnostic logs you can use to help troubleshoot a problem with your VPN Gateway.
●● GatewayDiagnosticLog - Contains diagnostic logs for gateway configuration events, primary chang-
es, and maintenance events.
●● TunnelDiagnosticLog - Contains tunnel state change events. Tunnel connect/disconnect events have
a summarized reason for the state change if applicable.
●● RouteDiagnosticLog - Logs changes to static routes and BGP events that occur on the gateway.
●● IKEDiagnosticLog - Logs IKE control messages and events on the gateway.
●● P2SDiagnosticLog - Logs point-to-site control messages and events on the gateway.
Use Azure Monitor to analyze the data collected in the diagnostic logs.
quiz title: Check your knowledge
Multiple choice
What are the two types of VPNs?
PolicyBased and RouteBased. {{Correct, VPNs can be RouteBased or PolicyBased.}}
PolicyBased and static. {{Incorrect, VPNs can be PolicyBased. Static is the name used for PolicyBased
VPNs in the classic deployment model.}}
RouteBased and dynamic. {{Incorrect, VPNs can be RouteBased. Dynamic is the name used for Route-
Based VPNs in the classic deployment model.}}
4 https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-troubleshoot-site-to-site-cannot-connect
5 https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-third-party-settings
81
Multiple choice
What is the default high availability configuration for VPN gateways?
Active-standby {{Correct, Every Azure VPN gateway consists of two instances in an active-standby
configuration.}}
Active-active {{Incorrect, You can create an Azure VPN gateway in an active-active configuration, but
this is not the default.}}
Dual-redundancy {{Incorrect, This is the most reliable option, combining the active-active gateways on
both your network and Azure, but it is not the default.}}
3-Exercise: Create and configure a virtual net-

work gateway
In this exercise you will configure a virtual network gateway to connect the Contoso Core Services VNet
and Manufacturing VNet.
●● Task 1: Create CoreServicesVnet and ManufacturingVnet
●● Task 2: Create CoreServicesTestVM
●● Task 3: Create ManufacturingTestVM
●● Task 4: Connect to the Test VMs using RDP
●● Task 6: Create CoreServicesVnet Gateway
●● Task 7: Create ManufacturingVnet Gateway
●● Task 8: CoreServicesVnet to ManufacturingVnet
●● Task 9: Connect ManufacturingVnet to CoreServicesVnet
●● Task 10: Verify that the connections connect
Task 1: Create CoreServicesVnet and ManufacturingVnet

2. In the toolbar of the Cloud Shell pane, click the Upload/Download files icon, in the drop-down menu,
click Upload and upload the following files azuredeploy.json and azuredeploy.parameters.json into the
Cloud Shell home directory. Azure Resource Manager Templates for creating VNets6
3. Deploy the following Azure Resource Manager templates to create the virtual network and subnets
needed for this exercise:
$RGName = "ContosoResourceGroup"
6 https://github.com/MicrosoftLearning/AZ-700-Designing-and-Implementing-Microsoft-Azure-Networking-Solutions/tree/master/Allfiles/
Exercises/M02
82
#create resource group if it doesnt exist
New-AzResourceGroup -Name $RGName -Location West US
New-AzResourceGroupDeployment -ResourceGroupName $RGName -TemplateFile azuredeploy.json

-TemplateParameterFile azuredeploy.parameters.json
Task 2: Create CoreServicesTestVM

select Dev/Test.
create a VM.
Tab Option Value

Virtual machine name CoreServicesTestVM
Region (US) West US
required
83

- Gen 1
memory
Username TestUser
Public IP (new) CoreServicesTestVM-ip
Create
Task 3: Create ManufacturingTestVM

84
select Dev/Test.
create a VM.
Tab Option Value

Virtual machine name ManufacturingTestVM
required
- Gen 1
memory
Username TestUser
Networking Virtual network ManufacturingVnet
85
Subnet ManufacturingSystemSubnet
(10.40.40.0/24)
Public IP (new) ManufacturingTestVM-ip
Create
Task 4: Connect to the Test VMs using RDP

2. Select ManufacturingTestVM.
3. In ManufacturingTestVM, select Connect > RDP.
4. In ManufacturingTestVM | Connect, select Download RDP file.
6. Connect to ManufacturingTestVM using the RDP file, and the username and password you specified
when you created the VM.
8. Select CoreServicesTestVM.
9. In CoreServicesTestVM, select Connect > RDP.
10. In CoreServicesTestVM | Connect, select Download RDP file.
12. Connect to CoreServicesTestVM using the RDP file, and the username and password you specified
when you created the VM.
15. On CoreServicesTestVM, open PowerShell, and run the following command: ipconfig
16. Note the IPv4 address.

1. On the ManufacturingTestVM, open PowerShell.
2. Use the following command to verify that there is no connection to CoreServicesTestVM on CoreSer-
vicesVnet. Be sure to use the IPv4 address for CoreServicesTestVM.
86
3. The test connection should fail, and you will see a result similar to the following:
Task 6: Create CoreServicesVnet Gateway

1. In Search resources, services, and docs (G+/), enter Virtual network gateway, and then select
Virtual network gateways from the results.
2. In Virtual network gateways, select + Create.

3. Use the information in the following table to create the virtual network gateway:
Tab Section Option Value

Basics Project Details Subscription No changes required
ResourceGroup ContosoResourceGroup
Instance Details Name CoreServicesVnetGate-
way
Region West US
Gateway type VPN
VPN type Route-based
SKU VpnGw1
Generation Generation1
Virtual network CoreServicesVnet
Subnet GatewaySubnet
(10.20.0.0/27)
Public IP address Public IP address Create new
87
Public IP address name CoreServicesVnetGate-

way-ip
Public IP address SKU Basic
Enable active-active Disabled
mode
Configure BGP Disabled
Review + create Review your settings
and select Create.
[!NOTE]
It can take up to 45 minutes to create a virtual network gateway.
Task 7: Create ManufacturingVnet Gateway

2. In Virtual network gateways, select + Create.
3. Use the information in the following table to create the virtual network gateway:
Tab Section Option Value

Basics Project Details Subscription No changes required
ResourceGroup ContosoResourceGroup
Instance Details Name ManufacturingVnet-
Gateway
Region North Europe
Gateway type VPN
VPN type Route-based
SKU VpnGw1
Generation Generation1
Virtual network ManufacturingVnet
Subnet GatewaySubnet
(10.30.0.0/27)
Public IP address Public IP address Create new
Public IP address name ManufacturingVnet-
Gateway-ip
Enable active-active Disabled
mode
Review + create Review your settings
and select Create.
[!NOTE]
It can take up to 45 minutes to create a virtual network gateway.
88
Task 8: Connect CoreServicesVnet to ManufacturingVnet

2. In Virtual network gateways, select CoreServicesVnetGateway.
3. In CoreServicesGateway, select Connections, and then select + Add.
[!NOTE]
You will not be able to complete this configuration until the virtual network gateways are fully deployed.
4. Use the information in the following table to create the connection:
Option Value
Name CoreServicesGW-to-ManufacturingGW
Connection type VNet-to-VNet
First virtual network gateway CoreServicesVnetGateway
Second virtual network gateway ManufacturingVnetGateway
Shared key (PSK) abc123
Use Azure Private IP Address Not selected
Enable BGP Not selected
IKE Protocol IKEv2
Resource group No changes required
Location West US
5. To create the connection, select Create.
Task 9: Connect ManufacturingVnet to CoreServicesVnet

2. In Virtual network gateways, select ManufacturingVnetGateway.
3. In CoreServicesGateway, select Connections, and then select + Add.
4. Use the information in the following table to create the connection:
Option Value
Name ManufacturingGW-to-CoreServicesGW
Connection type VNet-to-VNet
First virtual network gateway ManufacturingVnetGateway
Second virtual network gateway CoreServicesVnetGateway
Shared key (PSK) abc123
Use Azure Private IP Address Not selected
Enable BGP Not selected
IKE Protocol IKEv2
Resource group No changes required
Location North Europe
89
5. To create the connection, select Create.
Task 10: Verify that the connections connect

1. In Search resources, services, and docs (G+/), enter connections, and then select connections from
the results.
2. Wait until the status of both connections is Connected. You may need to refresh your screen.

1. On the ManufacturingTestVM, open PowerShell.
2. Use the following command to verify that there is now a connection to CoreServicesTestVM on
CoreServicesVnet. Be sure to use the IPv4 address for CoreServicesTestVM.
3. The test connection should succeed, and you will see a result similar to the following:
Congratulations! You have configured a VNet-to-VNet connection by using a virtual network gateway.
4-Connect networks with Site-to-site VPN con-

nections
A site-to-site (S2S) VPN gateway connection lets you create a secure connection to your virtual network
from another virtual network or a physical network. The following diagram illustrates how you would
connect an on-premises network to the Azure platform. The internet connection uses an IPsec VPN
tunnel.
90
In the diagram:
●● The on-premises network represents your on-premises Active Directory and any data or resources.
●● The gateway is responsible for sending encrypted traffic to a virtual IP address when it uses a public
connection.
●● The Azure virtual network holds all your cloud applications and any Azure VPN gateway components.
●● An Azure VPN gateway provides the encrypted link between the Azure virtual network and your
on-premises network. An Azure VPN gateway is made up of these elements:
●● Virtual network gateway
●● Local network gateway
●● Connection
●● Gateway subnet
●● Cloud applications are the ones you've made available through Azure.
●● An internal load balancer, located in the front end, routes cloud traffic to the correct cloud-based
application or resource.
Using this architecture offers several benefits, including:
●● Configuration and maintenance are simplified.
●● Having a VPN gateway helps ensure that all data and traffic are encrypted between the on-premises
gateway and the Azure gateway.
●● The architecture can be scaled and extended to meet your organization's networking needs.
This architecture isn't applicable in all situations because it uses an existing internet connection as the link
between the two gateway points. Bandwidth constraints can cause latency issues that result from reuse of
the existing infrastructure.
91
5-Connect devices to networks with Point-to-

site VPN connections
A Point-to-Site (P2S) VPN gateway connection lets you create a secure connection to your virtual network
from an individual client computer. A P2S connection is established by starting it from the client comput-
er. This solution is useful for telecommuters who want to connect to Azure VNets from a remote location,
such as from home or a conference. P2S VPN is also a useful solution to use instead of S2S VPN when
you have only a few clients that need to connect to a VNet.
Point-to-site protocols
Point-to-site VPN can use one of the following protocols:
●● OpenVPN® Protocol, an SSL/TLS based VPN protocol. A TLS VPN solution can penetrate firewalls,
since most firewalls open TCP port 443 outbound, which TLS uses. OpenVPN can be used 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), a proprietary TLS-based VPN protocol. A TLS VPN solution
can penetrate firewalls, since most firewalls open TCP port 443 outbound, which TLS uses. SSTP is only
supported on Windows devices. Azure supports all versions of Windows that have SSTP (Windows 7
and later).
●● IKEv2 VPN, a standards-based IPsec VPN solution. IKEv2 VPN can be used to connect from Mac
devices (macOS versions 10.11 and above).
Point-to-site authentication methods

The user must be authenticated before Azure accepts a P2S VPN connection. There are two mechanisms
that Azure offers to authenticate a connecting user.
92
Authenticate using native Azure certificate authentication

When using the native Azure certificate authentication, a client certificate on the device is used to
authenticate the connecting user. Client certificates are generated from a trusted root certificate and then
installed on each client computer. You can use a root certificate that was generated using an Enterprise
solution, or you can generate a self-signed certificate.
The validation of the client certificate is performed by the VPN gateway and happens during establish-
ment of the P2S VPN connection. The root certificate is required for the validation and must be uploaded
to Azure.
Authenticate using native Azure Active Directory authentica-

tion
Azure AD authentication allows users to connect to Azure using their Azure Active Directory credentials.
Native Azure AD authentication is only supported for OpenVPN protocol and Windows 10 and requires
the use of the Azure VPN Client.
With native Azure AD authentication, you can leverage Azure AD's conditional access as well as multifac-
tor authentication (MFA) features for VPN.
At a high level, you need to perform the following steps to configure Azure AD authentication:
●● Configure an Azure AD tenant
●● Enable Azure AD authentication on the gateway
●● Download and configure Azure VPN Client
Authenticate using Active Directory (AD) Domain Server

AD Domain authentication is a popular option because it allows users to connect to Azure using their
organization domain credentials. It requires a RADIUS server that integrates with the AD server. Organiza-
tions can also leverage their existing RADIUS deployment.
The RADIUS server is deployed either on-premises or in your Azure VNet. During authentication, the
Azure VPN Gateway passes authentication messages back and forth between the RADIUS server and the
connecting device. Thus, the Gateway must be able to communicate with the RADIUS server. If the
RADIUS server is present on-premises, then a VPN S2S connection from Azure to the on-premises site is
required for reachability.
The RADIUS server can also integrate with AD certificate services. This lets you use the RADIUS server and
your enterprise certificate deployment for P2S certificate authentication as an alternative to the Azure
certificate authentication. Integrating the RADIUS server with AD certificate services means that you can
do all your certificate management in AD, you don’t need to upload root certificates and revoked certifi-
cates to Azure.
A RADIUS server can also integrate with other external identity systems. This opens many authentication
options for P2S VPN, including multi-factor options.
93
Configure point-to-site clients

Users use the native VPN clients on Windows and Mac devices for P2S. Azure provides a VPN client
configuration zip file that contains settings required by these native clients to connect to Azure.
●● For Windows devices, the VPN client configuration consists of an installer package that users install on
their devices.
●● For Mac devices, it consists of the mobileconfig file that users install on their devices.
94
The zip file also provides the values of some of the important settings on the Azure side that you can use
to create your own profile for these devices. Some of the values include the VPN gateway address,
configured tunnel types, routes, and the root certificate for gateway validation.
Note: That for Windows clients, you must have administrator rights on the client device to initiate the
VPN connection from the client device to Azure.
Multiple choice
What is a site-to-site VPN Gateway connection?
A site-to-site VPN Gateway connection securely connects two networks. {{Correct, A site-to-site (S2S)
VPN gateway connection lets you create a secure connection to your virtual network from another
virtual network or a physical network.}}
A site-to-site VPN Gateway connection securely connects an individual client computer to a network.
{{Incorrect, A point-to-site (P2S) VPN gateway connection lets you create a secure connection to your
virtual network from an individual client computer.}}
A site-to-site VPN Gateway connection securely connects two individual computers. {{Incorrect, A
site-to-site (S2S)VPN gateway connection does not connect two individual computers.}}
95
Multiple choice
To authenticate a user connecting through a point-to-site connection using Active Directory Domain Server,
what type of server is required?
RADIUS {{Correct, AD Domain authentication allows users to connect to Azure using their organization
domain credentials. It requires a RADIUS server that integrates with the AD server.}}
Active Directory Domain Controller only {{Incorrect, An Active Directory Domain Controller alone is
not sufficient. Another type of server is required.}}
DNS server {{Incorrect, A DNS server may be required for name resolution, but it is not sufficient for
authentication.}}
6-Connect remote resources by using Azure Vir-

tual WANs
Today’s workforce is more distributed than ever before. Organizations are exploring options that enable
their employees, partners, and customers to connect to the resources they need from wherever they are.
It’s not unusual for organizations to operate across regional and national boundaries, and across time
zones.
What is Azure Virtual WAN?

An organization might have a large user center at headquarters, multiple branch offices, and multiple
remote users. All these sites need to connect to resources throughout the organization. Historically,
organizations used a combination of VPNs to provide site-to-site connections for branch offices, point-
to-site connections for individual remote users, and connections to Cloud services. Traditional Software
Defined Wide Area Network (SD WAN) technologies combine and manage the connections, requiring
connectivity appliances such as gateways at each site, and connecting them through internet tunnels.
Azure Virtual WAN combines all these methods of connectivity to enable the organization to leverage the
Microsoft backbone network, which connects Microsoft data centers across Azure regions and a large
mesh of edge-nodes around the world. By connecting to the backbone network, organizations can
leverage its reliability, capacity, and flexibility to connect their regional Azure VNets, network edge
locations like ExpressRoute, and carrier neutral connections.
A Virtual WAN is a security delineation; each instance of a Virtual WAN is self-contained in terms of
connectivity and hence also provides security isolation. Organizations will generally only require one
instance of a Virtual WAN. Each Virtual WAN is implemented as a hub-and-spoke topology, and can have
one or more hubs, which support connectivity between different types of endpoints including connectivi-
ty vendors like AT&T, Verizon, and T-Mobile. All hubs are connected in a full mesh topology in a Standard
Virtual WAN making it easy for the user to use the Microsoft backbone for any-to-any (any spoke)
transitive connectivity.
A secured virtual hub is an Azure Virtual WAN Hub with associated security and routing policies config-
ured by Azure Firewall Manager. Use secured virtual hubs to easily create hub-and-spoke and transitive
architectures with native security services for traffic governance and protection. You can use a secured
virtual hub to filter traffic between virtual networks (V2V), virtual networks and branch offices (B2V) and
traffic to the Internet (B2I/V2I). A secured virtual hub provides automated routing. There's no need to
configure your own UDRs (user defined routes) to route traffic through your firewall.
96
The following diagram shows an organization with a single Virtual WAN hub connecting the spokes.
VNets, Site-to-site and point-to-site VPNs, SD WANs, and ExpressRoute connectivity are all supported.
Gateway scale
Gateway scale units allow you pick the aggregate throughput of the VPN gateway being created in the
virtual hub to connect sites to. If you pick 1 scale unit = 500 Mbps, it implies that two instances for
redundancy will be created, each having a maximum throughput of 500 Mbps. For example, if you had
five branches, each doing 10 Mbps at the branch, you will need an aggregate of 50 Mbps at the head
end. Planning for aggregate capacity of the Azure VPN gateway should be done after assessing the
capacity needed to support the number of branches to the hub.
Choose a Virtual WAN SKU

There are two types of Virtual WANs: Basic and Standard. The following table shows the available config-
urations for each type.
Virtual WAN type Hub type Available configurations

Basic Basic Site-to-site VPN only
Standard Standard ExpressRoute
User VPN (P2S)
VPN (site-to-site)
Inter-hub and VNet-to-VNet
transiting through the virtual
hub
97
Hub private address space

The minimum address space is /24 to create a hub. If you use anything in the range from /25 to /32, it will
produce an error during creation. You don't need to explicitly plan the subnet address space for the
services in the virtual hub. Because Azure Virtual WAN is a managed service, it creates the appropriate
subnets in the virtual hub for the different gateways/services (for example, VPN gateways, ExpressRoute
gateways, User VPN point-to-site gateways, Firewall, routing, etc.).
Connect cross-tenant VNets to a Virtual WAN hub

You can use Virtual WAN to connect a VNet to a virtual hub in a different tenant. This architecture is
useful if you have client workloads that must be connected to be the same network but are on different
tenants. For example, as shown in the following diagram, you can connect a non-Contoso VNet (the
Remote Tenant) to a Contoso virtual hub (the Parent Tenant).
Before you can connect a cross-tenant VNet to a Virtual WAN hub, you must have the following configu-
ration already set up:
●● A Virtual WAN and virtual hub in the parent subscription.
●● A virtual network configured in a subscription in the remote tenant.
●● Non-overlapping address spaces in the remote tenant and address spaces within any other VNets
already connected to the parent virtual hub.
Assign permissions
For the parent subscription with the virtual hub to modify and access the virtual networks in the remote
tenant, you need to assign Contributor permissions to your parent subscription from the remote tenant
subscription.
●● Add the Contributor role assignment to the parent account (the one with the virtual WAN hub). You
can use PowerShell or the Azure portal to assign this role.
●● Add the remote tenant subscription and the parent tenant subscription to the current session of
PowerShell by running the Add-AzAccount command. If you are signed into the parent, you only need
to run the command for the remote tenant.
●● Verify that the role assignment is successful by logging into Azure PowerShell using the parent
credentials and running the Get-AzSubscription command. If the permissions have successfully
98
propagated to the parent and have been added to the session, the output of the command will list
the subscription owned by the remote tenant.
Virtual Hub routing

The routing capabilities in a virtual hub are provided by a router that manages all routing between
gateways using Border Gateway Protocol (BGP). A virtual hub can contain multiple gateways such as a
Site-to-site VPN gateway, ExpressRoute gateway, Point-to-site gateway, Azure Firewall. This router also
provides transit connectivity between virtual networks that connect to a virtual hub and can support up
to an aggregate throughput of 50 Gbps. These routing capabilities apply to Standard Virtual WAN
customers.
To learn more about how to configure routing, see How to configure virtual hub routing7.
Hub route table

A virtual hub route table can contain one or more routes. A route includes its name, a label, a destination
type, a list of destination prefixes, and next hop information for a packet to be routed. A Connection
typically will have a routing configuration that associated or propagates to a route table.
Connections
Connections are Resource Manager resources that have a routing configuration. The four types of
connections are:
●● VPN connection: Connects a VPN site to a virtual hub VPN gateway.
●● ExpressRoute connection: Connects an ExpressRoute circuit to a virtual hub ExpressRoute gateway.
●● P2S configuration connection: Connects a User VPN (Point-to-site) configuration to a virtual hub User
VPN (Point-to-site) gateway.
●● Hub virtual network connection: Connects virtual networks to a virtual hub.
You can set up the routing configuration for a virtual network connection during setup. By default, all
connections associate and propagate to the Default route table.
Association
Each connection is associated to one route table. Associating a connection to a route table allows the
traffic to be sent to the destinations indicated as routes in the route table. The routing configuration of
the connection will show the associated route table. Multiple connections can be associated to the same
route table. All VPN, ExpressRoute, and User VPN connections are associated to the same (default) route
table.
By default, all connections are associated to a Default route table in a virtual hub. Each virtual hub has its
own Default route table, which can be edited to add a static route(s). Routes added statically take
precedence over dynamically learned routes for the same prefixes.
7 https://docs.microsoft.com/en-us/azure/virtual-wan/how-to-virtual-hub-routing
99
Propagation
Connections dynamically propagate routes to a route table. With a VPN connection, ExpressRoute
connection, or P2S configuration connection, routes are propagated from the virtual hub to the on-prem-
ises router using BGP. Routes can be propagated to one or multiple route tables.
A None route table is also available for each virtual hub. Propagating to the None route table implies that
no routes are required to be propagated from the connection. VPN, ExpressRoute, and User VPN connec-
tions propagate routes to the same set of route tables.
Labels
Labels provide a mechanism to logically group route tables. This is especially helpful during propagation
of routes from connections to multiple route tables. For example, the Default Route Table has a built-in
100
label called ‘Default’. When users propagate connection routes to 'Default' label, it automatically applies
to all the Default Route Tables across every hub in the Virtual WAN.
Configuring static routes in a virtual network connection

Configuring static routes provides a mechanism to steer traffic through a next hop IP, which could be of a
Network Virtual Appliance (NVA) provisioned in a Spoke VNet attached to a virtual hub. The static route
is composed of a route name, list of destination prefixes, and a next hop IP.
Route tables for pre-existing routes

Route tables now have features for association and propagation. A pre-existing route table is a route
table that does not have these features. If you have pre-existing routes in hub routing and would like to
use the new capabilities, consider the following:
●● Standard Virtual WAN Customers with pre-existing routes in virtual hub: If you have pre-existing
routes in Routing section for the hub in Azure portal, you will need to first delete them and then
attempt creating new route tables (available in the Route Tables section for the hub in Azure portal).
●● Basic Virtual WAN Customers with pre-existing routes in virtual hub: If you have pre-existing
routes in Routing section for the hub in Azure portal, you will need to first delete them, then upgrade
your Basic Virtual WAN to Standard Virtual WAN.
Troubleshooting failed resources by using a hub reset

Virtual Hub Reset is available only in the Azure portal. Resetting provides you a way to bring any failed
resources such as route tables, hub router, or the virtual hub resource itself back to its rightful provision-
ing state. Consider resetting the hub prior to contacting Microsoft for support. This operation does not
reset any of the gateways in a virtual hub.
Multiple choice
What is an Azure Virtual WAN?
Azure Virtual WAN is a collection of connectivity resources like VPNs, which enables organizations to
use the Microsoft backbone. {{Correct, Azure Virtual WAN is a centrally managed collection of connec-
tivity resources like VPNs, which enables organizations to use the Microsoft backbone in a self-con-
tained, security isolated manner.}}
Azure WAN describes two or more VNets connected through peering. {{Incorrect, Azure WAN con-
nects VNets, on-premises networks and individual computers to the Microsoft backbone.}}
Azure WAN is a collection of on-premises networks connected to each other through VPNs. {{Incor-
rect, Azure WAN connects VNets, on-premises networks and individual computers to the Microsoft
backbone.}}
101
Multiple choice
What is the purpose of associating a connection to a route table?
Associating a connection to a route table allows the traffic to be sent to the destinations indicated as
routes in the route table. {{Correct, Associating a connection to a route table allows the traffic to be
sent to the destination indicated as routes in the route table. Each connection is associated to one
route table.}}
Associating a connection to a route table allows the connection to dynamically propagate routes to
other route tables. {{Incorrect, Connections dynamically propagate routes to a specified route table.}}
Associating a connection to a route table allows users to be authenticated. {{Incorrect, Users are not
authenticated using route tables.}}
7-Exercise: create a Virtual WAN by using the

Azure portal
In this exercise, you will create a Virtual WAN for Contoso.
●● Task 1: Create a Virtual WAN
●● Task 2: Create a hub by using Azure portal
●● Task 3: Connect a VNet to the Virtual Hub
Task 1: Create a Virtual WAN

1. From a browser, navigate to the Azure portal and sign in with your Azure account.
2. In the portal, type Virtual WAN into the search box and select Virtual WANs from the results list.
102
3. On the Virtual WAN page, select + Create.

4. On the Create WAN page, on the Basics tab, fill in the following fields:
●● Subscription: Use the existing subscription
●● Resource group: ContosoResourceGroup
●● Resource group location: Choose a resource location from the dropdown. A WAN is a global
resource and does not live in a particular region. However, you must select a region to manage
and locate the WAN resource that you create.
●● Name: ContosoVirtualWAN
●● Type: Standard
5. When you have finished filling out the fields, select Review +Create.
6. Once validation passes, select Create to create the Virtual WAN.
Task 2: Create a hub by using Azure portal

A hub contains gateways for site-to-site, ExpressRoute, or point-to-site functionality. It takes 30 minutes
to create the site-to-site VPN gateway in the virtual hub. You must create a Virtual WAN before you can
create a hub.
1. Locate the Virtual WAN that you created.
2. On the Virtual WAN page, under Connectivity, select Hubs.
103
3. On the Hubs page, select +New Hub to open the Create virtual hub page.
4. On the Create virtual hub page Basics tab, complete the following fields:
●● Region: West US
●● Name: ContosoVirtualWANHub-WestUS
●● Hub private address space: 10.60.0.0/24
5. Select Next: Site-to-site.
6. On the Site-to-site tab, complete the following fields:
●● Do you want to create a Site to site (VPN gateway)?: Yes
●● The AS Number field cannot be edited.
●● Gateway scale units: 1 scale unit = 500 Mbps
7. Select Review + Create to validate.
8. Select Create to create the hub.
9. After 30 minutes, Refresh to view the hub on the Hubs page.
104
Task 3: Connect a VNet to the Virtual Hub

1. Locate the Virtual WAN that you created.
2. In ContosoVirtualWAN, under Connectivity, select Virtual network connections.
3. On ContosoVirtualWAN | Virtual network connections, select + Add connection.

4. In Add connection, use the following information to create the connection.
●● Connection name: ContosoVirtualWAN-to-ResearchVNet
●● Hubs: ContosoVirtualWANHub-WestUS
●● Subscription: no changes
●● Resource Group: ContosoResourceGroup
●● Virtual network: ResearchVNet
●● Propagate to none: Yes
●● Associate Route Table: Default
5. Select Create.
Congratulations! You have created a Virtual WAN and a Virtual WAN Hub and connected the Research-
VNet to the hub.

command:
105
Note: The command executes asynchronously (as determined by the -AsJob parameter), so while you will
be able to run another PowerShell command immediately afterwards within the same PowerShell session,
it will take a few minutes before the resource groups are actually removed.
8-Create a network virtual appliance (NVA) in a

virtual hub
One of the benefits of Azure Virtual WAN is the ability to support reliable connections from many
different technologies, whether Microsoft based, such as ExpressRoute or a VPN Gateway, or from a
networking partner, such as Barracuda CloudGen WAN, Cisco Cloud OnRamp for Multi-Cloud, and
VMware SD-WAN. These types of devices are known as network virtual appliances (NVAs); they are
deployed directly into a Virtual WAN hub and have an externally facing public IP address. This enables
customers who want to connect their branch Customer Premises Equipment (CPE) to the same brand
NVA in the virtual hub to take advantage of proprietary end-to-end SD-WAN capabilities. Once VNets are
connected to the virtual hub, NVAs enable transitive connectivity throughout the organization's Virtual
WAN.
Manage an NVA in a Virtual Hub

The NVAs available in the Azure Marketplace are designed to be deployed directly into a virtual hub and
nowhere else. Each is deployed as a Managed Application, which allows Azure Virtual WAN to manage
the configuration of the NVA. They cannot be deployed within an arbitrary VNet.
The following diagram shows the NVA deployment process:
Although each NVA offers support for different CPEs and has a slightly different user experience, they all
offer a Managed Application experience through Azure Marketplace, NVA Infrastructure Unit-based
capacity and billing, and Health Metrics surfaced through Azure Monitor.
Deploy an NVA in your Virtual Hub

To deploy an NVA in your virtual hub, you can access the Azure Marketplace through the Azure portal
and select the Managed Application for the NVA partner that you need to enable connectivity for your
106
devices. When you create an NVA in the Virtual WAN hub, like all Managed Applications, there will be two
Resource Groups created in your subscription.
●● Customer Resource Group - This will contain an application placeholder for the Managed Applica-
tion. Partners can use this to expose whatever customer properties they choose here.
●● Managed Resource Group - Customers cannot configure or change resources in this resource group
directly, as this is controlled by the publisher of the Managed Application. This Resource Group will
contain the NetworkVirtualAppliances resource.
The NVA is configured automatically as part of the deployment process. Once the NVA has been provi-
sioned into the virtual hub, any additional configuration must be performed via the NVA partners portal
or management application. You cannot access the NVA directly.
Unlike Azure VPN Gateway configurations, you do not need to create Site resources, Site-to-Site connec-
tion resources, or point-to-site connection resources to connect your branch sites to your NVA in the
Virtual WAN hub. This is all managed via the NVA partner.
You still need to create Hub-to-VNet connections to connect your Virtual WAN hub to your Azure VNets.
Create the Network Virtual Appliance in the hub

In this step, you will create a Network Virtual Appliance in the hub. The procedure for each NVA will be
different for each NVA partner's product. For this example, we are creating a Barracuda CloudGen WAN
Gateway.
1. Locate the Virtual WAN hub you created in the previous step and open it.
2. Find the Network Virtual Appliances tile and select the Create link.
107
3. On the Network Virtual Appliance blade, select Barracuda CloudGen WAN, then select the Create
button.
4. This will take you to the Azure Marketplace offer for the Barracuda CloudGen WAN gateway. Read the
terms, then select the Create button when you're ready.

5. On the Basics page you will need to provide the following information:
●● Subscription - Choose the subscription you used to deploy the Virtual WAN and hub.
108
●● Resource Group - Choose the same Resource Group you used to deploy the Virtual WAN and
hub.
●● Region - Choose the same Region in which your Virtual hub resource is located.
●● Application Name - The Barracuda NextGen WAN is a Managed Application. Choose a name that
makes it easy to identify this resource, as this is what it will be called when it appears in your
subscription.
●● Managed Resource Group - This is the name of the Managed Resource Group in which Barracuda
will deploy resources that are managed by them. The name should be pre-populated for this.
6. Select the Next: CloudGen WAN gateway button.

7. Provide the following information here:
●● Virtual WAN Hub - The Virtual WAN hub you want to deploy this NVA into.
●● NVA Infrastructure Units - Indicate the number of NVA Infrastructure Units you want to deploy
this NVA with. Choose the amount of aggregate bandwidth capacity you want to provide across all
of the branch sites that will be connecting to this hub through this NVA.
●● Token - Barracuda requires that you provide an authentication token here in order to identify
yourself as a registered user of this product. You'll need to obtain this from Barracuda.
NVA Infrastructure Units

When you create an NVA in the Virtual WAN hub, you must choose the number of NVA Infrastructure
Units you want to deploy it with. An NVA Infrastructure Unit is a unit of aggregate bandwidth capacity for
109
an NVA in the Virtual WAN hub. An NVA Infrastructure Unit is similar to a VPN Scale Unit in terms of the
way you think about capacity and sizing.
●● 1 NVA Infrastructure Unit represents 500 Mbps of aggregate bandwidth for all branch site connec-
tions coming into this NVA.
●● Azure supports from 1-80 NVA Infrastructure Units for a given NVA virtual hub deployment.
●● Each partner may offer different NVA Infrastructure Unit bundles that are a subset of all supported
NVA Infrastructure Unit configurations.
To learn more about deploying an NVA, see How to create a Network Virtual Appliance in an Azure
Virtual WAN hub (Preview)8.
Multiple choice
A network engineer wants to provide VMware SD-WAN connectivity for their clients. Which Azure resource
should they deploy?
Network Virtual Appliance (NVA). {{Correct, Azure Virtual WAN supports connections from networking
partners, such as VMware SD-WAN. These types of devices are known as network virtual appliances
(NVAs).}}
Point-to-site VPN Gateway {{Incorrect, A point-to-site VPN Gateway supports connections from
individual computers.}}
Local network gateway {{Incorrect, A local network gateway represents the on-premises network.}}
Multiple choice
Where can an NVA be deployed?
NVAs are deployed directly into a Virtual WAN hub. {{Correct, NVAs are deployed directly into a
Virtual WAN hub and have an externally facing public IP address.}}
NVAs are deployed into an on-premises subnet. {{Incorrect, NVAs are not deployed into an on-prem-
ises subnet.}}
NVAs are deployed into a security-isolated subnet. {{Incorrect, NVAs do not require security isolation.}}
9-Summary
As your organization moves to Azure, you must design and implement a hybrid connectivity solution that
will address the short term and long-term goals of the organization's global enterprise IT footprint.
In this module you learned about three ways to connect your on premises data center and remote users
to an Azure virtual network.
You now have the fundamental knowledge required to design and implement hybrid networking in
Azure.
●● Design and implement a site-to-site VPN connection
8 https://docs.microsoft.com/en-us/azure/virtual-wan/how-to-nva-hub
110
●● Design and implement a point-to-site VPN connection

●● Design and implement authentication for point-to-site VPN connections
●● Design and implement Azure Virtual WAN
111
Answers
Multiple choice
What are the two types of VPNs?
■■ PolicyBased and RouteBased. {{Correct, VPNs can be RouteBased or PolicyBased.}}
PolicyBased and static. {{Incorrect, VPNs can be PolicyBased. Static is the name used for PolicyBased
VPNs in the classic deployment model.}}
RouteBased and dynamic. {{Incorrect, VPNs can be RouteBased. Dynamic is the name used for Route-
Based VPNs in the classic deployment model.}}
Explanation
Multiple choice
What is the default high availability configuration for VPN gateways?
■■ Active-standby {{Correct, Every Azure VPN gateway consists of two instances in an active-standby
configuration.}}
Active-active {{Incorrect, You can create an Azure VPN gateway in an active-active configuration, but
this is not the default.}}
Dual-redundancy {{Incorrect, This is the most reliable option, combining the active-active gateways on
both your network and Azure, but it is not the default.}}
Explanation
Multiple choice
What is a site-to-site VPN Gateway connection?
■■ A site-to-site VPN Gateway connection securely connects two networks. {{Correct, A site-to-site (S2S)
VPN gateway connection lets you create a secure connection to your virtual network from another
virtual network or a physical network.}}
A site-to-site VPN Gateway connection securely connects an individual client computer to a network.
{{Incorrect, A point-to-site (P2S) VPN gateway connection lets you create a secure connection to your
virtual network from an individual client computer.}}
A site-to-site VPN Gateway connection securely connects two individual computers. {{Incorrect, A
site-to-site (S2S)VPN gateway connection does not connect two individual computers.}}
Explanation
Multiple choice
To authenticate a user connecting through a point-to-site connection using Active Directory Domain
Server, what type of server is required?
■■ RADIUS {{Correct, AD Domain authentication allows users to connect to Azure using their organization
domain credentials. It requires a RADIUS server that integrates with the AD server.}}
Active Directory Domain Controller only {{Incorrect, An Active Directory Domain Controller alone is
not sufficient. Another type of server is required.}}
DNS server {{Incorrect, A DNS server may be required for name resolution, but it is not sufficient for
authentication.}}
Explanation
112
Multiple choice
What is an Azure Virtual WAN?
■■ Azure Virtual WAN is a collection of connectivity resources like VPNs, which enables organizations to
use the Microsoft backbone. {{Correct, Azure Virtual WAN is a centrally managed collection of connec-
tivity resources like VPNs, which enables organizations to use the Microsoft backbone in a self-con-
tained, security isolated manner.}}
Azure WAN describes two or more VNets connected through peering. {{Incorrect, Azure WAN con-
nects VNets, on-premises networks and individual computers to the Microsoft backbone.}}
Azure WAN is a collection of on-premises networks connected to each other through VPNs. {{Incor-
rect, Azure WAN connects VNets, on-premises networks and individual computers to the Microsoft
backbone.}}
Explanation
Multiple choice
What is the purpose of associating a connection to a route table?
■■ Associating a connection to a route table allows the traffic to be sent to the destinations indicated as
routes in the route table. {{Correct, Associating a connection to a route table allows the traffic to be
sent to the destination indicated as routes in the route table. Each connection is associated to one
route table.}}
Associating a connection to a route table allows the connection to dynamically propagate routes to
other route tables. {{Incorrect, Connections dynamically propagate routes to a specified route table.}}
Associating a connection to a route table allows users to be authenticated. {{Incorrect, Users are not
authenticated using route tables.}}
Explanation
Multiple choice
A network engineer wants to provide VMware SD-WAN connectivity for their clients. Which Azure
resource should they deploy?
■■ Network Virtual Appliance (NVA). {{Correct, Azure Virtual WAN supports connections from networking
partners, such as VMware SD-WAN. These types of devices are known as network virtual appliances
(NVAs).}}
Point-to-site VPN Gateway {{Incorrect, A point-to-site VPN Gateway supports connections from
individual computers.}}
Local network gateway {{Incorrect, A local network gateway represents the on-premises network.}}
Explanation
Multiple choice
Where can an NVA be deployed?
■■ NVAs are deployed directly into a Virtual WAN hub. {{Correct, NVAs are deployed directly into a
Virtual WAN hub and have an externally facing public IP address.}}
NVAs are deployed into an on-premises subnet. {{Incorrect, NVAs are not deployed into an on-prem-
ises subnet.}}
NVAs are deployed into a security-isolated subnet. {{Incorrect, NVAs do not require security isolation.}}
Explanation
Module 3 Design and implement Azure Ex-
pressRoute
Design and implement Azure ExpressRoute

1-Introduction
ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a private connec-
tion with the help of a connectivity provider. With ExpressRoute, you can establish connections to various
Microsoft cloud services, such as Microsoft Azure and Microsoft 365. Connectivity can be from an
any-to-any (IP VPN) network, a point-to-point Ethernet network, or a virtual cross-connection through a
connectivity provider at a colocation facility. Since ExpressRoute connections do not go over the public
Internet, this approach allows ExpressRoute connections to offer more reliability, faster speeds, consistent
latencies, and higher security.
Learning objectives
●● Learn about Express Route and how to design your network with ExpressRoute
●● Learn about Express Route configuration choices and how to decide on the appropriate SKU based on
your requirements
●● Learn about ExpressRoute Global Reach
●● Explore Express Route FastPath
●● Understand Express Route peering, Private and Microsoft peering
Prerequisites
(DNS), and routing
114
●● You should be able to navigate the Azure portal

2-Explore Azure ExpressRoute
ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a private connec-
tion with the help of a connectivity provider. With ExpressRoute, you can establish connections to various
Microsoft cloud services, such as Microsoft Azure and Microsoft 365. Connectivity can be from an
any-to-any (IP VPN) network, a point-to-point Ethernet network, or a virtual cross-connection through a
connectivity provider at a colocation facility. Since ExpressRoute connections do not go over the public
Internet, this approach allows ExpressRoute connections to offer more reliability, faster speeds, consistent
latencies, and higher security.
ExpressRoute capabilities
Some key benefits of ExpressRoute are:
●● Layer 3 connectivity between your on-premises network and the Microsoft Cloud through a connec-
tivity provider
●● Connectivity can be from an any-to-any (IPVPN) network, a point-to-point Ethernet connection, or
through a virtual cross-connection via an Ethernet exchange
●● Connectivity to Microsoft cloud services across all regions in the geopolitical region
●● Global connectivity to Microsoft services across all regions with the ExpressRoute premium add-on
●● Built-in redundancy in every peering location for higher reliability
Azure ExpressRoute is used to create private connections between Azure datacenters and infrastructure
on your premises or in a colocation environment. ExpressRoute connections do not go over the public
Internet, and they offer more reliability, faster speeds, and lower latencies than typical Internet connec-
tions.
Understand use cases for Azure ExpressRoute

Faster and Reliable connection to Azure services - Organizations leveraging Azure services look for
reliable connections to Azure services and data centers. Public internet is dependent upon many factors
and may not be suitable for a business. Azure ExpressRoute is used to create private connections be-
tween Azure data centers and infrastructure on your premises or in a colocation environment. Using
ExpressRoute connections to transfer data between on-premises systems and Azure can also give
significant cost benefits.
Storage, backup, and Recovery - Backup and Recovery are important for an organization for business
continuity and recovering from outages. ExpressRoute gives you a fast and reliable connection to Azure
with bandwidths up to 100 Gbps, which makes it excellent for scenarios such as periodic data migration,
replication for business continuity, disaster recovery and other high-availability strategies.
Extends Data center capabilities - ExpressRoute can be used to connect and add compute and storage
capacity to your existing data centers. With high throughput and fast latencies, Azure will feel like a
natural extension to or between your data centers, so you enjoy the scale and economics of the public
cloud without having to compromise on network performance.
115
Predictable, reliable, and high-throughput connections - With predictable, reliable, and high-through-
put connections offered by ExpressRoute, enterprises can build applications that span on-premises
infrastructure and Azure without compromising privacy or performance. For example, run a corporate
intranet application in Azure that authenticates your customers with an on-premises Active Directory
service, and serve all your corporate customers without traffic ever routing through the public Internet.
ExpressRoute connectivity models

You can create a connection between your on-premises network and the Microsoft cloud in four different
ways, CloudExchange Co-location, Point-to-point Ethernet Connection, Any-to-any (IPVPN) Connection,
and ExpressRoute Direct. Connectivity providers may offer one or more connectivity models.
Co-located at a cloud exchange

If you are co-located in a facility with a cloud exchange, you can order virtual cross-connections to the
Microsoft cloud through the co-location provider’s Ethernet exchange. Co-location providers can offer
either Layer 2 cross-connections, or managed Layer 3 cross-connections between your infrastructure in
the co-location facility and the Microsoft cloud.
Point-to-point Ethernet connections
You can connect your on-premises datacenters/offices to the Microsoft cloud through point-to-point
Ethernet links. Point-to-point Ethernet providers can offer Layer 2 connections, or managed Layer 3
connections between your site and the Microsoft cloud.
Any-to-any (IPVPN) networks
You can integrate your WAN with the Microsoft cloud. IPVPN providers (typically MPLS VPN) offer
any-to-any connectivity between your branch offices and datacenters. The Microsoft cloud can be
interconnected to your WAN to make it look just like any other branch office. WAN providers typically
offer managed Layer 3 connectivity.
Direct from ExpressRoute sites
You can connect directly into the Microsoft's global network at a peering location strategically distributed
across the world. ExpressRoute Direct provides dual 100 Gbps or 10-Gbps connectivity, which supports
Active/Active connectivity at scale.
116
Design considerations for ExpressRoute deployments

When planning an ExpressRoute deployment, there many decisions to make. This section discusses a few
key areas that you must consider as you design your deployment.
Choose between provider and direct model (ExpressRoute

Direct)
ExpressRoute Direct
ExpressRoute Direct gives you the ability to connect directly into Microsoft’s global network at peering
locations strategically distributed around the world. ExpressRoute Direct provides dual 100 Gbps or
10-Gbps connectivity, which supports Active/Active connectivity at scale. You can work with any service
provider for ExpressRoute Direct.
Key features that ExpressRoute Direct provides includes:
●● Massive Data Ingestion into services like Storage and Cosmos DB
●● Physical isolation for industries that are regulated and require dedicated and isolated connectivity like:
Banking, Government, and Retail
●● Granular control of circuit distribution based on business unit
Using ExpressRoute direct vs using a Service Provider
ExpressRoute using a Service Provider ExpressRoute Direct

Uses service providers to enable fast onboarding Requires 100 Gbps/10 Gbps infrastructure and full
and connectivity into existing infrastructure management of all layers
Integrates with hundreds of providers including Direct/Dedicated capacity for regulated industries
Ethernet and MPLS and massive data ingestion
Circuits SKUs from 50 Mbps to 10 Gbps Customer may select a combination of the
following circuit SKUs on 100-Gbps ExpressRoute
Direct: 5 Gbps 10 Gbps 40 Gbps 100 Gbps Cus-
tomer may select a combination of the following
circuit SKUs on 10-Gbps ExpressRoute Direct: 1
Gbps 2 Gbps 5 Gbps 10 Gbps
Optimized for single tenant Optimized for single tenant with multiple business
units and multiple work environments
Route advertisement
When Microsoft peering gets configured on your ExpressRoute circuit, the Microsoft Edge routers
establish a pair of Border Gateway Protocol (BGP) sessions with your edge routers through your connec-
tivity provider. No routes are advertised to your network. To enable route advertisements to your net-
work, you must associate a route filter.
In order to associate a route filter:
●● You must have an active ExpressRoute circuit that has Microsoft peering provisioned.
●● Create an ExpressRoute circuit and have the circuit enabled by your connectivity provider before you
continue. The ExpressRoute circuit must be in a provisioned and enabled state.
●● Create Microsoft peering if you manage the BGP session directly. Or, have your connectivity provider
provision Microsoft peering for your circuit.
117
Get a list of BGP community values

BGP community values associated with services accessible through Microsoft peering is available in the
ExpressRoute routing requirements1 page.
Make a list of the values that you want to use
Make a list of BGP community values2 you want to use in the route filter.
Bidirectional Forwarding Detection

ExpressRoute supports Bidirectional Forwarding Detection (BFD) both over private and Microsoft peering.
When you enable BFD over ExpressRoute, you can speed up the link failure detection between Microsoft
Enterprise edge (MSEE) devices and the routers that your ExpressRoute circuit gets configured (CE/PE).
You can configure ExpressRoute over your edge routing devices or your Partner Edge routing devices (if
you went with managed Layer 3 connection service). This section walks you through the need for BFD,
and how to enable BFD over ExpressRoute.
You can enable ExpressRoute circuit either by Layer 2 connections or managed Layer 3 connections. In
both cases, if there are more than one Layer-2 devices in the ExpressRoute connection path, the responsi-
bility of detecting any link failures in the path lies with the overlying BGP session.
On the MSEE devices, BGP keep-alive and hold-time are typically configured as 60 and 180 seconds,
respectively. For that reason, when a link failure happens it can take up to three minutes to detect any
link failure and switch traffic to alternate connection.
You can control the BGP timers by configuring a lower BGP keep-alive and hold-time on your edge
peering device. If the BGP timers are not the same between the two peering devices, the BGP session will
establish using the lower time value. The BGP keep-alive can be set as low as three seconds, and the
hold-time as low as 10 seconds. However, setting a very aggressive BGP timer isn't recommended
because the protocol is process intensive.
In this scenario, BFD can help. BFD provides low-overhead link failure detection in a sub second time
interval.
The following diagram shows the benefit of enabling BFD over an ExpressRoute circuit:
Enabling BFD
1 https://docs.microsoft.com/en-us/azure/expressroute/expressroute-routing
2 https://docs.microsoft.com/en-us/azure/expressroute/expressroute-routing
118
BFD is configured by default under all the newly created ExpressRoute private peering interfaces on the
MSEEs. As such, to enable BFD, you only need to configure BFD on both your primary and secondary
devices. Configuring BFD is two-step process. You configure the BFD on the interface and then link it to
the BGP session.
When you disable a peering, the Border Gateway Protocol (BGP) session for both the primary and the
secondary connection of your ExpressRoute circuit is shut down. When you enable a peering, the BGP
session on both the primary and the secondary connection of your ExpressRoute circuit is restored.
[!NOTE]
The first time you configure the peering on your ExpressRoute circuit, the Peerings are enabled by
default.
Resetting your ExpressRoute Peerings might be helpful in the following scenarios:
You are testing your disaster recovery design and implementation. For example, assume that you have
two ExpressRoute circuits. You can disable the Peerings of one circuit and force your network traffic to
use the other circuit.
You want to enable Bidirectional Forwarding Detection (BFD) on Azure private peering or Microsoft
peering. If your ExpressRoute circuit was created before August 1, 2018, on Azure private peering or
before January 10, 2020, on Microsoft peering, BFD was not enabled by default. Reset the peering to
enable BFD.
Configure encryption over ExpressRoute

This section shows you how to use Azure Virtual WAN to establish an IPsec/IKE VPN connection from
your on-premises network to Azure over the private peering of an Azure ExpressRoute circuit. This
technique can provide an encrypted transit between the on-premises networks and Azure virtual net-
works over ExpressRoute, without going over the public internet or using public IP addresses.
Topology and routing
The following diagram shows an example of VPN connectivity over ExpressRoute private peering:
The diagram shows a network within the on-premises network connected to the Azure hub VPN gateway
over ExpressRoute private peering. The connectivity establishment is straightforward:
●● Establish ExpressRoute connectivity with an ExpressRoute circuit and private peering.
●● Establish the VPN connectivity.
An important aspect of this configuration is routing between the on-premises networks and Azure over
both the ExpressRoute and VPN paths.
Traffic from on-premises networks to Azure
For traffic from on-premises networks to Azure, the Azure prefixes (including the virtual hub and all the
spoke virtual networks connected to the hub) are advertised via both the ExpressRoute private peering
119
BGP and the VPN BGP. This results in two network routes (paths) toward Azure from the on-premises
networks:
●● One over the IPsec-protected path
●● One directly over ExpressRoute without IPsec protection
To apply encryption to the communication, you must make sure that for the VPN-connected network in
the diagram, the Azure routes via on-premises VPN gateway are preferred over the direct ExpressRoute
path.
Traffic from Azure to on-premises networks
The same requirement applies to the traffic from Azure to on-premises networks. To ensure that the IPsec
path is preferred over the direct ExpressRoute path (without IPsec), you have two options:
●● Advertise more specific prefixes on the VPN BGP session for the VPN-connected network. You can
advertise a larger range that encompasses the VPN-connected network over ExpressRoute private
peering, then more specific ranges in the VPN BGP session. For example, advertise 10.0.0.0/16 over
ExpressRoute, and 10.0.1.0/24 over VPN.
●● Advertise disjoint prefixes for VPN and ExpressRoute. If the VPN-connected network ranges are
disjoint from other ExpressRoute connected networks, you can advertise the prefixes in the VPN and
ExpressRoute BGP sessions, respectively. For example, advertise 10.0.0.0/24 over ExpressRoute, and
10.0.1.0/24 over VPN.
In both examples, Azure will send traffic to 10.0.1.0/24 over the VPN connection rather than directly over
ExpressRoute without VPN protection.
[!WARNING]
If you advertise the same prefixes over both ExpressRoute and VPN connections, Azure will use the
ExpressRoute path directly without VPN protection.
Design redundancy for an ExpressRoute deployment

There are 2 ways in which redundancy can be planned for an ExpressRoute deployment.
●● Configure ExpressRoute and site to site coexisting connections
●● Create a zone redundant VNET gateway in Azure Availability zones
Configure ExpressRoute and site to site coexisting connec-

tions
This section helps you configure ExpressRoute and Site-to-Site VPN connections that coexist. Having the
ability to configure Site-to-Site VPN and ExpressRoute has several advantages. You can configure Site-to-
Site VPN as a secure failover path for ExpressRoute or use Site-to-Site VPNs to connect to sites that are
not connected through ExpressRoute.
Configuring Site-to-Site VPN and ExpressRoute coexisting connections has several advantages:
●● You can configure a Site-to-Site VPN as a secure failover path for ExpressRoute.
●● Alternatively, you can use Site-to-Site VPNs to connect to sites that are not connected through
ExpressRoute.
You can configure either gateway first. Typically, you will incur no downtime when adding a new gateway
or gateway connection.
120
Network Limits and limitations

●● Only route-based VPN gateway is supported. You must use a route-based VPN gateway. You also
can use a route-based VPN gateway with a VPN connection configured for ‘policy-based traffic
selectors’.
●● The ASN of Azure VPN Gateway must be set to 65515. Azure VPN Gateway supports the BGP
routing protocol. For ExpressRoute and Azure VPN to work together, you must keep the Autonomous
System Number of your Azure VPN gateway at its default value, 65515. If you previously selected an
ASN other than 65515 and you change the setting to 65515, you must reset the VPN gateway for the
setting to take effect.
●● The gateway subnet must be /27 or a shorter prefix, (such as /26, /25), or you will receive an error
message when you add the ExpressRoute virtual network gateway.
●● Coexistence in a dual stack VNet is not supported. If you are using ExpressRoute IPv6 support and
a dual-stack ExpressRoute gateway, coexistence with VPN Gateway will not be possible.
Create a zone redundant VNet gateway in Azure availability

zones
You can deploy VPN and ExpressRoute gateways in Azure Availability Zones3. This brings resiliency,
scalability, and higher availability to virtual network gateways. Deploying gateways in Azure Availability
Zones physically and logically separates gateways within a region, while protecting your on-premises
network connectivity to Azure from zone-level failures.
Zone-redundant gateways
To automatically deploy your virtual network gateways across availability zones, you can use zone-redun-
dant virtual network gateways. With zone-redundant gateways, you can benefit from zone-resiliency to
access your mission-critical, scalable services on Azure.
Zonal gateways
3 https://docs.microsoft.com/en-us/azure/availability-zones/az-overview
121
To deploy gateways in a specific zone, you can use zonal gateways. When you deploy a zonal gateway, all
instances of the gateway are deployed in the same Availability Zone.
Gateway SKUs
Zone-redundant and zonal gateways are available as gateway SKUs. There is a new virtual network
gateway SKUs in Azure AZ regions. These SKUs are like the corresponding existing SKUs for ExpressRoute
and VPN Gateway, except that they are specific to zone-redundant and zonal gateways. You can identify
these SKUs by the “AZ” in the SKU name.
Public IP SKUs
Zone-redundant gateways and zonal gateways both rely on the Azure public IP resource Standard SKU.
The configuration of the Azure public IP resource determines whether the gateway that you deploy is
zone-redundant, or zonal. If you create a public IP resource with a Basic SKU, the gateway will not have
any zone redundancy, and the gateway resources will be regional.
●● Zone-redundant gateways
●● When you create a public IP address using the Standard public IP SKU without specifying a zone,
the behavior differs depending on whether the gateway is a VPN gateway, or an ExpressRoute
gateway.
●● For a VPN gateway, the two gateway instances will be deployed in any 2 out of these three zones
to provide zone-redundancy.
●● For an ExpressRoute gateway, since there can be more than two instances, the gateway can span
across all the three zones.
●● Zonal gateways
●● When you create a public IP address using the Standard public IP SKU and specify the Zone (1, 2,
or 3), all the gateway instances will be deployed in the same zone.
●● Regional gateways
●● When you create a public IP address using the Basic public IP SKU, the gateway is deployed as a
regional gateway and does not have any zone-redundancy built into the gateway.
122
Configure a Site-to-Site VPN as a failover path for Ex-

pressRoute
You can configure a Site-to-Site VPN connection as a backup for ExpressRoute. This connection applies
only to virtual networks linked to the Azure private peering path. There is no VPN-based failover solution
for services accessible through Azure Microsoft peering. The ExpressRoute circuit is always the primary
link. Data flows through the Site-to-Site VPN path only if the ExpressRoute circuit fails. To avoid asym-
metrical routing, your local network configuration should also prefer the ExpressRoute circuit over the
Site-to-Site VPN. You can prefer the ExpressRoute path by setting higher local preference for the routes
received the ExpressRoute.
[!Note]
If you have ExpressRoute Microsoft Peering enabled, you can receive the public IP address of your Azure
VPN gateway on the ExpressRoute connection. To set up your site-to-site VPN connection as a backup,
you must configure your on-premises network so that the VPN connection is routed to the Internet.
[!Note]
While ExpressRoute circuit is preferred over Site-to-Site VPN when both routes are the same, Azure will
use the longest prefix match to choose the route towards the packet's destination.
Use cross-region connectivity to link multiple Express-

Route locations
There are various ways of designing and implementing ExpressRoute based on specific organizational
requirements.
ExpressRoute connections enable access to the following services:
●● Microsoft Azure services
●● Microsoft 365 services
Connectivity to all regions within a geopolitical region
You can connect to Microsoft in one of the peering locations and access regions within the geopolitical
region.
For example, if you connect to Microsoft in Amsterdam through ExpressRoute, you will have access to all
Microsoft cloud services hosted in Northern and Western Europe.
Global connectivity with ExpressRoute Premium
You can enable ExpressRoute Premium to extend connectivity across geopolitical boundaries. For exam-
ple, if you connect to Microsoft in Amsterdam through ExpressRoute, you will have access to all Microsoft
cloud services hosted in all regions across the world. You can also access services deployed in South
America or Australia the same way you access North and West Europe regions. National clouds are
excluded.
Local connectivity with ExpressRoute Local
You can transfer data cost-effectively by enabling the Local SKU. With Local SKU, you can bring your data
to an ExpressRoute location near the Azure region you want. With Local, Data transfer is included in the
ExpressRoute port charge.
Across on-premises connectivity with ExpressRoute Global Reach
123
You can enable ExpressRoute Global Reach to exchange data across your on-premises sites by connecting
your ExpressRoute circuits. For example, if you have a private data center in California connected to an
ExpressRoute circuit in Silicon Valley and another private data center in Texas connected to an Express-
Route circuit in Dallas. With ExpressRoute Global Reach, you can connect your private data centers
together through these two ExpressRoute circuits. Your cross-data-center traffic will traverse through
Microsoft's network.
Rich connectivity partner ecosystem
ExpressRoute has a constantly growing ecosystem of connectivity providers and systems integrator
partners. You can refer to ExpressRoute partners and peering locations4.
Connectivity to national clouds
Microsoft operates isolated cloud environments for special geopolitical regions and customer segments.
ExpressRoute Direct
ExpressRoute Direct provides customers the opportunity to connect directly into Microsoft’s global
network at peering locations strategically distributed across the world. ExpressRoute Direct provides dual
100-Gbps connectivity, which supports Active/Active connectivity at scale.
Multiple choice
Which one of the following is the most effective use of ExpressRoute?
Provide reliable and secure connectivity to Azure services.{{Correct. Azure ExpressRoute is used to
create private connections between Azure data centers, Azure services, and infrastructure on your
premises or in a colocation environment.}}
Connect your network to the public internet.{{Incorrect. Azure ExpressRoute isn't the most effective
way to connect your network to the public internet.}}
Connect data center services internal to an organization.{{Incorrect. Azure ExpressRoute isn't used to
connect data center services internal to an organization.}}
Multiple choice
What is the benefit of Bidirectional forwarding?
Bidirectional forwarding reduces the failure deduction time.{{Correct. Enabling BFD over an Express-
Route circuit can reduce the failure deduction time from a few tens of seconds to less than a second.}}
Bidirectional forwarding allows traffic to flow in both directions.{{Incorrect. Bidirectional forwarding
isn't concerned with normal traffic flow.}}
Bidirectional forwarding enables you to configure BGP keep-alive times of less than 3 seconds.
{{Incorrect. The BGP keep-alive can be set as low as three seconds, but this aggressive schedule isn't
recommended.}}
4 https://docs.microsoft.com/en-us/azure/expressroute/expressroute-locations
124
3-Design an ExpressRoute deployment
ExpressRoute enables us to connect on Premises to Azure services seamlessly. lets review some design
decisions you will make before deploying an ExpressRoute circuit.
ExpressRoute circuit SKUs

Azure ExpressRoute has three different circuit SKUs: Local5, Standard, and Premium6. The way you are
charged for your ExpressRoute usage varies between these three SKU types.
●● Local SKU - With Local SKU, you are automatically charged with an Unlimited data plan.
●● Standard and Premium SKU - You can select between a Metered or an Unlimited data plan. All
ingress data are free of charge except when using the Global Reach add-on.
[!Important]
Based on requirements of workloads and data plan, selection of SKU types can help optimize cost and
budget.
Explore pricing based on ExpressRoute SKU

SKU models have been discussed previously as Local, Standard and Premium. It is a good practice to
estimate costs before using Azure ExpressRoute as the price might affect your design decisions.
Use the Azure pricing calculator7 to estimate costs before you create an Azure ExpressRoute circuit.
1. On the left, select Networking, then select Azure ExpressRoute to begin.
2. Select the appropriate Zone depending on your peering location.
3. Then select the SKU, Circuit Speed, and the Data Plan you would like an estimate for.
4. In the Additional outbound data transfer, enter an estimate in GB of how much outbound data you
might use over the course of a month.
5. Lastly, you can add the Global Reach Add-on to the estimate.
Choose a peering location

Peering location is of importance when working with ExpressRoute.
[!Note]
Azure regions and ExpressRoute locations are two distinct and different concepts, understanding the
difference between the two is critical to exploring Azure hybrid networking connectivity.
Azure regions
Azure regions are global datacenters where Azure compute, networking and storage resources are
located. When creating an Azure resource, a customer needs to select a resource location. The resource
location determines which Azure datacenter (or availability zone) the resource is created in.
5 https://docs.microsoft.com/en-us/azure/expressroute/expressroute-faqs
6 https://docs.microsoft.com/en-us/azure/expressroute/expressroute-faqs
7 https://azure.microsoft.com/pricing/calculator/
125
ExpressRoute locations (Peering locations)

ExpressRoute locations (sometimes referred to as peering locations or meet-me-locations) are co-loca-
tion facilities where Microsoft Enterprise Edge (MSEE) devices are located. ExpressRoute locations are the
entry point to Microsoft's network – and are globally distributed, providing customers the opportunity to
connect to Microsoft's network around the world. These locations are where ExpressRoute partners and
ExpressRoute Direct customers issue cross connections to Microsoft's network. You would have access to
Azure services across all regions within a geopolitical region if you connected to at least one Express-
Route location within the geopolitical region.
Azure regions to ExpressRoute locations within a geopolitical region.
The following link provides a list of Azure regions to ExpressRoute locations8 within a geopolitical
region. This page is kept up to date with the latest ExpressRoute locations and providers.
ExpressRoute connectivity providers
The following link list's locations by service provider. This page is kept up to date with the latest available
providers by location, see Service providers by location9.
Connectivity through Exchange providers
If your connectivity provider is not listed in previous sections, you can still create a connection. Several
connectivity providers are already connected to Ethernet exchanges.
Connectivity through satellite operators
If you are remote and do not have fiber connectivity or want to explore other connectivity options, you
can check the following satellite operators.
Additional Connectivity options:
●● Through additional service providers
●● Datacenter providers
●● National Research and Education networks (NERN)
●● System integrators
Choose the right ExpressRoute circuit and billing model

Microsoft offers various Express Route options depending on the desired bandwidth of this private
connection between the customer on premises network and the selected Azure region. Typically, enter-
prises need to evaluate their current usage and determine how much data they use monthly to start with.
The next step is to figure out which of the available ExpressRoute is the best choice depending upon the
requirements of the Enterprise keeping in mind the budget and SLA requirements.
When you deploy ExpressRoute, you must choose between the Local, Standard and Premium SKUs. All
these options are available in a metered version, where you pay per used GB and an unlimited option.
The other option is the ExpressRoute Direct, connecting your network to the closest Microsoft Edge node
which then connects to the Microsoft Global Network, to connect to other customers offices or factories
and any Azure Region. The usage of the Microsoft Global Network is charged on top of the of the
ExpressRoute Direct.
8 https://docs.microsoft.com/azure/expressroute/expressroute-locations
9 https://docs.microsoft.com/azure/expressroute/expressroute-locations-providers
126
Please refer to the Express Route pricing10 for details on metered and unlimited data plan based on the
bandwidth.
you can purchase ExpressRoute circuits for a wide range of bandwidths. The supported bandwidths are
listed as followed. Be sure to check with your connectivity provider to determine the bandwidths they
support.
50 Mbps
100 Mbps
200 Mbps
500 Mbps
1 Gbps
2 Gbps
5 Gbps
10 Gbps
Choose a billing model

You can pick a billing model that works best for you. Choose between the billing models listed as fol-
lowed.
●● Unlimited data. Billing is based on a monthly fee; all inbound and outbound data transfer is included
free of charge.
●● Metered data. Billing is based on a monthly fee; all inbound data transfer is free of charge. Outbound
data transfer is charged per GB of data transfer. Data transfer rates vary by region.
●● ExpressRoute premium add-on. ExpressRoute premium is an add-on to the ExpressRoute circuit. The
ExpressRoute premium add-on provides the following capabilities:
●● Increased route limits for Azure public and Azure private peering from 4,000 routes to 10,000
routes.
●● Global connectivity for services. An ExpressRoute circuit created in any region (excluding national
clouds) will have access to resources across every other region in the world. For example, a virtual
network created in West Europe can be accessed through an ExpressRoute circuit provisioned in
Silicon Valley.
●● Increased number of VNet links per ExpressRoute circuit from 10 to a larger limit, depending on
the bandwidth of the circuit.
Multiple choice
Which of the following can be connected with ExpressRoute Premium?
Resources in different Geopolitical regions.{{Correct. You can enable ExpressRoute Premium to extend
connectivity across geopolitical boundaries. For example, if you connect to Microsoft in Amsterdam
10 https://azure.microsoft.com/pricing/details/expressroute/
127
through ExpressRoute, you'll have access to all Microsoft cloud services hosted in all regions across
the world.}}
Resources within local regions.{{Incorrect. Azure Premium can connect more than resources within
local regions.}}
Resources within a single metropolitan area only.{{Incorrect. Azure Premium can connect more than
resources within a single metropolitan area.}}
Multiple choice
How can one provide a failover path for ExpressRoute?
Configure a Site-to-Site VPN connection as a backup for ExpressRoute.{{Correct. You can configure a
Site-to-Site VPN connection as a backup for ExpressRoute. This connection applies only to virtual
networks linked to the Azure private peering path.}}
Configure a Point-to-Site VPN connection as a backup for ExpressRoute.{{Incorrect. A Point-to-Site
VPN connection will not function as a backup for ExpressRoute.}}
You cannot configure a backup path for ExpressRoute.{{Incorrect. It is possible to configure a backup
path for ExpressRoute.}}
4-Exercise: configure an ExpressRoute gateway

Note: To complete this exercise, you will need a Microsoft Azure subscription. If you don't already have
one, you can sign up for a free trial at https://azure.com/free .
Deploy ExpressRoute gateways

To connect your Azure virtual network and your on-premises network via ExpressRoute, you must create a
virtual network gateway first. A virtual network gateway serves two purposes: to exchange IP routes
between the networks and to route network traffic.
Gateway types
When you create a virtual network gateway, you need to specify several settings. One of the required
settings, ‘-GatewayType’, specifies whether the gateway is used for ExpressRoute, or VPN traffic. The two
gateway types are:
●● VPN - To send encrypted traffic across the public Internet, you use the gateway type ‘VPN’. This is also
referred to as a VPN gateway. Site-to-Site, Point-to-Site, and VNet-to-VNet connections all use a VPN
gateway.
●● ExpressRoute - To send network traffic on a private connection, you use the gateway type ‘Express-
Route’. This is also referred to as an ExpressRoute gateway and is the type of gateway used when
configuring ExpressRoute.
Each virtual network can have only one virtual network gateway per gateway type. For example, you can
have one virtual network gateway that uses -GatewayType VPN, and one that uses -GatewayType Ex-
pressRoute.
●● Task 1: Create the VNet and gateway subnet
●● Task 2: Create the virtual network gateway
128
Task 1: Create the VNet and gateway subnet

1. On any Azure portal page, in Search resources, services and docs, enter virtual network, and then
select Virtual networks from the results.
2. On the Virtual networks page, select +Create.
3. On the Create virtual networks pane, on the Basics tab, use the information in the following table to
create the VNet:
Setting Value
Virtual Network Name CoreServicesVNet
Resource Group ContosoResourceGroup
Location West US
4. Select Next : IP addresses.
5. On the IP Addresses tab, in IPv4 address space, remove the default and enter 10.20.0.0/16, and then
select + Add subnet.
6. In the Add subnet pane, use the information in the following table to create the subnet:
Setting Value
Gateway Subnet name GatewaySubnet
Gateway Subnet address space 10.20.0.0/27
7. And then select Add.
8. On the Create virtual network page, select Review + Create.
11
9. Confirm that the VNet passes the validation and then select Create.
Note: If you are using a dual stack virtual network and plan to use IPv6-based private peering over
ExpressRoute, click Add IP6 address space and input IPv6 address range values.
Task 2: Create the virtual network gateway

1. On any Azure portal page, in Search resources, services and docs (G+/), enter virtual network
gateway, and then select Virtual network gateways from the results.
2. On the Create virtual network gateway page, use the information in the following table to create
the gateway:
Setting Value
Project details
Resource Group ContosoResourceGroup
Instance details
Name CoreServicesVnetGateway
Region West US
Gateway type ExpressRoute
11 https://microsoftdigitallearning.visualstudio.com/DefaultCollection/Courseware/_git/LP_AZ_designing-implementing-microsoft-azure-
networking?path=%2FModules%2FM03-design-implement-azure-expressroute%2Fmedia%2Fadd-gateway-subnet.png&version=GBmaste
r&anchor=lightbox
129
SKU Standard
Virtual network CoreServicesVNet
Public IP address
Public IP address Create new
Public IP address name CoreServicesVnetGateway-IP
Assignment Not configurable
Enable active-active mode Disabled
3. Select Review + Create.
4. Confirm that the Gateway configuration passes validation and then select Create.
5. When the deployment is complete, select Go to Resource.
Note: It can take up to 45 minutes to deploy a Gateway.
Congratulations! You have successfully created a Virtual network, a gateway subnet, and an ExpressRoute
Gateway.
5-Exercise: provision an ExpressRoute circuit

In this exercise, you will create an ExpressRoute circuit using the Azure portal and the Azure Resource
Manager deployment model.
To watch a demonstration of how to create an ExpressRoute circuit, see Azure ExpressRoute - How to
create an ExpressRoute circuit | Azure | Channel 9 (msdn.com)12.
●● Task 1: Create and provision an ExpressRoute circuit
●● Task 2: Retrieve your Service key
●● Task 3: Deprovisioning an ExpressRoute circuit
12 https://channel9.msdn.com/Blogs/Azure/Azure-ExpressRoute-How-to-create-an-ExpressRoute-circuit?term=ExpressRoute&lang-
en=true&pageSize=15&skip=15
130
Task 1: Create and provision an ExpressRoute circuit

1. From a browser, navigate to the Azure portal13 and sign in with your Azure account.
[!Important]
Your ExpressRoute circuit is billed from the moment a service key is issued. Ensure that you perform this
operation when the connectivity provider is ready to provision the circuit.
2. On the Azure portal menu, select + Create a resource. Select Networking, and then select Express-
Route, as shown in the following image. If ExpressRoute does not appear in the list, use Search the
marketplace to search for it:
3. On the Create ExpressRoute page, provide the Resource Group, Region, and Name for the circuit
with the following: ExpressRouteResourceGroup, West US 2, TestERCircuit . Then select Next: Config-
uration >.
131
4. When you are filling in the values on this page, make sure that you specify the correct SKU tier (Local,
Standard, or Premium) and data metering billing model (Unlimited or Metered).
132
●● Port type determines if you are connecting to a service provider or directly into Microsoft's global
network at a peering location.
●● Create new or import from classic determines if a new circuit is being created or if you are migrating a
classic circuit to Azure Resource Manager.
●● Provider is the internet service provider who you will be requesting your service from.
●● Peering Location is the physical location where you are peering with Microsoft.
[!Important]
The Peering Location indicates the physical location14 where you are peering with Microsoft. This is not
linked to “Location” property, which refers to the geography where the Azure Network Resource Provider
is located. While they are not related, it is a good practice to choose a Network Resource Provider
geographically close to the Peering Location of the circuit.
●● SKU determines whether an ExpressRoute local, ExpressRoute standard, or an ExpressRoute premium
add-on is enabled. You can specify Local to get the local SKU, Standard to get the standard SKU or
Premium for the premium add-on. You can change the SKU to enable the premium add-on.
14 https://docs.microsoft.com/en-us/azure/expressroute/expressroute-locations
133
[!Important]
You cannot change the SKU from Standard/Premium to Local.
●● Billing model determines the billing type. You can specify Metered for a metered data plan and
Unlimited for an unlimited data plan. You can change the billing type from Metered to Unlimited.
[!Important]
You cannot change the type from Unlimited to Metered.
●● Allow classic operation will allow classic virtual networks to be link to the circuit.
Task 2: Retrieve your service key

1. You can view all the circuits that you created by selecting All services > Networking > ExpressRoute
circuits.
2. All ExpressRoute circuits created in the subscription will appear here.
3. The circuit page displays the properties of the circuit. The service key appears in the service key field.
Your service provider will need the Service Key to complete the provisioning process. The service key is
134
specific to your circuit. **You must send the service key to your connectivity provider for provisioning.**
4. On this page, Provider status gives you the current state of provisioning on the service-provider side.
Circuit status provides you the state on the Microsoft side.
5. When you create a new ExpressRoute circuit, the circuit is in the following state:
●● Provider status: Not provisioned
●● Circuit status: Enabled
●● The circuit changes to the following state when the connectivity provider is currently enabling it
for you:
●● Provider status: Provisioning
●● To use the ExpressRoute circuit, it must be in the following state:
●● Provider status: Provisioned
●● You should periodically check the provisioning status and the state of the circuit key.
6. You can view the properties of the circuit that you are interested in by selecting it. Check the Provider
status and ensure that it has moved to Provisioned before you continue.
135
Watch this demonstration of how to create and provision an ExpressRoute circuit: Azure ExpressRoute
- How to create an ExpressRoute circuit | Azure | Channel 9 (msdn.com)15.
Congratulations! You have created an ExpressRoute circuit and located the Service key, which you would
need to complete the provisioning of the circuit.
Task 3: Deprovisioning an ExpressRoute circuit

If the ExpressRoute circuit service provider provisioning state is Provisioning or Provisioned, you must
work with your service provider to deprovision the circuit on their side. Microsoft can continue to reserve
resources and bill you until the service provider completes deprovisioning the circuit and notifies us.
[!Note]
You must unlink all virtual networks from the ExpressRoute circuit before deprovisioning. If this operation
fails, check whether any virtual networks are linked to the circuit.
If the service provider has deprovisioned the circuit (the service provider provisioning state is set to Not
provisioned), you can delete the circuit. This stops billing for the circuit.

You can delete your ExpressRoute circuit by selecting the Delete icon. Ensure the provider status is Not
provisioned before proceeding.
15 https://channel9.msdn.com/Blogs/Azure/Azure-ExpressRoute-How-to-create-an-ExpressRoute-circuit?term=ExpressRoute&lang-
en=true&pageSize=15&skip=15
136
Note: Remember to remove any newly created Azure resources that you no longer use. Removing
command:
6-Configure peering for an ExpressRoute de-

ployment
An ExpressRoute circuit two peering options associated with it: Azure private, and Microsoft. Each peering
is configured identically on a pair of routers (in active-active or load sharing configuration) for high
availability. Azure services are categorized as Azure public and Azure private to represent the IP address-
ing schemes.
137
Create Peering configuration

●● You can configure private peering and Microsoft peering for an ExpressRoute circuit. Peering's can be
configured in any order you choose. However, you must make sure that you complete the configura-
tion of each peering one at a time.
●● You must have an active ExpressRoute circuit. Have the circuit enabled by your connectivity provider
before you continue. To configure peering(s), the ExpressRoute circuit must be in a provisioned and
enabled state.
●● If you plan to use a shared key/MD5 hash, be sure to use the key on both sides of the tunnel. The limit
is a maximum of 25 alphanumeric characters. Special characters are not supported.
●● This only applies to circuits created with service providers offering Layer 2 connectivity services. If you
are using a service provider that offers managed Layer 3 services (typically an IPVPN, like MPLS), your
connectivity provider configures and manages the routing for you.
Choose between private peering only, Microsoft peering

only, or both
The following table compares the two peering. Public peering is deprecated for new peering.
Max. # prefixes supported per Private Peering Microsoft Peering

peering
IP address ranges supported 4000 by default, 10,000 with 200
ExpressRoute Premium
AS Number requirements Any valid IP address within your Public IP addresses owned by
WAN. you or your connectivity provid-
er.
138
IP protocols supported Private and public AS numbers. Private and public AS numbers.
You must own the public AS However, you must prove
number if you choose to use ownership of public IP addresses.
one.
Routing Interface IP addresses IPv4, IPv6 (preview) IPv4, IPv6
Routing Interface IP addresses RFC1918 and public IP addresses Public IP addresses registered to
you in routing registries.
MD5 Hash support Yes Yes
You may enable one or more of the routing domains as part of your ExpressRoute circuit. You can choose
to have all the routing domains put on the same VPN if you want to combine them into a single routing
domain. The recommended configuration is that private peering is connected directly to the core net-
work, and the public and Microsoft peering links are connected to your DMZ.
Each peering requires separate BGP sessions (one pair for each peering type). The BGP session pairs
provide a highly available link. If you are connecting through layer 2 connectivity providers, you are
responsible for configuring and managing routing.
[!Important]
IPv6 support for private peering is currently in Public Preview. If you would like to connect your virtual
network to an ExpressRoute circuit with IPv6-based private peering configured, please make sure that
your virtual network is dual stack and follows the guidelines for IPv6 for Azure VNet16.
Configure private peering

Azure compute services, namely virtual machines (IaaS) and cloud services (PaaS), that are deployed
within a virtual network can be connected through the private peering domain. The private peering
domain is a trusted extension of your core network into Microsoft Azure. You can set up bi-directional
connectivity between your core network and Azure virtual networks (VNets). This peering lets you
connect to virtual machines and cloud services directly on their private IP addresses.
You can connect more than one virtual network to the private peering domain. You can visit the Azure
Subscription and Service Limits, Quotas, and Constraints17 page for up-to-date information on limits.
To watch a demonstration of configuring private peering, see Azure ExpressRoute - How to set up
Azure private peering for your ExpressRoute circuit | Azure | Channel 9 (msdn.com)18.
Configure Microsoft peering

Microsoft 365 was created to be accessed securely and reliably via the Internet. Because of this, it is
recommended ExpressRoute for specific scenarios.
Connectivity to Microsoft online services (Microsoft 365 and Azure PaaS services) occurs through Micro-
soft peering. You can enable bidirectional connectivity between your WAN and Microsoft cloud services
through the Microsoft peering routing domain. You must connect to Microsoft cloud services only over
public IP addresses that are owned by you or your connectivity provider and you must adhere to all the
defined rules.
16 https://docs.microsoft.com/en-us/azure/virtual-network/ipv6-overview
17 https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits
18 https://channel9.msdn.com/Blogs/Azure/Azure-ExpressRoute-How-to-set-up-Azure-private-peering-for-your-ExpressRoute-
circuit?term=ExpressRoute&lang-en=true&pageSize=15&skip=15
139
To watch a demonstration of configuring Microsoft peering, see Azure ExpressRoute - How to set up
Microsoft peering for your ExpressRoute circuit | Azure | Channel 9 (msdn.com)19.
Configure route filters for Microsoft Peering

Route filters are a way to consume a subset of supported services through Microsoft peering.
Microsoft 365 services such as Exchange Online, SharePoint Online, and Skype for Business, are accessible
through the Microsoft peering. When Microsoft peering gets configured in an ExpressRoute circuit, all
prefixes related to these services gets advertised through the BGP sessions that are established. A BGP
community value is attached to every prefix to identify the service that is offered through the prefix.
Connectivity to all Azure and Microsoft 365 services causes many prefixes gets advertised through BGP.
The large number of prefixes significantly increases the size of the route tables maintained by routers
within your network. If you plan to consume only a subset of services offered through Microsoft peering,
you can reduce the size of your route tables in two ways. You can:
●● Filter out unwanted prefixes by applying route filters on BGP communities. Route filtering is a stand-
ard networking practice and is used commonly within many networks.
●● Define route filters and apply them to your ExpressRoute circuit. A route filter is a new resource that
lets you select the list of services you plan to consume through Microsoft peering. ExpressRoute
routers only send the list of prefixes that belong to the services identified in the route filter.
About route filters
When Microsoft peering gets configured on your ExpressRoute circuit, the Microsoft Edge routers
establish a pair of BGP sessions with your edge routers through your connectivity provider. No routes are
advertised to your network. To enable route advertisements to your network, you must associate a route
filter.
A route filter lets you identify services you want to consume through your ExpressRoute circuit's Micro-
soft peering. It is essentially an allowed list of all the BGP community values. Once a route filter resource
gets defined and attached to an ExpressRoute circuit, all prefixes that map to the BGP community values
gets advertised to your network.
To attach route filters with Microsoft 365 services, you must have authorization to consume Microsoft 365
services through ExpressRoute. If you are not authorized to consume Microsoft 365 services through
ExpressRoute, the operation to attach route filters fails.
Create a route filter and a filter rule

A route filter can have only one rule, and the rule must be of type ‘Allow’. This rule can have a list of BGP
community values associated with it.
●● Select Create a resource then search for Route filter as shown in the following image:
19 https://channel9.msdn.com/Blogs/Azure/Azure-ExpressRoute-How-to-set-up-Microsoft-peering-for-your-ExpressRoute-
circuit?term=ExpressRoute&lang-en=true&pageSize=15&skip=15
140
●● Place the route filter in a resource group. Ensure the location is the same as the ExpressRoute circuit.
Select Review + create and then Create.
Create a filter rule

141
To add and update rules, select the manage rule tab for your route filter.
●● Select the services you want to connect to from the drop-down list and save the rule when done.
142
Attach the route filter to an ExpressRoute circuit

●● Attach the route filter to a circuit by selecting the + Add Circuit button and selecting the Express-
Route circuit from the drop-down list.
143
●● If the connectivity provider configures peering for your ExpressRoute circuit, refresh the circuit from
the ExpressRoute circuit page before you select the + Add Circuit button.
Common tasks
To get the properties of a route filter
●● You can view properties of a route filter when you open the resource in the portal.
144
To update the properties of a route filter

You can update the list of BGP community values attached to a circuit by selecting the Manage rule
button.
●● Select the service communities you want and then select Save.
145
To detach a route filter from an ExpressRoute circuit

●● To detach a circuit from the route filter, right-click on the circuit and select Disassociate.
146
Clean up resources
●● You can delete a route filter by selecting the Delete button. Ensure the Route filter is not associate to
any circuits before doing so.
147
Reset peering
Sign into the Azure portal
From a browser, go to the Azure portal20, and then sign in with your Azure account.
Reset a peering
You can reset the Microsoft peering and the Azure private peering on an ExpressRoute circuit inde-
pendently.
●● Choose the circuit that you want to change.
●● Choose the peering configuration that you want to reset.
●● Clear the Enable Peering check box, and then select Save to disable the peering configuration.
148
●● Select the Enable Peering check box, and then select Save to re-enable the peering configuration.
Multiple choice
An engineer wants to consume a specific set of services through Microsoft peering. Which feature should be
configured?
Route filters.{{Correct. Route filters are a way to consume a subset of supported services through
Microsoft peering.}}
Network Firewall.{{Incorrect. Network Firewall allows control traffic flow using rules that specify
allowed or blocked IP address and ports.}}
You cannot consume only a subset of services.{{Incorrect. You can configure Microsoft peering to
consume only a subset of services.}}
Multiple choice
To provide connectivity to Microsoft 365 and PaaS services. Which peering service should select?
Microsoft Peering.{{Correct. Connectivity to Microsoft online services (Microsoft 365 and Azure PaaS
services) occurs through Microsoft peering.}}
Private peering.{{Incorrect. Connectivity to Microsoft online services (Microsoft 365 and Azure PaaS
services) does not occur through private peering.}}
Public peering.{{Incorrect. Connectivity to Microsoft online services (Microsoft 365 and Azure PaaS
services) does not occur through public peering.}}
149
7-Connect an ExpressRoute circuit to a virtual

network
An ExpressRoute circuit represents a logical connection between your on-premises infrastructure and
Microsoft cloud services through a connectivity provider. You can order multiple ExpressRoute circuits.
Each circuit can be in the same or different regions and can be connected to your premises through
different connectivity providers. ExpressRoute circuits do not map to any physical entities. A circuit is
uniquely identified by a standard GUID called as a service key (s-key).
In the previous exercises you created an ExpressRoute Gateway and an ExpressRoute circuit. You then
learned how to configure peering for an express route circuit. You will now learn how to create a connec-
tion between your ExpressRoute circuit and Azure virtual network.
Connect a virtual network to an ExpressRoute circuit

●● You must have an active ExpressRoute circuit.
●● Ensure that you have Azure private peering configured for your circuit.
●● Ensure that Azure private peering gets configured and establishes BGP peering between your network
and Microsoft for end-to-end connectivity.
●● Ensure that you have a virtual network and a virtual network gateway created and fully provisioned. A
virtual network gateway for ExpressRoute uses the GatewayType ‘ExpressRoute’, not VPN.
●● You can link up to 10 virtual networks to a standard ExpressRoute circuit. All virtual networks must be
in the same geopolitical region when using a standard ExpressRoute circuit.
●● A single VNet can be linked to up to 16 ExpressRoute circuits. Use the following process to create a
new connection object for each ExpressRoute circuit you are connecting to. The ExpressRoute circuits
can be in the same subscription, different subscriptions, or a mix of both.
●● If you enable the ExpressRoute premium add-on, you can link virtual networks outside of the geopo-
litical region of the ExpressRoute circuit. The premium add-on will also allow you to connect more
than 10 virtual networks to your ExpressRoute circuit depending on the bandwidth chosen.
●● To create the connection from the ExpressRoute circuit to the target ExpressRoute virtual network
gateway, the number of address spaces advertised from the local or peered virtual networks needs to
be equal to or less than 200. Once the connection has been successfully created, you can add addi-
tional address spaces, up to 1,000, to the local or peered virtual networks.
To watch a demonstration of how to create an ExpressRoute circuit, see Azure ExpressRoute How to
create a connection between your VPN Gateway and ExpressRoute circuit21
Add a VPN to an ExpressRoute deployment

This section helps you configure secure encrypted connectivity between your on-premises network and
your Azure virtual networks (VNets) over an ExpressRoute private connection. You can use Microsoft
peering to establish a site-to-site IPsec/IKE VPN tunnel between your selected on-premises networks and
Azure VNets. Configuring a secure tunnel over ExpressRoute allows for data exchange with confidentiali-
ty, anti-replay, authenticity, and integrity.
21 https://channel9.msdn.com/Blogs/Azure/Azure-ExpressRoute-How-to-create-a-connection-between-your-VPN-Gateway-and-
ExpressRoute-circuit?term=ExpressRoute&lang-en=true&pageSize=15&skip=15
150
Note: When you set up site-to-site VPN over Microsoft peering, you are charged for the VPN gateway
and VPN egress.
For high availability and redundancy, you can configure multiple tunnels over the two MSEE-PE pairs of
an ExpressRoute circuit and enable load balancing between the tunnels.
VPN tunnels over Microsoft peering can be terminated either using VPN gateway or using an appropriate
Network Virtual Appliance (NVA) available through Azure Marketplace. You can exchange routes statically
or dynamically over the encrypted tunnels without exposing the route exchange to the underlying
Microsoft peering. In this section, BGP (different from the BGP session used to create the Microsoft
peering) is used to dynamically exchange prefixes over the encrypted tunnels.
[!IMPORTANT] For the on-premises side, typically Microsoft peering is terminated on the DMZ and
private peering is terminated on the core network zone. The two zones would be segregated using
firewalls. If you are configuring Microsoft peering exclusively for enabling secure tunneling over Express-
Route, remember to filter through only the public IPs of interest that are getting advertised via Microsoft
peering.
Steps
●● Configure Microsoft peering for your ExpressRoute circuit.
●● Advertise selected Azure regional public prefixes to your on-premises network via Microsoft peering.
●● Configure a VPN gateway and establish IPsec tunnels
●● Configure the on-premises VPN device.
●● Create the site-to-site IPsec/IKE connection.
●● (Optional) Configure firewalls/filtering on the on-premises VPN device.
●● Test and validate the IPsec communication over the ExpressRoute circuit.
8-Connect geographically dispersed networks

with ExpressRoute global reach
ExpressRoute is a private and resilient way to connect your on-premises networks to the Microsoft Cloud.
You can access many Microsoft cloud services such as Azure and Microsoft 365 from your private data
center or your corporate network. For example, you may have a branch office in San Francisco with an
ExpressRoute circuit in Silicon Valley and another branch office in London with an ExpressRoute circuit in
the same city. Both branch offices have high-speed connectivity to Azure resources in US West and UK
South. However, the branch offices cannot connect and send data directly with one another. In other
words, 10.0.1.0/24 can send data to 10.0.3.0/24 and 10.0.4.0/24 network, but NOT to 10.0.2.0/24 network.
151
Choose when to use ExpressRoute global reach

ExpressRoute Global Reach is designed to complement your service provider’s WAN implementation and
connect your branch offices across the world. For example, if your service provider primarily operates in
the United States and has linked all your branches in the U.S., but the service provider does not operate
in Japan and Hong Kong SAR, with ExpressRoute Global Reach you can work with a local service provider
and Microsoft will connect your branches there to the ones in the U.S. using ExpressRoute and the
Microsoft global network.
152
Configure ExpressRoute global reach

These steps show you how to configure ExpressRoute Global Reach using Azure portal.
Before you begin
Before you start configuration, confirm the following criteria:
●● You understand ExpressRoute circuit provisioning workflows.
●● Your ExpressRoute circuits are in a provisioned state.
●● Azure private peering is configured on your ExpressRoute circuits.
●● If you want to run PowerShell locally, verify that the latest version of Azure PowerShell is installed on
your computer.
Identify circuits
Identify the ExpressRoute circuits that you want use. You can enable ExpressRoute Global Reach between
the private peering of any two ExpressRoute circuits, if they are in the supported countries/regions. The
circuits are required to be created at different peering locations.
●● If your subscription owns both circuits, you can choose either circuit to run the configuration in the
following sections.
●● If the two circuits are in different Azure subscriptions, you need authorization from one Azure sub-
scription. Then you pass in the authorization key when you run the configuration command in the
other Azure subscription.
Enable connectivity
Enable connectivity between your on-premises networks. There are separate sets of instructions for
circuits that are in the same Azure subscription, and circuits that are different subscriptions.
ExpressRoute circuits in the same Azure subscription
1. Select the Azure private peering configuration.
153
2. Select Add Global Reach to open the Add Global Reach configuration page.
3. On the Add Global Reach configuration page, give a name to this configuration. Select the Express-
Route circuit you want to connect this circuit to and enter in a /29 IPv4 for the Global Reach subnet.
Azure uses IP addresses in this subnet to establish connectivity between the two ExpressRoute circuits.
Do not use the addresses in this subnet in your Azure virtual networks, or in your on-premises
network. Select Add to add the circuit to the private peering configuration.
154
4. Select Save to complete the Global Reach configuration. When the operation completes, you will have
connectivity between your two on-premises networks through both ExpressRoute circuits.
Verify the configuration

Verify the Global Reach configuration by selecting Private peering under the ExpressRoute circuit configu-
ration. When configured correctly your configuration should look as followed:
155
Disable connectivity
To disable connectivity between an individual circuit, select the delete button next to the Global Reach
name to remove connectivity between them. Then select Save to complete the operation.
156
Quiz title: Check your knowledge
Multiple choice
What is ExpressRoute Global Reach primarily designed for?
Connect branch offices across the world.{{Correct. ExpressRoute Global Reach is designed to comple-
ment your service provider’s WAN implementation and connect your branch offices across the world.}}
Connect a data center to the public internet.{{Incorrect. ExpressRoute Global Reach was not primarily
designed to connect a data center to public internet.}}
Connect a local service provider to a data center.{{Incorrect. ExpressRoute Global Reach was not
primarily designed to connect a local service provider to a data center.}}
Multiple choice
How can a network engineer for a company with offices in London and Tokyo configure communications
between the two offices?
Use a local service provider in London and a different local service provider in Tokyo. GlobalReach
connects the branches using ExpressRoute and the Microsoft global network.{{Correct. You can use a
local service provider wherever your offices are, and GlobalReach will connect the branches using
ExpressRoute and the Microsoft global network.}}
Use a local service provider that has a presence in both London and Tokyo, and enable GlobalReach to
connect to each local service provider location.{{Incorrect. You can use different local service providers
in each location.}}
Use GlobalReach to connect each location to a private VPN, and use local service providers for
point-to-site access.{{Incorrect. Each location should connect to GlobalNet through a local service
provider.}}
9-Improve data path performance between net-

works with ExpressRoute FastPath
ExpressRoute virtual network gateway is designed to exchange network routes and route network traffic.
FastPath is designed to improve the data path performance between your on-premises network and your
virtual network. When enabled, FastPath sends network traffic directly to virtual machines in the virtual
network, bypassing the gateway.
Circuits
FastPath is available on all ExpressRoute circuits.
Gateways
FastPath still requires a virtual network gateway to be created to exchange routes between virtual
network and on-premises network.
157
Gateway requirements for ExpressRoute FastPath

To configure FastPath, the virtual network gateway must be either:
●● Ultra-Performance
●● ErGw3AZ
[!IMPORTANT] If you plan to use FastPath with IPv6-based private peering over ExpressRoute, make sure
to select ErGw3AZ for SKU. Note that this is only available for circuits using ExpressRoute Direct.
Limitations
While FastPath supports most configurations, it does not support the following features:
●● UDR on the gateway subnet: This UDR has no impact on the network traffic that FastPath sends
directly from your on-premises network to the virtual machines in Azure virtual network.
●● VNet Peering: If you have other virtual networks peered with the one that is connected to Express-
Route, the network traffic from your on-premises network to the other virtual networks (i.e., the
so-called “Spoke” VNets) will continue to be sent to the virtual network gateway. The workaround is
to connect all the virtual networks to the ExpressRoute circuit directly.
●● Basic Load Balancer: If you deploy a Basic internal load balancer in your virtual network or the Azure
PaaS service you deploy in your virtual network uses a Basic internal load balancer, the network traffic
from your on-premises network to the virtual IPs hosted on the Basic load balancer will be sent to the
virtual network gateway. The solution is to upgrade the Basic load balancer to a Standard load
balancer.
●● Private Link: If you connect to a private endpoint in your virtual network from your on-premises
network, the connection will go through the virtual network gateway.
Configure ExpressRoute FastPath

To enable FastPath, connect a virtual network to an ExpressRoute circuit using the Azure portal.
This section shows you how to create a connection to link a virtual network to an Azure ExpressRoute
circuit using the Azure portal. The virtual networks that you connect to your Azure ExpressRoute circuit
can either be in the same subscription or be part of another subscription.
Prerequisites
●● Review the routing requirements, and workflows before you begin configuration.
●● You must have an active ExpressRoute circuit.
●● Follow the instructions to create an ExpressRoute circuit and have the circuit enabled by your connec-
tivity provider.
●● Ensure that you have Azure private peering configured for your circuit.
●● Ensure that Azure private peering gets configured and establishes BGP peering between your network
and Microsoft for end-to-end connectivity.
●● Ensure that you have a virtual network and a virtual network gateway created and fully provisioned. A
virtual network gateway for ExpressRoute uses the GatewayType ‘ExpressRoute’, not VPN.
●● You can link up to 10 virtual networks to a standard ExpressRoute circuit. All virtual networks must be
in the same geopolitical region when using a standard ExpressRoute circuit.
158
●● A single VNet can be linked to up to 16 ExpressRoute circuits. Use the following process to create a
new connection object for each ExpressRoute circuit you are connecting to. The ExpressRoute circuits
can be in the same subscription, different subscriptions, or a mix of both.
●● If you enable the ExpressRoute premium add-on, you can link virtual networks outside of the geopo-
litical region of the ExpressRoute circuit. The premium add-on will also allow you to connect more
than 10 virtual networks to your ExpressRoute circuit depending on the bandwidth chosen.
●● To create the connection from the ExpressRoute circuit to the target ExpressRoute virtual network
gateway, the number of address spaces advertised from the local or peered virtual networks needs to
be equal to or less than 200. Once the connection has been successfully created, you can add addi-
tional address spaces, up to 1,000, to the local or peered virtual networks.
Connect a VNet to a circuit - same subscription
[!NOTE] BGP configuration information will not appear if the layer 3 provider configured your peering. If
your circuit is in a provisioned state, you should be able to create connections.
1. To create a connection Ensure that your ExpressRoute circuit and Azure private peering have been
configured successfully. Your ExpressRoute circuit should look like the following image:
2. You can now start provisioning a connection to link your virtual network gateway to your Express-
Route circuit. Select Connection > Add to open the Add connection page.
159
3. Enter a name for the connection and then select Next: Settings >.
4. Select the gateway that belongs to the virtual network that you want to link to the circuit and select
Review + create. Then select Create after validation completes.
160
5. After your connection has been successfully configured, your connection object will show the infor-
mation for the connection.
Administration - About circuit owners and circuit users

The ‘circuit owner’ is an authorized Power User of the ExpressRoute circuit resource. The circuit owner can
create authorizations that can be redeemed by 'circuit users'. Circuit users are owners of virtual network
gateways that are not within the same subscription as the ExpressRoute circuit. Circuit users can redeem
authorizations (one authorization per virtual network).
161
The circuit owner has the power to modify and revoke authorizations at any time. Revoking an authoriza-
tion results in all link connections being deleted from the subscription whose access was revoked.
Circuit owner operations
To create a connection authorization
The circuit owner creates an authorization, which creates an authorization key to be used by a circuit user
to connect their virtual network gateways to the ExpressRoute circuit. An authorization is valid for only
one connection.
[!NOTE] Each connection requires a separate authorization.
1. In the ExpressRoute page, select Authorizations and then type a name for the authorization and
select Save.
2. Once the configuration is saved, copy the Resource ID and the Authorization Key.
3. To delete a connection authorization

You can delete a connection by selecting the Delete icon for the authorization key for your connection.
162
If you want to delete the connection but retain the authorization key, you can delete the connection from
the connection page of the circuit.
Circuit user operations

The circuit user needs the resource ID and an authorization key from the circuit owner.
To redeem a connection authorization
1. Select the + Create a resource button. Search for Connection and select Create.
163
2. Make sure the Connection type is set to ExpressRoute. Select the Resource group and Location, then
select OK in the Basics page.
[!Note] The location must match the virtual network gateway location you are creating the connection
for.
164
3. In the Settings page, Select the Virtual network gateway and check the Redeem authorization check
box. Enter the Authorization key and the Peer circuit URI and give the connection a name. Select OK.
[!Note] The Peer Circuit URI is the Resource ID of the ExpressRoute circuit (which you can find under the
Properties Setting pane of the ExpressRoute Circuit).
165
4. Review the information in the Summary page and select OK.
Clean up resources
You can delete a connection and unlink your VNet to an ExpressRoute circuit by selecting the Delete icon
on the page for your connection.
166
Multiple choice
How does ExpressRoute FastPath send network traffic?
Directly to virtual machines in the virtual network.{{Correct. FastPath sends network traffic directly to
virtual machines in the virtual network, bypassing the gateway.}}
Through the gateway to Virtual machines.{{Incorrect. ExpressRoute FastPath does not send traffic
through the gateway to virtual machines.}}
Through the public internet.{{Incorrect. ExpressRoute FastPath does not send traffic through the public
internet.}}
Multiple choice
A network has multiple VNets peered with the VNet that is connected to ExpressRoute. How should the
ExpressRoute FastPath deployment be modified?
Connect all the virtual networks to the ExpressRoute FastPath circuit directly.{{Correct. To avoid traffic
being routed through the VNet gateways, connect all the VNets to ExpressRoute FastPath circuit
directly.}}
Connect the VNet gateways to ExpressRoute FastPath.{{Incorrect. The VNet gateways still support
VNet-to-Vnet peering and should not be connected directly to FastPath.}}
Modify the VNet peering configuration.{{Incorrect. The VNet gateways can still support VNet-to-Vnet
peering and do not have to be modified.}}
167
10-Troubleshoot ExpressRoute connection issues
As an Azure network engineer supporting an ExpressRoute deployment, you will have to diagnose and
resolve any ExpressRoute connection issues that arise.
ExpressRoute connectivity traditionally involves three distinct network zones, as follows:
●● Customer Network
●● Provider Network
●● Microsoft Datacenter
[!NOTE] In the ExpressRoute direct connectivity model (offered at 10/100 Gbps bandwidth), customers
can directly connect to Microsoft Enterprise Edge (MSEE) routers' port. Therefore, in the direct connectivi-
ty model, there are only customer and Microsoft network zones.
Verify circuit provisioning and state through the Azure

portal
Provisioning an ExpressRoute circuit establishes a redundant Layer 2 connections between CEs/PE-MSEEs
(2)/(4) and MSEEs (5).
[!TIP] A service key uniquely identifies an ExpressRoute circuit. Should you need assistance from Microsoft
or from an ExpressRoute partner to troubleshoot an ExpressRoute issue, provide the service key to readily
identify the circuit.
In the Azure portal, open the ExpressRoute circuit blade. In the section of the blade, the ExpressRoute
essentials are listed as shown in the following screenshot:
168
In the ExpressRoute Essentials, Circuit status indicates the status of the circuit on the Microsoft side.
Provider status indicates if the circuit has been Provisioned/Not provisioned on the service-provider side.
For an ExpressRoute circuit to be operational, the Circuit status must be Enabled, and the Provider status
must be Provisioned.
[!NOTE] After configuring an ExpressRoute circuit, if the Circuit status is stuck in not enabled status,
contact Microsoft Support22. On the other hand, if the Provider status is stuck in not provisioned status,
contact your service provider.
Validate peering configuration

After the service provider has completed the provisioning the ExpressRoute circuit, multiple eBGP based
routing configurations can be created over the ExpressRoute circuit between CEs/MSEE-PEs (2)/ (4) and
MSEEs (5). Each ExpressRoute circuit can have: Azure private peering (traffic to private virtual networks in
Azure), and/or Microsoft peering (traffic to public endpoints of PaaS and SaaS).
Note: In IPVPN connectivity model, service providers handle the responsibility of configuring the peering
(layer 3 services). In such a model, after the service provider has configured a peering and if the peering is
blank in the portal, try refreshing the circuit configuration using the refresh button on the portal. This
operation will pull the current routing configuration from your circuit.
In the Azure portal, status of an ExpressRoute circuit peering can be checked under the ExpressRoute
circuit blade. In the overview section of the blade, the ExpressRoute peering would be listed as shown in
the following screenshot:
In the preceding example, as noted Azure private peering is provisioned, whereas Azure public and
Microsoft peering are not provisioned. A successfully provisioned peering context would also have the
primary and secondary point-to-point subnets listed. The /30 subnets are used for the interface IP
address of the MSEEs and CEs/PE-MSEEs. For the peering that are provisioned, the listing also indicates
who last modified the configuration.
[!NOTE] If enabling a peering fails, check if the primary and secondary subnets assigned match the
configuration on the linked CE/PE-MSEE. Also check if the correct VlanId, AzureASN, and PeerASN are
22 https://portal.azure.com/?
169
used on MSEEs and if these values map to the ones used on the linked CE/PE-MSEE. If MD5 hashing is
chosen, the shared key should be same on MSEE and PE-MSEE/CE pair. Previously configured shared key
would not be displayed for security reasons. Should you need to change any of these configuration on an
MSEE router, refer to Create and modify routing for an ExpressRoute circuit23.
[!NOTE] On a /30 subnet assigned for interface, Microsoft will pick the second usable IP address of the
subnet for the MSEE interface. Therefore, ensure that the first usable IP address of the subnet has been
assigned on the peered CE/PE-MSEE.
Validate Address Resolution Protocol (ARP)

Address Resolution Protocol (ARP) is a layer 2 protocol defined in RFC 826. ARP is used to map the
Ethernet address (MAC address) with an ip address. ARP tables can help validate layer 2 configuration
and troubleshooting basic layer 2 connectivity issues.
The ARP table provides a mapping of the IP address and MAC address for a particular peering. The ARP
table for an ExpressRoute circuit peering provides the following information for each interface (primary
and secondary):
●● Mapping of on-premises router interface ip address to the MAC address
●● Mapping of ExpressRoute router interface ip address to the MAC address
●● Age of the mapping ARP tables can help validate layer 2 configuration and troubleshooting basic
layer 2 connectivity issues.
ARP table when Microsoft side has problems
●● You won't see an ARP table shown for a peering if there are issues on the Microsoft side.
●● Open a support ticket with Microsoft support. Specify that you have an issue with layer 2 connectivity.
Next Steps
●● Validate Layer 3 configurations for your ExpressRoute circuit.
●● Get route summary to determine the state of BGP sessions.
●● Get route table to determine which prefixes are advertised across ExpressRoute.
●● Validate data transfer by reviewing bytes in / out.
●● Open a support ticket with Microsoft support if you're still experiencing issues.
ExpressRoute monitoring tools

ExpressRoute uses Network insights to provide a detailed topology mapping of all ExpressRoute compo-
nents (peerings, connections, gateways) in relation with one another. Network insights for ExpressRoute
also have preloaded metrics dashboard for availability, throughput, packet drops, and gateway metrics.
You can analyze metrics for Azure ExpressRoute with metrics from other Azure services using metrics
explorer by opening Metrics from the Azure Monitor menu.
●● To view ExpressRoute metrics, filter by Resource Type ExpressRoute circuits.
●● To view Global Reach metrics, filter by Resource Type ExpressRoute circuits and select an ExpressRoute
circuit resource that has Global Reach enabled.
●● To view ExpressRoute Direct metrics, filter Resource Type by ExpressRoute Ports.
23 https://docs.microsoft.com/en-us/azure/expressroute/expressroute-howto-routing-portal-resource-manager
170
Multiple choice
What property of an ExpressRoute circuit is useful when opening a support ticket with the service provider?
Service key.{{Correct. A service key uniquely identifies an ExpressRoute circuit. If you need assistance
from Microsoft or from an ExpressRoute partner to troubleshoot an ExpressRoute issue, provide the
service key to readily identify the circuit.}}
Circuit name.{{Incorrect. The Circuit name may not be unique or easily searchable for the service
provider.}}
Circuit number.{{Incorrect. There is no circuit number property.}}
Multiple choice
An engineer wants to know if their service provider has made any changes that affect their circuit. Where
can they check for this information?
Check the Last modified by property of the relevant peering.{{Correct. Azure resources record
information about changes, in this case, who made the last change.}}
Call the service provider and ask them.{{Incorrect. This may get you the correct answer, but it is not
the quickest way to check.}}
Raise a support ticket with Microsoft.{{Incorrect. This may get you the correct answer, but it is not the
quickest way to check.}}
11-Summary and resources

●● Learn about Express Route, its use cases and implementation
●● Understand Express Route configuration and when to choose the appropriate SKU
●● Learn about ExpressRoute Global Reach and connecting branch offices
●● Explore Express Route FastPath to improve performance
●● Understand Express Route peering, Private and Microsoft peering
Resources
●● ExpressRoute documentation | Microsoft Docs24
24 https://docs.microsoft.com/en-us/azure/expressroute/
171
Answers
Multiple choice
Which one of the following is the most effective use of ExpressRoute?
■■ Provide reliable and secure connectivity to Azure services.{{Correct. Azure ExpressRoute is used to
create private connections between Azure data centers, Azure services, and infrastructure on your
premises or in a colocation environment.}}
Connect your network to the public internet.{{Incorrect. Azure ExpressRoute isn't the most effective
way to connect your network to the public internet.}}
Connect data center services internal to an organization.{{Incorrect. Azure ExpressRoute isn't used to
connect data center services internal to an organization.}}
Explanation
Multiple choice
What is the benefit of Bidirectional forwarding?
■■ Bidirectional forwarding reduces the failure deduction time.{{Correct. Enabling BFD over an Express-
Route circuit can reduce the failure deduction time from a few tens of seconds to less than a second.}}
Bidirectional forwarding allows traffic to flow in both directions.{{Incorrect. Bidirectional forwarding
isn't concerned with normal traffic flow.}}
Bidirectional forwarding enables you to configure BGP keep-alive times of less than 3 seconds.
{{Incorrect. The BGP keep-alive can be set as low as three seconds, but this aggressive schedule isn't
recommended.}}
Explanation
Multiple choice
Which of the following can be connected with ExpressRoute Premium?
■■ Resources in different Geopolitical regions.{{Correct. You can enable ExpressRoute Premium to extend
connectivity across geopolitical boundaries. For example, if you connect to Microsoft in Amsterdam
through ExpressRoute, you'll have access to all Microsoft cloud services hosted in all regions across
the world.}}
Resources within local regions.{{Incorrect. Azure Premium can connect more than resources within
local regions.}}
Resources within a single metropolitan area only.{{Incorrect. Azure Premium can connect more than
resources within a single metropolitan area.}}
Explanation
172
Multiple choice
How can one provide a failover path for ExpressRoute?
■■ Configure a Site-to-Site VPN connection as a backup for ExpressRoute.{{Correct. You can configure a
Site-to-Site VPN connection as a backup for ExpressRoute. This connection applies only to virtual
networks linked to the Azure private peering path.}}
Configure a Point-to-Site VPN connection as a backup for ExpressRoute.{{Incorrect. A Point-to-Site
VPN connection will not function as a backup for ExpressRoute.}}
You cannot configure a backup path for ExpressRoute.{{Incorrect. It is possible to configure a backup
path for ExpressRoute.}}
Explanation
Multiple choice
An engineer wants to consume a specific set of services through Microsoft peering. Which feature should
be configured?
■■ Route filters.{{Correct. Route filters are a way to consume a subset of supported services through
Microsoft peering.}}
Network Firewall.{{Incorrect. Network Firewall allows control traffic flow using rules that specify
allowed or blocked IP address and ports.}}
You cannot consume only a subset of services.{{Incorrect. You can configure Microsoft peering to
consume only a subset of services.}}
Explanation
Multiple choice
To provide connectivity to Microsoft 365 and PaaS services. Which peering service should select?
■■ Microsoft Peering.{{Correct. Connectivity to Microsoft online services (Microsoft 365 and Azure PaaS
services) occurs through Microsoft peering.}}
Private peering.{{Incorrect. Connectivity to Microsoft online services (Microsoft 365 and Azure PaaS
services) does not occur through private peering.}}
Public peering.{{Incorrect. Connectivity to Microsoft online services (Microsoft 365 and Azure PaaS
services) does not occur through public peering.}}
Explanation
Multiple choice
What is ExpressRoute Global Reach primarily designed for?
■■ Connect branch offices across the world.{{Correct. ExpressRoute Global Reach is designed to comple-
ment your service provider’s WAN implementation and connect your branch offices across the world.}}
Connect a data center to the public internet.{{Incorrect. ExpressRoute Global Reach was not primarily
designed to connect a data center to public internet.}}
Connect a local service provider to a data center.{{Incorrect. ExpressRoute Global Reach was not
primarily designed to connect a local service provider to a data center.}}
Explanation
173
Multiple choice
How can a network engineer for a company with offices in London and Tokyo configure communications
between the two offices?
■■ Use a local service provider in London and a different local service provider in Tokyo. GlobalReach
connects the branches using ExpressRoute and the Microsoft global network.{{Correct. You can use a
local service provider wherever your offices are, and GlobalReach will connect the branches using
ExpressRoute and the Microsoft global network.}}
Use a local service provider that has a presence in both London and Tokyo, and enable GlobalReach to
connect to each local service provider location.{{Incorrect. You can use different local service providers
in each location.}}
Use GlobalReach to connect each location to a private VPN, and use local service providers for
point-to-site access.{{Incorrect. Each location should connect to GlobalNet through a local service
provider.}}
Explanation
Multiple choice
How does ExpressRoute FastPath send network traffic?
■■ Directly to virtual machines in the virtual network.{{Correct. FastPath sends network traffic directly to
virtual machines in the virtual network, bypassing the gateway.}}
Through the gateway to Virtual machines.{{Incorrect. ExpressRoute FastPath does not send traffic
through the gateway to virtual machines.}}
Through the public internet.{{Incorrect. ExpressRoute FastPath does not send traffic through the public
internet.}}
Explanation
Multiple choice
A network has multiple VNets peered with the VNet that is connected to ExpressRoute. How should the
ExpressRoute FastPath deployment be modified?
■■ Connect all the virtual networks to the ExpressRoute FastPath circuit directly.{{Correct. To avoid traffic
being routed through the VNet gateways, connect all the VNets to ExpressRoute FastPath circuit
directly.}}
Connect the VNet gateways to ExpressRoute FastPath.{{Incorrect. The VNet gateways still support
VNet-to-Vnet peering and should not be connected directly to FastPath.}}
Modify the VNet peering configuration.{{Incorrect. The VNet gateways can still support VNet-to-Vnet
peering and do not have to be modified.}}
Explanation
174
Multiple choice
What property of an ExpressRoute circuit is useful when opening a support ticket with the service
provider?
■■ Service key.{{Correct. A service key uniquely identifies an ExpressRoute circuit. If you need assistance
from Microsoft or from an ExpressRoute partner to troubleshoot an ExpressRoute issue, provide the
service key to readily identify the circuit.}}
Circuit name.{{Incorrect. The Circuit name may not be unique or easily searchable for the service
provider.}}
Circuit number.{{Incorrect. There is no circuit number property.}}
Explanation
Multiple choice
An engineer wants to know if their service provider has made any changes that affect their circuit. Where
can they check for this information?
■■ Check the Last modified by property of the relevant peering.{{Correct. Azure resources record
information about changes, in this case, who made the last change.}}
Call the service provider and ask them.{{Incorrect. This may get you the correct answer, but it is not
the quickest way to check.}}
Raise a support ticket with Microsoft.{{Incorrect. This may get you the correct answer, but it is not the
quickest way to check.}}
Explanation
Module 4 Load balance non-HTTP(S) traffic in
Azure
Load balance non-HTTP(S) traffic in Azure

1-Introduction
Imagine yourself in the role of a network engineer at an organization that is migrating to Azure. As the
network engineer you need to ensure line-of-business applications, services, and data are available to
end users of your corporate network whenever and wherever possible. You also need to ensure users get
access to those network resources in an efficient and timely manner.
Azure provides different flavors of load balancing services that help with the distribution of workloads
across your networks. The aim of load balancing is to optimize the use of your resources, while maximiz-
ing throughput and minimizing the time it takes for a response. You can create internal and public load
balancers in an Azure environment to distribute the network traffic within your network and the network
traffic arriving from outside your network. In this module you will learn about using the Azure Load
Balancer, and Traffic Manager load balancing services.
Learning objectives
●● Understand options for load balancing
●● Design and implement an Azure Load Balancer
●● Implement a Traffic Manager profile
Prerequisites
(DNS), and routing
176
2-Explore load balancing
The term load balancing refers to the even distribution of workloads (that is, incoming network traffic),
across a group of backend computing resources or servers. Load balancing aims to optimize resource
use, maximize throughput, minimize response time, and avoid overloading any single resource. It can also
improve availability by sharing a workload across redundant computing resources.
Load Balancing options for Azure

Azure provides various load balancing services that you can use to distribute your workloads across
multiple computing resources, but the following are the main services:
●● Azure Load Balancer - high-performance, ultra-low-latency Layer 4 load-balancing service (inbound
and outbound) for all UDP and TCP protocols. It is built to handle millions of requests per second
while ensuring your solution is highly available. Azure Load Balancer is zone-redundant, ensuring high
availability across Availability Zones.
●● Traffic Manager - DNS-based traffic load balancer that enables you to distribute traffic optimally to
services across global Azure regions, while providing high availability and responsiveness. Because
Traffic Manager is a DNS-based load-balancing service, it load-balances only at the domain level. For
that reason, it can't fail over as quickly as Front Door, because of common challenges around DNS
caching and systems not honoring DNS time-to-live values (TTLs).
●● Azure Application Gateway - provides application delivery controller (ADC) as a service, offering
various Layer 7 load-balancing capabilities. Use it to optimize web farm productivity by offloading
CPU-intensive SSL termination to the gateway.
●● Azure Front Door - application delivery network that provides global load balancing and site acceler-
ation service for web applications. It offers Layer 7 capabilities for your application like SSL offload,
path-based routing, fast failover, caching, etc. to improve performance and high-availability of your
applications.
Categorizing load balancing services

The above load balancing services can be categorized in two ways: global versus regional, and HTTP(S)
versus non-HTTP(S).
Global versus regional

Global load-balancing services distribute traffic across regional backends, clouds, or hybrid on-premises
services. These services route end-user traffic to the closest available backend. They also react to changes
in service reliability or performance, in order to maximize availability and performance. You can think of
them as systems that load balance between application stamps, endpoints, or scale-units hosted across
different regions/geographies.
In contrast, Regional load-balancing services distribute traffic within virtual networks across virtual
machines (VMs) or zonal and zone-redundant service endpoints within a region. You can think of them as
systems that load balance between VMs, containers, or clusters within a region in a virtual network.
177
HTTP(S) versus non-HTTP(S)

HTTP(S) load-balancing services are Layer 7 load balancers that only accept HTTP(S) traffic. They are
intended for web applications or other HTTP(S) endpoints. They include features such as SSL offload, web
application firewall, path-based load balancing, and session affinity.
In contrast, non-HTTP(S) load-balancing services can handle non-HTTP(S) traffic and are recommended
for non-web workloads.
The table below summarizes these categorizations for each Azure load balancing service.
Service Global or Regional Recommended Traffic

Azure Load Balancer Regional Non-HTTP(S)
Azure Application Gateway Regional HTTP(S)
Azure Front Door Global HTTP(S)
Traffic Manager Global Non-HTTP(S)
Choosing a load balancing option for Azure

When choosing an appropriate load balancing option, there are some key factors to consider:
●● Type of traffic - is it for a web application? Is it a public-facing or private application?
●● Scope - do you need to load balance virtual machines and containers within a virtual network, or load
balance across regions, or both? (see ‘Global versus regional’ above)
●● Availability - what is the Service Level Agreement (SLA) for the service?
●● Cost - In addition to the cost of the actual service itself, consider the operational cost to manage and
maintain a solution built on that service. See Load balancing pricing1.
●● Features and limitations - what features and benefits does each service provide, and what are its
limitations? See Load balancer limits2.
The flowchart below will help you to select the most appropriate load-balancing solution for your
application, by guiding you through a set of key decision criteria in order to reach a recommendation.
1 https://azure.microsoft.com/pricing/details/load-balancer/
2 https://docs.microsoft.com/azure/azure-resource-manager/management/azure-subscription-service-limits
178
As every application will have its own unique requirements, you should only use this flowchart and
the suggested recommendation as a starting point, and then perform a more detailed evaluation
yourself in order to select the best option for your environment.
If your application consists of multiple workloads, evaluate each workload separately. A complete
solution may incorporate two or more load-balancing solutions.
179
Selecting a load balancing solution by using the Azure

portal
You can use the Azure Load Balancing page in the Azure portal to help you guide to the right load-bal-
ancing solution for your business need. Azure Load Balancing includes the decision-making queries
described in the workflow diagram above.
●● Sign into the Azure portal at https://portal.azure.com3.
●● In the search box at the top of the page, type load balancing. When Load balancing - help me
choose (Preview) appears in the search results, click it.

●● Answer the Yes or No questions on this page to get a recommended solution. Note, that the final
recommended solution may be a combination of multiple load balancing services.
180
●● Depending on what answers you give, the list of potential load balancing services will change.
●● Optionally, you can also click the Service comparison or Tutorial tabs for more information and
training on the different load balancing services.
Now let's look at each of the main Azure load balancing services in more detail.
Multiple choice
An engineer has a secure web application that experiences high traffic, and they want to use a load balanc-
er to distribute the workload. Which load balancers will support this type of traffic?
Azure Application Gateway and Azure Front Door.{{Correct, Secure web applications use HTTPS traffic.
Azure Application Gateway and Azure Front Door support HTTPS traffic.}}
Azure Load Balancer and Traffic Manager.{{Incorrect, Secure web applications use HTTPS traffic. Azure
Load Balancer and Traffic Manager support non-HTTPS traffic.}}
Azure Application Gateway only.{{Incorrect, Secure web applications use HTTPS traffic. Azure Applica-
tion Gateway does support HTTPS traffic, but it's not the only load balancer that does.}}
Multiple choice
Which type of load balancing services distribute traffic within virtual networks across virtual machines?
Regional.{{Correct, Regional load-balancing services distribute traffic within virtual networks across
virtual machines (VMs) or zonal and zone-redundant service endpoints within a region.}}
Global.{{Incorrect, Global load-balancing services distribute traffic across regional backends, clouds,
or hybrid on-premises services.}}
Regional and Global.{{Incorrect, Regional load-balancing services distribute traffic within virtual
networks across virtual machines (VMs) or zonal and zone-redundant service endpoints within a
region, whereas Global load-balancing services distribute traffic across regional backends, clouds, or
hybrid on-premises services.}}
181
3-Design and implement Azure load balancer

using the Azure portal
Azure Load Balancer operates at layer 4 of the Open Systems Interconnection (OSI) model. It's the single
point of contact for clients. Azure Load Balancer distributes inbound flows that arrive at the load balanc-
er's front end to backend pool instances. These flows are according to configured load-balancing rules
and health probes. The backend pool instances can be Azure Virtual Machines or instances in a virtual
machine scale set.
Choosing a load balancer type

Load balancers can be public (also known as external) or internal (also known as private).
A public load balancer4 can provide outbound connections for virtual machines (VMs) inside your virtual
network. These connections are accomplished by translating their private IP addresses to public IP
addresses. External load balancers are used to distribute client traffic from the internet across your VMs.
That internet traffic might come from web browsers, module apps, or other sources.
An internal load balancer5 is used where private IPs are needed at the frontend only. Internal load
balancers are used to load balance traffic from internal Azure resources to other Azure resources inside a
virtual network. A load balancer frontend can also be accessed from an on-premises network in a hybrid
scenario.
4 https://docs.microsoft.com/en-us/azure/load-balancer/components
5 https://docs.microsoft.com/en-us/azure/load-balancer/components
182
Azure load balancer and availability zones

Azure services that support availability zones fall into three categories:
●● Zonal services: Resources can be pinned to a specific zone. For example, virtual machines, managed
disks, or standard IP addresses can be pinned to a specific zone, which allows for increased resilience
by having one or more instances of resources spread across zones.
●● Zone-redundant services: Resources are replicated or distributed across zones automatically. Azure
replicates the data across three zones so that a zone failure does not impact its availability.
●● Non-regional services: Services are always available from Azure geographies and are resilient to
zone-wide outages as well as region-wide outages.
Azure Load Balancer supports availability zones scenarios. You can use Standard Load Balancer to
increase availability throughout your scenario by aligning resources with, and distribution across zones.
Review this document to understand these concepts and fundamental scenario design guidance
A Load Balancer can either be zone redundant, zonal, or non-zonal. To configure the zone related
properties (mentioned above) for your load balancer, select the appropriate type of frontend needed.
183
Zone redundant
In a region with Availability Zones, a Standard Load Balancer can be zone-redundant. This traffic is served
by a single IP address.
A single frontend IP address will survive zone failure. The frontend IP may be used to reach all (non-im-
pacted) backend pool members no matter the zone. One or more availability zones can fail and the data
path survives as long as one zone in the region remains healthy.
The frontend's IP address is served simultaneously by multiple independent infrastructure deployments in
multiple availability zones. Any retries or reestablishment will succeed in other zones not affected by the
zone failure.
Zonal
You can choose to have a frontend guaranteed to a single zone, which is known as a zonal. This scenario
means any inbound or outbound flow is served by a single zone in a region. Your frontend shares fate
with the health of the zone. The data path is unaffected by failures in zones other than where it was
guaranteed. You can use zonal frontends to expose an IP address per Availability Zone.
Additionally, the use of zonal frontends directly for load balanced endpoints within each zone is support-
ed. You can use this configuration to expose per zone load-balanced endpoints to individually monitor
each zone. For public endpoints, you can integrate them with a DNS load-balancing product like Traffic
Manager and use a single DNS name.
184
For a public load balancer frontend, you add a zones parameter to the public IP. This public IP is refer-
enced by the frontend IP configuration used by the respective rule.
For an internal load balancer frontend, add a zones parameter to the internal load balancer frontend IP
configuration. A zonal frontend guarantees an IP address in a subnet to a specific zone.
Selecting an Azure load balancer SKU

Two SKUs are available when you create a load balancer in Azure: Basic load balancers and Standard load
balancers. These SKUs differ in terms of their scenario scope and scale, features, and cost. Any scenario
that is possible with the Basic load balancer can also be created with the Standard load balancer.
To compare and understand the differences, review the table below.
Features Standard Load Balancer Basic Load Balancer

Backend pool size Supports up to 1000 instances. Supports up to 300 instances.
Backend pool endpoints Any virtual machines or virtual Virtual machines in a single avail-
machine scale sets in a single ability set or virtual machine
virtual network. scale set.
Health probes TCP, HTTP, HTTPS TCP, HTTP
Health probe down behavior TCP connections stay alive on an TCP connections stay alive on an
instance probe down and on all instance probe down. All TCP
probes down. connections end when all probes
are down.
Availability Zones Zone-redundant and zonal Not available
frontends for inbound and
outbound traffic.
Diagnostics Azure Monitor multi-dimensional Azure Monitor logs (https://
metrics docs.microsoft.com/azure/
load-balancer/load-balanc-
er-monitor-log)
HA Ports Available for Internal Load Not available
Balancer
185
Secure by default Closed to inbound flows unless Open by default. Network

allowed by a network security security group optional.
group. Internal traffic from the
virtual network to the internal
load balancer is allowed.
Outbound Rules Declarative outbound NAT Not available
configuration
TCP Reset on Idle Available on any rule Not available
Multiple front ends Inbound and outbound Inbound only
Management Operations Most operations < 30 seconds 60-90+ seconds typical
SLA 99.99% (https://azure.microsoft. Not available
com/support/legal/sla/load-bal-
ancer/v1_0/)
Microsoft recommends Standard load balancer. Standalone VMs, availability sets, and virtual
machine scale sets can be connected to only one SKU, never both. Load balancer and the public IP
address SKU must match when you use them with public IP addresses.
SKUs aren't mutable; therefore, you cannot change the SKU of an existing resource.
Creating and configuring an Azure load balancer

There are several tasks you need to perform to successfully create and configure an Azure Load Balancer.
Create the load balancer

In this example, we are looking at the tasks required to create and configure a Public (external) load
balancer in a Basic SKU. The first task is to create the load balancer itself.
From the Azure portal home page, select Create a resource.

On the Create a resource page, you can either browse to try and find the resource type you want to
create or enter your search criteria in the search box and press ENTER. For example, type Load Balancer.
186
To narrow down the search results, you can use the filters to the right of the search box. For example,
select Publisher Type, and then choose Microsoft.
Then choose the Load Balancer resource from Microsoft.
On the Load balancer page, choose Create to start the process.

On the Create load balancer page, you must supply the following required information:
●● Subscription - select the Azure subscription that you want to create your new load balancer resource
in.
187
●● Resource group - here you can select an existing resource group or create a new one.
●● Name - provide a unique name for the instance.
●● Region - select the region where the virtual machines were created.
●● Type - this is where you select whether your load balancer is going to be Internal (private) or Public
(external). If you choose Internal, you will need to specify a virtual network and IP address assign-
ment, but if you choose Public, you will need to specify several Public IP address details.
●● SKU - here you can select either the Standard SKU or the Basic SKU (for production workloads you
should choose Standard, but for testing and evaluation and training purposes, you could choose
Basic, but you will not get all the possible load balancer features). Depending on which SKU you
select here, the remaining configuration options will differ slightly.
●● Tier - this is where you select whether your load balancer is balancing within a region (Regional) or
across regions (Global) - If you select the Basic SKU above, this setting is greyed out.
●● Public IP address - here you specify whether to create a new public IP address for your public-facing
front-end, or use an existing one, and you also specify a name for your public IP address, and whether
to use a dynamic or statically assigned IP address. You can optionally also assign an IPv6 address to
your load balancer in addition to the default IPv4 one.
188
After you click Review + Create, the configuration settings for the new load balancer resource will be
validated, and then you can click Create to start creating it.
The resource will start to be deployed.

189
When it completes, you can click Go to resource to view the new load balancer resource in the portal.
Add a backend pool

The next task is to create a backend pool in the load balancer and then add your virtual machines to it.
From the Azure portal home page, select All resources.
190
Select your load balancer from the list.
Under the Settings section choose Backend pools, and then Add to add a pool.
191
You need to enter the following information on the Add backend pool page.
●● Name: Enter a unique name for the backend pool
●● Virtual network: Specify the name of the virtual network where the resources are located that you
will be adding to the backend pool
●● Associated to: You need to associate the backend pool with one or more virtual machines, or to a
virtual machine scale set
●● IP Version: Select either IPv4 or IPv6
You could add existing virtual machines to the backend pool at this point, or you can create and add
them later. You then click Add to add the backend pool.
192
Add virtual machines to the backend pool

The next task is to add the virtual machines to the existing back-end pool.
On the Backend pools page, select the backend pool from the list.
193
You need to enter the following information to add the virtual machine to the backend pool.
●● Virtual network: Specify the name of the virtual network where the resources are located that you
will be adding to the backend pool
●● Associated to: You need to associate the backend pool with one or more virtual machines, or to a
virtual machine scale set
Then under the Virtual machines section, click Add.
194
Select the virtual machines you want to add to the backend pool and click Add.
195
Then click Save to add them to the backend pool.
Add health probes

The next task is to create a health probe to monitor the virtual machines in the back-end pool.
On the Backend pools page of the load balancer, under Settings, select Health probes, and then click
Add.
196
You need to enter the following information on the Add health probe page.
●● Name: Enter a unique name for the health probe
●● Protocol: Select either TCP or HTTP
●● Port: Specify the destination port number for the health signal. The default is port 80
●● Interval: Specify the interval time in seconds between probe attempts. The default is 5 seconds
●● Unhealthy threshold: Specify the number of consecutive probe failures that must occur before a
virtual machine is considered to be in an unhealthy state. The default is 2 failures
You then click Add to add the health probe.
197
Add a load balancer rule

The last task is to create a load balancing rule for the load balancer. A load balancing rule distributes
incoming traffic that is sent to a selected IP address and port combination across a group of backend
pool instances. Only backend instances that the health probe considers healthy receive new traffic.
On the Health probes page of the load balancer, under Settings, select Load balancing rules, and then
click Add.
You need to enter the following information on the Add load balancing rule page.
●● Name: Enter a unique name for the load balancing rule
●● Frontend IP address: Select the existing public-facing IP address of the load balancer
●● Protocol: Select either the TCP or UDP protocol
198
●● Port: Specify the port number for the load balancing rule. The default is port 80
●● Backend port: You can choose to route traffic to the virtual machine in the backend pool using a
different port than the one that clients use by default to communicate with the load balancer (port 80)
●● Backend pool: Select an existing backend pool. The virtual machines in this backend pool will be the
target for the load balanced traffic of this rule.
●● Health probe: Select an existing health probe or create a new one. The load balancing rule uses the
health probe to determine which virtual machines in the backend pool are healthy and therefore can
receive load balanced traffic.
●● Session persistence: You can choose None, or Client IP, or Client IP and protocol. Session persis-
tence specifies that traffic from a client should be handled by the same virtual machine in the backend
pool for the duration of a session. None specifies that successive requests from the same client may
be handled by any virtual machine. Client IP specifies that successive requests from the same client IP
address will be handled by the same virtual machine. Client IP and protocol specifies that successive
requests from the same client IP address and protocol combination will be handled by the same
virtual machine.
●● Idle timeout(minutes): Specify the time to keep a TCP or HTTP connection open without relying on
clients to send keep-alive messages. The default idle timeout is 4 minutes, which is also the minimum
setting. The maximum setting is 30 minutes.
●● Floating IP: Choose between Disabled or Enabled. With Floating IP set to Disabled, Azure exposes a
traditional load balancing IP address mapping scheme for ease of use (the VM instances' IP). With
Floating IP set to Enabled, it changes the IP address mapping to the Frontend IP of the load balancer
to allow for additional flexibility.
You then click Add to add the load balancing rule.
199
200
Test the load balancer

Having completed the various tasks to create and configure your public load balancer and its compo-
nents, you should then test your configuration to ensure it works successfully. The simplest way to do this
is to copy the Public IP Address from the public load balancer resource you created and paste it into a
web browser. You should receive a response from one of the VMs in your load balancer. You could then
stop whichever VM randomly responds, and once that VM has stopped, refresh the browser page to
verify that you receive a response from the other VM in the load balancer instead.
Multiple choice
Which of the following statement about external load balancers is correct?
They have a public IP address.{{Correct, External load balancers have public IP addresses.}}
They don't have a listener IP address.{{Incorrect, External load balancers have public IP addresses.}}
They have a private, front-facing IP address.{{Incorrect, External load balancers have public IP address-
es.}}
Multiple choice
When deploying a new Azure Load Balancer that must support outbound traffic rules. Which SKU should be
selected?
Standard{{Correct, Standard SKU supports outbound rules through declarative outbound NAT config-
uration.}}
Basic{{Incorrect, Basic SKU does not support outbound rules.}}
Either Standard or Basic{{Incorrect, Basic SKU does not support outbound rules.}}
4-Exercise: create and configure an Azure load

balancer
In this exercise, you will create an internal load balancer for the fictional Contoso Ltd organization.
The steps to create an internal load balancer, are very similar to those you have already learned about in
this module, to create a public load balancer. The key difference is that with a public load balancer the
front end is accessed via a public IP address, and you test connectivity from a host which is located
outside your virtual network; whereas, with an internal load balancer, the front end is a private IP address
inside your virtual network, and you test connectivity from a host inside the same network.
The diagram below illustrates the environment you will be deploying in this exercise.
201

●● Task 1: Create the virtual network
●● Task 2: Create backend servers
●● Task 3: Create the load balancer
●● Task 4: Create load balancer resources
●● Task 5: Test the load balancer
Task 1: Create the virtual network

In this section, you will create a virtual network and a subnet.
1. Log in to the Azure portal.
2. On the Azure portal home page, click Create a resource, then Networking, then select Virtual
Network (if this resource type is not listed on the page, use the search box at the top of the page to
search for it and select it).
3. Click Create.
202
4. On the Basics tab, use the information in the table below to create the virtual network.
Setting Value
Subscription Select your subscription
Resource group Select Create new Name: IntLB-RG
Name IntLB-VNet
Region (US) West US
5. Click Next : IP Addresses.
6. On the IP Addresses tab, in the IPv4 address space box, remove the default and type 10.1.0.0/16.
7. Under Subnet name, select the word default.
8. In the Edit subnet pane, provide a subnet name of myBackendSubnet, and a subnet address range
of 10.1.0.0/24.
9. Click Save.
10. Click Add subnet, provide a subnet name of myFrontEndSubnet, and a subnet address range of
10.1.2.0/24. Click Add
11. Click Next : Security.
12. Under BastionHost select Enable, then enter the information from the table below.
Setting Value
Bastion name myBastionHost
AzureBastionSubnet address space 10.1.1.0/24
Public IP address Select Create new Name: myBastionIP
13. Click Review + create.
14. Click Create.
203
Task 2: Create backend servers

In this section, you will create three VMs, that will be in the same availability set, for the backend pool of
the load balancer, add the VMs to the backend pool, and then install IIS on the three VMs to test the load
balancer.
click Upload and upload the following files azuredeploy.json, azuredeploy.parameters.vm1.json,
azuredeploy.parameters.vm2.json and azuredeploy.parameters.vm3.json into the Cloud Shell home
directory. Azure Resource Manager Templates for this task6
3. Deploy the following Azure Resource Manager templates to create the virtual network, subnets, and
VMs needed for this exercise:
$RGName = "IntLB-RG"

-TemplateParameterFile azuredeploy.parameters.vm1.json
Task 3: Create the load balancer

In this section, you will create an internal Standard SKU load balancer. The reason we are creating a
Standard SKU load balancer here in the exercise, instead of a Basic SKU load balance, is for later exercises
that require a Standard SKU version of the load balancer.
1. On the Azure portal home page, click Create a resource.
2. In the search box at the top of the page, type Load Balancer, then press Enter
[!NOTE]
do not select one from the list
1. Scroll down to the bottom of the page and select Load Balancer (the one that says ‘Microsoft’ and
'Azure Service' under the name).
Exercises/M04
204
2. Click Create.
3. On the Basics tab, use the information in the table below to create the load balancer.
Setting Value
Resource group IntLB-RG
Name myIntLoadBalancer
Region (US) West US
Type Internal
SKU Standard
4. Click Next: Frontend IP configurations.
5. Click Add a frontend IP
6. On the Add frontend IP address blade, enter the information from the table below.
Setting Value
Name LoadBalancerFrontEnd
Virtual network IntLB-VNet
Subnet myFrontEndSubnet
Assignment Dynamic
8. Click Create.
Task 4: Create load balancer resources

In this section, you will configure load balancer settings for a backend address pool, then create a health
probe and a load balancer rule.
205
Create a backend pool and add VMs to the backend pool

The backend address pool contains the IP addresses of the virtual NICs connected to the load balancer.
1. On the Azure portal home page, click All resources, then click on myIntLoadBalancer from the
resources list.
2. Under Settings, select Backend pools, and then click Add.
3. On the Add backend pool page, enter the information from the table below.
Setting Value
Name myBackendPool
Associated to Virtual machines
4. Under Virtual machines, click Add.
5. Select the checkboxes for all 3 VMs (myVM1, myVM2, and myVM3), then click Add
6. Click Add.
Create a health probe

The load balancer monitors the status of your app with a health probe. The health probe adds or removes
VMs from the load balancer based on their response to health checks. Here you will create a health probe
to monitor the health of the VMs.
1. Under Settings, click Health probes, then click Add.
2. On the Add health probe page, enter the information from the table below.
Setting Value
Name myHealthProbe
Protocol HTTP
Port 80
Path /
206
Interval 15
Unhealthy threshold 2
3. Click Add.
Create a load balancer rule

A load balancer rule is used to define how traffic is distributed to the VMs. You define the frontend IP
configuration for the incoming traffic and the backend IP pool to receive the traffic. The source and
destination port are defined in the rule. Here you will create a load balancer rule.
1. From the Backend pools page of your load balancer, under Settings, click Load balancing rules,
then click Add.
2. On the Add load balancing rule page, enter the information from the table below.
Setting Value
Name myHTTPRule
IP Version IPv4
Frontend IP address LoadBalancerFrontEnd
Protocol TCP
Port 80
Backend port 80
Backend pool myBackendPool
Health probe myHealthProbe
Session persistence None
Idle timeout (minutes) 15
Floating IP Disabled
207
3. Click Add.
Task 5: Test the load balancer

In this section, you will create a test VM, and then test the load balancer.
Create test VM
1. On the Azure portal home page, click Create a resource, then Compute, then select Virtual machine
(if this resource type is not listed on the page, use the search box at the top of the page to search for
it and select it).
2. On the Create a virtual machine page, on the Basics tab, use the information in the table below to
create the first VM.
Setting Value
Virtual machine name myTestVM
Region (US) West US
Availability options No infrastructure redundancy required
Image Windows Server 2019 Datacenter - Gen 1
Size Standard_DS1_v2 - 1 vcpu, 3.5 GiB memory
Username TestUser
Confirm password TestPa$$w0rd!
3. Click Next : Disks, then click Next : Networking.
4. On the Networking tab, use the information in the table below to configure networking settings.
Setting Value
208

Subnet myBackendSubnet
Public IP Change to None
NIC network security group Advanced
Configure network security group Select the existing myNSG
Place this virtual machine behind an existing load Off (unchecked)
balancing solution?
6. Click Create.
7. Wait for this last VM to be deployed before moving forward with the next task.
Connect to the test VM to test the load balancer

resources list.
2. On the Overview page, make a note of the Private IP address, or copy it to the clipboard.
3. Click Home, then on the Azure portal home page, click All resources, then click on the myTestVM
virtual machine that you just created.
4. On the Overview page, select Connect, then Bastion.
5. Click Use Bastion.
6. In the Username box, type TestUser and in the Password box, type TestPa$$w0rd!, then click
Connect.
7. The myTestVM window will open in another browser tab.
8. If a Networks pane appears, click Yes.
9. Click the Internet Explorer icon in the task bar to open the web browser.
10. Click OK on the Set up Internet Explorer 11 dialog box.
11. Enter (or paste) the Private IP address (e.g. 10.1.0.4) from the previous step into the address bar of
the browser and press Enter.
12. The default web home page of the IIS Web server is displayed in the browser window. One of the
three virtual machines in the backend pool will respond.

209
13. If you click the refresh button in the browser a few times, you will see that the response comes
randomly from the different VMs in the backend pool of the internal load balancer.
Clean up resources
[!NOTE]
Remember to remove any newly created Azure resources that you no longer use. Removing unused
resources ensures you will not see unexpected charges.
command:
[!NOTE]
The command executes asynchronously (as determined by the -AsJob parameter), so while you will be
able to run another PowerShell command immediately afterwards within the same PowerShell session, it
will take a few minutes before the resource groups are actually removed.
explore-azure-traffic-manager
5-Explore Azure Traffic Manager
Azure Traffic Manager is a DNS-based traffic load balancer. This service allows you to distribute traffic to
your public facing applications across the global Azure regions. Traffic Manager also provides your public
endpoints with high availability and quick responsiveness.
Traffic Manager uses DNS to direct the client requests to the appropriate service endpoint based on a
traffic-routing method. Traffic manager also provides health monitoring for every endpoint. The endpoint
can be any Internet-facing service hosted inside or outside of Azure. Traffic Manager provides a range of
traffic-routing methods and endpoint monitoring options to suit different application needs and auto-
matic failover models. Traffic Manager is resilient to failure, including the failure of an entire Azure region.
Key features of Traffic Manager

Traffic Manager offers the several key features.
Feature Description
210
Increase application availability Traffic Manager delivers high availability for your
critical applications by monitoring your endpoints
and providing automatic failover when an end-
point goes down.
Improve application performance Azure allows you to run cloud services and
websites in datacenters located around the world.
Traffic Manager can improve the responsiveness of
your website by directing traffic to the endpoint
with the lowest latency.
Service maintenance without downtime You can have planned maintenance done on your
applications without downtime. Traffic Manager
can direct traffic to alternative endpoints while the
maintenance is in progress.
Combine hybrid applications Traffic Manager supports external, non-Azure
endpoints enabling it to be used with hybrid cloud
and on-premises deployments, including the
burst-to-cloud, migrate-to-cloud, and failover-to-
cloud scenarios.
Distribute traffic for complex deployments Using nested Traffic Manager profiles, multiple
traffic-routing methods can be combined to create
sophisticated and flexible rules to scale to the
needs of larger, more complex deployments.
How Traffic Manager works

Azure Traffic Manager enables you to control the distribution of traffic across your application endpoints.
An endpoint is any Internet-facing service hosted inside or outside of Azure.
Traffic Manager provides two key benefits:
●● Distribution of traffic according to one of several traffic-routing methods
●● Continuous monitoring of endpoint health and automatic failover when endpoints fail
When a client attempts to connect to a service, it must first resolve the DNS name of the service to an IP
address. The client then connects to that IP address to access the service.
Traffic Manager uses DNS to direct clients to specific service endpoints based on the rules of the traf-
fic-routing method. Clients connect to the selected endpoint directly. Traffic Manager is not a proxy or a
gateway. Traffic Manager does not see the traffic passing between the client and the service.
Traffic Manager works at the DNS level which is at the Application layer (Layer-7).
Traffic Manager example deployment

Contoso Corp have developed a new partner portal. The URL for this portal is https://partners.contoso.
com/login.aspx.
The application is hosted in three regions of Azure. To improve availability and maximize global perfor-
mance, they use Traffic Manager to distribute client traffic to the closest available endpoint.
To achieve this configuration, they complete the following steps:
1. Deploy three instances of their service. The DNS names of these deployments are contoso-us.
cloudapp.net, contoso-eu.cloudapp.net, and contoso-asia.cloudapp.net.
211
2. Create a Traffic Manager profile, named contoso.trafficmanager.net, and configure it to use the
‘Performance’ traffic-routing method across the three endpoints.
3. Configure their vanity domain name, partners.contoso.com, to point to contoso.trafficmanager.net,
using a DNS CNAME record.
Traffic Manager example client usage

Following on from the deployment example above; when a client requests the page https://partners.
contoso.com/login.aspx, the client performs the following steps to resolve the DNS name and establish a
connection:
1. The client sends a DNS query to its configured recursive DNS service to resolve the name ‘partners.
contoso.com’. A recursive DNS service, sometimes called a 'local DNS' service, does not host DNS
212
domains directly. Rather, the client off-loads the work of contacting the various authoritative DNS
services across the Internet needed to resolve a DNS name.
2. To resolve the DNS name, the recursive DNS service finds the name servers for the ‘contoso.com’
domain. It then contacts those name servers to request the 'partners.contoso.com' DNS record. The
contoso.com DNS servers return the CNAME record which points to contoso.trafficmanager.net.
3. Next, the recursive DNS service finds the name servers for the ‘trafficmanager.net’ domain, which are
provided by the Azure Traffic Manager service. It then sends a request for the 'contoso.trafficmanager.
net' DNS record to those DNS servers.
4. The Traffic Manager name servers receive the request. They choose an endpoint based on:
●● The configured state of each endpoint (disabled endpoints are not returned)
●● The current health of each endpoint, as determined by the Traffic Manager health checks.
●● The chosen traffic-routing method.
5. The chosen endpoint is returned as another DNS CNAME record. In this case, let us suppose conto-
so-eu.cloudapp.net is returned.
6. Next, the recursive DNS service finds the name servers for the ‘cloudapp.net’ domain. It contacts those
name servers to request the 'contoso-eu.cloudapp.net' DNS record. A DNS ‘A’ record containing the
IP address of the EU-based service endpoint is returned.
7. The recursive DNS service consolidates the results and returns a single DNS response to the client.
8. The client receives the DNS results and connects to the given IP address. The client connects to the
application service endpoint directly, not through Traffic Manager. Since it is an HTTPS endpoint, the
client performs the necessary SSL/TLS handshake, and then makes an HTTP GET request for the ‘/
login.aspx’ page.
The recursive DNS service caches the DNS responses it receives. The DNS resolver on the client device
also caches the result. Caching enables subsequent DNS queries to be answered more quickly by using
data from the cache rather than querying other name servers. The duration of the cache is determined by
the ‘time-to-live’ (TTL) property of each DNS record. Shorter values result in faster cache expiry and thus
more round-trips to the Traffic Manager name servers. Longer values mean that it can take longer to
direct traffic away from a failed endpoint. Traffic Manager allows you to configure the TTL used in Traffic
Manager DNS responses to be as low as 0 seconds and as high as 2,147,483,647 seconds (the maximum
range compliant with RFC-1035), enabling you to choose the value that best balances the needs of your
application.
Traffic routing methods

Azure Traffic Manager supports six traffic-routing methods to determine how to route network traffic to
the various service endpoints. For any profile, Traffic Manager applies the traffic-routing method associat-
ed to it to each DNS query it receives. The traffic-routing method determines which endpoint is returned
in the DNS response.
The following traffic routing methods are available in Traffic Manager:
Routing method When to use

213
Priority Select this routing method when you want to have

a primary service endpoint for all traffic. You can
provide multiple backup endpoints in case the
primary or one of the backup endpoints is unavail-
able.
Weighted Select this routing method when you want to
distribute traffic across a set of endpoints based
on their weight. Set the weight the same to
distribute evenly across all endpoints.
Performance Select the routing method when you have end-
points in different geographic locations, and you
want end users to use the "closest" endpoint for
the lowest network latency.
Geographic Select this routing method to direct users to
specific endpoints (Azure, External, or Nested)
based on where their DNS queries originate from
geographically. With this routing method, it
enables you to be compliant with scenarios such
as data sovereignty mandates, localization of
content & user experience and measuring traffic
from different regions.
MultiValue Select this routing method for Traffic Manager
profiles that can only have IPv4/IPv6 addresses as
endpoints. When a query is received for this
profile, all healthy endpoints are returned.
Subnet Select this routing method to map sets of end-us-
er IP address ranges to a specific endpoint. When
a request is received, the endpoint returned will be
the one mapped for that request’s source IP
address.
Routing method examples

This is an example of the Priority routing method.
214
For more information, see Priority traffic-routing method7.

This is an example of the Weighted routing method.
7 https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-routing-methods
215
For more information, see Weighted traffic-routing method8.

This is an example of the Performance routing method.
216
For more information, see Performance traffic-routing method9.

This is an example of the Geographic routing method.
217
For more information, see Geographic traffic-routing method10.
Traffic Manager profiles

Within a Traffic Manager profile, you can only configure one traffic routing method at a time. You can
select a different traffic routing method for your profile at any time. Your changes will be applied within a
minute without any downtime.
All Traffic Manager profiles have health monitoring and automatic failover of endpoints.
Nested Traffic Manager profiles

As mentioned earlier, each Traffic Manager profile can only specify one traffic-routing method. However,
you may have scenarios that require more complicated traffic routing than the routing that can be
provided by a single Traffic Manager profile. In these situations, you can combine traffic routing methods
by using nested Traffic Manager profiles to gain the benefits of multiple traffic-routing methods. Nested
profiles enable you to override the default Traffic Manager behavior to support larger and more complex
traffic-routing configurations for your application deployments.
218
The example and diagrams below illustrate the combining of the Performance and Weighted traf-
fic-routing methods in nested profiles.
Example: combining ‘performance’ and 'weighted' traffic

routing methods using nested profiles
Suppose that you deployed an application in the following Azure regions: West US, West Europe, and
East Asia. You use the Performance traffic-routing method to distribute traffic to the region closest to
the user.
But what if you wanted to test an update to your service before rolling it out more widely, and you
wanted to use the Weighted traffic-routing method to direct a small percentage of traffic to your test
deployment?
You would set up the test deployment alongside the existing production deployment in West Europe.
As you just learned, you cannot combine both the Weighted and Performance traffic-routing methods
in a single profile. Therefore, to support this scenario, you would create a Traffic Manager profile using
the two West Europe endpoints and the Weighted traffic-routing method. Then you would add this child
profile as an endpoint to the parent profile. The parent profile would still use the Performance traf-
fic-routing method and would contain the other global deployments as endpoints.
The diagram below illustrates this example scenario:
219
With the above configuration, traffic directed via the parent profile (using the Performance routing
method) distributes traffic across regions normally. While, within West Europe, the nested child profile
(using the Weighted routing method) distributes traffic to the production and test endpoints according
to the weights assigned.
When the parent profile uses the Performance traffic-routing method, each endpoint must be assigned
a location, which is done when you configure the endpoint. Choose the Azure region closest to your
deployment.
For more information, and for more example scenarios, see Nested Traffic Manager profiles11.
Traffic Manager endpoints

Azure Traffic Manager enables you to control how network traffic is distributed to application deploy-
ments running in your different datacenters. You configure each application deployment as an endpoint
in Traffic Manager. When Traffic Manager receives a DNS request, it chooses an available endpoint to
return in the DNS response. Traffic manager bases the choice on the current endpoint status and the
traffic-routing method.
Traffic Manager supports three types of endpoints:
●● Azure endpoints - Use this type of endpoint to load-balance traffic to a cloud service, web app, or
public IP address in the same subscription within Azure.
●● External endpoints - Use this type of endpoint to load balance traffic for IPv4/IPv6 addresses,
FQDNs, or for services hosted outside Azure. These services can either be on-premises or with a
different hosting provider.
●● Nested endpoints - Use this type of endpoint to combine Traffic Manager profiles to create more
flexible traffic-routing schemes to support the needs of larger, more complex deployments. With
Nested endpoints, a child profile is added as an endpoint to a parent profile. Both the child and
parent profiles can contain other endpoints of any type, including other nested profiles.
There are no restrictions on how different endpoints types can be combined in a single Traffic Manager
profile; each profile can contain any mix of endpoint types.
11 https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-nested-profiles
220
You add endpoints to existing Traffic Manager profiles from the Endpoints page of a Traffic Manager
profile in the Azure portal.
For more information, visit Traffic Manager endpoints12.
Configuring Traffic Manager profiles

This example shows how to create and configure a new Traffic Manager profile to direct client traffic
based on endpoint priority.
From the Azure portal home page, select Create a resource. In the search box, query for ‘Traffic Manager
profile’, and then click Traffic Manager profile.
Click Create.
You need to enter the following information on the Create Traffic Manager profile page.
12 https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-endpoint-types
221
Field Information
Name Enter a unique name for the Traffic Manager
profile.
Routing method Select the routing method to use in this profile.
Subscription Select the subscription from the list that you want
this profile to be applied to.
Resource group Select the appropriate resource group from the list
or create a new one.
Resource group location The Azure Traffic Manager service is global and
not bound to a location. This setting refers to the
location of the selected resource group and has
no impact on the runtime availability of your
Traffic Manager profile.
Click Create to create the profile.
The next step is to add endpoints to the Traffic Manager profile.

From the Azure portal home page, select All resources, then select the Traffic Manager profile from the
list.
222
On the Traffic manager profile page, under Settings, select Endpoints, then click Add.
You then enter the required information on the Add endpoint page.
Field Information
Type Select the type of endpoint to add. You can select
from the following endpoint types: Azure end-
pointsExternal endpointsNested endpoints
Depending on which endpoint type you select
here, the remaining options will differ.
Name Enter a unique name for the endpoint.
223
Target resource type (for Azure endpoints only) If you select the Azure endpoint type, you can
select from the following resource types: Cloud
serviceApp ServiceApp Service slotPublic IP
address
Target resource (for Azure and Nested endpoints Select the appropriate target service, IP address, or
only) profile from the list. The available options will
differ depending on which endpoint type and
target resource type are selected above.
Fully-qualified domain name (FQDN) or IP (for Specify the FQDN or IP address for the external
External endpoints only) endpoint.
Priority Specify the priority for this endpoint. If you enter
1, then all traffic goes to this endpoint when it's
healthy.
Minimum child endpoints (for Nested endpoints Specify the minimum number of endpoints that
only) must be available in the child Traffic Manager
profile for it to receive traffic. If the available
endpoints in the child profile falls below this
threshold, this endpoint will be considered as
degraded.
Custom Header setting (optional setting) You can configure custom headers for your
endpoint, using the following paired formatting:
host:contoso.com,customheader:contoso The
maximum number of supported pairs is 8, and
they are applicable for both the HTTP and HTTPS
protocols. These endpoint Custom Header settings
override the settings configured in a profile.
Add as disabled (optional setting) Disabling an endpoint in Traffic Manager can be
useful to temporarily remove traffic from an
endpoint that is in maintenance mode or being
redeployed. Once the endpoint is running again, it
can be re-enabled.
Click Add to add the endpoint to the Traffic Manager profile.
224
If you are adding a failover endpoint for another Azure region, then you would add another endpoint for
that region. This would point to the application target resource in the other region and would have a
priority setting of 2.
225
When you add endpoints to a Traffic Manager profile, their status will be checked.
Once they have been checked their Monitor status changes to Online.
Configuring endpoint monitoring

Azure Traffic Manager includes built-in endpoint monitoring and automatic endpoint failover. This feature
helps you deliver high-availability applications that are resilient to endpoint failure, including Azure
region failures.
To configure endpoint monitoring, you open the Configuration page for the Traffic Manager profile.
Then, under the Endpoint monitor settings section, you specify the following settings for the Traffic
Manager profile:
226
Setting Description
Protocol Choose HTTP, HTTPS, or TCP as the protocol that
Traffic Manager uses when probing your endpoint
to check its health. HTTPS monitoring doesn't
verify whether your TLS/SSL certificate is valid; it
only checks that the certificate is present.
Port Choose the port used for the request.
Path This configuration setting is valid only for the
HTTP and HTTPS protocols, for which specifying
the path setting is required. Providing this setting
for the TCP monitoring protocol results in an error.
For HTTP and HTTPS protocol, give the relative
path and the name of the webpage or the file that
the monitoring accesses. A forward slash (/) is a
valid entry for the relative path. This value implies
that the file is in the root directory (default).
Custom Header settings This configuration setting helps you add specific
HTTP headers to the health checks that Traffic
Manager sends to endpoints under a profile. The
custom headers can be specified at a profile level
to be applicable for all endpoints in that profile
and / or at an endpoint level applicable only to
that endpoint. You can use custom headers for
health checks of endpoints in a multi-tenant
environment. That way it can be routed correctly
to their destination by specifying a host header.
You can also use this setting by adding unique
headers that can be used to identify Traffic
Manager originated HTTP(S) requests and pro-
cesses them differently. You can specify up to
eight header:value pairs separated by a comma.
Example - header1:value1, header2:value2
Expected Status Code Ranges This setting allows you to specify multiple success
code ranges in the format 200-299, 301-301. If
these status codes are received as response from
an endpoint when a health check is done, Traffic
Manager marks those endpoints as healthy. You
can specify a maximum of eight status code
ranges. This setting is applicable only to HTTP and
HTTPS protocol and to all endpoints. This setting
is at the Traffic Manager profile level and by
default the value 200 is defined as the success
status code.
227
Probing interval This value specifies how often an endpoint is

checked for its health from a Traffic Manager
probing agent. You can specify two values here: 30
seconds (normal probing) and 10 seconds (fast
probing). If no values are provided, the profile sets
to a default value of 30 seconds. Visit the Traffic
Manager Pricing (https://azure.microsoft.com/
pricing/details/traffic-manager) page to learn more
about fast probing pricing.
Tolerated number of failures This value specifies how many failures a Traffic
Manager probing agent tolerates before marking
that endpoint as unhealthy. Its value can range
between 0 and 9. A value of 0 means a single
monitoring failure can cause that endpoint to be
marked as unhealthy. If no value is specified, it
uses the default value of 3.
Probe timeout This property specifies the amount of time the
Traffic Manager probing agent should wait before
considering a health probe check to an endpoint a
failure. If the Probing Interval is set to 30 seconds,
then you can set the Timeout value between 5 and
10 seconds. If no value is specified, it uses a
default value of 10 seconds. If the Probing Interval
is set to 10 seconds, then you can set the Timeout
value between 5 and 9 seconds. If no Timeout
value is specified, it uses a default value of 9
seconds.
Click Save when you have finished endpoint monitor configuration.
228
How endpoint monitoring works

When the monitoring protocol is set as HTTP or HTTPS, the Traffic Manager probing agent makes a GET
request to the endpoint using the protocol, port, and relative path given. An endpoint is considered
healthy if probing agent receives a 200-OK response, or any of the responses configured in the Expected
status code *ranges. If the response is a different value or no response get received within the timeout
period, the Traffic Manager probing agent reattempts according to the Tolerated Number of Failures
setting. No reattempts are done if this setting is 0. The endpoint is marked unhealthy if the number of
consecutive failures is higher than the Tolerated Number of Failures setting.
When the monitoring protocol is TCP, the Traffic Manager probing agent creates a TCP connection
request using the port specified. If the endpoint responds to the request with a response to establish the
connection, that health check is marked as a success. The Traffic Manager probing agent resets the TCP
connection. In cases where the response is a different value or no response get received within the
timeout period, the Traffic Manager probing agent reattempts according to the Tolerated Number of
Failures setting. No reattempts are made if this setting is 0. If the number of consecutive failures is higher
than the Tolerated Number of Failures setting, then that endpoint is marked unhealthy.
In all cases, Traffic Manager probes from multiple locations. The consecutive failure determines what
happen within each region. That's why endpoints are receiving health probes from Traffic Manager with a
higher frequency than the setting used for Probing Interval.
For HTTP or HTTPS monitoring protocol, a common practice on the endpoint side is to implement
a custom page within your application - for example, /health.aspx. Using this path for monitoring,
229
you can perform application-specific checks, such as checking performance counters or verifying
database availability. Based on these custom checks, the page returns an appropriate HTTP status
code.
All endpoints in a Traffic Manager profile share monitoring settings. If you need to use different monitor-
ing settings for different endpoints, you can create nested Traffic Manager profiles13.
Multiple choice
What are two benefits of Traffic Manager?
Distribution of traffic and continuous monitoring of endpoint health.{{Correct, Distribution of traffic
according to one of several traffic-routing methods and continuous monitoring of endpoint health
and automatic failover when endpoints fail.}}
Resolution of DNS queries and reduced need for DNS servers.{{Incorrect, Traffic Manager uses DNS to
direct clients to specific service endpoints based on the rules of the traffic-routing method, it does not
resolve queries itself.}}
Supports one traffic-routing method and integrates with DNS.{{Incorrect, Azure Traffic Manager
supports six traffic-routing methods. The traffic-routing method determines which endpoint is
returned in the DNS response.}}
Multiple choice
Which traffic-routing method should be use when end users need to use the "closest" endpoint for the
lowest network latency?
Performance{{Correct, Use when you have endpoints in different geographic locations, and you want
end users to use the "closest" endpoint for the lowest network latency.}}
Geographic{{Incorrect, Select this routing method to direct users to specific endpoints (Azure, Exter-
nal, or Nested) based on where their DNS queries originate from geographically.}}
Priority{{Incorrect, Select this routing method when you want to have a primary service endpoint for
all traffic. You can provide multiple backup endpoints in case the primary or one of the backup
endpoints is unavailable.}}
6-Exercise: create a Traffic Manager profile using

the Azure portal
In this exercise, you will create a Traffic Manager profile to deliver high availability for the fictional
Contoso Ltd organization's web application.
You will create two instances of a web application deployed in two different regions (East US and West
Europe). The East US region will act as a primary endpoint for Traffic Manager, and the West Europe
region will act as a failover endpoint.
13 https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-nested-profiles
230
You will then create a Traffic Manager profile based on endpoint priority. This profile will direct user traffic
to the primary site running the web application. Traffic Manager will continuously monitor the web
application, and if the primary site in East US is unavailable, it will provide automatic failover to the
backup site in West Europe.
The diagram below approximately illustrates the environment you will be deploying in this exercise.

●● Task 1: Create the web apps
●● Task 2: Create a Traffic Manager profile
●● Task 3: Add Traffic Manager endpoints
●● Task 4: Test the Traffic Manager profile
Task 1: Create the web apps

In this section, you will create two instances of a web application deployed in the two different Azure
regions.
1. On the Azure portal home page, click Create a resource, then select Web App (if this resource type is
not listed on the page, use the search box at the top of the page to search for it and select it).
2. On the Create Web App page, on the Basics tab, use the information in the table below to create the
first web application.
Setting Value
Resource group Select Create new Name: Contoso-RG-TM1
Name ContosoWebAppEastUS
Publish Code
Runtime stack ASP.NET V4.8
Operating system Windows
Region East US
Windows Plan Select Create new Name: ContosoAppService-
PlanEastUS
Sku and size Standard S1 100 total ACU, 1.75-GB memory
3. Click Next : Deployment (Preview), then click Next : Monitoring.
4. On the Monitoring tab, select the No option for Enable Application Insights.
231
6. Click Create. When the Web App successfully deploys, it creates a default web site.
7. Repeat steps 1-6 above to create a second web app. Use the same settings as before except for the
information in the table below.
Setting Value
Resource group Select Create new Name: Contoso-RG-TM2
Name ContosoWebAppWestEurope
Region West Europe
Windows Plan Select Create new Name: ContosoAppService-
PlanWestEurope
8. On the Azure home page, click All services, in the left navigation menu, select Web, and then click
App Services.
9. You should see the two new web apps listed.
232
Task 2: Create a Traffic Manager profile

Now you will create a Traffic Manager profile that directs user traffic based on endpoint priority.
2. In the search box at the top of the page, type Traffic Manager profile, and then select it from the
pop-up list.
3. Click Create.
4. On the Create Traffic Manager profile page, use the information in the table below to create the
Traffic Manager profile.
Setting Value
Name Contoso-TMProfile
Routing method Priority
Resource group Contoso-RG-TM1
Resource group location East US
5. Click Create.
233
Task 3: Add Traffic Manager endpoints

In this section, you will add the website in the East US as the primary endpoint to route all the user traffic.
You will then add the website in West Europe as a failover endpoint. If the primary endpoint becomes
unavailable, then traffic will automatically be routed to the failover endpoint.
1. On the Azure portal home page, click All resources, then click on Contoso-TMProfile in the resourc-
es list.
2. Under Settings, select Endpoints, and then click Add.
3. On the Add endpoint page, enter the information from the table below.
Setting Value
Type Azure endpoint
Name myPrimaryEndpoint
Target resource type App Service
Target resource ContosoWebAppEastUS (East US)
Priority 1
4. Click Add.
5. Repeat steps 2-4 above to create the failover endpoint. Use the same settings as before except for the
information in the table below.
Setting Value
Name myFailoverEndpoint
Target resource ContosoWebAppWestEurope (West Europe)
Priority 2
6. Setting a priority of 2 means that traffic will route to this failover endpoint if the configured primary
endpoint becomes unhealthy.
7. The two new endpoints are displayed in the Traffic Manager profile. Notice that after a few minutes
the Monitoring status should change to Online.
234
Task 4: Test the Traffic Manager profile

In this section, you will check the DNS name of your Traffic Manager profile, and then you will configure
the primary endpoint so that it is unavailable. You will then verify that the web app is still available, to test
that the Traffic Manager profile is successfully sending traffic to the failover endpoint.
1. On the Contoso-TMProfile page, click Overview.
2. On the Overview screen, copy the DNS name entry to the clipboard (or take note of it somewhere).
3. Open a web browser tab, and paste (or enter) the DNS name entry (contoso-tmprofile.trafficmanager.
net) into the address bar, and press Enter.
4. The web app's default web site should be displayed.
235
5. Currently all traffic is being sent to the primary endpoint as you set its Priority to 1.
6. To test the failover endpoint is working properly, you need to disable the primary site.
7. On the Contoso-TMProfile page, on the overview screen, select myPrimaryEndpoint.
8. On the myPrimaryEndpoint page, under Status, click Disabled, and then click Save.
9. Close the myPrimaryEndpoint page (click the X in the top right corner of the page).
10. On the Contoso-TMProfile page, the Monitor status for myPrimaryEndpoint should now be
Disabled.
236
11. Open a new web browser session, and paste (or enter) the DNS name entry (contoso-tmprofile.
trafficmanager.net) into the address bar, and press Enter.
12. Verify that the web app is still responding. As the primary endpoint was not available, the traffic was
instead routed to the failover endpoint to allow the web site to still function.

command:
7-Summary
In this module, you had a high-level overview of the different load-balancing options available to you in
Azure. You learned in detail about two of those Azure load-balancing technologies, namely Azure Load
Balancer and Azure Traffic Manager.
You now have the knowledge required to help you to load balance network traffic in your Azure net-
works.
●● Understand options for load balancing
●● Design and implement an Azure Load Balancer
●● Implement a Traffic Manager profile
237
Answers
Multiple choice
An engineer has a secure web application that experiences high traffic, and they want to use a load
balancer to distribute the workload. Which load balancers will support this type of traffic?
■■ Azure Application Gateway and Azure Front Door.{{Correct, Secure web applications use HTTPS traffic.
Azure Application Gateway and Azure Front Door support HTTPS traffic.}}
Azure Load Balancer and Traffic Manager.{{Incorrect, Secure web applications use HTTPS traffic. Azure
Load Balancer and Traffic Manager support non-HTTPS traffic.}}
Azure Application Gateway only.{{Incorrect, Secure web applications use HTTPS traffic. Azure Applica-
tion Gateway does support HTTPS traffic, but it's not the only load balancer that does.}}
Explanation
Multiple choice
Which type of load balancing services distribute traffic within virtual networks across virtual machines?
■■ Regional.{{Correct, Regional load-balancing services distribute traffic within virtual networks across
virtual machines (VMs) or zonal and zone-redundant service endpoints within a region.}}
Global.{{Incorrect, Global load-balancing services distribute traffic across regional backends, clouds,
or hybrid on-premises services.}}
Regional and Global.{{Incorrect, Regional load-balancing services distribute traffic within virtual
networks across virtual machines (VMs) or zonal and zone-redundant service endpoints within a
region, whereas Global load-balancing services distribute traffic across regional backends, clouds, or
hybrid on-premises services.}}
Explanation
Multiple choice
Which of the following statement about external load balancers is correct?
■■ They have a public IP address.{{Correct, External load balancers have public IP addresses.}}
They don't have a listener IP address.{{Incorrect, External load balancers have public IP addresses.}}
They have a private, front-facing IP address.{{Incorrect, External load balancers have public IP address-
es.}}
Explanation
Multiple choice
When deploying a new Azure Load Balancer that must support outbound traffic rules. Which SKU should
be selected?
■■ Standard{{Correct, Standard SKU supports outbound rules through declarative outbound NAT config-
uration.}}
Basic{{Incorrect, Basic SKU does not support outbound rules.}}
Either Standard or Basic{{Incorrect, Basic SKU does not support outbound rules.}}
Explanation
238
Multiple choice
What are two benefits of Traffic Manager?
■■ Distribution of traffic and continuous monitoring of endpoint health.{{Correct, Distribution of traffic
according to one of several traffic-routing methods and continuous monitoring of endpoint health
and automatic failover when endpoints fail.}}
Resolution of DNS queries and reduced need for DNS servers.{{Incorrect, Traffic Manager uses DNS to
direct clients to specific service endpoints based on the rules of the traffic-routing method, it does not
resolve queries itself.}}
Supports one traffic-routing method and integrates with DNS.{{Incorrect, Azure Traffic Manager
supports six traffic-routing methods. The traffic-routing method determines which endpoint is
returned in the DNS response.}}
Explanation
Multiple choice
Which traffic-routing method should be use when end users need to use the "closest" endpoint for the
lowest network latency?
■■ Performance{{Correct, Use when you have endpoints in different geographic locations, and you want
end users to use the "closest" endpoint for the lowest network latency.}}
Geographic{{Incorrect, Select this routing method to direct users to specific endpoints (Azure, Exter-
nal, or Nested) based on where their DNS queries originate from geographically.}}
Priority{{Incorrect, Select this routing method when you want to have a primary service endpoint for
all traffic. You can provide multiple backup endpoints in case the primary or one of the backup
endpoints is unavailable.}}
Explanation
Module 5 Load balance HTTP(S) traffic in Az-
ure
Load balance HTTP(S) traffic in Azure

1-Introduction
As an organization migrates infrastructure and applications to Azure, network engineers need to ensure
that end users have consistent access to the applications, services, and data.
Azure provides load balancing tools to support consistency of access. Load balancing is the process of
distributing network traffic across multiple servers. This ensures no single server bears too much demand.
By spreading the work evenly, load balancing improves application responsiveness, and increases availa-
bility of applications and services for users. Load balancers also have additional capabilities including
application security. In this module you will learn about using Azure Front Door, and Azure Application
Gateway load balancing services.
Learning objectives
●● Design and implement Azure Application Gateway
●● Implement Azure Front Door
Prerequisites
(DNS), and routing
240
2-Design Azure Application Gateway

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web
applications. Traditional load balancers operate at the transport layer (OSI layer 4 - TCP and UDP) and
route traffic based on source IP address and port, to a destination IP address and port.
Application Gateway can make routing decisions based on additional attributes of an HTTP request, for
example URI path or host headers. For example, you can route traffic based on the incoming URL. So, if /
images is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) config-
ured for images. If /video is in the URL, that traffic is routed to another pool that's optimized for videos.
This type of routing is known as application layer (OSI layer 7) load balancing. Azure Application Gateway
can do URL-based routing and more.
Application Gateway features

●● Support for the HTTP, HTTPS, HTTP/2 and WebSocket protocols.
●● A web application firewall to protect against web application vulnerabilities.
241
●● End-to-end request encryption.

●● Autoscaling, to dynamically adjust capacity as your web traffic load change.
●● Redirection: Redirection can be used to another site, or from HTTP to HTTPS.
●● Rewrite HTTP headers: HTTP headers allow the client and server to pass parameter information with
the request or the response.
●● Custom error pages: Application Gateway allows you to create custom error pages instead of
displaying default error pages. You can use your own branding and layout using a custom error page.
Determine Application Gateway routing

Clients send requests to your web apps to the IP address or DNS name of the gateway. The gateway
routes requests to a selected web server in the back-end pool, using a set of rules configured for the
gateway to determine where the request should go.
There are two primary methods of routing traffic, path-based routing, and multiple site routing.
Path-based routing
Path-based routing sends requests with different URL paths different pools of back-end servers. For
example, you could direct requests with the path /video/* to a back-end pool containing servers that are
optimized to handle video streaming, and direct /images/* requests to a pool of servers that handle
image retrieval.
Multiple site routing

Multiple site routing configures more than one web application on the same application gateway in-
stance. In a multi-site configuration, you register multiple DNS names (CNAMEs) for the IP address of the
Application Gateway, specifying the name of each site. Application Gateway uses separate listeners to
wait for requests for each site. Each listener passes the request to a different rule, which can route the
requests to servers in a different back-end pool. For example, you could direct all requests for http://
contoso.com1 to servers in one back-end pool, and requests for http://fabrikam.com2 to another
back-end pool. The following diagram shows this configuration.
1 http://contoso.com/
2 http://fabrikam.com/
242
Multi-site configurations are useful for supporting multi-tenant applications, where each tenant has its
own set of virtual machines or other resources hosting a web application.
Choosing an Azure Application Gateway SKU

Application Gateway is available under a Standard_v2 SKU. Web Application Firewall (WAF) is available
under a WAF_v2 SKU. The v2 SKU offers performance enhancements and adds support for critical new
features like autoscaling, zone redundancy, and support for static VIPs. Existing features under the
Standard and WAF SKU continue to be supported in the new v2 SKU.
The new v2 SKU includes the following enhancements:
Autoscaling: Application Gateway or WAF deployments under the autoscaling SKU can scale out or in
based on changing traffic load patterns. Autoscaling also removes the requirement to choose a deploy-
ment size or instance count during provisioning. This SKU offers true elasticity. In the Standard_v2 and
WAF_v2 SKU, Application Gateway can operate both in fixed capacity (autoscaling disabled) and in
autoscaling enabled mode. Fixed capacity mode is useful for scenarios with consistent and predictable
workloads. Autoscaling mode is beneficial in applications that see variance in application traffic.
Zone redundancy: An Application Gateway or WAF deployment can span multiple Availability Zones,
removing the need to provision separate Application Gateway instances in each zone with a Traffic
Manager. You can choose a single zone or multiple zones where Application Gateway instances are
deployed, which makes it more resilient to zone failure. The backend pool for applications can be similar-
ly distributed across availability zones.
Not all Azure regions support availability zones yet.
Static VIP: Application Gateway v2 SKU supports the static VIP type exclusively. This ensures that the VIP
associated with the application gateway doesn't change for the lifecycle of the deployment, even after a
restart. There isn't a static VIP in v1, so you must use the application gateway URL instead of the IP
address for domain name routing to App Services via the application gateway.
Header Rewrite: Application Gateway allows you to add, remove, or update HTTP request and response
headers with v2 SKU.
Key Vault Integration: Application Gateway v2 supports integration with Key Vault for server certificates
that are attached to HTTPS enabled listeners.
243
Azure Kubernetes Service Ingress Controller: The Application Gateway v2 Ingress Controller allows the
Azure Application Gateway to be used as the ingress for an Azure Kubernetes Service (AKS) known as AKS
Cluster.
Performance enhancements: The v2 SKU offers up to 5X better TLS offload performance as compared
to the Standard/WAF SKU.
Faster deployment and update time: The v2 SKU provides faster deployment and update time as
compared to Standard/WAF SKU. This also includes WAF configuration changes.
Choosing between Azure Application Gateway v2 and Web

Application Firewall V2 SKUs
When choosing whether to deploy an Application Gateway or a Web Application Firewall, there are
several factors you must consider, including the scaling strategy you want to follow and the cost of the
service.
Scaling Application Gateway and WAF v2

Application Gateway and WAF can be configured to scale in two modes:
Autoscaling: With autoscaling enabled, the Application Gateway and WAF v2 SKUs scale up or down
based on application traffic requirements. This mode offers better elasticity to your application and
eliminates the need to guess the application gateway size or instance count. This mode also allows you to
save cost by not requiring the gateway to run at peak provisioned capacity for anticipated maximum
traffic load. You must specify a minimum and optionally maximum instance count. Minimum capacity
ensures that Application Gateway and WAF v2 don't fall below the minimum instance count specified,
even in the absence of traffic. Each instance is roughly equivalent to 10 additional reserved Capacity
Units. Zero signifies no reserved capacity and is purely autoscaling in nature. You can also optionally
specify a maximum instance count, which ensures that the Application Gateway doesn't scale beyond the
specified number of instances. You will only be billed for traffic served by the Gateway. The instance
counts can range from 0 to 125. The default value for maximum instance count is 20 if not specified.
Manual: You can alternatively choose Manual mode where the gateway won't autoscale. In this mode, if
there is more traffic than the Application Gateway or WAF can handle, it could result in traffic loss. With
manual mode, specifying instance count is mandatory. Instance count can vary from 1 to 125 instances.
Pricing
With the v2 SKU, the pricing model is driven by consumption and is no longer attached to instance
counts or sizes. The v2 SKU pricing has two components:
Fixed price: This is hourly (or partial hour) price to provision a Standard_v2 or WAF_v2 Gateway. Please
note that 0 additional minimum instances still ensure high availability of the service which is always
included with fixed price.
Capacity Unit price: This is a consumption-based cost that is charged in addition to the fixed cost.
Capacity unit charge is also computed hourly or partial hourly. There are three dimensions to capacity
unit - compute unit, persistent connections, and throughput. Compute unit is a measure of processor
capacity consumed. Factors affecting compute unit are TLS connections/sec, URL Rewrite computations,
and WAF rule processing. Persistent connection is a measure of established TCP connections to the
application gateway in each billing interval. Throughput is average Megabits/sec processed by the system
in each billing interval. The billing is done at a Capacity Unit level for anything above the reserved
instance count.
244
Each capacity unit is composed of at most: 1 compute unit, 2500 persistent connections, and 2.22-Mbps
throughput.
3-Configure Azure Application Gateway
Application Gateway has a series of components that combine to route requests to a pool of web servers
and to check the health of these web servers.
Frontend configuration
For the Application Gateway v2 SKU, there must be a public frontend IP configuration. You can still have
both a Public and a Private frontend IP configuration, but Private only frontend IP configuration (Only ILB
mode) is currently not enabled for the v2 SKU.
You can configure the Frontend IP to be Public or Private as per your use case.
Backend configuration
The backend pool is used to route requests to the backend servers that serve the request. Backend pools
can be composed of NICs, virtual machine scale sets, public IP addresses, internal IP addresses, fully
qualified domain names (FQDN), and multi-tenant back-ends like Azure App Service. You can create an
empty backend pool with your application gateway and then add backend targets to the backend pool.
Configure health probes

Azure Application Gateway by default monitors the health of all resources in its back-end pool and
automatically removes any resource considered unhealthy from the pool. Application Gateway continues
to monitor the unhealthy instances and adds them back to the healthy back-end pool once they become
available and respond to health probes. By default, Application gateway sends the health probes with the
245
same port that is defined in the back-end HTTP settings. A custom probe port can be configured using a
custom health probe.
The source IP address Application Gateway uses for health probes depends on the backend pool:
●● If the server address in the backend pool is a public endpoint, then the source address is the applica-
tion gateway's frontend public IP address.
●● If the server address in the backend pool is a private endpoint, then the source IP address is from the
application gateway subnet's private IP address space.
Default health probe

An application gateway automatically configures a default health probe when you don't set up any
custom probe configurations. The monitoring behavior works by making an HTTP GET request to the IP
addresses or FQDN configured in the back-end pool. For default probes if the backend http settings are
configured for HTTPS, the probe uses HTTPS to test health of the backend servers.
For example: You configure your application gateway to use back-end servers A, B, and C to receive HTTP
network traffic on port 80. The default health monitoring tests the three servers every 30 seconds for a
healthy HTTP response with a 30 second timeout for each request. A healthy HTTP response has a status
code between 200 and 399. In this case, the HTTP GET request for the health probe will look like
http://127.0.0.1/.
If the default probe check fails for server A, the application gateway stops forwarding requests to this
server. The default probe continues to check for server A every 30 seconds. When server A responds
successfully to one request from a default health probe, application gateway starts forwarding the
requests to the server again.
Default health probe settings
The following table lists the default health probe settings:
Probe property Value Description

246
Probe URL <proto- The protocol and port are

col>://127.0.0.1:<port>/ inherited from the backend HTTP
settings to which the probe is
associated
Interval 30 The amount of time in seconds
to wait before the next health
probe is sent.
Time-out 30 The amount of time in seconds
the application gateway waits for
a probe response before mark-
ing the probe as unhealthy. If a
probe returns as healthy, the
corresponding backend is
immediately marked as healthy.
Unhealthy threshold 3 Governs how many probes to
send in case there's a failure of
the regular health probe. In v1
SKU, these additional health
probes are sent in quick succes-
sion to determine the health of
the backend quickly and don't
wait for the probe interval. In the
case of v2 SKU, the health
probes wait the interval. The
back-end server is marked down
after the consecutive probe
failure count reaches the un-
healthy threshold.
Probe intervals
All instances of Application Gateway probe the backend independent of each other. The same probe
configuration applies to each Application Gateway instance. For example, if the probe configuration is to
send health probes every 30 seconds and the application gateway has two instances, then both instances
send the health probe every 30 seconds.
If there are multiple listeners, then each listener probes the backend independent of each other.
Custom health probe

Custom probes give you more granular control over the health monitoring. When using custom probes,
you can configure a custom hostname, URL path, probe interval, and how many failed responses to
accept before marking the back-end pool instance as unhealthy, etc.
Custom health probe settings
The following table provides definitions for the properties of a custom health probe.
Probe property Description

Name Name of the probe. This name is used to identify
and refer to the probe in back-end HTTP settings.
247
Protocol Protocol used to send the probe. This must match

with the protocol defined in the back-end HTTP
settings it is associated to
Host Host name to send the probe with. In v1 SKU, this
value will be used only for the host header of the
probe request. In v2 SKU, it will be used both as
host header as well as SNI
Path Relative path of the probe. A valid path starts with
'/'
Port If defined, this is used as the destination port.
Otherwise, it uses the same port as the HTTP
settings that it is associated to. This property is
only available in the v2 SKU
Interval Probe interval in seconds. This value is the time
interval between two consecutive probes
Time-out Probe time-out in seconds. If a valid response isn't
received within this time-out period, the probe is
marked as failed
Unhealthy threshold Probe retry count. The back-end server is marked
down after the consecutive probe failure count
reaches the unhealthy threshold
Probe matching
By default, an HTTP(S) response with status code between 200 and 399 is considered healthy. Custom
health probes additionally support two matching criteria. Matching criteria can be used to optionally
modify the default interpretation of what makes a healthy response.
The following are matching criteria:
●● HTTP response status code match - Probe matching criterion for accepting user specified http
response code or response code ranges. Individual comma-separated response status codes or a
range of status code is supported.
●● HTTP response body match - Probe matching criterion that looks at HTTP response body and match-
es with a user specified string. The match only looks for presence of user specified string in response
body and isn't a full regular expression match.
Match criteria can be specified using the New-AzApplicationGatewayProbeHealthResponseMatch cmdlet.
Configure listeners
A listener is a logical entity that checks for incoming connection requests by using the port, protocol,
host, and IP address. When you configure a listener, you must enter values that match the corresponding
values in the incoming request on the gateway.
When you create an application gateway by using the Azure portal, you also create a default listener by
choosing the protocol and port for the listener. You can choose whether to enable HTTP2 support on the
listener. After you create the application gateway, you can edit the settings of that default listener
(appGatewayHttpListener) or create new listeners.
248
Listener type
When you create a new listener, you must choose between basic and multi-site.
●● Basic: All requests for any domain will be accepted and forwarded to backend pools.
●● Multi-site: Forward requests to different backend pools based on the host header or host names. You
must specify a host name that matches with the incoming request. This is because Application
Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP
address and port.
Order of processing listeners

For the v1 SKU, requests are matched according to the order of the rules and the type of listener. If a rule
with basic listener comes first in the order, it's processed first and will accept any request for that port
and IP combination. To avoid this, configure the rules with multi-site listeners first and push the rule with
the basic listener to the last in the list.
For the v2 SKU, multi-site listeners are processed before basic listeners.
Front-end IP address
Choose the front-end IP address that you plan to associate with this listener. The listener will listen to
incoming requests on this IP.
249
Front-end port
Choose the front-end port. Select an existing port or create a new one. Choose any value from the
allowed range of ports. You can use not only well-known ports, such as 80 and 443, but any allowed
custom port that's suitable. A port can be used for public-facing listeners or private-facing listeners.
Protocol
Choose HTTP or HTTPS:
●● HTTP: traffic between the client and the application gateway is unencrypted.
●● HTTPS: enables TLS termination or end-to-end TLS encryption. The TLS connection terminates at the
application gateway. Traffic between the client and the application gateway is encrypted. If you want
end-to-end TLS encryption, you must choose HTTPS and configure the back-end HTTP setting. This
ensures that traffic is re-encrypted when it travels from the application gateway to the back end.
To configure TLS termination and end-to-end TLS encryption, you must add a certificate to the listener to
enable the application gateway to derive a symmetric key. This is dictated by the TLS protocol specifica-
tion. The symmetric key is used to encrypt and decrypt the traffic that's sent to the gateway. The gateway
certificate must be in Personal Information Exchange (PFX) format. This format lets you export the private
key that the gateway uses to encrypt and decrypt traffic.
Redirection overview
You can use application gateway to redirect traffic. It has a generic redirection mechanism which allows
for redirecting traffic received at one listener to another listener or to an external site. This simplifies
application configuration, optimizes the resource usage, and supports new redirection scenarios includ-
ing global and path-based redirection.
A common redirection scenario for many web applications is to support automatic HTTP to HTTPS
redirection to ensure all communication between application and its users occurs over an encrypted path.
In the past, customers have used techniques such as creating a dedicated backend pool whose sole
purpose is to redirect requests it receives on HTTP to HTTPS. With redirection support in Application
Gateway, you can accomplish this simply by adding a new redirect configuration to a routing rule and
specifying another listener with HTTPS protocol as the target listener.
The following types of redirection are supported:
●● 301 Permanent Redirect
●● 302 Found
●● 303 See Other
●● 307 Temporary Redirect
Application Gateway redirection support offers the following capabilities:
●● Global redirection: Redirects from one listener to another listener on the gateway. This enables HTTP
to HTTPS redirection on a site.
●● Path-based redirection: Enables HTTP to HTTPS redirection only on a specific site area, for example a
shopping cart area denoted by /cart/*.
●● Redirect to external site: Requires a new redirect configuration object, which specifies the target
listener or external site to which redirection is desired. The configuration element also supports
250
options to enable appending the URI path and query string to the redirected URL. The redirect
configuration is attached to the source listener via a new rule.
For more information on configuring redirection in Application Gateway, see URL path-based redirec-
tion using PowerShell - Azure Application Gateway | Microsoft Docs3.
Application Gateway request routing rules

When you create an application gateway using the Azure portal, you create a default rule (rule1). This rule
binds the default listener (appGatewayHttpListener) with the default back-end pool (appGatewayBack-
endPool) and the default back-end HTTP settings (appGatewayBackendHttpSettings). After you create the
gateway, you can edit the settings of the default rule or create new rules.
Rule types:
●● Basic forwards all requests on the associated listener (for example, blog.contoso.com/*) to a single
back-end pool.
●● Path-based routes requests from specific URL paths to specific back-end pools.
Order of processing rules

For the v1 and v2 SKU, pattern matching of incoming requests is processed in the order that the paths
are listed in the URL path map of the path-based rule. If a request matches the pattern in two or more
paths in the path map, the path that's listed first is matched. And the request is forwarded to the back
end that's associated with that path.
Associated listener
Associate a listener to the rule so that the request-routing rule that's associated with the listener is
evaluated to determine the back-end pool to route the request to.
Associated back-end pool

Associate to the rule the back-end pool that contains the back-end targets that serve requests that the
listener receives.
For a basic rule, only one back-end pool is allowed. All requests on the associated listener are forwarded
to that back-end pool.
For a path-based rule, add multiple back-end pools that correspond to each URL path. The requests that
match the URL path that's entered are forwarded to the corresponding back-end pool. Also, add a default
back-end pool. Requests that don't match any URL path in the rule are forwarded to that pool.
Associated back-end HTTP setting

Add a back-end HTTP setting for each rule. Requests are routed from the application gateway to the
back-end targets by using the port number, protocol, and other information that's specified in this
setting.
For a basic rule, only one back-end HTTP setting is allowed. All requests on the associated listener are
forwarded to the corresponding back-end targets by using this HTTP setting.
3 https://docs.microsoft.com/en-us/azure/application-gateway/tutorial-url-redirect-powershell
251
For a path-based rule, add multiple back-end HTTP settings that correspond to each URL path. Requests
that match the URL path in this setting are forwarded to the corresponding back-end targets by using the
HTTP settings that correspond to each URL path. Also, add a default HTTP setting. Requests that don't
match any URL path in this rule are forwarded to the default back-end pool by using the default HTTP
setting.
Redirection setting
If redirection is configured for a basic rule, all requests on the associated listener are redirected to the
target. This is global redirection. If redirection is configured for a path-based rule, only requests in a
specific site area are redirected. An example is a shopping cart area that's denoted by /cart/*. This is
path-based redirection.
Redirection type
Choose the type of redirection required: Permanent(301), Temporary(307), Found(302), or See other(303).
Redirection target
Choose another listener or an external site as the redirection target.
Listener
Choose listener as the redirection target to redirect traffic from one listener to another on the gateway.
Externalsite
Choose external site when you want to redirect the traffic on the listener that's associated with this rule
to an external site. You can choose to include the query string from the original request in the request
that's forwarded to the redirection target. You can't forward the path to the external site that was in the
original request.
Rewrite HTTP headers and URL

By using rewrite rules, you can add, remove, or update HTTP(S) request and response headers as well as
URL path and query string parameters as the request and response packets move between the client and
backend pools via the application gateway.
The headers and URL parameters can be set to static values or to other headers and server variables. This
helps with important use cases, such as extracting client IP addresses, removing sensitive information
about the backend, adding more security, and so on.
Configure URL-based routing

URL Path Based Routing allows you to route traffic to back-end server pools based on URL Paths of the
request. One use case is to route requests for different content types to different backend server pools.
For the v1 SKU, rules are processed in the order they are listed in the portal. If a basic listener is
listed first and matches an incoming request, it gets processed by that listener. For the v2 SKU,
exact matches have higher precedence. However, it is highly recommended to configure multi-site
listeners first prior to configuring a basic listener. This ensures that traffic gets routed to the right
back end.
252
UrlPathMap configuration element

The urlPathMap element is used to specify Path patterns to back-end server pool mappings. The follow-
ing code example is the snippet of urlPathMap element from template file.
"urlPathMaps": [{
"name": "{urlpathMapName}",
"id": "/subscriptions/{subscriptionId}/../microsoft.network/application-
Gateways/{gatewayName}/urlPathMaps/{urlpathMapName}",
"properties": {
"defaultBackendAddressPool": {
Gateways/{gatewayName}/backendAddressPools/{poolName1}"
},
"defaultBackendHttpSettings": {
Gateways/{gatewayName}/backendHttpSettingsList/{settingname1}"
},
"pathRules": [{
"name": "{pathRuleName}",
"properties": {
"paths": [
"{pathPattern}"
],
"backendAddressPool": {
Gateways/{gatewayName}/backendAddressPools/{poolName2}"
},
"backendHttpsettings": {
Gateways/{gatewayName}/backendHttpsettingsList/{settingName2}"
253
}]
}]
PathPattern
PathPattern is a list of path patterns to match. Each must start with / and the only place a “*” is allowed is
at the end following a "/." The string fed to the path matcher does not include any text after the first ? or
#, and those chars are not allowed here. Otherwise, any characters allowed in a URL are allowed in
PathPattern. The supported patterns depend on whether you deploy Application Gateway v1 or v2.
PathBasedRouting rule
RequestRoutingRule of type PathBasedRouting is used to bind a listener to a urlPathMap. All requests
that are received for this listener are routed based on policy specified in urlPathMap.
Configure rewrite policies in Application Gateway

Application Gateway allows you to rewrite selected content of requests and responses. With this feature,
you can translate URLs, query string parameters as well as modify request and response headers. It also
allows you to add conditions to ensure that the URL or the specified headers are rewritten only when
certain conditions are met. These conditions are based on the request and response information.
HTTP header and URL rewrite features are only available for the Application Gateway v2 SKU.
Supported rewrite types

Application Gateway supports multiple rewrite types.
Request and response headers
HTTP headers allow a client and server to pass additional information with a request or response. By
rewriting these headers, you can accomplish important tasks, such as adding security-related header
fields like HSTS/ X-XSS-Protection, removing response header fields that might reveal sensitive informa-
tion, and removing port information from X-Forwarded-For headers.
Application Gateway allows you to add, remove, or update HTTP request and response headers while the
request and response packets move between the client and back-end pools.
254
URL path and query string

With URL rewrite capability in Application Gateway, you can:
●● Rewrite the host name, path, and query string of the request URL
●● Choose to rewrite the URL of all requests on a listener or only those requests which match one or
more of the conditions you set. These conditions are based on the request and response properties
(request, header, response header and server variables).
●● Choose to route the request (select the backend pool) based on either the original URL or the rewrit-
ten URL.
Rewrite actions
You use rewrite actions to specify the URL, request headers or response headers that you want to rewrite
and the new value to which you intend to rewrite them to. The value of a URL or a new or existing header
can be set to these types of values:
●● Text
●● Request header. To specify a request header, you need to use the syntax {http_req_headerName}
●● Response header. To specify a response header, you need to use the syntax {http_resp_headerName}
●● Server variable. To specify a server variable, you need to use the syntax {var_serverVariable}. See the
list of supported server variables
A combination of text, a request header, a response header, and a server variable.
Rewrite conditions
You can use rewrite conditions, an optional configuration, to evaluate the content of HTTP(S) requests
and responses and perform a rewrite only when one or more conditions are met. The application gateway
uses these types of variables to evaluate the content of requests and responses:
●● HTTP headers in the request
●● HTTP headers in the response
●● Application Gateway server variables
You can use a condition to evaluate whether a specified variable is present, whether a specified variable
matches a specific value, or whether a specified variable matches a specific pattern.
Rewrite configuration
To configure a rewrite rule, you need to create a rewrite rule set and add the rewrite rule configuration in
it.
A rewrite rule set contains:
●● Request routing rule association: The rewrite configuration is associated to the source listener via
the routing rule. When you use a basic routing rule, the rewrite configuration is associated with a
255
source listener and is a global header rewrite. When you use a path-based routing rule, the rewrite
configuration is defined on the URL path map. In that case, it applies only to the specific path area of
a site. You can create multiple rewrite sets and apply each rewrite set to multiple listeners. But you can
apply only one rewrite set to a specific listener.
●● Rewrite Condition: It is an optional configuration. Rewrite conditions evaluate the content of the
HTTP(S) requests and responses. The rewrite action will occur if the HTTP(S) request or response
matches the rewrite condition. If you associate more than one condition with an action, the action
occurs only when all the conditions are met. In other words, the operation is a logical AND operation.
●● Rewrite type: There are 3 types of rewrites available:
●● Rewriting request headers
●● Rewriting response headers
●● Rewriting URL components
●● URL path: The value to which the path is to be rewritten to.
●● URL Query String: The value to which the query string is to be rewritten to.
●● Re-evaluate path map: Used to determine whether the URL path map is to be re-evaluated or
not. If kept unchecked, the original URL path will be used to match the path-pattern in the URL
path map. If set to true, the URL path map will be re-evaluated to check the match with the
rewritten path. Enabling this switch helps in routing the request to a different backend pool
post rewrite.
For more information on Configuring rewrites in application Gateway, see Rewrite HTTP headers and
URL with Azure Application Gateway | Microsoft Docs4.
Multiple choice
You are configuring Azure Application Gateway for your organization and you want to ensure that users
don't experience performance degradation during peak times. Which setting should you configure?
Autoscaling {{Correct, With autoscaling enabled, the Application Gateway scales up or down based on
application traffic requirements.}}
Manual scaling {{Incorrect, With Manual scaling enabled, the gateway won't autoscale. If there is more
traffic than the Application Gateway can handle, it could result in traffic loss.}}
Health probes {{Incorrect, Health probes monitor the health of all resources in the back-end pool and
automatically removes any resource considered unhealthy from the pool.}}
4 https://docs.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers-url
256
Multiple choice
What is a listener?
A listener is an entity that checks for incoming connection requests. {{Correct, A listener is a logical
entity that checks for incoming connection requests by using the port, protocol, host, and IP address.}}
A listener is an entity that routes traffic based on basic or path-based rules. {{Incorrect, A routing rule
is an entity that routes traffic based on basic or path-based rules.}}
A listener is a collection of servers that respond to requests. {{Incorrect, A backend pool}}
4-Exercise: deploy Azure Application Gateway

In this exercise, you use the Azure portal to create an application gateway. Then you test it to make sure
it works correctly.
The application gateway directs application web traffic to specific resources in a backend pool. You assign
listeners to ports, create rules, and add resources to a backend pool. For the sake of simplicity, this article
uses a simple setup with a public front-end IP, a basic listener to host a single site on the application
gateway, a basic request routing rule, and two virtual machines in the backend pool.
For Azure to communicate between the resources that you create, it needs a virtual network. You can
either create a new virtual network or use an existing one. In this example, you'll create a new virtual
network while you create the application gateway. Application Gateway instances are created in separate
subnets. You create two subnets in this example: one for the application gateway, and another for the
backend servers.
●● Task 1: Create an application gateway
●● Task 2: Add backend targets
●● Task 3: Add backend servers to backend pool
●● Task 4: Test the application gateway
Task 1: Create an application gateway

1. Sign in to the Azure portal5 with your Azure account.
257
2. On any Azure portal page, in Search resources, services and docs (G+/), enter application gateway,
and then select Application gateways from the results.

3. On the Application gateways page, select + Create.
4. On the Create application gateway Basics tab, enter, or select the following information:
Setting Value
Resource group Select Create new ContosoResourceGroup
Application Gateway ContosoAppGateway
Region Select West US
Virtual Network Select Create new
5. In Create virtual network, enter, or select the following information:
Setting Value
Name ContosoVNet
ADDRESS SPACE
Address range 10.0.0.0/16
SUBNETS
Subnet name Change default to AGSubnet
Subnet name BackendSubnet
6. Select OK to return to the Create application gateway Basics tab.
7. Accept the default values for the other settings and then select Next: Frontends.
8. On the Frontends tab, verify Frontend IP address type is set to Public.
9. Select Add new for the Public IP address and enter AGPublicIPAddress for the public IP address
name, and then select OK.
10. Select Next: Backends.
258
11. On the Backends tab, select Add a backend pool.

12. In the Add a backend pool window that opens, enter the following values to create an empty
backend pool:
Setting Value
Name BackendPool
Add backend pool without targets Yes
13. In the Add a backend pool window, select Add to save the backend pool configuration and return to
the Backends tab.
14. On the Backends tab, select Next: Configuration.
15. On the Configuration tab, you'll connect the frontend and backend pool you created using a routing
rule.
16. In the Routing rules column, select Add a routing rule.
17. In the Rule name box, enter RoutingRule.
18. On the Listener tab, enter or select the following information:
Setting Value
Listener name Listener
Frontend IP Select Public
19. Accept the default values for the other settings on the Listener tab.
20. Select the Backend targets tab to configure the rest of the routing rule.
21. On the Backend targets tab, enter or select the following information:
Setting Value
Target type Backend pool
259
HTTP Settings Create new

22. In Add a HTTP setting, enter or select the following information:
Setting Value
HTTP settings name HTTPSetting
Backend port 80
23. Accept the default values for the other settings in the Add an HTTP setting window, then select Add
to return to Add a routing rule.
24. Select Add to save the routing rule and return to the Configuration tab.
25. Select Next: Tags and then Next: Review + create.
26. Review the settings on the Review + create tab
27. Select Create to create the virtual network, the public IP address, and the application gateway.
It may take several minutes for Azure to create the application gateway. Wait until the deployment
finishes successfully before moving on to the next section.
Task 2: Add backend targets

In this example, you'll use virtual machines as the target backend. You'll create two virtual machines as
backend servers for the application gateway.
To do this, you'll:
●● Create two new VMs, BackendVM1 and BackendVM2, to be used as backend servers.
●● Install IIS on the virtual machines to verify that the application gateway was created successfully.
●● Add the backend servers to the backend pool.
Create virtual machines

1. On any Azure portal page, in Search resources, services and docs (G+/), enter virtual machine, and
then select Virtual machines from the results.
2. On the Virtual machines page, select + Create > + Virtual machine.
3. In Create a virtual machine, enter, or select the following information (If the setting is not listed, use
the default value):
Setting Value
Basics tab
Resource group Select ContosoResourceGroup
Virtual machine name BackendVM1
Image Select Windows Server 2016 Datacenter - Gen1
Username TestUser
Password TestPa$$w0rd
Public inbound ports None
Networking
Virtual network ContosoVnet
260
Subnet BackendSubnet (10.0.1.0/24)

Management
Boot diagnostics Disable
4. Accept the other defaults and then select Review + create.
5. On the Review + create tab, review the settings, correct any validation errors, and then select Create.
Wait for the virtual machine creation to complete before continuing.
Install IIS for testing

In this example, you install IIS on the virtual machines to verify Azure created the application gateway
successfully.
1. Open Azure PowerShell.
2. Select Cloud Shell from the top navigation bar of the Azure portal and then select PowerShell from
the drop-down list.

3. Run the following command to install IIS on the virtual machine. Change the Location parameter if
necessary:
Set-AzVMExtension `
-ResourceGroupName ContosoResourceGroup `
-ExtensionName IIS `
-VMName BackendVM1 `
261
-Publisher Microsoft.Compute `
-ExtensionType CustomScriptExtension `
-TypeHandlerVersion 1.4 `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell

Add-Content -Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}' `
-Location WestUS
4. Create a second virtual machine and install IIS by using the Create virtual machines and Install IIS for
testing steps that you previously completed. Use BackendVM2 for the virtual machine name and for
the VMName setting of the Set-AzVMExtension cmdlet.
Task 3: Add backend servers to backend pool

1. On the Azure portal menu, select All resources or search for and select All resources. Then select
ContosoAppGateway.
2. Under Settings, select Backend pools.
3. Select BackendPool.
4. On the Edit backend pool page, under Backend targets, in Target type, select Virtual machine.
5. Under Target, select BackendVM1.
6. In Target type, select Virtual machine.
7. Under Target, select BackendVM2.
262
8. Select Save.
Wait for the deployment to complete before proceeding to the next step.
Task 4: Test the application gateway

Although IIS isn't required to create the application gateway, you installed it in this exercise to verify if
Azure successfully created the application gateway.
Use IIS to test the application gateway:

1. Find the public IP address for the application gateway on its Overview page.
263
2. Copy the public IP address, and then paste it into the address bar of your browser to browse that IP
address.
3. Check the response. A valid response verifies that the application gateway was successfully created
and can successfully connect with the backend.
4. Refresh the browser multiple times and you should see connections to both BackendVM1 and
BackendVM2.
Congratulations! You have configured and tested an Azure Application Gateway.
5-Design and configure Azure Front Door
Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network to create
fast, secure, and widely scalable web applications. With Front Door, you can transform your global
consumer and enterprise applications into robust, high-performing personalized modern applications
with contents that reach a global audience through Azure.
264
Front Door works at Layer 7 (HTTP/HTTPS layer) using anycast protocol with split TCP and Microsoft's
global network to improve global connectivity. Based on your routing method you can ensure that Front
Door will route your client requests to the fastest and most available application backend. An application
backend is any Internet-facing service hosted inside or outside of Azure. Front Door provides a range of
traffic-routing methods6 and backend health monitoring options7 to suit different application needs
and automatic failover scenarios. Like Traffic Manager8, Front Door is resilient to failures, including
failures to an entire Azure region.
What is the difference between Azure Front Door and Azure

Application Gateway?
While both Front Door and Application Gateway are layer 7 (HTTP/HTTPS) load balancers, the primary
difference is that Front Door is a global service whereas Application Gateway is a regional service. Front
Door can load balance between your different scale units/clusters/stamp units across regions, and
Application Gateway allows you to load balance between your VMs/containers that is within the scale
unit.
6 https://docs.microsoft.com/en-us/azure/frontdoor/front-door-routing-methods
7 https://docs.microsoft.com/en-us/azure/frontdoor/front-door-health-probes
8 https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview
265
Configure redirection rules in Front Door

After establishing a connection and completing a TLS handshake, when a request lands on a Front Door
environment one of the first things that Front Door does is determine which routing rule to match the
request to and then take the defined action in the configuration.
Front Door route rules configuration structure

A Front Door routing rule configuration is composed of two major parts: a “left-hand side” and a "right-
hand side". Front Door matches the incoming request to the left-hand side of the route. The right-hand
side defines how Front Door processes the request.
Incoming match
The following properties determine whether the incoming request matches the routing rule (or left-hand
side):
●● HTTP Protocols (HTTP/HTTPS)
●● Hosts (for example, www.foo.com, *.bar.com)
●● Paths (for example, /, /users/, /file.gif)
These properties are expanded out internally so that every combination of Protocol/Host/Path is a
potential match set.
Route data
Front Door speeds up the processing of requests by using caching. If caching is enabled for a specific
route, it uses the cached response. If there is no cached response for the request, Front Door forwards
the request to the appropriate backend in the configured backend pool.
Route matching
Front Door attempts to match to the most-specific match first looking only at the left-hand side of the
route. It first matches based on HTTP protocol, then Frontend host, then the Path.
●● Frontend host matching:
●● Look for any routing with an exact match on the host.
●● If no exact frontend hosts match, reject the request and send a 400 Bad Request error.
●● Path matching:
●● Look for any routing rule with an exact match on the Path.
●● If no exact match Paths, look for routing rules with a wildcard Path that matches.
●● If no routing rules are found with a matching Path, then reject the request and return a 400: Bad
Request error HTTP response.
If there are no routing rules for an exact-match frontend host with a catch-all route Path (/*), then
there will not be a match to any routing rule.
Azure Front Door redirects traffic at each of the following levels: protocol, hostname, path, query string.
These functionalities can be configured for individual microservices since the redirection is path-based.
This can simplify application configuration by optimizing resource usage and supports new redirection
scenarios including global and path-based redirection.
266
Redirection types
A redirect type sets the response status code for the clients to understand the purpose of the redirect.
The following types of redirection are supported:
Redirection type Action Description

301 Moved permanently Indicates that the target resource
has been assigned a new
permanent URI. Any future
references to this resource will
use one of the enclosed URIs.
Use 301 status code for HTTP to
HTTPS redirection.
302 Found Indicates that the target resource
is temporarily under a different
URI. Since the redirection can
change on occasion, the client
should continue to use the
effective request URI for future
requests.
267
307 Temporary redirect Indicates that the target resource

is temporarily under a different
URI. The user agent MUST NOT
change the request method if it
does an automatic redirection to
that URI. Since the redirection
can change over time, the client
ought to continue using the
original effective request URI for
future requests.
308 Permanent redirect Indicates that the target resource
has been assigned a new
permanent URI. Any future
references to this resource
should use one of the enclosed
URIs.
Redirection protocol
You can set the protocol that will be used for redirection. The most common use case of the redirect
feature is to set HTTP to HTTPS redirection.
●● HTTPS only: Set the protocol to HTTPS only, if you're looking to redirect the traffic from HTTP to
HTTPS. Azure Front Door recommends that you should always set the redirection to HTTPS only.
●● HTTP only: Redirects the incoming request to HTTP. Use this value only if you want to keep your
traffic HTTP that is, non-encrypted.
●● Match request: This option keeps the protocol used by the incoming request. So, an HTTP request
remains HTTP and an HTTPS request remains HTTPS post redirection.
Destination host
As part of configuring a redirect routing, you can also change the hostname or domain for the redirect
request. You can set this field to change the hostname in the URL for the redirection or otherwise pre-
serve the hostname from the incoming request. So, using this field you can redirect all requests sent on
https://www.contoso.com/* to https://www.fabrikam.com/*.
Destination path
For cases where you want to replace the path segment of a URL as part of redirection, you can set this
field with the new path value. Otherwise, you can choose to preserve the path value as part of redirect.
So, using this field, you can redirect all requests sent to https://www.contoso.com/* to https://www.
contoso.com/redirected-site.
Destination fragment
The destination fragment is the portion of URL after '#', which is used by the browser to land on a specific
section of a web page. You can set this field to add a fragment to the redirect URL.
268
Query string parameters

You can also replace the query string parameters in the redirected URL. To replace any existing query
string from the incoming request URL, set this field to ‘Replace’ and then set the appropriate value.
Otherwise, keep the original set of query strings by setting the field to 'Preserve'. As an example, using
this field, you can redirect all traffic sent to https://www.contoso.com/foo/bar to https://www.contoso.
com/foo/bar?&utm_referrer=https%3A%2F%2Fwww.bing.com%2F.
Configure rewrite policies

Azure Front Door supports URL rewrite by configuring an optional Custom Forwarding Path to use when
constructing the request to forward to the backend. By default, if a custom forwarding path isn't provid-
ed, the Front Door will copy the incoming URL path to the URL used in the forwarded request. The Host
header used in the forwarded request is as configured for the selected backend. Read Backend Host
Header to learn what it does and how you can configure it.
The powerful part of URL rewrite is that the custom forwarding path will copy any part of the incoming
path that matches to a wildcard path to the forwarded path (these path segments are the green seg-
ments in the example below):
Configure health probes, including customization of HTTP

response codes
To determine the health and proximity of each backend for a given Front Door environment, each Front
Door environment periodically sends a synthetic HTTP/HTTPS request to each of your configured back-
ends. Front Door then uses these responses from the probe to determine the “best” backend resources to
route your client requests.
Since Front Door has many edge environments globally, health probe volume for your backends can be
quite high - ranging from 25 requests every minute to as high as 1200 requests per minute, depending
on the health probe frequency configured. With the default probe frequency of 30 seconds, the probe
volume on your backend should be about 200 requests per minute.
Supported HTTP methods for health probes

Front Door supports sending probes over either HTTP or HTTPS protocols. These probes are sent over
the same TCP ports configured for routing client requests and cannot be overridden.
Front Door supports the following HTTP methods for sending the health probes:
GET: The GET method means retrieve whatever information (in the form of an entity) is identified by the
Request-URI.
269
HEAD: The HEAD method is identical to GET except that the server MUST NOT return a message-body in
the response. Because it has lower load and cost on your backends, for new Front Door profiles, by
default, the probe method is set as HEAD.
Health probe responses

The following table describes responses to the health probe:
Response Description
Determining Health A 200 OK status code indicates the backend is
healthy. Everything else is considered a failure. If
for any reason (including network failure) a valid
HTTP response isn't received for a probe, the
probe is counted as a failure.
Measuring Latency Latency is the wall-clock time measured from the
moment immediately before the probe request is
sent to the moment the last byte of the response
is received. A new TCP connection is used for each
request, so this measurement isn't biased towards
backends with existing warm connections.
Azure Front Door uses the same three-step process below across all algorithms to determine health.
1. Exclude disabled backends.
2. Exclude backends that have health probe errors:
●● This selection is done by looking at the last n health probe responses. If at least x are healthy, the
backend is considered healthy.
●● n is configured by changing the SampleSize property in load-balancing settings.
●● x is configured by changing the SuccessfulSamplesRequired property in load-balancing settings.
3. For the sets of healthy backends in the backend pool, Front Door additionally measures and maintains
the latency (round-trip time) for each backend.
If you have a single backend in your backend pool, you can choose to disable the health probes reducing
the load on your application backend. Even if you have multiple backends in the backend pool but only
one of them is in enabled state, you can disable health probes.
Secure Front Door with SSL

Use the HTTPS protocol on your custom domain (for example, https://www.contoso.com), you ensure
that your sensitive data is delivered securely via TLS/SSL encryption when it's sent across the internet.
When your web browser is connected to a web site via HTTPS, it validates the web site's security certifi-
cate and verifies that it was issued by a legitimate certificate authority. This process provides security and
protects your web applications from attacks.
Some of the key attributes of the custom HTTPS feature are:
●● No extra cost: There are no costs for certificate acquisition or renewal and no extra cost for HTTPS
traffic.
●● Simple enablement: One-click provisioning is available from the Azure portal. You can also use REST
API or other developer tools to enable the feature.
270
●● Complete certificate management: All certificate procurement and management is handled for you.
Certificates are automatically provisioned and renewed before expiration, which removes the risks of
service interruption because of a certificate expiring.
You can enable the HTTPS protocol for a custom domain that's associated with your Front Door under
the frontend hosts section.
For more information on how to configure HTTPS on Front door, see Tutorial - Configure HTTPS on a
custom domain for Azure Front Door | Microsoft Docs9.
Multiple choice
What is the difference between Azure Front Door and Azure Application Gateway?
Front Door is a global service, Application Gateway is a regional service. {{Correct, Front Door and
Application Gateway are layer 7 (HTTP/HTTPS) load balancers, Front Door is a global service whereas
Application Gateway is a regional service.}}
Front Door is a regional service, Application Gateway is a global service. {{Incorrect, Front Door and
Front Door uses health probes to monitor the health of backends, Application Gateway does not.
{{Incorrect, Both Front Door and Application gateway use health probes to monitor the health of
backends.}}
Multiple choice
Front Door route rules determine whether the incoming request matches the routing rule and route traffic
accordingly. What properties are matched?
HTTP protocols (HTTP/HTTPS), Hosts, and Paths. {{Correct, When evaluating routing rules, Front Door
looks for matches in HTTP protocols (HTTP/HTTPS), Hosts, and Paths.}}
HTTP protocols (HTTP/HTTPS), Hosts, and time stamp. {{Incorrect, When evaluating routing rules,
Front Door does not look for matches in time stamps.}}
Hosts, paths, and user certificates. {{Incorrect, When evaluating routing rules, Front Door does not
look for matches in user certificates.}}
6-Exercise: create a Front Door for a highly avail-

able web application
In this exercise, you will set up an Azure Front Door configuration that pools two instances of a web
application that runs in different Azure regions. This configuration directs traffic to the nearest site that
runs the application. Azure Front Door continuously monitors the web application. You will demonstrate
automatic failover to the next available site when the nearest site is unavailable. The network configura-
tion is shown in the following diagram:
9 https://docs.microsoft.com/en-us/azure/frontdoor/front-door-custom-domain-https
271

●● Task 1: Create two instances of a web app
●● Task 2: Create a Front Door for your application
●● Task 3: View Azure Front Door in action
Task 1: Create two instances of a web app

This exercise requires two instances of a web application that run in different Azure regions. Both the web
application instances run in Active/Active mode, so either one can take traffic. This configuration differs
from an Active/Stand-By configuration, where one acts as a failover.
1. Sign in to the Azure portal at https://portal.azure.com10.
2. On the Azure portal home page, select + Create a resource.
3. On the Create a resource page, select WebApp.

4. On the Create Web App page, on the Basics tab, enter or select the following information.
272
Setting Value
Resource group Select the resource group provided by Learn.
Name Enter a unique Name for your web app. This exam-
ple uses WebAppContoso-1.
Publish Select Code.
Runtime stack Select .NET Core 2.1 (LTS).
Operating System Select Windows.
Region Select Central US.
Windows Plan Select Create new and enter myAppServicePlan-
CentralUS in the text box.
SKU and size Select Standard S1 100 total ACU, 1.75 GB
memory.
5. Select Review + create, review the Summary, and then select Create.
‎It might take several minutes for the deployment to complete.
6. Create a second web app. On the Azure portal home page, select + Create a resource.
7. On the Create a resource page, select WebApp.
8. On the Create Web App page, on the Basics tab, enter or select the following information.
Setting Value
Name Enter a unique Name for your web app. This exam-
ple uses WebAppContoso-2.
Publish Select Code.
Runtime stack Select .NET Core 2.1 (LTS).
Operating System Select Windows.
Region Select East US.
Windows Plan Select Create new and enter myAppServicePlanE-
astUS in the text box.
SKU and size Select Standard S1 100 total ACU, 1.75 GB
memory.
9. Select Review + create, review the Summary, and then select Create.
‎It might take several minutes for the deployment to complete.
Task 2: Create a Front Door for your application

Configure Azure Front Door to direct user traffic based on lowest latency between the two web apps
servers. To begin, add a frontend host for Azure Front Door.
1. On any Azure portal page, in Search resources, services and docs (G+/), enter front door, and then
select Front Doors from the results.
273
2. On the Front Doors page, select + Create.

3. In Create a Front Door, enter or select the following information.
Setting Value
Resource group location Select Central US.
4. Select Next: Configuration.
5. On the Configuration tab, in Frontends/domains, select + to add a frontend host.
274
6. Enter a globally unique host name, like contoso-frontend, and then select Add.
7. Next, create a backend pool that contains your two web apps.
‎In Create a Front Door, in Backend pools, select + to add a backend pool.
8. Enter a globally unique host name, like BackendPool.

9. Under BACKENDS, select + Add a backend.
10. In Add a backend, enter, or select the following information.
Setting Value
Backend host type Select App service.
275

Backend host name Select the first web app you created. In this
example, the web app was WebAppContoso-1.
11. Leave all other fields as default and then select Add.
12. Select + Add a backend again, enter or select the following.
Setting Value
Backend host type Select App service.
Backend host name Select the second web app you created. In this
example, the web app was WebAppContoso-2.
13. Leave all other fields as default and then select Add.
14. On the Add a backendpool blade, select Add to complete the configuration of the backend pool.
15. Finally, add a routing rule. A routing rule maps your frontend host to the backend pool. This rule
forwards a request for contoso-frontend.azurefd.net to myBackendPool.
16. In Create a Front Door, in Routing rules, select + to configure a routing rule.
17. In Add a rule, for Name, enter LocationRule.

18. Accept all the default values, then select Add to add the routing rule.
19. Select Review + Create, and then Create.
You must ensure that each of the frontend hosts in your Front Door has a routing rule with a
default path (*) associated with it. That is, across all your routing rules there must be at least one
routing rule for each of your frontend hosts defined at the default path (*). Failing to do so may
result in your end-user traffic not getting routed correctly.
276
Task 3: View Azure Front Door in action

Once you create a Front Door, it takes a few minutes for the configuration to be deployed globally. Once
complete, access the frontend host you created.
1. In the Azure portal, navigate to your Front Door frontend. Select Go to Resource. Or in Search
resources, services, and docs (G+/), enter front door, and select Front Doors from the results, and
then select your Front Door.
2. On the Front Door page, note the Frontend host URL. This exercise uses contoso-frontend.azurefd.
net, but you may have altered it to ensure the name is unique.
3. In a browser, go to your Frontend host URL (contoso-frontend.azurefd.net). Your request will automat-
ically be routed to the nearest server to you from the specified servers in the backend pool.
4. You'll see the following information page:
5. To test instant global failover in action, try the following steps:

6. Switch to the Azure portal, search for and select App services.
7. Select one of your web apps, then select Stop, and then select Yes to verify.
277
8. Switch back to your browser and select Refresh. You should see the same information page.
There may be a delay while the web app stops. If you get an error page in your browser, refresh
the page.
1. Switch back to the Azure portal, locate the other web app, and stop it.
2. Switch back to your browser and select Refresh. This time, you should see an error message.
Congratulations! You have configured and tested an Azure Front Door.

[!NOTE]
Remember to remove any newly created Azure resources that you no longer use. Removing unused
resources ensures you will not see unexpected charges.
command:
278
[!NOTE]
7-Summary
In this module you had an in-depth look at Azure Front Door and Azure Application Gateway. You
learned how to load balance network traffic effectively to ensure high availability of services.
●● Design and implement Azure Application Gateway
●● Implement Azure Front Door
279
Answers
Multiple choice
You are configuring Azure Application Gateway for your organization and you want to ensure that users
don't experience performance degradation during peak times. Which setting should you configure?
■■ Autoscaling {{Correct, With autoscaling enabled, the Application Gateway scales up or down based on
application traffic requirements.}}
Manual scaling {{Incorrect, With Manual scaling enabled, the gateway won't autoscale. If there is more
traffic than the Application Gateway can handle, it could result in traffic loss.}}
Health probes {{Incorrect, Health probes monitor the health of all resources in the back-end pool and
automatically removes any resource considered unhealthy from the pool.}}
Explanation
Multiple choice
What is a listener?
■■ A listener is an entity that checks for incoming connection requests. {{Correct, A listener is a logical
entity that checks for incoming connection requests by using the port, protocol, host, and IP address.}}
A listener is an entity that routes traffic based on basic or path-based rules. {{Incorrect, A routing rule
is an entity that routes traffic based on basic or path-based rules.}}
A listener is a collection of servers that respond to requests. {{Incorrect, A backend pool}}
Explanation
Multiple choice
What is the difference between Azure Front Door and Azure Application Gateway?
■■ Front Door is a global service, Application Gateway is a regional service. {{Correct, Front Door and
Front Door is a regional service, Application Gateway is a global service. {{Incorrect, Front Door and
Front Door uses health probes to monitor the health of backends, Application Gateway does not.
{{Incorrect, Both Front Door and Application gateway use health probes to monitor the health of
backends.}}
Explanation
280
Multiple choice
Front Door route rules determine whether the incoming request matches the routing rule and route
traffic accordingly. What properties are matched?
■■ HTTP protocols (HTTP/HTTPS), Hosts, and Paths. {{Correct, When evaluating routing rules, Front Door
looks for matches in HTTP protocols (HTTP/HTTPS), Hosts, and Paths.}}
HTTP protocols (HTTP/HTTPS), Hosts, and time stamp. {{Incorrect, When evaluating routing rules,
Front Door does not look for matches in time stamps.}}
Hosts, paths, and user certificates. {{Incorrect, When evaluating routing rules, Front Door does not
look for matches in user certificates.}}
Explanation
Module 6 Design and implement network se-
curity
Design and implement network security

1-Introduction
Network security is the process of protecting resources from unauthorized access or attack by applying
controls to network traffic, allowing only legitimate traffic/requests. Azure includes a robust networking
infrastructure to support your application and service connectivity requirements.
Your security requirements might include:
●● Authentication and authorization (for your application)
●● Intrusion detection and response
●● URL filtering
●● Application access control
●● DDoS protection
Learning objectives
●● Understand how to implement compliance
●● Configure and monitor an Azure DDoS protection plan
●● Implement and manage firewalls
●● Implement network security groups (NSGs)
●● Implement a web application firewall (WAF) on Azure Front Door
●● Configure a monitoring environment for networking
282
Prerequisites
(DNS) and routing
●● You should be able to navigate the Azure portal
2-Secure your virtual networks in the Azure por-

tal
Network security covers a multitude of technologies, devices, and processes. It provides a set of rules and
configurations designed to protect the integrity, confidentiality and accessibility of computer networks
and data. Every organization, regardless of size, industry, or infrastructure, requires a degree of network
security solutions in place to protect it from the ever-growing risks of attacks.
For Microsoft Azure, securing or providing the ability to secure resources like microservices, VMs, data,
and others is paramount. Microsoft Azure ensures it through a distributed virtual firewall.
A virtual network in Microsoft Azure is isolated from other networks, while communicating through
private IP addresses.
Azure Security Benchmark

The Azure Security Benchmark (ASB) provides prescriptive best practices and recommendations to help
improve the security of workloads, data, and services on Azure.
The Azure Security Benchmark includes a collection of high-impact security recommendations you can
use to help secure the services you use in Azure:
●● Security controls: These recommendations are generally applicable across your Azure tenant and
Azure services. Each recommendation identifies a list of stakeholders that are typically involved in
planning, approval, or implementation of the benchmark.
●● Service baselines: These apply the controls to individual Azure services to provide recommendations
on that service’s security configuration.
Implement the Azure Security Benchmark

●● Plan your Azure Security Benchmark implementation by reviewing the documentation for the enter-
prise controls and service-specific baselines to plan your control framework and how it maps to
guidance like CIS (Controls v7.1) and NIST (SP 800-53) framework.
●● Monitor your compliance with Azure Security Benchmark status (and other control sets) using the
Azure Security Center regulatory compliance dashboard.
●● Establish guardrails to automate secure configurations and enforce compliance with Azure Security
Benchmark (and other requirements in your organization) with Azure Blueprints and Azure Policy.
Azure Security Benchmark v2 is aligned with Microsoft Security Best Practices so that Azure Security
Benchmark provides a single consolidated view of Microsoft’s Azure security recommendations.
283
Common Use Cases

Azure Security Benchmark is frequently used to address these common challenges for customers or
service partners who are:
●● New to Azure and are looking for security best practices to ensure a secure deployment.
●● Improving security posture of existing Azure deployments to prioritize top risks and mitigations.
●● Approving Azure services for use by technology and business use to meet specific security guidelines.
●● Meeting regulatory requirements for customers who are from government or highly regulated
industries like finance and healthcare (or service vendors who need to build systems for these custom-
ers). These customers need to ensure their configuration of Azure meets the security capabilities
specified in an industry framework such as CIS, NIST, or PCI. Azure Security Benchmark provides an
efficient approach with the controls already pre-mapped to these industry benchmarks.
Terminology
The terms “control”, "benchmark", and “baseline” are used often in the Azure Security Benchmark docu-
mentation, and it is important to understand how Azure uses those terms.
Term Description Example

Control A control is a high-level descrip- Data Protection is one of the
tion of a feature or activity that security controls. This control
needs to be addressed and is not contains specific actions that
specific to a technology or must be addressed to help
implementation. ensure data is protected.
Benchmark A benchmark contains security The Azure Security Benchmark
recommendations for a specific comprises the security recom-
technology, such as Azure. The mendations specific to the Azure
recommendations are catego- platform
rized by the control to which
they belong.
Baseline A baseline is the implementation The Contoso company looks to
of the benchmark on the enabling Azure SQL security
individual Azure service. Each features by following the
organization decides benchmark configuration recommended in
recommendation and corre- Azure SQL security baseline.
sponding configurations are
needed in the Azure implemen-
tation scope.
Using Azure Security Center for regulatory compliance

Azure Security Center helps streamline the process for meeting regulatory compliance requirements,
using the regulatory compliance dashboard.
The regulatory compliance dashboard shows the status of all the assessments within your environment
for your chosen standards and regulations. As you act on the recommendations and reduce risk factors in
your environment, your compliance posture improves.
284
Security Center regulatory compliance dashboard
The dashboard shows an overview of your compliance status with the set of supported compliance
regulations. You will see your overall compliance score, and the number of passing vs. failing assessments
associated with each standard.
285
Compliance controls
1. Tab for each compliance standard that is relevant to you.

2. Subscriptions the standard is applied on.
3. List of all controls for that standard.
4. View the details of passing and failing assessments associated with that control.
5. Number of affected resources.
Some controls are grayed out. These controls do not have any Security Center assessments associated
with them. Check their requirements and assess them in your environment. Some of these might be
process-related and not technical.
Exploring the details of compliance with a specific standard

To generate a PDF report with a summary of your current compliance status for a particular standard,
select Download report.
286
The report provides a high-level summary of your compliance status for the selected standard based on
Security Center assessments data. The report is organized according to the controls of that standard. The
report can be shared with relevant stakeholders and might provide evidence to internal and external
auditors.
Alerts in Security Center

Security Center automatically collects, analyzes, and integrates log data from your Azure resources, the
network, and connected partner solutions - like firewall and endpoint protection solutions - to detect real
threats and reduce false positives. A list of prioritized security alerts is shown in Security Center along
with the information you need to quickly investigate the problem and steps to take to remediate an
attack.
Manage your security alerts

The Security Center overview page shows the Security alerts tile at the top of the page, and as a link from
the sidebar.
The security alerts page shows the active alerts. You can sort the list by Severity, Alert title, Affected
resource, Activity start time. MITRE ATTACK tactics, and status.
287
To filter the alerts list, select any of the relevant filters. You can add further filters with the Add filter
option.
288
The list updates according to the filtering options you have selected. Filtering can be very helpful. For
example, you might want to address security alerts that occurred in the last 24 hours because you are
investigating a potential breach in the system.
Respond to security alerts

From the Security alerts list, select an alert. A side pane opens and shows a description of the alert and all
the affected resources.
View full details displays further information, as shown in the following image:
289
The left pane of the security alert page shows high-level information regarding the security alert: title,
severity, status, activity time, description of the suspicious activity, and the affected resource. Alongside
the affected resource are the Azure tags relevant to the resource. Use these to infer the organizational
context of the resource when investigating the alert.
The right pane includes the Alert details tab containing further details of the alert to help you investigate
the issue: IP addresses, files, processes, and more.
Also in the right pane is the Take action tab. Use this tab to take further actions regarding the security
alert. Actions such as:
●● Mitigate the threat: Provides manual remediation steps for this security alert
●● Prevent future attacks: Provides security recommendations to help reduce the attack surface,
increase security posture, and thus prevent future attacks
●● Trigger automated response: Provides the option to trigger a logic app as a response to this security
alert
●● Suppress similar alerts: Provides the option to suppress future alerts with similar characteristics if the
alert isn’t relevant for your organization
Network Security
Network Security covers controls to secure and protect Azure networks, including securing virtual
networks, establishing private connections, preventing and mitigating external attacks, and securing DNS.
Full description of the controls can be found at Security Control V2: Network Security on Microsoft
Docs1.
1 https://docs.microsoft.com/security/benchmark/azure/security-controls-v2-network-security
290
NS-1: Implement security for internal traffic

Segmentation and isolation of virtual networks should be applied based on business risks. Generally,
“deny by default, permit by exception” approach should be followed.
Azure Security Center is a unified infrastructure security management system that strengthens the
security posture of your data centers and provides advanced threat protection across your hybrid
workloads in the cloud as well as on premises. Use Azure Security Center to:
●● Strengthen security posture: Security Center assesses your environment and enables you to under-
stand the status of your resources, and whether they are secure.
●● Protect against threats: Security Center assesses your workloads and raises threat prevention
recommendations and security alerts.
●● Get secure faster: In Security Center, everything is done in cloud speed. Because it is natively inte-
grated, deployment of Security Center is easy, providing you with auto-provisioning and protection
with Azure services.
Azure Security Center Adaptive Network Hardening2 is an agentless feature of Azure Security Center
- nothing needs to be installed on your machines to benefit from this network hardening tool. Azure
Security Center Adaptive Network Hardening3 provides guidance about recommended network
security group configurations like limiting ports and source IPs with reference to external network traffic
rules. For more information on adaptive network hardening, see Adaptive network hardening in Azure
Security Center4.
NS-2: Connect private networks together

Use Azure ExpressRoute or Azure virtual private network (VPN) to create private connections between
Azure datacenters and on-premises infrastructure in a colocation environment. ExpressRoute connections
do not go over the public internet, and they offer more reliability, faster speeds, and lower latencies than
typical internet connections.
NS-3: Establish private network access to Azure services

Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL
Database) and Azure hosted customer-owned/partner services over a private endpoint in your virtual
network.
2 https://docs.microsoft.com/azure/security-center/security-center-adaptive-network-hardening
291
NS-4: Protect applications and services from external net-

work attacks
Microsoft Azure provides native capabilities for protecting applications, services and APIs against poten-
tially malicious traffic using Azure Firewall and Web Application Firewall in Application Gateway, Front
Door, CDN (Content Delivery Network)
NS-5: Deploy intrusion detection/intrusion prevention sys-

tems (IDS/IPS)
Use Azure Firewall threat intelligence-based filtering to alert on and/or block traffic to and from known
malicious IP addresses and domains. The IP addresses and domains are sourced from the Microsoft
Threat Intelligence feed.
NS-6: Simplify network security rules

Use application security groups as a natural extension to your security policies instead of defining explicit
security policies per application.
292
NS-7: Secure Domain Name Service (DNS)

Follow the best practices for DNS security to mitigate against common attacks like dangling DNS, DNS
amplifications attacks, DNS poisoning and spoofing, etc.
Multiple choice
What Azure service can we use to create a private connection between Azure PaaS and hosted services?
(x ) Azure Private Link {{Correct. Azure Private Link enables you to access Azure PaaS Services (for example,
Azure Storage and SQL Database) and Azure hosted customer-owned/partner services over a private
endpoint in your virtual network.}}
Azure Service Endpoint {{Incorrect. Azure Service Endpoint provides secure and direct connectivity to
Azure PaaS services over an optimized route over the Azure backbone network.}}
Azure NaaS (network as a service) {{Incorrect. There is no such service as Azure NaaS.}}
Multiple choice
Which tool in Azure automatically collects, analyzes, and integrates log data from your Azure resources?
(x ) Azure Security Center {{Correct. Security Center automatically collects, analyzes, and integrates log data
from your Azure resources, the network, and other connected partner solutions, such as firewall and
endpoint protection solutions.}}
Azure Security Benchmark {{Incorrect. The Azure Security Benchmark provides prescriptive best
practices and recommendations to help improve the security of workloads, data, and services on
293
Azure. It includes a collection of high-impact security recommendations you can use to help secure
the services you use in Azure.}}
Azure Sentinel {{Incorrect. Azure Sentinel is a scalable, cloud-native, security information event
management and security orchestration automated response solution. It delivers intelligent security
analytics and threat intelligence across the enterprise, providing a single solution for alert detection,
threat visibility, proactive hunting, and threat response. It needs to be onboarded and configured to
collect data from your resources in Azure.}}
3-Deploy Azure DDoS Protection by using the

Azure portal
Distributed Denial of Service (DDoS)

A denial of service attack (DoS) is an attack that has the goal of preventing access to services or systems.
If the attack originates from one location, it is called a DoS. If the attack originates from multiple net-
works and systems, it is called distributed denial of service (DDoS).
Distributed Denial of Service (DDoS) attacks are some of the largest availability and security concerns
facing customers that are moving their applications to the cloud. A DDoS attack tries to drain an API's or
application's resources, making that application unavailable to legitimate users. DDoS attacks can be
targeted at any endpoint that is publicly reachable through the internet.
DDoS implementation
Azure DDoS protection, combined with application design best practices, provide defense against DDoS
attacks. Azure DDoS protection provides the following service tiers:
●● Basic: Automatically enabled as part of the Azure platform. Always-on traffic monitoring, and re-
al-time mitigation of common network-level attacks, provide the same defenses utilized by Micro-
soft's online services. The entire scale of Azure's global network can be used to distribute and mitigate
attack traffic across regions. Protection is provided for IPv4 and IPv6 Azure public IP addresses.
●● Standard: Provides additional mitigation capabilities over the Basic service tier that are tuned specifi-
cally to Azure Virtual Network resources. DDoS Protection Standard is simple to enable, and requires
no application changes. Protection policies are tuned through dedicated traffic monitoring and
machine learning algorithms. Policies are applied to public IP addresses associated to resources
deployed in virtual networks, such as Azure Load Balancer, Azure Application Gateway, and Azure
Service Fabric instances, but this protection does not apply to App Service Environments. Real-time
telemetry is available through Azure Monitor views during an attack, and for history. Rich attack
mitigation analytics are available via diagnostic settings. Application layer protection can be added
through the Azure Application Gateway Web Application Firewall or by installing a 3rd party firewall
from Azure Marketplace. Protection is provided for IPv4 and IPv6 Azure public IP addresses.
DDoS Protection Standard protects resources in a virtual network including public IP addresses associat-
ed with virtual machines, load balancers, and application gateways. When coupled with the Application
Gateway web application firewall, or a third-party web application firewall deployed in a virtual network
with a public IP, DDoS Protection Standard can provide full layer 3 to layer 7 mitigation capability.
294
Every property in Azure is protected by Azure's infrastructure DDoS (Basic) Protection at no additional
cost. While DDoS Protection Standard is a paid service, design for services that are deployed in a virtual
network.
Types of DDoS attacks

DDoS Protection Standard can mitigate the following types of attacks:
Volumetric attacks - These attacks flood the network layer with a substantial amount of seemingly
legitimate traffic. They include UDP floods, amplification floods, and other spoofed-packet floods. DDoS
Protection Standard mitigates these potential multi-gigabyte attacks by absorbing and scrubbing them,
with Azure's global network scale, automatically.
Protocol attacks - These attacks render a target inaccessible, by exploiting a weakness in the layer 3 and
layer 4 protocol stack. They include SYN flood attacks, reflection attacks, and other protocol attacks.
DDoS Protection Standard mitigates these attacks, differentiating between malicious and legitimate
traffic, by interacting with the client, and blocking malicious traffic.
Resource (application) layer attacks - These attacks target web application packets, to disrupt the
transmission of data between hosts. They include HTTP protocol violations, SQL injection, cross-site
scripting, and other layer 7 attacks. Use a Web Application Firewall, such as the Azure Application Gate-
way web application firewall, as well as DDoS Protection Standard to provide defense against these
attacks. There are also third-party web application firewall offerings available in the Azure Marketplace.
Azure DDoS protection features

Some of Azure DDoS protection features include:
●● Native platform integration: Natively integrated into Azure and configured through portal.
●● Turnkey protection: Simplified configuration protecting all resources immediately.
●● Always-on traffic monitoring: Your application traffic patterns are monitored 24 hours a day, 7 days
a week, looking for indicators of DDoS attacks.
●● Adaptive tuning: Profiling and adjusting to your service's traffic.
●● Attack analytics: Get detailed reports in five-minute increments during an attack, and a complete
summary after the attack ends.
●● Attack metrics and alerts: Summarized metrics from each attack are accessible through Azure
Monitor. Alerts can be configured at the start and stop of an attack, and over the attack's duration,
using built-in attack metrics.
●● Multi-layered protection: When deployed with a web application firewall (WAF), DDoS Protection
Standard protects both at the network layer (Layer 3 and 4, offered by Azure DDoS Protection Stand-
ard) and at the application layer (Layer 7, offered by a WAF).
Let us have a look in a bit more detail at some of those key features.
Always-on traffic monitoring

DDoS Protection Standard monitors actual traffic utilization and constantly compares it against the
thresholds defined in the DDoS Policy. When the traffic threshold is exceeded, DDoS mitigation is
initiated automatically. When traffic returns below the thresholds, the mitigation is stopped.
295
During mitigation, traffic sent to the protected resource is redirected by the DDoS protection service and
several checks are performed, such as:
●● Ensure packets conform to internet specifications and are not malformed.
●● Interact with the client to determine if the traffic is potentially a spoofed packet (e.g: SYN Auth or SYN
Cookie or by dropping a packet for the source to retransmit it).
●● Rate-limit packets if no other enforcement method can be performed.
DDoS protection drops attack traffic and forwards the remaining traffic to its intended destination. Within
a few minutes of attack detection, you are notified using Azure Monitor metrics. By configuring logging
on DDoS Protection Standard telemetry, you can write the logs to available options for future analysis.
Metric data in Azure Monitor for DDoS Protection Standard is retained for 30 days.
Adaptive real-time tuning

The Azure DDoS Protection service helps protect customers and prevent impacts to other customers. For
example, if a service is provisioned for a typical volume of legitimate incoming traffic that is smaller than
the trigger rate of the infrastructure-wide DDoS Protection policy, a DDoS attack on that customer’s
resources might go unnoticed. More generally, the complexity of recent attacks (for example, multi-vec-
tor DDoS) and the application-specific behaviors of tenants call for per-customer, tailored protection
policies.
The service accomplishes this by using two insights:

●● Automatic learning of per-customer (per- Public IP) traffic patterns for Layer 3 and 4.
●● Minimizing false positives, considering that the scale of Azure allows it to absorb a significant amount
of traffic.
296
Attack metrics, alerts, and logs

DDoS Protection Standard exposes rich telemetry via the Azure Monitor tool. You can configure alerts for
any of the Azure Monitor metrics that DDoS Protection uses. You can integrate logging with Splunk
(Azure Event Hubs), Azure Monitor logs, and Azure Storage for advanced analysis via the Azure Monitor
Diagnostics interface.
In the Azure portal, select Monitor > Metrics. In the Metrics pane, select the resource group, select a
resource type of Public IP Address, and select your Azure public IP address. DDoS metrics are visible in
the Available metrics pane.
DDoS Protection Standard applies three autotuned mitigation policies (SYN, TCP, and UDP) for each
public IP of the protected resource, in the virtual network that has DDoS enabled. You can view the policy
thresholds by selecting the Inbound [SYN/TCP/UDP] packets to trigger DDoS mitigation metrics as
shown in the example screenshot below.
The policy thresholds are autoconfigured via machine learning-based network traffic profiling. DDoS
mitigation occurs for an IP address under attack only when the policy threshold is exceeded.
If the public IP address is under attack, the value for the Under DDoS attack or not metric changes to 1
as DDoS Protection performs mitigation on the attack traffic.
It is recommended to configure an alert on this metric as you will then get notified if there is an active
DDoS mitigation performed on your public IP address.
297
Multi-layered protection
Specific to resource attacks at the application layer, you should configure a web application firewall (WAF)
to help secure web applications. A WAF inspects inbound web traffic to block SQL injections, cross-site
scripting, DDoS, and other Layer 7 attacks. Azure provides WAF as a feature of Application Gateway for
centralized protection of your web applications from common exploits and vulnerabilities. There are
other WAF offerings available from Azure partners that might be more suitable for your needs via the
Azure Marketplace.
Even web application firewalls are susceptible to volumetric and state exhaustion attacks. Therefore, it is
firmly recommended to enable DDoS Protection Standard on the WAF virtual network to help protect
from volumetric and protocol attacks.
298
Deploying a DDoS protection plan

The key stages of deploying as DDoS Protection plan are as follows:
●● Create a resource group
●● Create a DDoS Protection Plan
●● Enable DDoS protection on a new or existing virtual network
●● Configure DDoS telemetry
●● Configure DDoS diagnostic logs
●● Configure DDoS alerts
●● Run a test DDoS attack and monitor the results
Multiple choice
Which one of these is a symptom of a DDoS attack?
(x ) An unexplained surge in requests. {{Correct. You are not expecting that many concurrent requests that
they start to overwhelm your resources.}}
Application running slowly. {{Incorrect. This could just be other performance-related issues in your
application/connectivity.}}
HTTP 400 Bad Request {{Incorrect. HTTP 400 Bad Request response status code indicates that the
server cannot or will not process the request due to something that is perceived to be a client error}}
Multiple choice
Which action shall we take when under DDoS attack?
(x ) Monitor Alerts and review attack profile. {{Correct. You should look at any alerts sent out and review the
attack profile (what type of attack, where is it originating, is it targeting a particular resource).}}
Scale out your Azure resources to keep systems running. {{Incorrect. Adding more resources will only
help temporarily make your services available. The attacker could just ramp up the attack to over-
whelm new resources.}}
Email your IT team. {{Incorrect. Letting your IT team know is a good idea, but you need to monitor and
protect your resources first.}}
4-Exercise: Configure DDoS Protection on a vir-

tual network using the Azure portal
Being responsible for Contoso's Network Security team, you are going to run a mock DDoS attack on the
virtual network. The following steps walk you through creating a virtual network, configuring DDoS
Protection, and creating an attack which you can observe and monitor with the help of telemetry and
metrics.
299

●● Task 1: Create a resource group
●● Task 2: Create a DDoS Protection plan
●● Task 3: Enable DDoS Protection on a new virtual network
●● Task 4: Configure DDoS telemetry
●● Task 5: Configure DDoS diagnostic logs
●● Task 6: Configure DDoS alerts
●● Task 7: Submit a DDoS service request to run a DDoS attack
Task 1: Create a resource group

1. Log in to your Azure account.
2. On the Azure portal home page, select Resource groups.
3. Click Create.
4. On the Basics tab, in Resource group, enter MyResourceGroup.
5. In Region, select your region from the list.
7. Click Create.
300
Task 2: Create a DDoS Protection plan

1. On the Azure portal home page, select Create a resource, then in the search box, type DDoS and
click DDoS protection plan when it appears.
2. Click Create.
3. On the Basics tab, in the Resource group list, select the resource group you just created.
4. In the Instance name box, type MyDdoSProtectionPlan, then click Review + create.
301
5. Click Create.
Task 3: Enable DDoS Protection on a new virtual network

Here you will enable DDoS on a new virtual network rather than on an existing one, so first you need to
create the new virtual network, then enable DDoS protection on it using the plan you created previously.
1. On the Azure portal home page, select Create a resource, then in the search box, type Virtual
Network, then click Virtual Network when it appears.
302
2. On the Virtual Network page, click Create.

3. On the Basics tab, select the resource group you created previously.
4. In the Name box, type MyVirtualNetwork, then click the Security tab.
5. On the Security tab, next to DDoS Protection Standard, select Enable.

6. In the DDoS protection plan drop-down list, select MyDdosProtectionPlan.
303

8. Click Create.
Task 4: Configure DDoS telemetry

You create a Public IP address, and then set up telemetry in the next steps.
1. On the Azure portal home page, select Create a resource, then in the search box, type public ip, then
click Public IP address when it appears.
2. On the Public IP address page, click Create.
3. On the Create public IP address page, under SKU, select Basic.
4. In the Name box, type MyPublicIPAddress.
5. Under IP address assignment, select Static.
6. In DNS name label, type mypublicdns.
7. Select your resource group from the list.
304
8. Click Create.
9. On the Azure home page, click All resources.
10. In the list of your resources, click MyDdosProtectionPlan.
11. Under Monitoring, select Metrics.
12. Select the Scope box, then select the checkbox next to MyPublicIPAddress.
13. Click Apply.

14. In the Metrics box, select Inbound packets dropped DDoS.
15. In the Aggregation box, select Max.
305
Task 5: Configure DDoS diagnostic logs

2. In the list of your resources, click MyPublicIPAddress.
3. Under Monitoring, select Diagnostic settings.
4. Click Add diagnostic setting.
5. On the Diagnostic setting page, in the Diagnostic setting name box, type MyDiagnosticSetting.
6. Under Category details, select all 3 log checkboxes and the AllMetrics checkbox.
7. Under Destination details, select the Send to Log Analytics workspace checkbox. Here, you could
select a pre-existing Log Analytics workspace, but as you haven't set up a destination for the diagnos-
tic logs yet, you will just enter the settings, but then discard them in the next step in this exercise.
306
8. Normally you would now click Save to save your diagnostic settings. Note that this option is still
grayed out as we cannot complete the setting configuration yet.
9. Click Discard, then click Yes.
Task 6: Configure DDoS alerts

In this step you will create a virtual machine, assign a public IP address to it, and then configure DDoS
alerts.
Create the VM
1. On the Azure portal home page, select Create a resource, then in the search box, type virtual
machine, then click Virtual machine when it appears.
2. On the Virtual machine page, click Create.
3. On the Basics tab, create a new VM using the information in the table below.
Setting Value
Resource group MyResourceGroup
Virtual machine name MyVirtualMachine
Region Your region
Image Ubuntu Server 18.04 LTS - Gen 1
Size Select See all sizes, then choose B1ls in the list
and choose Select(Standard_B1ls - 1 vcpu, 0.5
GiB memory)
Authentication type SSH public key
307
Username azureuser
SSH public key source Generate new key pair
Key pair name myvirtualmachine-ssh-key
5. Click Create.
6. In the Generate new key pair dialog box, click Download private key and create resource.
7. Save the private key.
8. When deployment is complete, click Go to resource.
308
Assign the Public IP address

1. On the Overview page of the new virtual machine, under Settings, click Networking.
2. Next to Network Interface, click myvirtualmachinexxx (e.g., myvirtualmachine892).
3. Under Settings, click IP configurations.
4. Select ipconfig1.
5. In the Public IP address list, select MyPublicIPAddress.
6. Click Save.
Configure DDoS alerts

2. In the list of your resources, click MyDdosProtectionPlan.
3. Under Monitoring, select Alerts.
4. Click New alert rule.
5. On the Create alert rule page, under Scope, click Edit resource.
6. In the Select a resource pane, in the Filter by resource type box, scroll down the list and select
Public IP addresses.
309
7. In the Resource list, select MyPublicIPAddress, then click Done.

8. On the Create alert rule page, under Condition, click Add condition.
9. Select Under DDoS attack or not.
310
10. In the Operator box select Greater than or equal to.

11. In Threshold value, enter 1 (means under attack).
12. Click Done.
311
13. Back on the Create alert rule page, scroll down to the Alert rule details section and in Alert rule
name, enter MyDdosAlert.
312
14. Click Create alert rule.
Task 7: Submit a DDoS service request to run a DDoS at-

tack
1. Create an account with BreakingPoint Cloud5
2. Set up your DDoS test as per the settings in the screenshot below, but specifying the IP address of
your own MyPublicIPAddress resource in the Target IP Address box (e.g., 51.140.137.219)
5 https://breakingpoint.cloud/
313
3. On the Azure portal home page, click All resources.

4. In the resources list, click your MyPublicIPAddress resource, then under Monitoring, click Metrics.
5. In the Metric box, select Under DDoS attack or not from the list.
6. And here you can see DDoS attack as it happened.
314
5-Deploy Network Security Groups by using the

Azure portal
A Network Security Group (NSG) in Azure allows you to filter network traffic to and from Azure resources
in an Azure virtual network. A network security group contains security rules that allow or deny inbound
network traffic to, or outbound network traffic from, several types of Azure resources. For each rule, you
can specify source and destination, port, and protocol.
NSG security rules

A network security group contains zero, or as many rules as desired, within Azure subscription limits. Each
rule specifies the following properties:
●● Name - Must be a unique name within the network security group.
●● Priority - Can be any number between 100 and 4096. Rules are processed in priority order, with lower
numbers processed before higher numbers, because lower numbers have higher priority. Once traffic
315
matches a rule, processing stops. As a result, any rules that exist with lower priorities (higher numbers)
that have the same attributes as rules with higher priorities are not processed.
●● Source or destination - Can be set to Any, or an individual IP address, or classless inter-domain
routing (CIDR) block (10.0.0.0/24, for example), service tag, or application security group.
●● Protocol - Can be TCP, UDP, ICMP, ESP, AH, or Any.
●● Direction - Can be configured to apply to inbound, or outbound traffic.
●● Port range - Can be specified either as an individual port or range of ports. For example, you could
specify 80 or 10000-10005. Specifying ranges enables you to create fewer security rules.
●● Action - Can be set to Allow or deny.
Network security group security rules are evaluated by priority using the 5-tuple information (source,
source port, destination, destination port, and protocol) to allow or deny the traffic.
Default security rules

Azure creates the following default rules in each network security group that you create:
Direction Name Priority Source Source Destina- Destina- Protocol Access

Ports tion tion
Ports
Inbound Al- 65000 Virtual- 0-65535 Virtual- 0-65535 Any Allow
Network Network
Inbound AllowA- 65001 Azure- 0-65535 0.0.0.0/0 0-65535 Any Allow
zure- LoadBal-
LoadBal- ancer
ancerIn-
Bound
Inbound Deny- 65500 0.0.0.0/0 0-65535 0.0.0.0/0 0-65535 Any Deny
Out- Al- 65000 Virtual- 0-65535 Virtual- 0-65535 Any Allow
bound Network Network
Out- AllowIn- 65001 0.0.0.0/0 0-65535 Internet 0-65535 Any Allow
bound ter-
netOut-
Bound
Out- DenyAll- 65500 0.0.0.0/0 0-65535 0.0.0.0/0 0-65535 Any Deny
bound Out-
Bound
The following diagram and bullet points illustrate different scenarios for how network security groups
might be deployed to allow network traffic to and from the internet over TCP port 80:
316
For inbound traffic Azure processes the rules in a network security group associated to a subnet first, if
there is one, and then the rules in a network security group associated to the network interface, if there is
one.
●● VM1: The security rules in NSG1 are processed since it is associated to Subnet1 and VM1 is in Sub-
net1. Unless you have created a rule that allows port 80 inbound, the traffic is denied by the Deny-
AllInbound default security rule, and never evaluated by NSG2, since NSG2 is associated to the
network interface. If NSG1 has a security rule that allows port 80, the traffic is then processed by
NSG2. To allow port 80 to the virtual machine, both NSG1 and NSG2 must have a rule that allows port
80 from the internet.
●● VM2: The rules in NSG1 are processed because VM2 is also in Subnet1. Since VM2 does not have a
network security group associated to its network interface, it receives all traffic allowed through NSG1
or is denied all traffic denied by NSG1. Traffic is either allowed or denied to all resources in the same
subnet when a network security group is associated to a subnet.
●● VM3: Since there is no network security group associated to Subnet2, traffic is allowed into the
subnet and processed by NSG2, because NSG2 is associated to the network interface attached to
VM3.
●● VM4: Traffic is allowed to VM4, because a network security group is not associated to Subnet3, or the
network interface in the virtual machine. All network traffic is allowed through a subnet and network
interface if they do not have a network security group associated to them.
317
For outbound traffic, Azure processes the rules in a network security group associated to a network
interface first, if there is one, and then the rules in a network security group associated to the subnet, if
there is one.
●● VM1: The security rules in NSG2 are processed. Unless you create a security rule that denies port 80
outbound to the internet, the traffic is allowed by the AllowInternetOutbound default security rule in
both NSG1 and NSG2. If NSG2 has a security rule that denies port 80, the traffic is denied, and never
evaluated by NSG1. To deny port 80 from the virtual machine, either, or both of the network security
groups must have a rule that denies port 80 to the internet.
●● VM2: All traffic is sent through the network interface to the subnet, since the network interface
attached to VM2 does not have a network security group associated to it. The rules in NSG1 are
processed.
●● VM3: If NSG2 has a security rule that denies port 80, the traffic is denied. If NSG2 has a security rule
that allows port 80, then port 80 is allowed outbound to the internet, since a network security group is
not associated to Subnet2.
●● VM4: All network traffic is allowed from VM4, because a network security group is not associated to
the network interface attached to the virtual machine, or to Subnet3.
Application Security Groups

An Application Security Group (ASG) enables you to configure network security as a natural extension of
an application's structure, allowing you to group virtual machines and define network security policies
based on those groups. You can reuse your security policy at scale without manual maintenance of explic-
it IP addresses. The platform handles the complexity of explicit IP addresses and multiple rule sets,
allowing you to focus on your business logic.
To minimize the number of security rules you need, and the need to change the rules, plan out the
application security groups you need and create rules using service tags or application security groups,
rather than individual IP addresses, or ranges of IP addresses, whenever possible.
Filter network traffic with an NSG using the Azure portal

You can use a network security group to filter network traffic inbound and outbound from a virtual
network subnet. Network security groups contain security rules that filter network traffic by IP address,
port, and protocol. Security rules are applied to resources deployed in a subnet.
The key stages to filter network traffic with an NSG using the Azure portal are:
1. Create a resource group - this can either be done beforehand or as you create the virtual network in
the next stage. All other resources that you create must be in the same region specified here.
2. Create a virtual network - this must be deployed in the same resource group you created above.
3. Create application security groups - the application security groups you create here will enable you
to group together servers with similar functions, such as web servers or management servers. You
would create two application security groups here; one for web servers and one for management
servers (for example, MyAsgWebServers and MyAsgMgmtServers)
4. Create a network security group - the network security group will secure network traffic in your
virtual network. This NSG will be associated with a subnet in the next stage.
5. Associate a network security group with a subnet - this is where you will associate the network
security group you create above, with the subnet of the virtual network you created in stage 2 above.
318
6. Create security rules - this is where you create your inbound security rules. Here you would create a
security rule to allow ports 80 and 443 to the application security group for your web servers (for
example, MyAsgWebServers). Then you would create another security rule to allow RDP traffic on port
3389 to the application security group for your management servers (for example, MyAsgMgmtServ-
ers). These rules will control from where you can access your VM remotely and your IIS Webserver.
7. Create virtual machines - this is where you create the web server (for example, MyVMWeb) and
management server (for example, MyVMMgmt) virtual machines which will be associated with their
respective application security group in the next stage.
8. Associate NICs to an ASG - this is where you associate the network interface card (NIC) attached to
each virtual machine with the relevant application security group that you created in stage 3 above.
9. Test traffic filters - the final stage is where you test that your traffic filtering is working as expected.
●● To test this, you would attempt to connect to the management server virtual machine (for exam-
ple, MyVMMgmt) by using an RDP connection, thereby verifying that you can connect because
port 3389 is allowing inbound connections from the Internet to the management servers applica-
tion security group (for example, MyAsgMgmtServers).
●● While connected to the RDP session on the management server (for example, MyVMMgmt), you
would then test an RDP connection from the management server virtual machine (for example,
MyVMMgmt) to the web server virtual machine (for example, MyVMWeb), which again should
succeed because virtual machines in the same network can communicate with each over any port
by default.
●● However, you will not be able to create an RDP connection to the web server virtual machine (for
example, MyVMWeb) from the internet, because the security rule for the web servers application
security group (for example, MyAsgWebServers) prevents connections to port 3389 inbound from
the Internet. Inbound traffic from the Internet is denied to all resources by default.
●● While connected to the RDP session on the web server (for example, MyVMWeb), you could then
install IIS on the web server, then disconnect from the web server virtual machine RDP session, and
disconnect from the management server virtual machine RDP session. In the Azure portal, you
would then determine the Public IP address of the web server virtual machine (for example,
MyVMWeb), and confirm you can access the web server virtual machine from the Internet by
opening a web browser on your computer and navigating to http:// (for example,
http://23.96.39.113) . You should see the standard IIS welcome screen, because port 80 is allowed
inbound access from the Internet to the web servers application security group (for example,
MyAsgWebServers). The network interface attached to the web server virtual machine (for exam-
ple, MyVMWeb) is associated with the web servers application security group (for example,
MyAsgWebServers) and therefore allows the connection.
To view the detailed steps for all these tasks, see Tutorial: Filter network traffic with a network securi-
ty group using the Azure portal6.
6 https://docs.microsoft.com/azure/virtual-network/tutorial-filter-network-traffic
319
Multiple choice
What should be the principle when designing security configurations?
deny by default, permit by exception.{{Correct. Denying all will stop all possible access, and then you
can allow as needed.}}
deny specific, permit all.{{In Correct. Denying only known and allowing all access can result in unwant-
ed/yet-to-be-discovered access to your resources.}}
permit all, monitor and deny as needed.{{Incorrect. Allowing all access can result in unwanted/
yet-to-be-discovered access to your resources, and you will be at risk during discovery phase.}}
Multiple choice
Which one of these is a default network security rule in an NSG?
AllowInternetOutBound.{{Correct. Network Security Group rules allow all internet (destination)
outbound traffic by default.}}
AllowAllInbound.{{Incorrect. There is no default rule to allow all inbound traffic.}}
AllowVnetOutBound.{{Incorrect. VNet OutBound traffic is allowed (not denied) where the source and
destination are Virtual Network.}}
6-Design and implement Azure Firewall
Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual
Network resources. It is a fully stateful firewall as a service with built-in high availability and unrestricted
cloud scalability.
320
Azure Firewall features

Azure Firewall includes the following features:
●● Built-in high availability - High availability is built in, so no extra load balancers are required and
there's nothing you need to configure.
●● Unrestricted cloud scalability - Azure Firewall can scale out as much as you need to accommodate
changing network traffic flows, so you do not need to budget for your peak traffic.
●● Application FQDN filtering rules - You can limit outbound HTTP/S traffic or Azure SQL traffic to a
specified list of fully qualified domain names (FQDN) including wild cards. This feature does not
require TLS termination.
●● Network traffic filtering rules - You can centrally create allow or deny network filtering rules by
source and destination IP address, port, and protocol. Azure Firewall is fully stateful, so it can distin-
guish legitimate packets for different types of connections. Rules are enforced and logged across
multiple subscriptions and virtual networks.
●● FQDN tags - These tags make it easy for you to allow well-known Azure service network traffic
through your firewall. For example, say you want to allow Windows Update network traffic through
your firewall. You create an application rule and include the Windows Update tag. Now network traffic
from Windows Update can flow through your firewall.
●● Service tags - A service tag represents a group of IP address prefixes to help minimize complexity for
security rule creation. You cannot create your own service tag, nor specify which IP addresses are
included within a tag. Microsoft manages the address prefixes encompassed by the service tag, and
automatically updates the service tag as addresses change.
321
●● Threat intelligence - Threat intelligence-based filtering can be enabled for your firewall to alert and
deny traffic from/to known malicious IP addresses and domains. The IP addresses and domains are
sourced from the Microsoft Threat Intelligence feed.
●● Outbound SNAT support - All outbound virtual network traffic IP addresses are translated to the
Azure Firewall public IP (Source Network Address Translation (SNAT)). You can identify and allow
traffic originating from your virtual network to remote Internet destinations.
●● Inbound DNAT support - Inbound Internet network traffic to your firewall public IP address is
translated (Destination Network Address Translation) and filtered to the private IP addresses on your
virtual networks.
●● Multiple public IP addresses - You can associate multiple public IP addresses (up to 250) with your
firewall, to enable specific DNAT and SNAT scenarios.
●● Azure Monitor logging - All events are integrated with Azure Monitor, allowing you to archive logs
to a storage account, stream events to your Event Hub, or send them to Azure Monitor logs.
●● Forced tunneling - You can configure Azure Firewall to route all Internet-bound traffic to a designat-
ed next hop instead of going directly to the Internet. For example, you may have an on-premises edge
firewall or other network virtual appliance (NVA) to process network traffic before it is passed to the
Internet.
●● Web categories (preview) - Web categories let administrators allow or deny user access to web site
categories such as gambling websites, social media websites, and others. Web categories are included
in Azure Firewall Standard, but it is more fine-tuned in Azure Firewall Premium Preview. As opposed to
the Web categories capability in the Standard SKU that matches the category based on an FQDN, the
Premium SKU matches the category according to the entire URL for both HTTP and HTTPS traffic.
●● Certifications - Azure Firewall is Payment Card Industry (PCI), Service Organization Controls (SOC),
International Organization for Standardization (ISO), and ICSA Labs compliant.
Rule processing in Azure Firewall

In the Azure Firewall, you can configure NAT rules, network rules, and applications rules, and this can be
done either by using classic rules or Firewall Policy. An Azure Firewall denies all traffic by default, until
rules are manually configured to allow traffic.
Rule processing with classic rules

With classic rules, rule collections are processed according to the rule type in priority order, lower
numbers to higher numbers from 100 to 65,000. A rule collection name can have only letters, numbers,
underscores, periods, or hyphens. It must also begin with either a letter or a number, and it must end
with a letter, a number, or an underscore. The maximum name length is 80 characters. It is best practice
to initially space your rule collection priority numbers in increments of 100 (i.e., 100, 200, 300, and so on)
so that you give yourself space to add more rule collections when needed.
Rule processing with Firewall Policy

With Firewall Policy, rules are organized inside Rule Collections which are contained in Rule Collection
Groups. Rule Collections can be of the following types:
●● DNAT (Destination Network Address Translation)
●● Network
322
●● Application
You can define multiple Rule Collection types within a single Rule Collection Group, and you can define
zero or more Rules in a Rule Collection, but the rules within a Rule Collection must be of the same type
(i.e., DNAT, Network, or Application).
With Firewall Policy, rules are processed based on Rule Collection Group Priority and Rule Collection
priority. Priority is any number between 100 (highest priority) and 65,000 (lowest priority). Highest priority
Rule Collection Groups are processed first, and inside a Rule Collection Group, Rule Collections with the
highest priority (i.e., the lowest number) are processed first.
In the case of a Firewall Policy being inherited from a parent policy, Rule Collection Groups in the parent
policy always takes precedence regardless of the priority of the child policy.
Application rules are always processed after network rules, which are themselves always processed after
DNAT rules regardless of Rule Collection Group or Rule Collection priority and policy inheritance.
Outbound connectivity using network rules and application

rules
If you configure both network rules and application rules, then network rules are applied in priority order
before application rules. Additionally, all rules are terminating, therefore, if a match is found in a network
rule, no other rules are processed thereafter.
If there is no network rule match, and if the protocol is either HTTP, HTTPS, or MSSQL, then the packet is
then evaluated by the application rules in priority order. For HTTP, Azure Firewall looks for an application
rule match according to the Host Header, whereas for HTTPS, Azure Firewall looks for an application rule
match according to Server Name Indication (SNI) only.
Inbound connectivity using DNAT rules and network rules

Inbound Internet connectivity can be enabled by configuring DNAT. As mentioned previously, DNAT rules
are applied in priority before network rules. If a match is found, an implicit corresponding network rule to
allow the translated traffic is added. For security reasons, the recommended approach is to add a specific
Internet source to allow DNAT access to the network and avoid using wildcards.
Application rules aren't applied for inbound connections. So, if you want to filter inbound HTTP/S traffic,
you should use Web Application Firewall (WAF).
For enhanced security, if you modify a rule to deny access to traffic that had previously been allowed, any
relevant existing sessions are dropped.
Deploying and configuring Azure Firewall

Be aware of the following when deploying Azure Firewall:
●● It can centrally create, enforce, and log application and network connectivity policies across subscrip-
tions and virtual networks.
●● It uses a static, public IP address for your virtual network resources. This allows outside firewalls to
identify traffic originating from your virtual network.
●● It is fully integrated with Azure Monitor for logging and analytics.
●● When creating firewall rules, it is best to use the FQDN tags.
323
The key stages of deploying and configuring Azure Firewall are as follows:
●● Create a resource group
●● Create a virtual network and subnets
●● Create a workload VM in a subnet
●● Deploy the firewall and policy to the virtual network
●● Create a default outbound route
●● Configure an application rule
●● Configure a network rule
●● Configure a Destination NAT (DNAT) rule
●● Test the firewall
Deploying Azure Firewall with Availability Zones

One of the major features of Azure Firewall is Availability Zones.
When deploying Azure Firewall, you can configure it to span multiple Availability Zones for increased
availability. When you configure Azure Firewall in this way your availability increases to 99.99% uptime.
The 99.99% uptime SLA is offered when two or more Availability Zones are selected.
You can also associate Azure Firewall to a specific zone just for proximity reasons, using the service
standard 99.95% SLA.
For more information, see the Azure Firewall Service Level Agreement (SLA)7.
There is no additional cost for a firewall deployed in an Availability Zone. However, there are added costs
for inbound and outbound data transfers associated with Availability Zones.
For more information, see Bandwidth pricing details8.
Azure Firewall Availability Zones are only available in regions that support Availability Zones.
Availability Zones can only be configured during firewall deployment. You cannot configure an existing
firewall to include Availability Zones.
Methods for deploying an Azure Firewall with Availability

Zones
You can use several methods for deploying your Azure Firewall using Availability Zones.
●● Azure portal
●● Azure PowerShell - see Deploy an Azure Firewall with Availability Zones using Azure PowerShell9
●● Azure Resource Manager template - see Quickstart: Deploy Azure Firewall with Availability Zones
- Azure Resource Manager template10
7 https://azure.microsoft.com/support/legal/sla/azure-firewall/v1_0/
8 https://azure.microsoft.com/pricing/details/bandwidth/
9 https://docs.microsoft.com/azure/firewall/deploy-availability-zone-powershell
10 https://docs.microsoft.com/azure/firewall/deploy-template
324
Multiple choice
Filtering of which direction of traffic does Azure Firewall support?
Inbound and Outbound.{{Correct. Azure Firewall supports inbound and outbound filtering. Inbound
protection is typically used for non-HTTP/S protocols. For example RDP, SSH, and FTP protocols.}}
Outbound only.{{Incorrect. Azure Firewall supports inbound and outbound filtering.}}
Inbound only.{{Incorrect. Azure Firewall supports inbound and outbound filtering.}}
Multiple choice
Which one of the following priority levels is considered to be highest for a security rule?
0{{Incorrect. Priority settings must use a number between 100 and 65000.}}
100{{Correct. Priority settings can be any number between 100 and 65000. With 100 being the highest
priority.}}
110{{Incorrect. 110 will be considered lower priority than 100. The smaller the number, the higher the
priority.}}
7-Exercise: Deploy and configure Azure Firewall

Being part of the Network Security team at Contoso, your next task is to create firewall rules to allow/
deny access to certain websites. The following steps walk you through creating a resource group, a virtual
network and subnets, and a virtual machine as environment preparation tasks, and then deploying a
firewall and firewall policy, configuring default routes and application, network and DNAT rules, and
finally testing the firewall.
●● Task 2: Create a virtual network and subnets
●● Task 3: Create a virtual machine
●● Task 4: Deploy the firewall and firewall policy
●● Task 5: Create a default route
●● Task 6: Configure an application rule
●● Task 7: Configure a network rule
●● Task 8: Configure a Destination NAT (DNAT) rule
●● Task 9: Change the primary and secondary DNS address for the server's network interface
●● Task 10: Test the firewall
325

In this task, you will create a new resource group.
1. Log in to your Azure account.
3. Click Create.
4. On the Basics tab, in Resource group, enter Test-FW-RG.
5. In Region, select your region from the list.

7. Click Create.
Task 2: Create a virtual network and subnets

In this task, you will create a single virtual network with two subnets.
network and select Virtual Network when it appears.
2. Click Create.
3. Select the Test-FW-RG resource group you created previously.
4. In the Name box, enter Test-FW-VN.
326
5. Click Next: IP Addresses.

6. Under Subnet name, click the word default.
7. In the Edit subnet dialog box, change the name to AzureFirewallSubnet.
8. Change the Subnet address range to 10.0.1.0/26.
9. Click Save.
327
10. Click Add subnet, to create another subnet, which will host the workload server that you will create
328
shortly.
11. In the Edit subnet dialog box, change the name to Workload-SN.
13. Click Add.

15. Click Create.
329
Task 3: Create a virtual machine

In this task, you will create the workload virtual machine and place it in the Workload-SN subnet created
previously.
machine and select Virtual machine when it appears.
2. On the Virtual machine page, click Create.
3. On the Basics tab, create a new VM using the information in the table below.
Setting Value
Resource group Test-FW-RG
Virtual machine name Srv-Work
Region Your region
Size Select See all sizes, then choose B1s in the list
and choose Select
(Standard_B1s - 1 vcpu, 1 GiB memory

Username MyAdmin
Public inbound ports Select None
330
4. Click Next : Disks.

5. Click Next : Networking.
6. Ensure that Test-FW-VN is selected for the virtual network and the subnet is Workload-SN.
7. For Public IP, select None.
8. Click Next : Management.
9. Under Monitoring, set Boot diagnostics to Disable.
11. Click Create.
12. When deployment of the VM completes, click Go to resource.
13. On the Overview page of Srv-Work, on the right of the page under Networking, take a note of the
Private IP address for this VM (e.g., 10.0.2.4).
331
Task 4: Deploy the firewall and firewall policy

In this task, you will deploy the firewall into the virtual network with a firewall policy configured.
1. On the Azure portal home page, select Create a resource, then in the search box, type firewall and
select Firewall when it appears.
2. On the Firewall page, click Create.
3. On the Basics tab, create a firewall using the information in the table below.
Setting Value
Virtual machine name Test-FW01
Region Your region
Firewall tier Standard
Firewall management Use a Firewall Policy to manage this firewall
Firewall policy Select Add new
Name: fw-test-pol
Region: your region
Choose a virtual network Use existing

Virtual network Test-FW-VN
332
Public IP address Select Add new

Name: fw-pip
4. Review all the settings to ensure they match the screenshot below.

333
6. Click Create and wait for the firewall deployment to complete.

7. When deployment of the firewall is completed, click Go to resource.
8. On the Overview page of Test-FW01, on the right of the page, take a note of the Firewall private IP
for this firewall (e.g., 10.0.1.4).
9. In the menu on the left, under Settings, click Public IP configuration.
10. Take a note of the address under IP Address for the fw-pip public IP configuration (e.g.,
20.90.136.51).
Task 5: Create a default route

In this task, on the Workload-SN subnet, you will configure the outbound default route to go through the
firewall.
1. On the Azure portal home page, select Create a resource, then in the search box, type route and
select Route table when it appears.
2. On the Route table page, click Create.
3. On the Basics tab, create a new route table using the information in the table below.
Setting Value
Region Your region
Name Firewall-route
Propagate gateway routes Yes
5. Click Create.
334
6. After deployment completes, select Go to resource.

7. On the Firewall-route page, under Settings, click Subnets and then click Associate.
8. In Virtual network, select Test-FW-VN.
9. In Subnet, select Workload-SN. Make sure that you select only the Workload-SN subnet for this
route, otherwise your firewall won't work correctly.
10. Click OK.
11. Under Settings, select Routes and then click Add.
12. In Route name, enter fw-dg.
13. In Address prefix, enter 0.0.0.0/0.
14. In Next hop type, select Virtual appliance.
15. In Next hop address, type the private IP address for the firewall that you noted previously (e.g.,
10.0.1.4)
16. Click OK.
335
Task 6: Configure an application rule

In this task, you will add an application rule that allows outbound access to www.google.com.
1. On the Azure portal home page, select All resources.
2. In the list of resources, click your firewall policy, fw-test-pol.
3. Under Settings, click Application Rules.
4. Click Add a rule collection.
5. On the Add a rule collection page, create a new application rule using the information in the table
below.
Setting Value
Name App-Coll01
Rule collection type Application
Priority 200
Rule collection action Allow
Rule collection group DefaultApplicationRuleCollectionGroup
Rules Section
Name Allow-Google
Source type IP Address
Source 10.0.2.0/24
Protocol http,https
Destination type FQDN
Destination www.google.com
336
6. Click Add.
Task 7: Configure a network rule

In this task, you will add a network rule that allows outbound access to two IP addresses at port 53 (DNS).
1. On the fw-test-pol page, under Settings, click Network Rules.
3. On the Add a rule collection page, create a new network rule using the information in the table
below.
Setting Value
Name Net-Coll01
Rule collection type Network
Priority 200
Rule collection action Allow
Rule collection group DefaultNetworkRuleCollectionGroup
Rules Section
Name Allow-DNS
Source 10.0.2.0/24
Protocol UDP
Destination Ports 53
Destination Type IP Address
Destination 209.244.0.3, 209.244.0.4
These are public DNS servers operated by Century
Link
337
4. Click Add.
Task 8: Configure a Destination NAT (DNAT) rule

In this task, you will add a DNAT rule that allows you to connect a remote desktop to the Srv-Work virtual
machine through the firewall.
1. On the fw-test-pol page, under Settings, click DNAT Rules.
3. On the Add a rule collection page, create a new DNAT rule using the information in the table below.
Setting Value
Name rdp
Rule collection type DNAT
Priority 200
Rule collection group DefaultDnatRuleCollectionGroup
Rules Section
Name rdp-nat
Source *
Protocol TCP
Destination Ports 3389
Destination Type IP Address
Destination Enter the firewall public IP address from fw-pip
that you noted earlier.
e.g. - 20.90.136.51
Translated address Enter the private IP address from Srv-Work that
you noted earlier.
e.g. - 10.0.2.4
Translated port 3389
338
4. Click Add.
Task 9: Change the primary and secondary DNS address

for the server's network interface
For testing purposes in this exercise, in this task, you will configure the Srv-Work server's primary and
secondary DNS addresses. However, this is not a general Azure Firewall requirement.
2. In the list of resource groups, click your resource group, Test-FW-RG.
3. In the list of resources in this resource group, select the network interface for the Srv-Work virtual
machine (e.g., srv-work350).
4. Under Settings, select DNS servers.

5. Under DNS servers, select Custom.
6. Type 209.244.0.3 in the Add DNS server text box, and 209.244.0.4 in the next text box.
7. Select Save.
339
8. Restart the Srv-Work virtual machine.
Task 10: Test the firewall

In this final task, you will test the firewall to verify that the rules are configured correctly and working as
expected. This configuration will enable you to connect a remote desktop connection to the Srv-Work
virtual machine through the firewall, via the firewall's public IP address.
1. Open Remote Desktop Connection on your PC.
2. In the Computer box, enter the firewall's public IP address (e.g., 20.90.136.51) followed by :3389
(e.g., 20.90.136.51:3389).
3. In the Username box, enter MyAdmin.
4. Click Connect.
340
5. In the Enter your credentials dialog box, log into the Srv-Work server virtual machine, by using the
password, TestPa$$w0rd!.
6. Click OK.
7. Click Yes on the certificate message.
8. Open Internet Explorer and browse to https://www.google.com.
9. In the Security Alert dialog box, click OK.
10. Click Close on the Internet Explorer security alerts that may pop-up.
11. You should see the Google home page.
341
12. Browse to https://www.microsoft.com.

13. You should be blocked by the firewall.
342
8-Secure your networks with Azure Firewall

Manager
Working with Azure Firewall Manager
Azure Firewall Manager is a security management service that provides central security policy and route
management for cloud-based security perimeters.
343
Azure Firewall Manager simplifies the process of centrally defining network and application-level rules for
traffic filtering across multiple Azure Firewall instances. You can span different Azure regions and sub-
scriptions in hub and spoke architectures for traffic governance and protection.
If you manage multiple firewalls, you know that continuously changing firewall rules make it difficult to
keep them in sync. Central IT teams need a way to define base firewall policies and enforce them across
multiple business units. At the same time, DevOps teams want to create their own local derived firewall
policies that are implemented across organizations. Azure Firewall Manager can help solve these prob-
lems.
Firewall Manager can provide security management for two network architecture types:
●● Secured Virtual Hub - This is the name given to any Azure Virtual WAN Hub when security and
routing policies have been associated with it. An Azure Virtual WAN Hub is a Microsoft-managed
resource that lets you easily create hub and spoke architectures.
●● Hub Virtual Network - This is the name given to any standard Azure virtual network when security
policies are associated with it. A standard Azure virtual network is a resource that you create and
manage yourself. At this time, only Azure Firewall Policy is supported. You can peer spoke virtual
networks that contain your workload servers and services. You can also manage firewalls in standalone
virtual networks that are not peered to any spoke.
Azure Firewall Manager features

The key features offered by Azure Firewall Manager are:
●● Central Azure Firewall deployment and configuration - You can centrally deploy and configure
multiple Azure Firewall instances that span different Azure regions and subscriptions.
●● Hierarchical policies (global and local) - You can use Azure Firewall Manager to centrally manage
Azure Firewall policies across multiple secured virtual hubs. Your central IT teams can author global
344
firewall policies to enforce organization wide firewall policy across teams. Locally authored firewall
policies allow a DevOps self-service model for better agility.
●● Integrated with third-party security-as-a-service for advanced security - In addition to Azure
Firewall, you can integrate third-party security-as-a-service providers to provide additional network
protection for your VNet and branch Internet connections. This feature is available only with secured
virtual hub deployments (see above).
●● Centralized route management - You can easily route traffic to your secured hub for filtering and
logging without the need to manually set up User Defined Routes (UDR) on spoke virtual networks.
This feature is available only with secured virtual hub deployments (see above).
●● Region availability - You can use Azure Firewall Policies across regions. For example, you can create a
policy in the West US region, and still use it in the East US region.
Azure Firewall Manager policies

A Firewall policy is an Azure resource that contains NAT, network, and application rule collections and
Threat Intelligence settings. It is a global resource that can be used across multiple Azure Firewall instanc-
es in Secured Virtual Hubs and Hub Virtual Networks. New policies can be created from scratch or inherit-
ed from existing policies. Inheritance allows DevOps to create local firewall policies on top of organiza-
tion mandated base policy. Policies work across regions and subscriptions.
You can create Firewall Policy and associations with Azure Firewall Manager. However, you can also create
and manage a policy using REST API, templates, Azure PowerShell, and the Azure CLI. Once you create a
policy, you can associate it with a firewall in a virtual WAN hub making it a Secured Virtual Hub and/or
associate it with a firewall in a standard Azure virtual network making it a Hub Virtual Network.
345
Deploying Azure Firewall Manager for Hub Virtual Networks

The recommended process to deploy Azure Firewall Manager for Hub Virtual Networks is as follows:
1. Create a firewall policy. You can either create a new policy, derive a base policy, and customize a
local policy, or import rules from an existing Azure Firewall. Ensure you remove NAT rules from
policies that should be applied across multiple firewalls.
2. Create your hub and spoke architecture. Do this either by creating a Hub Virtual Network using
Azure Firewall Manager and peering spoke virtual networks to it using virtual network peering, or by
creating a virtual network and adding virtual network connections and peering spoke virtual networks
to it using virtual network peering.
3. Select security providers and associate firewall policy. (At time of writing, only Azure Firewall is a
supported provider). This can be done while creating a Hub Virtual Network, or by converting an
existing virtual network to a Hub Virtual Network. It is also possible to convert multiple virtual net-
works.
4. Configure User Defined Routes to route traffic to your Hub Virtual Networkfirewall.
Deploying Azure Firewall Manager for Secured Virtual Hubs

The recommended process to deploy Azure Firewall Manager for Secured Virtual Hubs is as follows:
1. Create your hub and spoke architecture. Do this either by creating a Secured Virtual Hub using
Azure Firewall Manager and adding virtual network connections, or by creating a Virtual WAN Hub
and adding virtual network connections.
2. Select security providers. This can be done while creating a Secured Virtual Hub, or by converting an
existing Virtual WAN Hub to a Secure Virtual Hub.
3. Create a firewall policy and associate it with your hub. This is applicable only if you are using
Azure Firewall. Third-party security-as-a-service policies are configured via the partners management
experience.
4. Configure route settings to route traffic to your Secured Virtual Hub. You can easily route traffic
to your secured hub for filtering and logging without User Defined Routes (UDR) on spoke Virtual
Networks by using the Secured Virtual Hub Route Setting page.
You cannot have more than one hub per virtual WAN per region, however you can add multiple virtual
WANs in the region to achieve this.
You cannot have overlapping IP spaces for hubs in a vWAN.
Your hub VNet connections must be in the same region as the hub.
9-Exercise: secure your virtual hub using Azure

Firewall Manager
In this exercise, you will create the spoke virtual network and create a secured virtual hub, then you will
connect the hub and spoke virtual networks and route traffic to your hub. Next you will deploy the
workload servers, then create a firewall policy and secure your hub, and finally you will test the firewall.
346
Create a hub and spoke architecture

In this part of the exercise, you will create the spoke virtual networks and subnets where you will place
the workload servers. Then you will create the secured virtual hub and connect the hub and spoke virtual
networks.
●● Task 1: Create two spoke virtual networks and subnets
●● Task 2: Create the secured virtual hub
●● Task 3: Connect the hub and spoke virtual networks
●● Task 4: Deploy the servers
●● Task 5: Create a firewall policy and secure your hub
●● Task 6: Associate the firewall policy
●● Task 7: Route traffic to your hub
●● Task 8: Test the application rule
●● Task 9: Test the network rule
Task 1: Create two spoke virtual networks and subnets

In this task, you will create the two spoke virtual networks each containing a subnet that will host your
workload servers.
network and select Virtual Network when it appears.
2. Click Create.
3. In Resource group, select Create new, and enter fw-manager-rg as the name and click OK.
4. In Name, enter Spoke-01.
5. In Region, select your region.
6. Click Next: IP Addresses.
7. In IPv4 address space, enter 10.0.0.0/16.
8. Delete any other address spaces listed here, such as 10.1.0.0/16.
9. Under Subnet name, click the word default.
10. In the Edit subnet dialog box, change the name to Workload-01-SN.
12. Click Save.
14. Click Create.
Repeat steps 1 to 14 above to create another similar virtual network and subnet but using the following
information:
●● Resource Group: fw-manager-rg (select existing)
347
●● Name: Spoke-02
●● Address space: 10.1.0.0/16 - (delete any other listed address spaces)
●● Subnet name: Workload-02-SN
●● Subnet address range: 10.1.1.0/24
Task 2: Create the secured virtual hub

In this task you will create your secured virtual hub using Firewall Manager.
1. From the Azure portal home page, click All services.
2. In the search box, type firewall manager and select Firewall Manager when it appears.
3. On the Firewall Manager page, click View secured virtual hubs.
4. On the Virtual hubs page, click Create new secured virtual hub.
5. For Resource group, select fw-manager-rg.
6. For Region, select your region.
7. For the secured virtual hub name, enter Hub-01.
8. For Hub address space, enter 10.2.0.0/16.
9. Choose New vWAN.
10. In Virtual WAN Name, enter Vwan-01.
348
11. Click Next: Azure Firewall.

12. Click Next: Security Partner Provider.
13. Click Next: Review + create.
14. Click Create.
[!NOTE]
This can take up to 30 minutes to deploy.
349
15. When the deployment completes, from the Azure portal home page, click All services.
16. In the search box, type firewall manager and select Firewall Manager when it appears.
17. On the Firewall Manager page, click Virtual hubs.
18. Click Hub-01.
19. Click Public IP configuration.
20. Note down the public IP address (e.g., 51.143.226.18), which you will use later.
Task 3: Connect the hub and spoke virtual networks

In this task you will connect the hub and spoke virtual networks. This is commonly known as peering.
1. From the Azure portal home page, click Resource groups.
2. Select the fw-manager-rg resource group, then select the Vwan-01 virtual WAN.
3. Under Connectivity, click Virtual network connections.
4. Click Add connection.
5. For Connection name, enter hub-spoke-01.
6. For Hubs, select Hub-01.
7. For Resource group, select fw-manager-rg.
8. For Virtual network, select Spoke-01.
350
9. Click Create.
10. Repeat steps 4 to 9 above to create another similar connection but using the connection name of
hub-spoke-02 to connect the Spoke-02 virtual network.
351
Task 4: Deploy the servers

In this task you will deploy the two workload servers.
1. From the Azure portal home page, click Create a resource.
2. In the Popular offers list, select Windows Server Datacenter 2019.
3. On the Create a virtual machine page, on the Basics tab, create a new VM using the information in
the table below.
Setting Value
Resource group fw-manager-rg
Virtual machine name Srv-workload-01
Region Your region
Username MyAdmin
352
Public inbound ports None

4. Click Next : Disks.
5. Click Next : Networking.
6. In Virtual network, ensure that Spoke-01 is selected.
7. In Subnet, ensure that Workload-01-SN is selected.
8. In Public IP, select None.
9. Click Next : Management.
10. Under Monitoring, in Boot diagnostics, click Disable.
12. Click Create.
13. When this deployment has completed, click Create another VM.
14. Repeat steps 3 to 12 above to create another virtual machine but using the following information:
●● Virtual machine name: Srv-workload-02
●● Virtual network: Spoke-02
●● Subnet: Workload-02-SN
●● Public IP: None
15. When deployment of the second VM has completed, click Go to resource.
16. On the Overview page of Srv-workload-02, in the right-hand pane, under the Networking section,
note down the Private IP address (e.g., 10.1.1.4).
17. Click Home.
18. On the Azure portal home page, click All resources.
19. Click the Srv-workload-01 virtual machine.
20. On the Overview page of Srv-workload-01, in the right-hand pane, under the Networking section,
note down the Private IP address (e.g., 10.0.1.4).
Task 5: Create a firewall policy and secure your hub

In this task you will first create your firewall policy, then secure your hub. The firewall policy will define
collections of rules to direct traffic on one or more Secured virtual hubs.
1. From the Azure portal home page, click Firewall Manager.
●● If the Firewall Manager icon does not appear on the homepage, then click All services. Then in the
search box, type firewall manager and select Firewall Manager when it appears.
2. From Firewall Manager, click View Azure Firewall Policies.
3. Click Create Azure Firewall Policy.
4. In Resource group, select fw-manager-rg.
5. Under Policy details, for the Name, enter Policy-01.
6. In Region select your region.
7. Click Next : DNS Settings.
353
8. Click Next : TLS Inspection (preview).

9. Click Next : Rules.
10. On the Rules tab, click Add a rule collection.
11. On the Add a rule collection page, in Name, enter App-RC-01.
12. For Rule collection type, select Application.
13. For Priority, enter 100.
14. Ensure Rule collection action is Allow.
15. Under Rules, in Name type Allow-msft.
16. For the Source type, select IP Address.
17. For Source, enter *****.
18. For Protocol, enter http,https.
19. Ensure Destination type is FQDN.
20. For Destination, enter *.microsoft.com.
21. Click Add.
22. To add a DNAT rule so you can connect a remote desktop to the Srv-workload-01 VM, click Add a
rule collection.
23. For Name, enter dnat-rdp.
24. For Rule collection type, select DNAT.
26. Under Rules, in Name enter Allow-rdp.
354
29. For Protocol, select TCP.

30. For Destination Ports, enter 3389.
31. For Destination Type, select IP Address.
32. For Destination, enter the firewall virtual hub public IP address that you noted down earlier (e.g.,
51.143.226.18).
33. For Translated address, enter the private IP address for Srv-workload-01 that you noted down
earlier (e.g., 10.0.1.4).
34. For Translated port, enter 3389.
35. Click Add.
36. To add a Network rule so you can connect a remote desktop from Srv-workload-01 to Srv-work-
load-02 VM, click Add a rule collection.
37. For Name, enter vnet-rdp.
38. For Rule collection type, select Network.
40. For Rule collection action, select Allow.
41. Under Rules, in Name enter Allow-vnet.
44. For Protocol, select TCP.
45. For Destination Ports, enter 3389.
46. For Destination Type, select IP Address.
47. For Destination, enter the private IP address for Srv-workload-02 that you noted down earlier (e.g.,
10.1.1.4).
48. Click Add.
355
49. You should now have 3 rule collections listed.

51. Click Create.
Task 6: Associate the firewall policy

In this task you will associate the firewall policy with the virtual hub.
1. From the Azure portal home page, click Firewall Manager.
●● If the Firewall Manager icon does not appear on the homepage, then click All services. Then in the
search box, type firewall manager and select Firewall Manager when it appears.
2. In Firewall Manager, under Security, click Azure Firewall Policies.
3. Select the checkbox for Policy-01.
4. Select Manage associations>Associate hubs.
5. Select the checkbox for Hub-01.
6. Click Add.
7. When the policy has been attached, click Refresh. The association should be displayed.
356
Task 7: Route traffic to your hub

In this task you will ensure that network traffic gets routed through your firewall.
1. In Firewall Manager, click Virtual hubs.
2. Click Hub-01.
3. Under Settings, click Security configuration.
4. In Internet traffic, select Azure Firewall.
5. In Private traffic, select Send via Azure Firewall.
6. Click Save.
7. This will take a few minutes to complete.
8. Once configuration has completed, ensure that under INTERNET TRAFFIC and PRIVATE TRAFFIC, it
says Secured by Azure Firewall for both hub-spoke connections.
Task 8: Test the application rule

In this part of the exercise, you will connect a remote desktop to the firewall public IP address, which is
NATed to Srv-Workload-01. You will then use a web browser to test the application rule and connect a
remote desktop to Srv-Workload-02 to test the network rule.
In this task you will test the application rule to confirm that it works as expected.
1. Open Remote Desktop Connection on your PC.
2. In the Computer box, enter the firewall's public IP address (e.g., 51.143.226.18).
3. Click Show Options.
4. In the Username box, enter MyAdmin.
5. Click Connect.
6. In the Enter your credentials dialog box, log into the Srv-workload-01 server virtual machine, by
using the password, TestPa$$w0rd!.
7. Click OK.
357

9. Open Internet Explorer and click OK in the Set up Internet Explorer 11 dialog box.
10. Browse to https://www.microsoft.com.
11. In the Security Alert dialog box, click OK.
12. Click Close on the Internet Explorer security alerts that may pop-up.
13. You should see the Microsoft home page.

14. Browse to https://www.google.com.
358
15. You should be blocked by the firewall.

16. So, you have verified that you can connect to the one allowed FQDN but are blocked from all others.
Task 9: Test the network rule

In this task you will test the network rule to confirm that it works as expected.
1. While still logged in to the Srv-workload-01 RDP session, from this remote computer, open Remote
Desktop Connection.
2. In the Computer box, enter the private IP address of Srv-workload-02 (e.g., 10.1.1.4).
3. In the Enter your credentials dialog box, log in to the Srv-workload-02 server by using the user-
name MyAdmin, and a password of TestPa$$w0rd!.
4. Click OK.
359

6. So, now you have verified that the firewall network rule is working, as you have connected a remote
desktop from one server to another server located in another virtual network.
7. Close both RDP sessions to disconnect them.

command:
360
10-Implement a Web Application Firewall on Az-

ure Front Door
Web Application Firewall (WAF) provides centralized protection of your web applications from common
exploits and vulnerabilities. Web applications are increasingly targeted by malicious attacks that exploit
commonly known vulnerabilities. SQL injection and cross-site scripting are among the most common
attacks.
Preventing such attacks in application code is challenging. It can require rigorous maintenance, patching,
and monitoring at multiple layers of the application topology. A centralized web application firewall helps
make security management much simpler. A WAF also gives application administrators better assurance
of protection against threats and intrusions.
A WAF solution can react to a security threat faster by centrally patching a known vulnerability, instead of
securing each individual web application.
Web Application Firewall policy modes

When you create a Web Application Firewall (WAF) policy, by default the WAF policy is in Detection
mode. In Detection mode, WAF does not block any requests; instead, requests matching the WAF rules
are logged at WAF logs. To see WAF in action, you can change the mode settings from Detection to
Prevention. In Prevention mode, requests that match rules that are defined in Default Rule Set (DRS) are
blocked and logged at WAF logs.
361
Web Application Firewall Default Rule Set rule groups and

rules
Azure Front Door web application firewall (WAF) protects web applications from common vulnerabilities
and exploits. Azure-managed rule sets provide an easy way to deploy protection against a common set of
security threats. Since such rule sets are managed by Azure, the rules are updated as needed to protect
against new attack signatures.
Managed rules
Azure-managed Default Rule Set includes rules against the following threat categories:
●● Cross-site scripting
●● Java attacks
●● Local file inclusion
●● PHP injection attacks
●● Remote command execution
●● Remote file inclusion
●● Session fixation
●● SQL injection protection
●● Protocol attackers
Azure-managed Default Rule Set is enabled by default. The current default version is DefaultRuleSet_1.0.
From WAF Managed rules>Assign, the recently available ruleset Microsoft_DefaultRuleSet_1.1 is
available in the drop-down list.
To disable an individual rule, select the checkbox in front of the rule number, and select Disable at the
top of the page. To change action types for individual rules within the rule set, select the checkbox in
front of the rule number, and then select Change action at the top of the page.
362
Custom rules
Azure WAF with Front Door allows you to control access to your web applications based on the condi-
tions you define. A custom WAF rule consists of a priority number, rule type, match conditions, and an
action. There are two types of custom rules: match rules and rate limit rules. A match rule controls access
based on a set of matching conditions while a rate limit rule controls access based on matching condi-
tions and the rates of incoming requests. You may disable a custom rule to prevent it from being evaluat-
ed, but still keep the configuration.
When creating a WAF policy, you can create a custom rule by selecting Add custom rule under the
Custom rules section. This launches the custom rule configuration page.
The example screenshot below shows the configuration of a custom rule to block a request if the query
string contains blockme.
363
Create a Web Application Firewall policy on Azure Front

Door
This section describes how to create a basic Azure Web Application Firewall (WAF) policy and apply it to a
profile in Azure Front Door.
364
The key stages to create a WAF policy on Azure Front Door using the Azure portal are:
1. Create a Web Application Firewall policy - this is where you create a basic WAF policy with man-
aged Default Rule Set (DRS).
2. Associate the WAF policy with a Front Door profile - this is where you associate the WAF policy
created in stage 1 with a Front Door profile. This association can be done during the creation of the
WAF policy, or it can be done on a previously created WAF policy. During the association you specify
the Front Door profile and the domain/s within the Front Door profile you want the WAF policy to be
applied to. During this stage if the domain is associated to a WAF policy, it is shown as grayed out.
You must first remove the domain from the associated policy, and then re-associate the domain to a
new WAF policy.
3. Configure WAF policy settings and rules - this is an optional stage, where you can configure policy
settings such as the Mode (Prevention or Detection) and configure managed rules and custom rules.
To view the detailed steps for all these tasks, see Tutorial: Create a Web Application Firewall policy on
Azure Front Door using the Azure portal11.
Multiple choice
What are the two modes that a WAF policy can use?
WAF policy can either be in Prevention mode or Detection mode.{{Correct. When you create a Web
Application Firewall (WAF) policy, by default the WAF policy is in Detection mode, but you can change
it to Prevention mode.}}
WAF policy can either be in Default mode or Custom mode.{{Incorrect. When you create a Web
Application Firewall (WAF) policy, there are no modes called Default or Custom.}}
WAF policy can either be in Default Rule Set mode or Detection mode.{{Incorrect. When you create a
Web Application Firewall (WAF) policy, by default the WAF policy is in Detection mode, however there
is no mode called Default Rule Set.}}
Multiple choice
What are the two types of custom rule in a WAF policy?
Match rules and rate limit rules..{{Correct. There are two types of custom rules: match rules and rate
limit rules.}}
String rules and match rules.{{Incorrect. There are two types of custom rules: match rules and rate limit
rules, however there is no such custom rule type as String rule}}
Priority rules and rate limit rules.{{Incorrect. There are two types of custom rules: match rules and rate
limit rules, however there is no such custom rule type as Priority rule.}}

As your organization moves to Azure, you must design your network to protect resources from unauthor-
ized access or attack by applying controls to network traffic, allowing only legitimate traffic/requests. In
11 https://docs.microsoft.com/azure/web-application-firewall/afds/waf-front-door-create-portal
365
this module, you saw a range of network security solutions that you could implement to meet your
organizations network security requirements.
You now have the fundamental knowledge required to design and implement network security in Azure.
Summary
●● Understand how to implement compliance with network security rules
●● Configure and monitor an Azure DDoS protection plan
●● Implement and manage firewalls
●● Implement network security groups (NSGs)
●● Implement a web application firewall (WAF) on Azure Front Door
Resources
Azure best practices for network security12
Azure DDoS Protection13
12 https://docs.microsoft.com/azure/security/fundamentals/network-best-practices
13 https://docs.microsoft.com/azure/ddos-protection/fundamental-best-practices
366
Answers
Multiple choice
What Azure service can we use to create a private connection between Azure PaaS and hosted services?
(x ) Azure Private Link {{Correct. Azure Private Link enables you to access Azure PaaS Services (for exam-
ple, Azure Storage and SQL Database) and Azure hosted customer-owned/partner services over a private
endpoint in your virtual network.}}
Azure Service Endpoint {{Incorrect. Azure Service Endpoint provides secure and direct connectivity to
Azure PaaS services over an optimized route over the Azure backbone network.}}
Azure NaaS (network as a service) {{Incorrect. There is no such service as Azure NaaS.}}
Explanation
Multiple choice
Which tool in Azure automatically collects, analyzes, and integrates log data from your Azure resources?
(x ) Azure Security Center {{Correct. Security Center automatically collects, analyzes, and integrates log
data from your Azure resources, the network, and other connected partner solutions, such as firewall and
endpoint protection solutions.}}
Azure Security Benchmark {{Incorrect. The Azure Security Benchmark provides prescriptive best
practices and recommendations to help improve the security of workloads, data, and services on
Azure. It includes a collection of high-impact security recommendations you can use to help secure
the services you use in Azure.}}
Azure Sentinel {{Incorrect. Azure Sentinel is a scalable, cloud-native, security information event
management and security orchestration automated response solution. It delivers intelligent security
analytics and threat intelligence across the enterprise, providing a single solution for alert detection,
threat visibility, proactive hunting, and threat response. It needs to be onboarded and configured to
collect data from your resources in Azure.}}
Explanation
Multiple choice
Which one of these is a symptom of a DDoS attack?
(x ) An unexplained surge in requests. {{Correct. You are not expecting that many concurrent requests that
they start to overwhelm your resources.}}
Application running slowly. {{Incorrect. This could just be other performance-related issues in your
application/connectivity.}}
HTTP 400 Bad Request {{Incorrect. HTTP 400 Bad Request response status code indicates that the
server cannot or will not process the request due to something that is perceived to be a client error}}
Explanation
367
Multiple choice
Which action shall we take when under DDoS attack?
(x ) Monitor Alerts and review attack profile. {{Correct. You should look at any alerts sent out and review
the attack profile (what type of attack, where is it originating, is it targeting a particular resource).}}
Scale out your Azure resources to keep systems running. {{Incorrect. Adding more resources will only
help temporarily make your services available. The attacker could just ramp up the attack to over-
whelm new resources.}}
Email your IT team. {{Incorrect. Letting your IT team know is a good idea, but you need to monitor and
protect your resources first.}}
Explanation
Multiple choice
What should be the principle when designing security configurations?
■■ deny by default, permit by exception.{{Correct. Denying all will stop all possible access, and then you
can allow as needed.}}
deny specific, permit all.{{In Correct. Denying only known and allowing all access can result in unwant-
ed/yet-to-be-discovered access to your resources.}}
permit all, monitor and deny as needed.{{Incorrect. Allowing all access can result in unwanted/
yet-to-be-discovered access to your resources, and you will be at risk during discovery phase.}}
Explanation
Multiple choice
Which one of these is a default network security rule in an NSG?
■■ AllowInternetOutBound.{{Correct. Network Security Group rules allow all internet (destination)
outbound traffic by default.}}
AllowAllInbound.{{Incorrect. There is no default rule to allow all inbound traffic.}}
AllowVnetOutBound.{{Incorrect. VNet OutBound traffic is allowed (not denied) where the source and
destination are Virtual Network.}}
Explanation
Multiple choice
Filtering of which direction of traffic does Azure Firewall support?
■■ Inbound and Outbound.{{Correct. Azure Firewall supports inbound and outbound filtering. Inbound
protection is typically used for non-HTTP/S protocols. For example RDP, SSH, and FTP protocols.}}
Outbound only.{{Incorrect. Azure Firewall supports inbound and outbound filtering.}}
Inbound only.{{Incorrect. Azure Firewall supports inbound and outbound filtering.}}
Explanation
368
Multiple choice
Which one of the following priority levels is considered to be highest for a security rule?
0{{Incorrect. Priority settings must use a number between 100 and 65000.}}
■■ 100{{Correct. Priority settings can be any number between 100 and 65000. With 100 being the highest
priority.}}
110{{Incorrect. 110 will be considered lower priority than 100. The smaller the number, the higher the
priority.}}
Explanation
Multiple choice
What are the two modes that a WAF policy can use?
■■ WAF policy can either be in Prevention mode or Detection mode.{{Correct. When you create a Web
Application Firewall (WAF) policy, by default the WAF policy is in Detection mode, but you can change
it to Prevention mode.}}
WAF policy can either be in Default mode or Custom mode.{{Incorrect. When you create a Web
Application Firewall (WAF) policy, there are no modes called Default or Custom.}}
WAF policy can either be in Default Rule Set mode or Detection mode.{{Incorrect. When you create a
Web Application Firewall (WAF) policy, by default the WAF policy is in Detection mode, however there
is no mode called Default Rule Set.}}
Explanation
Multiple choice
What are the two types of custom rule in a WAF policy?
■■ Match rules and rate limit rules..{{Correct. There are two types of custom rules: match rules and rate
limit rules.}}
String rules and match rules.{{Incorrect. There are two types of custom rules: match rules and rate limit
rules, however there is no such custom rule type as String rule}}
Priority rules and rate limit rules.{{Incorrect. There are two types of custom rules: match rules and rate
limit rules, however there is no such custom rule type as Priority rule.}}
Explanation
Module 7 Design and implement private ac-
cess to Azure services
Design and implement private access to Azure

Services
1-Introduction
As an enterprise organization there are scenarios where you require private access to services hosted on
the Azure platform where you need to eliminating data exposure to the public internet. After completing
this module, you'll have a better understanding of solutions designed to enable private access to services
hosted on the Azure platform. You will understand how to privately connect from a virtual network to
Azure platform as a service (PaaS), customer-owned, or Microsoft partner services. You will learn to create
and manage private connectivity to services on Azure, integrate with on-premises and peered networks,
protect against data exfiltration for Azure resources and deliver services directly to your customers virtual
networks. Learning objectives
●● Understand the difference between private link and private endpoints
●● Design and configure Private Endpoints
●● Integrate a Private Link with DNS and on-premises clients
●● Create, configure, and provide access to Service Endpoints
●● Configure VNET integration for App Service
370
2-Define Private Link Service and private end-

point
What is Azure Private Link?

Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL
Database) and Azure hosted customer-owned/partner services over a Private Endpoint in your virtual
network.
Before you learn about Azure Private Link and its features and benefits, let's examine the problem that
Private Link is designed to solve.
Contoso has an Azure virtual network, and you want to connect to a PaaS resource such as an Azure SQL
database. When you create such resources, you normally specify a public endpoint as the connectivity
method.
Having a public endpoint means that the resource is assigned a public IP address. So, even though both
your virtual network and the Azure SQL database are located within the Azure cloud, the connection
between them takes place over the internet.
The concern here is that your Azure SQL database is exposed to the internet via its public IP address. That
exposure creates multiple security risks. The same security risks are present when an Azure resource is
accessed via a public IP address from the following locations:
●● A peered Azure virtual network
●● An on-premises network that connects to Azure using ExpressRoute and Microsoft peering
●● A customer's Azure virtual network that connects to an Azure service offered by your company
Private Link is designed to eliminate these security risks by removing the public part of the connection.
371
Private Link provides secure access to Azure services. Private Link achieves that security by replacing a
resource's public endpoint with a private network interface. There are three key points to consider with
this new architecture:
●● The Azure resource becomes, in a sense, a part of your virtual network.
●● The connection to the resource now uses the Microsoft Azure backbone network instead of the public
internet.
●● You can configure the Azure resource to no longer expose its public IP address, which eliminates that
potential security risk.
What is Azure Private Endpoint?

Private Endpoint is the key technology behind Private Link. Private Endpoint is a network interface that
enables a private and secure connection between your virtual network and an Azure service. In other
words, Private Endpoint is the network interface that replaces the resource's public endpoint.
Private Link provides secure access to Azure services. Private Link achieves that security by replacing a
resource's public endpoint with a private network interface. Private Endpoint uses a private IP address
from the VNet to bring the service into the VNet.
What is Azure Private Link Service?

Private Link gives you private access from your Azure virtual network to PaaS services and Microsoft
Partner services in Azure. However, what if your company has created its own Azure services that are
consumed by your company's customers? Is it possible to offer those customers a private connection to
your company's services?
Yes, by using Azure Private Link Service. This service lets you offer Private Link connections to your
custom Azure services. Consumers of your custom services can then access those services privately—that
is, without using the internet—from their own Azure virtual networks.
Azure Private Link service is the reference to your own service that is powered by Azure Private Link. Your
service that is running behind Azure standard load balancer can be enabled for Private Link access so that
consumers to your service can access it privately from their own VNets. Your customers can create a
private endpoint inside their VNet and map it to this service. A Private Link service receives connections
from multiple private endpoints. A private endpoint connects to one Private Link service.
372
Plan Private Endpoints

Before creating a Private Endpoint, you should consider the Private Endpoint properties and collect data
about specific needs to be addressed. These include:
●● A unique name with a resource group
●● A subnet to deploy and allocate private IP addresses from a virtual network
●● The Private Link resource to connect using resource ID or alias, from the list of available types. A
unique network identifier will be generated for all traffic sent to this resource.
●● The subresource to connect. Each Private Link resource type has different options to select based on
preference.
●● An automatic or manual connection approval method. Based on Azure role-based access control
(Azure RBAC) permissions, your Private Endpoint can be approved automatically. If you try to connect
to a Private Link resource without Azure RBAC, use the manual method to allow the owner of the
resource to approve the connection.
●● A specific request message for requested connections to be approved manually. This message can be
used to identify a specific request.
●● Connection status, A read-only property that specifies if the Private Endpoint is active. Only Private
Endpoints in an approved state can be used to send traffic.
Also consider the following details:
●● Private Endpoint enables connectivity between the consumers from the same VNet, regionally peered
VNets, globally peered VNets and on premises using VPN or Express Route and services powered by
Private Link.
●● Network connections can only be initiated by clients connecting to the Private Endpoint, Service
providers do not have any routing configuration to initiate connections into service consumers.
Connections can only be established in a single direction.
●● When creating a Private Endpoint, a read-only network interface is also created for the lifecycle of the
resource. The interface is assigned dynamically private IP addresses from the subnet that maps to the
Private Link resource. The value of the private IP address remains unchanged for the entire lifecycle of
the Private Endpoint.
●● The Private Endpoint must be deployed in the same region and subscription as the virtual network.
●● The Private Link resource can be deployed in a different region than the virtual network and Private
Endpoint.
●● Multiple Private Endpoints can be created using the same Private Link resource. For a single network
using a common DNS server configuration, the recommended practice is to use a single Private
Endpoint for a given Private Link resource to avoid duplicate entries or conflicts in DNS resolution.
●● Multiple Private Endpoints can be created on the same or different subnets within the same virtual
network. There are limits to the number of Private Endpoints you can create in a subscription. For
details, see Azure limits.
●● The subscription from the Private Link resource must also be registered with Microsoft.
373
Multiple choice
What is the key technology behind Private Links?
Private Endpoint.{{Correct! Private Links are dependent on Private Endpoints.}}
DNS Resolution.{{Incorrect, though the recommended practice is to use a single Private Endpoint for a
given Private Link resource to avoid duplicate entries or conflicts in DNS resolution. Private Links are
dependent on Private Endpoints.}}
Virtual Networks.{{Incorrect. Though Private Endpoint must be deployed in the same region and
subscription as the virtual network, Private Links are dependent on Private Endpoints. }}
Multiple choice
What is the difference between a Service Endpoint and a Private Endpoint?
A Service Endpoint connects to external systems and services.{{Correct! A Service Endpoint connects
to external resources. A Private Endpoint enables a private and secure connection between your
virtual network and Azure.}}
A Private Endpoint connects to external systems and services.{{Incorrect, a Private Endpoint enables a
private and secure connection between your virtual network and Azure. A Service Endpoint connects
to external resources.}}
Insert the second incorrect answer text in this cell.{{Insert the second incorrect answer feedback in this
cell.}}
3-Exercise: Create an Azure private endpoint us-

ing Azure PowerShell
one, you can sign up for a free trial at https://Azure.com/free.
Get started with Azure Private Link by using a Private Endpoint to connect securely to an Azure web app.
There are many ways to create Endpoints including portal, CLI, PowerShell etc.
You'll create a Private Endpoint for an Azure web app and deploy a virtual machine to test the private
connection.
Private Endpoints can be created for different kinds of Azure services, such as Azure SQL and Azure
Storage.
Prerequisites
●● An Azure account with an active subscription. Create an account for free.
●● An Azure Web App with a PremiumV2-tier or higher app service plan deployed in your Azure sub-
scription.
If you choose to install and use PowerShell locally, this example requires the Azure PowerShell module
version 5.4.1 or later. Run Get-Module -ListAvailable Az to find the installed version. If you need
374
to upgrade, see Install Azure PowerShell module1. If you're running PowerShell locally, you also need to
run Connect-AzAccount to create a connection with Azure.
●● Task 2: Create a virtual network and bastion host
●● Task 3: Create a test virtual machine
●● Task 4: Create a Private Endpoint
●● Task 5: Configure the private DNS zone
●● Task 6: Test connectivity to the Private Endpoint

An Azure resource group is a logical container into which Azure resources are deployed and managed.
Create a resource group with New-AzResourceGroup2:
New-AzResourceGroup -Name 'CreatePrivateEndpointQS-rg' -Location 'eastus'
Task 2: Create a virtual network and bastion host

You'll create a virtual network, subnet, and bastion host.
The bastion host will be used to connect securely to the virtual machine for testing the Private Endpoint.
Create a virtual network and bastion host with:
●● New-AzVirtualNetwork
●● New-AzPublicIpAddress
●● New-AzBastion
## Create backend subnet config. ##
$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name myBackendSubnet -Ad-

dressPrefix 10.0.0.0/24```
## Create Azure Bastion subnet. ##
$bastsubnetConfig = New-AzVirtualNetworkSubnetConfig -Name AzureBastionSubnet

-AddressPrefix 10.0.1.0/24
## Create the virtual network. ##
$parameters1 = @{
1 https://docs.microsoft.com/Azure/app-service/quickstart-dotnetcore
2 https://docs.microsoft.com/powershell/module/az.resources/new-azresourcegroup
375
Name = 'MyVNet'
ResourceGroupName = 'CreatePrivateEndpointQS-rg'
Location = 'eastus'
AddressPrefix = '10.0.0.0/16'
Subnet = $subnetConfig, $bastsubnetConfig
$vnet = New-AzVirtualNetwork @parameters1
## Create public IP address for bastion host. ##
$parameters2 = @{
Name = 'myBastionIP'
Location = 'eastus'
Sku = 'Standard'
AllocationMethod = 'Static'
$publicip = New-AzPublicIpAddress @parameters2
## Create bastion host ##
$parameters3 = @{
Name = 'myBastion'
PublicIpAddress = $publicip
VirtualNetwork = $vnet
New-AzBastion @parameters3
376
Task 3: Create a test virtual machine

In this section, you'll create a virtual machine that will be used to test the Private Endpoint.
Create the virtual machine with:
●● Get-Credential
●● New-AzNetworkInterface
●● New-AzVM
●● New-AzVMConfig
●● Set-AzVMOperatingSystem
●● Set-AzVMSourceImage
●● Add-AzVMNetworkInterface
## Set credentials for server admin and password. ##
$cred = Get-Credential
## Command to get virtual network configuration. ##
$vnet = Get-AzVirtualNetwork -Name myVNet -ResourceGroupName CreatePriva-

teEndpointQS-rg
## Command to create network interface for VM ##
$parameters1 = @{
Name = 'myNicVM'
Location = 'eastus'
Subnet = $vnet.Subnets[0]
$nicVM = New-AzNetworkInterface @parameters1
## Create a virtual machine configuration.##
$parameters2 = @{
VMName = 'myVM'
VMSize = 'Standard_DS1_v2'
$parameters3 = @{
377
ComputerName = 'myVM'
Credential = $cred
$parameters4 = @{
PublisherName = 'MicrosoftWindowsServer'
Offer = 'WindowsServer'
Skus = '2019-Datacenter'
Version = 'latest'
$vmConfig =
New-AzVMConfig @parameters2 | Set-AzVMOperatingSystem -Windows @parameters3

| Set-AzVMSourceImage @parameters4 | Add-AzVMNetworkInterface -Id $nicVM.Id
## Create the virtual machine ##
New-AzVM -ResourceGroupName 'CreatePrivateEndpointQS-rg' -Location 'eastus'

-VM $vmConfig
Azure provides an ephemeral IP for Azure Virtual Machines which aren't assigned a public IP address, or
are in the backend pool of an internal Basic Azure Load Balancer. The ephemeral IP mechanism provides
an outbound IP address that isn't configurable.
The ephemeral IP is disabled when a public IP address is assigned to the virtual machine or the virtual
machine is placed in the backend pool of a Standard Load Balancer with or without outbound rules. If a
Azure Virtual Network NAT gateway resource is assigned to the subnet of the virtual machine, the
ephemeral IP is disabled.
For more information on outbound connections in Azure, see Using Source Network Address Translation
(SNAT) for outbound connections.
Task 4: Create a Private Endpoint

In this section, you'll create the Private Endpoint and connection using:
●● New-AzPrivateLinkServiceConnection
●● New-AzPrivateEndpoint
378
## Place web app into variable. Replace <webapp-resource-group-name> with

the resource group of your webapp. ##
## Replace <your-webapp-name> with your webapp name ##
$webapp = Get-AzWebApp -ResourceGroupName <webapp-resource-group-name>

-Name <your-webapp-name>
## Create Private Endpoint connection. ##
$parameters1 = @{
Name = 'myConnection'
PrivateLinkServiceId = $webapp.ID
GroupID = 'sites'
$privateEndpointConnection = New-AzPrivateLinkServiceConnection @parame-

ters1
## Place virtual network into variable. ##
$vnet = Get-AzVirtualNetwork -ResourceGroupName 'CreatePrivateEnd-

pointQS-rg' -Name 'myVNet'
## Disable private endpoint network policy ##
$vnet.Subnets[0].PrivateEndpointNetworkPolicies = "Disabled"
$vnet | Set-AzVirtualNetwork
## Create private endpoint
$parameters2 = @{
Name = 'myPrivateEndpoint'
Location = 'eastus'
Subnet = $vnet.Subnets[0]
PrivateLinkServiceConnection = $privateEndpointConnection
New-AzPrivateEndpoint @parameters2
379
Task 5: Configure the private DNS zone

In this section you'll create and configure the private DNS zone using:
●● New-AzPrivateDnsZone
●● New-AzPrivateDnsVirtualNetworkLink
●● New-AzPrivateDnsZoneConfig
●● New-AzPrivateDnsZoneGroup
## Place virtual network into variable. ##
$vnet = Get-AzVirtualNetwork -ResourceGroupName 'CreatePrivateEnd-

pointQS-rg' -Name 'myVNet'
## Create private dns zone. ##
$parameters1 = @{
Name = 'privatelink.Azurewebsites.net'
$zone = New-AzPrivateDnsZone @parameters1
## Create dns network link. ##
$parameters2 = @{
ZoneName = 'privatelink.Azurewebsites.net'
Name = 'myLink'
VirtualNetworkId = $vnet.Id
$link = New-AzPrivateDnsVirtualNetworkLink @parameters2
## Create DNS configuration ##
$parameters3 = @{
Name = 'privatelink.Azurewebsites.net'
380
PrivateDnsZoneId = $zone.ResourceId
$config = New-AzPrivateDnsZoneConfig @parameters3
## Create DNS zone group. ##
$parameters4 = @{
PrivateEndpointName = 'myPrivateEndpoint'
Name = 'myZoneGroup'
PrivateDnsZoneConfig = $config
New-AzPrivateDnsZoneGroup @parameters4
Task 6: Test connectivity to the Private Endpoint

In this section, you'll use the virtual machine you created in the previous step to connect to the SQL
server across the Private Endpoint.
1. Sign in to the Azure portal3
2. Select Resource groups in the left-hand navigation pane.
3. Select CreatePrivateEndpointQS-rg.
4. Select myVM.
5. On the overview page for myVM, select Connect then Bastion.
6. Select the blue Use Bastion button.
7. Enter the username and password that you entered during the virtual machine creation.
8. Open Windows PowerShell on the server after you connect.
9. Enter nslookup <your- webapp-name>.Azurewebsites.net. Replace <your-webapp-name>
with the name of the web app you created in the previous steps. You'll receive a message similar to
what is displayed below:
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
3 https://portal.Azure.com/
381
Name: mywebapp8675.privatelink.Azurewebsites.net
Address: 10.0.0.5
Aliases: mywebapp8675.Azurewebsites.net
A private IP address of 10.0.0.5 is returned for the web app name. This address is in the subnet of the
virtual network you created previously.
10. In the bastion connection to myVM, open Internet Explorer.
11. Enter the url of your web app, https://<your-webapp-name>.Azurewebsites.net.
●● You'll receive the default web app page if your application hasn't been deployed:
12. Close the connection to myVM.

When you're done using the Private Endpoint and the VM, use Remove-AzResourceGroup4 to remove
the resource group and all the resources it has:
Remove-AzResourceGroup -Name CreatePrivateEndpointQS-rg -Force
4-Explain virtual network service endpoints

Use virtual network Service Endpoints to extend your private address space in Azure by providing a direct
connection to your Azure services. Service Endpoints let you secure your Azure resources to only your
virtual network. Service traffic will remain on the Azure backbone and doesn't go out to the internet.
4 https://docs.microsoft.com/powershell/module/az.resources/remove-azresourcegroup
382
By default, Azure services are all designed for direct internet access. All Azure resources have public IP
addresses, including PaaS services, such as Azure SQL Database and Azure Storage. Because these
services are exposed to the internet, anyone can potentially access your Azure services.
Service Endpoints can connect certain PaaS services directly to your private address space in Azure, so
they act like they’re on the same virtual network. Use your private address space to access the PaaS
services directly. Adding Service Endpoints doesn't remove the public endpoint. It simply provides a
redirection of traffic.
Azure Service Endpoints are available for many services, such as:
●● Azure Storage
●● Azure SQL Database
●● Azure Cosmos DB
●● Azure Key Vault
●● Azure Service Bus
●● Azure Data Lake
For a service like SQL Database, which can't be accessed until you add IP addresses to its firewall, Service
Endpoints should still be considered. Using a Service Endpoint for SQL Database restricts access to
specific virtual networks, providing greater isolation and reducing the attack surface.
What is a Service Endpoint?

In your company, you may need connect Azure to external systems or services. This is done with a bundle
of secure Azure DevOps properties known as Service Endpoints.
Service Endpoints include (but are not limited to) the following properties:
●● Service name
●● Description
●● Server URL
●● Certificates or tokens
●● Usernames and passwords
Once configured, extensions use the Service Endpoint to manage stored details and necessary operations
on that service.
How is Azure Private endpoint different from a service endpoint?
383
Private Endpoints grant network access to specific resources behind a given service providing granular
segmentation. Traffic can reach the service resource from on premises without using public endpoints.
A service endpoint remains a publicly routable IP address. A private endpoint is a private IP in the address
space of the virtual network where the private endpoint is configured.
Preparing to Implement Service Endpoints

To enable a Service Endpoint, you must do the following two things:
●● Turn off public access to the service.
●● Add the Service Endpoint to a virtual network.
When you enable a Service Endpoint, you restrict the flow of traffic, and enable your Azure VMs to access
the service directly from your private address space. Devices cannot access the service from a public
network. On a deployed VM vNIC, if you look at Effective routes, you'll notice the Service Endpoint as the
Next Hop Type.
This is an example route table, before enabling a Service Endpoint:
SOURCE STATE ADDRESS PREFIXES NEXT HOP TYPE

Default Active 10.1.1.0/24 VNet
Default Active 0.0.0.0./0 Internet
Default Active 10.0.0.0/8 None
Default Active 100.64.0.0./ None
And here's an example route table after you've added two Service Endpoints to the virtual network:
SOURCE STATE ADDRESS PREFIXES NEXT HOP TYPE

Default Active 10.1.1.0/24 VNet
Default Active 0.0.0.0./0 Internet
Default Active 100.64.0.0./ None
Default Active 20.38.106.0/23, 10 more VirtualNetworkServi-
ceEndpoint
Default Active 20.150.2.0/23, 9 more VirtualNetworkServi-
ceEndpoint
All traffic for the service now is routed to the Virtual Network Service Endpoint and remains internal to
Azure.
Create Service Endpoints

As the network engineer, you're planning to move sensitive engineering diagram files into Azure Storage.
The files must only be accessible from computers inside the corporate network. You want to create a
virtual network Service Endpoint for Azure Storage to secure the connectivity to your storage accounts.
You'll create a Service Endpoint and use network rules to restrict access to Azure Storage. You'll create a
virtual network Service Endpoint for Azure Storage on the Databases subnet. You'll then verify that your
DataServer VM can access Azure Storage. Lastly, you'll check that the AppServer VM, which is on a
different subnet, can't access storage.
384
Add rules to the network security group

Ensure that communications with Azure Storage pass through the Service Endpoint. Add outbound rules
to allow access to the Storage service but deny all other internet traffic.
●● To create an outbound rule to allow access to Storage, in the Cloud Shell, run the following command
using Azure CLI.
az network nsg rule create \
--resource-group $rg \
--nsg-name ERP-SERVERS-NSG \
--name Allow_Storage \
--priority 190 \
--direction Outbound \
--source-address-prefixes "VirtualNetwork" \
--source-port-ranges '*' \
--destination-address-prefixes "Storage" \
--destination-port-ranges '*' \
--access Allow \
--protocol '*' \
--description "Allow access to Azure Storage"
●● To create an outbound rule to deny all internet access, in the Cloud Shell, run the following command
using Azure CLI.
az network nsg rule create \
385
--nsg-name ERP-SERVERS-NSG \
--name Deny_Internet \
--priority 200 \
--direction Outbound \
--source-address-prefixes "VirtualNetwork" \
--source-port-ranges '*' \
--destination-address-prefixes "Internet" \
--destination-port-ranges '*' \
--access Deny \
--protocol '*' \
--description "Deny access to Internet."
You should now have the following rules in ERP-SERVERS-NSG:
Rule name Direction Priority Purpose

AllowSSHRule Inbound 100 Allow inbound SSH
httpRule Inbound 150 Deny from DataServer
to AppServer on 80
Allow_Storage Outbound 190 Allow access to Azure
Storage
Deny_Internet Outbound 200 Deny access to Internet
from VNet
At this point, both AppServer and DataServer have access to the Azure Storage service.
Configure storage account and file share
In this step, you'll create a new storage account, and then add an Azure file share to this account. This
share is where you'll store your engineering diagrams.
●● To create a storage account for engineering documents, in the Cloud Shell, run the following com-
mand.
STORAGEACCT=$(az storage account create \
--name engineeringdocs$RANDOM \
--sku Standard_LRS \
386
--query "name" | tr -d '"')
●● To store the primary key for your storage in a variable, in the Cloud Shell, run the following command.
STORAGEKEY=$(az storage account keys list \
--account-name $STORAGEACCT \
--query "[0].value" | tr -d '"')
●● To create an Azure file share called erp-data-share, in the Cloud Shell, run the following command.
az storage share create \
--account-key $STORAGEKEY \
--name "erp-data-share"
Enable the Service Endpoint

You now need to configure the storage account to be accessible only from database servers, by assigning
the storage endpoint to the Databases subnet. You then add a security rule to the storage account.
●● To assign the Microsoft.Storage endpoint to the subnet, in the Cloud Shell, run the following com-
mand.
az network vnet subnet update \
--vnet-name ERP-servers \
--name Databases \
--service-endpoints Microsoft.Storage
●● To deny all access to change the default action to Deny, in the Cloud Shell, run the following com-
mand. After network access is denied, the storage account is not accessible from any network.
az storage account network-rule add \
387
--vnet ERP-servers \
--subnet Databases
●● To restrict access to the storage account, in the Cloud Shell, run the following command. By default,
storage accounts are open to accept all traffic. You want only traffic from the Databases subnet to be
able to access the storage.
az storage account network-rule add \
--vnet-name ERP-servers \
--subnet Databases
Test access to storage resources

In this step, you'll connect to both of your servers, and verify that only DataServer has access to the Azure
file share on the storage account.
●● To save the public IP addresses of AppServer and DataServer to variables, in the Cloud Shell, run the
following command.
APPSERVERIP="$(az vm list-ip-addresses \
--name AppServer \
--query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
--output tsv)"
DATASERVERIP="$(az vm list-ip-addresses \
--name DataServer \
--query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
--output tsv)"
●● To connect to your AppServer VM, and attempt to mount the Azure file share, in the Cloud Shell, run
the following command.
388
ssh -t Azureuser@$APPSERVERIP \
"mkdir Azureshare; \
sudo mount -t cifs //$STORAGEACCT.file.core.windows.net/erp-data-share Azureshare \
-o vers=3.0,username=$STORAGEACCT,password=$STORAGEKEY,dir_mode=0777,file_
mode=0777,sec=ntlmssp; findmnt \
-t cifs; exit; bash"
●● Enter the password you used when you created the VM.
●● The response should include a mount error message. This connection isn't allowed, because there is
no Service Endpoint for the storage account on the Applications subnet.
●● To connect to your DataServer VM, and attempt to mount the Azure file share, in the Cloud Shell, run
the following command.
ssh -t Azureuser@$DATASERVERIP \
"mkdir Azureshare; \
sudo mount -t cifs //$STORAGEACCT.file.core.windows.net/erp-data-share Azureshare \
-o vers=3.0,username=$STORAGEACCT,password=$STORAGEKEY,dir_mode=0777,file_
mode=0777,sec=ntlmssp;findmnt \
-t cifs; exit; bash"
●● Enter the password you used when you created the VM.
●● The mount should be successful, and the response should include details of the mount point. This is
allowed because you created the Service Endpoint for the storage account on the Databases subnet.
By using the storage Service Endpoint on the Databases subnet, you've now verified that DataServer can
access storage. You've also verified that AppServer can't access storage. This is because this server is on
a different subnet and doesn't have access to the virtual network Service Endpoint.
Configure service tags

A service tag represents a group of IP address prefixes from a given Azure service. Microsoft manages the
address prefixes encompassed by the service tag and automatically updates the service tag as addresses
change, minimizing the complexity of frequent updates to network security rules.
You can use service tags to define network access controls on network security groups or Azure Firewall.
Use service tags in place of specific IP addresses when you create security rules. By specifying the service
tag name, such as API Management, in the appropriate source or destination field of a rule, you can allow
or deny the traffic for the corresponding service.
As of March 2021, you can also use Service Tags in place of explicit IP ranges in user defined routes. This
feature is currently in Public Preview.
389
You can use service tags to achieve network isolation and protect your Azure resources from the general
Internet while accessing Azure services that have public endpoints. Create inbound/outbound network
security group rules to deny traffic to/from Internet and allow traffic to/from AzureCloud or other
available service tags of specific Azure services.
Available service tags

The following table includes all the service tags available for use in network security group rules.
The columns indicate whether the tag:
●● Is suitable for rules that cover inbound or outbound traffic.
●● Supports regional scope.
●● Is usable in Azure Firewall rules.
By default, service tags reflect the ranges for the entire cloud. Some service tags also allow more granular
control by restricting the corresponding IP ranges to a specified region. For example, the service tag
Storage represents Azure Storage for the entire cloud, but Storage. WestUS narrows the range to only the
storage IP address ranges from the WestUS region. The following table indicates whether each service tag
supports such regional scope.
Tag Purpose Can use inbound Can be regional? Can use with
or outbound? Azure Firewall?
ActionGroup Action Group. Inbound No No
390
ApiManagement Management Inbound Yes Yes

traffic for Azure
API Manage-
ment-dedicated
deployments.
Note: This tag
represents the
Azure API Man-
agement Service
Endpoint for
control plane per
region. This
enables customers
to perform
management
operations on the
APIs, Operations,
Policies, Named-
Values configured
on the API Man-
agement service.
ApplicationIn- Application Inbound No No
sightsAvailability Insights Availabili-
ty.
AppConfiguration App Configuration. Outbound No No
AppService Azure App Service. Outbound Yes Yes
This tag is recom-
mended for
outbound security
rules to web apps
and Function apps.
AppServiceMan- Management Both No Yes
agement traffic for deploy-
ments dedicated
to App Service
Environment.
AzureActiveDirec- Azure Active Outbound No Yes
tory Directory.
AzureActiveDirec- Management Both No Yes
toryDomainServic- traffic for deploy-
es ments dedicated
to Azure Active
Directory Domain
Services.
AzureAdvanced- Azure Advanced Outbound No No
ThreatProtection Threat Protection.
391
AzureAPIForFHIR Azure API for FHIR Outbound No No

(Fast Healthcare
Interoperability
Resources). Note:
This tag is not
currently configur-
able via Azure
portal.
AzureArcInfra- Azure Arc enabled Outbound No Yes
structure servers, Azure Arc
enabled Kuber-
netes, and Guest
Configuration
traffic. Note: This
tag has a depend-
ency on the
AzureActiveDirec-
tory,AzureTraffic-
Manager, and
AzureResourceMa-
nager tags. This
tag is not currently
configurable via
Azure portal.
AzureBackup Azure Backup. Outbound No Yes
Note: This tag has
a dependency on
the Storage and
AzureActiveDirec-
tory tags.
AzureBotService Azure Bot Service. Outbound No No
AzureCloud All datacenter Outbound Yes Yes
public IP address-
es.
392
AzureCognitive- Azure Cognitive Inbound No No

Search Search. This tag or
the IP addresses
covered by this tag
can be used to
grant indexers
secure access to
data sources. Refer
to the indexer
connection
documentation for
more details. Note:
The IP of the
search service is
not included in the
list of IP ranges for
this service tag
and also needs to
be added to the IP
firewall of data
sources.
AzureConnectors This tag represents Inbound / Out- Yes Yes
the IP addresses bound
used for managed
connectors that
make inbound
webhook callbacks
to the Azure Logic
Apps service and
outbound calls to
their respective
services, for
example, Azure
Storage or Azure
Event Hubs.
AzureContainer- Azure Container Outbound Yes Yes
Registry Registry.
AzureCosmosDB Azure Cosmos DB. Outbound Yes Yes
AzureDatabricks Azure Databricks. Both No No
AzureDataEx- Azure Data Inbound No No
plorerManage- Explorer Manage-
ment ment.
AzureDataLake Azure Data Lake Outbound No Yes
Storage Gen1.
AzureDevSpaces Azure Dev Spaces. Outbound No No
393
AzureDevOps Azure Dev Ops. Inbound No Yes

Note: This tag is
not currently
configurable via
Azure portal
AzureDigitalTwins Azure Digital Inbound No Yes
Twins. Note: This
tag or the IP
addresses covered
by this tag can be
used to restrict
access to end-
points configured
for event routes.
This tag is not
currently configur-
able via Azure
portal
AzureEventGrid Azure Event Grid. Both No No
AzureFrontDoor. Azure Front Door. Both No No
Frontend Azure-
FrontDoor.Backend
AzureFrontDoor.
FirstParty
AzureInformation- Azure Information Outbound No No
Protection Protection. Note:
This tag has a
dependency on
the AzureActiveDi-
rectory, Azure-
FrontDoor.
Frontend and
AzureFrontDoor.
FirstParty tags.
AzureIoTHub Azure IoT Hub. Outbound No No
AzureKeyVault Azure Key Vault. Outbound Yes Yes
Note: This tag has
a dependency on
the AzureActiveDi-
rectory tag.
394
AzureLoadBalancer The Azure infra- Both No No

structure load
balancer. The tag
translates to the
virtual IP address
of the host
(168.63.129.16)
where the Azure
health probes
originate. This only
includes probe
traffic, not real
traffic to your
backend resource.
If you're not using
Azure Load
Balancer, you can
override this rule.
AzureMachine- Azure Machine Both No Yes
Learning Learning.
AzureMonitor Log Analytics, Outbound No Yes
Application
Insights, AzMon,
and custom
metrics (GiG
endpoints). Note:
For Log Analytics,
the Storage tag is
also required. If
Linux agents are
used, Gue-
stAndHybridMan-
agement tag is
also required.
AzureOpenData- Azure Open Outbound No No
sets Datasets. Note:
This tag has a
dependency on
the AzureFront-
Door.Frontend and
Storage tag.
395
AzurePlatformDNS The basic infra- Outbound No No

structure (default)
DNS service. You
can use this tag to
disable the default
DNS. Be cautious
when you use this
tag. We recom-
mend that you
read Azure
platform consider-
ations. We also
recommend that
you perform
testing before you
use this tag.
AzurePlat- Azure Instance Outbound No No
formIMDS Metadata Service
(IMDS), which is a
basic infrastructure
service. You can
use this tag to
disable the default
IMDS. Be cautious
when you use this
tag. We recom-
mend that you
read Azure
platform consider-
ations. We also
recommend that
you perform
testing before you
use this tag.
396
AzurePlatformLKM Windows licensing Outbound No No

or key manage-
ment service. You
can use this tag to
disable the
defaults for
licensing. Be
cautious when you
use this tag. We
recommend that
you read Azure
platform consider-
ations. We also
recommend that
you perform
testing before you
use this tag.
AzureResourceMa- Azure Resource Outbound No No
nager Manager.
AzureSignalR Azure SignalR. Outbound No No
AzureSiteRecovery Azure Site Recov- Outbound No No
ery. Note: This tag
has a dependency
on the AzureAc-
tiveDirectory,
AzureKeyVault,
EventHub,Gue-
stAndHybridMan-
agement and
Storage tags.
AzureTrafficMan- Azure Traffic Inbound No Yes
ager Manager probe IP
addresses. For
more information
on Traffic Manager
probe IP address-
es, see Azure
Traffic Manager
FAQ.
BatchNodeMan- Management Both No Yes
agement traffic for deploy-
ments dedicated
to Azure Batch.
CognitiveServices- The address Both No No
Management ranges for traffic
for Azure Cogni-
tive Services.
DataFactory Azure Data Factory Both No No
397
DataFactoryMan- Management Outbound No No

agement traffic for Azure
Data Factory.
Dynamics365For- The address Outbound Yes No
MarketingEmail ranges for the
marketing email
service of Dynam-
ics 365.
EOPExternalPub- This tag represents Both No Yes
lishedIPs the IP addresses
used for Security &
Compliance Center
PowerShell. Refer
to the Connect to
Security & Compli-
ance Center
PowerShell using
the EXO V2
module for more
details. Note: This
tag is not currently
configurable via
Azure portal.
EventHub Azure Event Hubs. Outbound Yes Yes
GatewayManager Management Inbound No No
traffic for deploy-
ments dedicated
to Azure VPN
Gateway and
Application
Gateway.
GuestAndHybrid- Azure Automation Outbound No Yes
Management and Guest Config-
uration.
HDInsight Azure HDInsight. Inbound Yes No
Internet The IP address Both No No
space that's
outside the virtual
network and
reachable by the
public internet.
The address range
includes the
Azure-owned
public IP address
space.
LogicApps Logic Apps. Both No No
398
LogicAppsMan- Management Inbound No No

agement traffic for Logic
Apps.
Microsoft- Microsoft Cloud Outbound No No
CloudAppSecurity App Security.
MicrosoftCon- Container registry Outbound Yes Yes
tainerRegistry for Microsoft
container images.
Note: This tag has
a dependency on
the AzureFront-
Door.FirstParty tag.
Power BI Power BI. Note: Both No No
This tag is not
currently configur-
able via Azure
portal.
PowerQueryOnline Power Query Both No No
Online.
ServiceBus Azure Service Bus Outbound Yes Yes
traffic that uses
the Premium
service tier.
ServiceFabric Azure Service Both No No
Fabric. Note: This
tag represents the
Service Fabric
Service Endpoint
for control plane
per region. This
enables customers
to perform
management
operations for
their Service Fabric
clusters from their
VNET (endpoint
eg. https:// westus.
servicefabric.Azure.
com)
399
Sql Azure SQL Data- Outbound Yes Yes

base, Azure
Database for
MySQL, Azure
Database for
PostgreSQL, and
Azure Synapse
Analytics. Note:
This tag represents
the service, but not
specific instances
of the service. For
example, the tag
represents the
Azure SQL Data-
base service, but
not a specific SQL
database or server.
This tag does not
apply to SQL
managed instance.
SqlManagement Management Both No Yes
traffic for
SQL-dedicated
deployments.
Storage Azure Storage. Outbound Yes Yes
Note: This tag
represents the
service, but not
specific instances
of the service. For
example, the tag
represents the
Azure Storage
service, but not a
specific Azure
Storage account.
StorageSyncSer- Storage Sync Both No No
vice Service.
WindowsVirtu- Windows Virtual Both No Yes
alDesktop Desktop.
400
VirtualNetwork The virtual network Both No No

address space (all
IP address ranges
defined for the
virtual network), all
connected
on-premises
address spaces,
peered virtual
networks, virtual
networks connect-
ed to a virtual
network gateway,
the virtual IP
address of the
host, and address
prefixes used on
user-defined
routes. This tag
might also contain
default routes.
In the classic deployment model (before Azure Resource Manager), a subset of the tags listed in the
previous table
In the classic deployment model (before Azure Resource Manager), a subset of the tags listed in the
previous table are supported. These tags are spelled differently:
Classic Spelling Equivalent Resource Manager Tag

Azure_LOADBALANCER AzureLoadBalancer
INTERNET Internet
VIRTUAL_NETWORK VirtualNetwork
Service tags of Azure services denote the address prefixes from the specific cloud being used. For
example, the underlying IP ranges that correspond to the SQL tag value on the Azure Public cloud will be
different from the underlying ranges on the Azure China cloud.
If you implement a virtual network Service Endpoint for a service, such as Azure Storage or Azure SQL
Database, Azure adds a route to a virtual network subnet for the service. The address prefixes in the route
are the same address prefixes, or CIDR ranges, as those of the corresponding service tag.
5-Exercise: Restrict network access to PaaS re-

sources with virtual network service endpoints
one, you can sign up for a free trial at https://Azure.com/free.
Virtual network service endpoints enable you to limit network access to some Azure service resources to
a virtual network subnet. You can also remove internet access to the resources. Service endpoints provide
direct connection from your virtual network to supported Azure services, allowing you to use your virtual
401
network's private address space to access the Azure services. Traffic destined to Azure resources through
service endpoints always stays on the Microsoft Azure backbone network.
●● Task 1: Create a virtual network
●● Task 2: Enable a service endpoint
●● Task 3: Restrict network access for a subnet
●● Task 4: Add additional outbound rules
●● Task 5: Allow access for RDP connections
●● Task 6: Restrict network access to a resource
●● Task 7: Create a file share in the storage account
●● Task 8: Restrict network access to a subnet
●● Task 9: Create virtual machines
●● Task 10: Confirm access to storage account
Task 1: Create a virtual network

1. On the Azure portal home page, select + Create a resource.
2. Search for virtual network and then select Virtual network from the results.
3. Select +Create.
4. Enter, or select, the following information
Setting Value
Resource group Select the provided resource group from Learn
Name CoreServicesVNet
402
Location Select West US

5. Select the IP Addresses tab and enter the following values (select default to change the subnet
name):
Setting Value
Address space 10.0.0.0/16
Subnet Name Public
Subnet Address range 10.0.0.0/24
6. Select the Security tab and enter the following values:
Setting Value
BastionHost Disabled
403
DDoS protection Disabled

Firewall Disabled
7. Click Review + Create. Once the resource is validated select Create.
Task 2: Enable a service endpoint

Service endpoints are enabled per service, per subnet. Create a subnet and enable a service endpoint for
the subnet.
1. In the Search resources, services, and docs box at the top of the portal, enter CoreServicesVNet.
When CoreServicesVNet appears in the search results, select it.
2. Add a subnet to the virtual network. Under Settings, select Subnets, and then select + Subnet, as
shown in the following picture:

3. Under Add subnet, select or enter the following information:
Setting Value
Name Private
Service endpoints: Services Select Microsoft.Storage
4. Select Save.
You should now have two subnets configured:
404
Task 3: Restrict network access for a subnet

By default, all VMs in a subnet can communicate with all resources. You can limit communication to and
from all resources in a subnet by creating a network security group and associating it to the subnet.
1. In the Search resources, services, and docs box at the top of the portal, enter security group. When
Network Security groups appears in the search results, select it.
2. In Network security groups, select + Create.
3. Enter or select, the following information:
Setting Value
Resource group Select Use existing and select the provided
resource group from Learn
Name ContosoPrivateNSG
4. select Review + create, then click Create:
405
5. After the ContosoPrivateNSG network security group is created, select Go to resource.

6. Under Settings, select Outbound security rules.
7. Select + Add.
406
8. Create a rule that allows outbound communication to the Azure Storage service. Enter, or select, the
following information:
Setting Value
Source Select VirtualNetwork
Source port ranges *
Destination Select Service Tag
Destination service tag Select Storage
Service Custom
Destination port ranges *
Protocol Any
Action Allow
Priority 100
Name Allow-Storage-All
9. Select Add:
407
Task 4: Add additional outbound rules

Create another outbound security rule that denies communication to the internet. This rule overrides a
default rule in all network security groups that allows outbound internet communication.
1. Select +Add under Outbound security rules.
2. Enter, or select, the following information:
Setting Value
Source Select VirtualNetwork
Destination Select Service Tag
Destination service tag Select Internet
Service Custom
408
Destination port ranges *

Protocol Any
Action Deny
Priority 110
Name Deny-Internet-All
3. Select Add.
Task 5: Allow access for RDP connections

Create an inbound security rule that allows Remote Desktop Protocol (RDP) traffic to the subnet from
anywhere. The rule overrides a default security rule that denies all inbound traffic from the internet.
Remote desktop connections are allowed to the subnet so that connectivity can be tested in a later step.
1. On ContosoPrivateNSG | Outbound security rules, under Settings, select Inbound security rules.
2. Select + Add.
409
3. In Add inbound security rule, enter the following values::
Setting Value
Source Any
Destination Select VirtualNetwork
Service Custom
Destination port ranges 3389
Protocol Any
Action Allow
Priority 120
Name Allow-RDP-All
4. And then select Add.
[!Warning]
410
RDP port 3389 is exposed to the Internet. This is only recommended for testing. For production environ-
ments, we recommend using a VPN or private connection.
5. Under Settings, select Subnets.
6. Select + Associate.
7. Under Associate subnet, select Virtual network and then select CoreServicesVNet under Choose a
virtual network.
8. Under Choose subnet, select Private, and then select OK.
Task 6: Restrict network access to a resource

The steps necessary to restrict network access to resources created through Azure services enabled for
service endpoints varies across services. See the documentation for individual services for specific steps
for each service. The remainder of this exercise includes steps to restrict network access for an Azure
Storage account, as an example.
1. In the Azure portal, select Storage accounts.
2. Select +Create.
3. Enter, or select, the following information and accept the remaining defaults:
Setting Value
411
Resource group Select Use existing and select the resource group
provided by Learn.
Name Enter a contosostoragewest..
Performance Standard StorageV2 (general purpose v2)
Replication Locally-redundant storage (LRS)
4. select Review + create, then click Create.
Task 7: Create a file share in the storage account

1. After the storage account is created, enter the name of the storage account in the Search resources,
services, and docs box, at the top of the portal. When the name of your storage account appears in
the search results, select it.
2. Select File shares, as shown in the following picture:

3. Select + File share.
4. Enter marketing under Name, and then select Create.
Task 8: Restrict network access to a subnet

By default, storage accounts accept network connections from clients in any network, including the
internet. Deny network access from the internet, and all other subnets in all virtual networks, except for
the Private subnet in the CoreServicesVNet virtual network.
1. Under Security + networking for the storage account, select Networking.
2. Select Selected networks.
412
3. Select +Add existing virtual network.
4. Under Add networks, select the following values:
Setting Value
Virtual networks Select CoreServicesVNet**.**
Subnets Select Private.
5. Select Add.
6. Select Save.
7. Under Security and Networking for the storage account, select Access keys.
8. Select Show Keys. Note the Key value, as you'll have to manually enter it in a later step when map-
ping the file share to a drive letter in a VM.
Task 9: Create virtual machines

To test network access to a storage account, deploy a VM to each subnet.
1. In the Azure portal Home screen, select Virtual machinesSelect + Create, then +Virtual machine.
413
2. On the Basics tab, enter, or select, the following information:
Setting Value
Project Details
Resource group Select Use existing and select the resource group
provided by Learn
Instance Details
Virtual machine name ContosoWestPublic
Region (US) West US
Availability Options No infrastructure redundancy required
Image Select Windows Server 2019 Datacenter.
Size Standard_D2s
Administrator Account
Authentication type SSH public key
Username Enter a user name of your choosing.
Password Enter a password of your choosing.
Confirm Password Re-enter the password.
Inbound port rules
414
3. Then select the Networking tab. Enter, or select, the following information:
Setting Value
Virtual network CoreServicesVNet
Subnet Public (10.0.0.0/24)
Public IP (new) ContosoWestPublic-ip
5. Select Create to start the virtual machine deployment. The VM takes a few minutes to deploy, but you
can continue to the next step while the VM is creating.
6. Create another virtual machine Complete steps 2-5 again, but name the virtual machine ContosoW-
estPrivate and and select the Private subnet.
The VM takes a few minutes to deploy. Do not continue to the next step until it finishes creating and its
settings open in the portal.
415
Task 10: Confirm access to storage account

1. Once the ContosoWestPrivate VM finishes creating, open the blade for the VM by selecting Go to
resource. Select the Connect button, then select RDP.

2. After selecting the Connect button and RDP, select the Download RDP File button. A Remote Desktop
Protocol (.rdp) file is created and downloaded to your computer.
3. Open the downloaded rdp file. If prompted, select Connect. Enter the user name and password you
specified when creating the VM. You may need to select More choices, then Use a different account,
to specify the credentials you entered when you created the VM.
4. Select OK.
5. You may receive a certificate warning during the sign-in process. If you receive the warning, select Yes
or Continue to proceed with the connection.
6. On the ContosoWestPrivate VM, map the Azure file share to drive Z using PowerShell. Before running
the commands that follow, replace and with values you supplied and retrieved in the Create a storage
account task.
$acctKey = ConvertTo-SecureString -String "<storage-account-key>" -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential -ArgumentList "Az-

ure\<storage-account-name>", $acctKey
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storage-account-name>.file.core.windows.

net\my-file-share" -Credential $credential
The Azure file share successfully mapped to the Z drive.

416
7. Confirm that the VM has no outbound connectivity to the internet from a command prompt: ping
bing.com You receive no replies because the network security group associated to the Private subnet
does not allow outbound access to the internet.
8. Close the remote desktop session to the ContosoWestPrivate VM.
Confirm access is denied to storage account

1. Enter ContosoWestPublic In the Search resources, services, and docs box at the top of the portal.
2. When ContosoWestPublic appears in the search results, select it.
3. Complete steps 1-6 in the Confirm access to storage account task for the ContosoWestPublic VM.
‎
‎After a short wait, you receive a New-PSDrive : Access is denied error. Access is denied because the
ContosoWestPublic VM is deployed in the Public subnet. The Public subnet does not have a service
endpoint enabled for Azure Storage. The storage account only allows network access from the Private
subnet, not the Public subnet.
4. Close the remote desktop session to the ContosoWestPublic VM.
5. From your computer, browse to the Azure portal.
6. Enter the name of the storage account you created in the Search resources, services, and docs box.
When the name of your storage account appears in the search results, select it.
7. Select File shares then select my-file-share.
8. You receive the error shown in the following screenshot:
Access is denied, because your computer is not in the Private subnet of the CoreServicesVNet virtual
network.
[!WARNING]
Prior to continuing you should remove all resources used for this lab. To do this in the Azure portal click
Resource groups. Select any resources groups you have created. On the resource group blade click Delete
Resource group, enter the Resource Group Name and click Delete. Repeat the process for any additional
Resource Groups you may have created. Failure to do this may cause issues with other labs.
Results: You have now completed this lab.
417

command:
[!NOTE]
6-Integrate Private Link with DNS
Private DNS zones are typically hosted centrally in the same Azure subscription where the hub VNet is
deployed. This central hosting practice is driven by cross-premises DNS name resolution and other needs
for central DNS resolution such as Active Directory. In most cases, only networking/identity admins have
permissions to manage DNS records in these zones.
Application teams do have permissions to create Azure resource in their own subscription. They do not
have any permissions in the central networking connectivity subscription, which includes managing DNS
records in the private DNS zones. This access limitation means they do not have the possibility to create
the DNS records required when deploying Azure PaaS services with Private Endpoints.
The following diagram shows a typical high-level architecture for enterprise environments with central
DNS resolution and where name resolution for Private Link resources is done via Azure Private DNS:
418
From the previous diagram, it is important to highlight that:

●● On-premises DNS servers have conditional forwarders configured for each Private Endpoint public
DNS zone forwarder pointing to the DNS forwarders (10.100.2.4 and 10.100.2.5) hosted in the hub
VNet.
●● The DNS servers 10.100.2.4 and 10.100.2.5 hosted in the hub VNet use the Azure-provided DNS
resolver (168.63.129.16) as a forwarder.
●● All Azure VNets have the DNS forwarders (10.100.2.4 and 10.100.2.5) configured as the primary and
secondary DNS servers.
●● There are two conditions that must be true to allow application teams the freedom to create any
required Azure PaaS resources in their subscription:
●● Central networking and/or central platform team must ensure that application teams can only deploy
and access Azure PaaS services via Private Endpoints.
●● Central networking and/or central platform teams must ensure that whenever Private Endpoints are
created, the corresponding records are automatically created in the centralized private DNS zone that
matches the service created.
●● DNS record needs to follow the lifecycle of the Private Endpoint and automatically remove the DNS
record when the Private Endpoint is deleted.
The following sections describe how application teams can enable these conditions by using Azure Policy.
We will use Azure Storage as the Azure service that application teams need to deploy in our example
below, but the same principle can be applied to most Azure services that support Private Link.
Azure Private Endpoint DNS configuration

It's important to correctly configure your DNS settings to resolve the Private Endpoint IP address to the
fully qualified domain name (FQDN) of the connection string.
Existing Microsoft Azure services might already have a DNS configuration for a public endpoint. This
configuration must be overridden to connect using your private endpoint.
The network interface associated with the Private Endpoint contains the information to configure your
DNS. The network interface information includes FQDN and private IP addresses for your Private Link
resource.
You can use the following options to configure your DNS settings for Private Endpoints:
●● Use the host file (only recommended for testing). You can use the host file on a virtual machine to
override the DNS.
●● Use a private DNS zone. You can use private DNS zones to override the DNS resolution for a Private
Endpoint. A private DNS zone can be linked to your virtual network to resolve specific domains.
●● Use your DNS forwarder (optional). You can use your DNS forwarder to override the DNS resolution
for a Private Link resource. Create a DNS forwarding rule to use a private DNS zone on your DNS
server hosted in a virtual network.
[!Important]
Is not recommended to override a zone that's actively in use to resolve public endpoints. Connections to
resources won't be able to resolve correctly without DNS forwarding to the public DNS. To avoid issues,
create a different domain name or follow the suggested name for each service below.
419
Significance of IP address 168.63.129.16

IP address 168.63.129.16 is a virtual public IP address that is used to facilitate a communication channel
to Azure platform resources. Customers can define any address space for their private virtual network in
Azure. The Azure platform resources must be presented as a unique public IP address. This virtual public
IP address facilitates the following things:
●● Enables the VM Agent to communicate with the Azure platform to signal that it is in a “Ready” state
●● Enables communication with the DNS virtual server to provide filtered name resolution to the resourc-
es (such as VM) that do not have a custom DNS server. This filtering makes sure that customers can
resolve only the hostnames of their resources
●● Enables health probes from Azure load balancer to determine the health state of VMs
●● Enables the VM to obtain a dynamic IP address from the DHCP service in Azure
●● Enables Guest Agent heartbeat messages for the PaaS role
In a non-virtual network scenario (Classic), a private IP address is used instead of 168.63.129.16. This
private IP address is dynamically discovered through DHCP. Firewall rules specific to 168.63.129.16 need
to be adjusted as appropriate.
Azure services DNS zone configuration

Azure creates a canonical name DNS record (CNAME) on the public DNS. The CNAME record redirects
the resolution to the private domain name. You can override the resolution with the private IP address of
your Private Endpoints.
Your applications don't need to change the connection URL. When resolving to a public DNS service, the
DNS server will resolve to your Private Endpoints. The process doesn't affect your existing applications.
Private networks already using the private DNS zone for a given type, can only connect to public resourc-
es if they don't have any Private Endpoint connections, otherwise a corresponding DNS configuration is
required on the private DNS zone in order to complete the DNS resolution sequence.
For Azure services, use the recommended zone names as described in the following table:
Private Link resource type / Private DNS zone name Public DNS zone forwarders
Subresource
Azure Automation / (Microsoft. privatelink.azure-automation.net azure-automation.net
Automation/automationAc-
counts) / Webhook, DSCAndHy-
bridWorker
Azure SQL Database (Microsoft. privatelink.database.windows.net database.windows.net
Sql/servers) / sqlServer
Azure Synapse Analytics (Micro- privatelink.database.windows.net database.windows.net
soft.Sql/servers) / sqlServer
Azure Synapse Analytics (Micro- privatelink.sql.azuresynapse.net sql.azuresynapse.net
soft.Synapse/workspaces) / Sql
Storage account (Microsoft. privatelink.blob.core.windows.net blob.core.windows.net
Storage/storageAccounts) / Blob
(blob, blob_secondary)
420
Storage account (Microsoft. privatelink.table.core.windows. table.core.windows.net

Storage/storageAccounts) / Table net
(table, table_secondary)
Storage account (Microsoft. privatelink.queue.core.windows. queue.core.windows.net
Storage/storageAccounts) / net
Queue (queue, queue_second-
ary)
Storage account (Microsoft. privatelink.file.core.windows.net file.core.windows.net
Storage/storageAccounts) / File
(file, file_secondary)
Storage account (Microsoft. privatelink.web.core.windows.net web.core.windows.net
Storage/storageAccounts) / Web
(web, web_secondary)
Azure Data Lake File System privatelink.dfs.core.windows.net dfs.core.windows.net
Gen2 (Microsoft.Storage/
storageAccounts) / Data Lake
File System Gen2 (dfs, dfs_sec-
ondary)
Azure Cosmos DB (Microsoft. privatelink.documents.azure.com documents.azure.com
AzureCosmosDB/databaseAc-
counts) / SQL
Azure Cosmos DB (Microsoft. privatelink.mongo.cosmos.azure. mongo.cosmos.azure.com
AzureCosmosDB/databaseAc- com
counts) / MongoDB
Azure Cosmos DB (Microsoft. privatelink.cassandra.cosmos. cassandra.cosmos.azure.com
AzureCosmosDB/databaseAc- azure.com
counts) / Cassandra
Azure Cosmos DB (Microsoft. privatelink.gremlin.cosmos.azure. gremlin.cosmos.azure.com
counts) / Gremlin
Azure Cosmos DB (Microsoft. privatelink.table.cosmos.azure. table.cosmos.azure.com
counts) / Table
Azure Database for PostgreSQL privatelink.postgres.database. postgres.database.azure.com
- Single server (Microsoft. azure.com
DBforPostgreSQL/servers) /
postgresqlServer
Azure Database for MySQL privatelink.mysql.database.azure. mysql.database.azure.com
(Microsoft.DBforMySQL/servers) com
/ mysqlServer
Azure Database for MariaDB privatelink.mariadb.database. mariadb.database.azure.com
(Microsoft.DBforMariaDB/ azure.com
servers) / mariadbServer
Azure Key Vault (Microsoft. privatelink.vaultcore.azure.net vault.azure.net
KeyVault/vaults) / vault
vaultcore.azure.net
421
Azure Kubernetes Service - Ku- privatelink.{region}.azmk8s.io {region}.azmk8s.io

bernetes API (Microsoft.Contain-
erService/managedClusters) /
management
Azure Search (Microsoft.Search/ privatelink.search.windows.net search.windows.net
searchServices) / searchService
Azure Container Registry privatelink.azurecr.io azurecr.io
(Microsoft.ContainerRegistry/
registries) / registry
Azure App Configuration privatelink.azconfig.io azconfig.io
(Microsoft.AppConfiguration/
configurationStores) / configura-
tionStores
Azure Backup (Microsoft. privatelink.{region}.backup. {region}.backup.windowsazure.
RecoveryServices/vaults) / vault windowsazure.com com
Azure Site Recovery (Microsoft. {region}.privatelink.siterecovery. {region}.hypervrecoverymanager.
RecoveryServices/vaults) / vault windowsazure.com windowsazure.com
Azure Event Hubs (Microsoft. privatelink.servicebus.windows. servicebus.windows.net
EventHub/namespaces) / net
namespace
Azure Service Bus (Microsoft. privatelink.servicebus.windows. servicebus.windows.net
ServiceBus/namespaces) / net
namespace
Azure IoT Hub (Microsoft. privatelink.azure-devices.net azure-devices.net
Devices/IotHubs) / iotHub
privatelink.servicebus.windows. servicebus.windows.net
net1
Azure Relay (Microsoft.Relay/ privatelink.servicebus.windows. servicebus.windows.net
namespaces) / namespace net
Azure Event Grid (Microsoft. privatelink.eventgrid.azure.net eventgrid.azure.net
EventGrid/topics) / topic
Azure Event Grid (Microsoft. privatelink.eventgrid.azure.net eventgrid.azure.net
EventGrid/domains) / domain
Azure Web Apps (Microsoft. privatelink.azurewebsites.net azurewebsites.net
Web/sites) / sites
Azure Machine Learning (Micro- privatelink.api.azureml.ms api.azureml.ms
soft.MachineLearningServices/
workspaces) / amlworkspace
privatelink.notebooks.azure.net notebooks.azure.net
instances.azureml.ms
aznbcontent.net
SignalR (Microsoft.SignalRSer- privatelink.service.signalr.net service.signalr.net
vice/SignalR) / signalR
Azure Monitor (Microsoft. privatelink.monitor.azure.com monitor.azure.com
Insights/privateLinkScopes) /
azuremonitor
422
privatelink.oms.opinsights.azure. oms.opinsights.azure.com
com
privatelink.ods.opinsights.azure. ods.opinsights.azure.com
com
privatelink.agentsvc.azure-auto- agentsvc.azure-automation.net
mation.net
Cognitive Services (Microsoft. privatelink.cognitiveservices. cognitiveservices.azure.com
CognitiveServices/accounts) / azure.com
account
Azure File Sync (Microsoft. privatelink.afs.azure.net afs.azure.net
StorageSync/storageSyncServic-
es) / afs
Azure Data Factory (Microsoft. privatelink.datafactory.azure.net datafactory.azure.net
DataFactory/factories) / dataFac-
tory
Azure Data Factory (Microsoft. privatelink.adf.azure.com adf.azure.com
DataFactory/factories) / portal
Azure Cache for Redis (Microsoft. privatelink.redis.cache.windows. redis.cache.windows.net
Cache/Redis) / redisCache net
DNS configuration scenarios

The FQDN of the services resolves automatically to a public IP address. To resolve to the private IP
address of the Private Endpoint, change your DNS configuration.
DNS is a critical component to make the application work correctly by successfully resolving the Private
Endpoint IP address.
Based on your preferences, the following scenarios are available with DNS resolution integrated:
●● Virtual network workloads without custom DNS server
●● On-premises workloads using a DNS forwarder
●● Virtual network and on-premises workloads using a DNS forwarder
Azure Firewall DNS proxy can be used as DNS forwarder for On-premises workloads and Virtual network
workloads using a DNS forwarder.
Virtual network workloads without custom DNS server

This configuration is appropriate for virtual network workloads without a custom DNS server. In this
scenario, the client queries for the Private Endpoint IP address to the Azure-provided DNS service
168.63.129.16. Azure DNS will be responsible for DNS resolution of the private DNS zones.
This scenario uses the Azure SQL Database-recommended private DNS zone. For other services, you can
adjust the model using the following reference: Azure services DNS zone configuration.
To configure properly, you need the following resources:
●● Client virtual network
●● Private DNS zone privatelink.database.windows.net with type A record
●● Private Endpoint information (FQDN record name and private IP address)
423
The following screenshot illustrates the DNS resolution sequence from virtual network workloads using
the private DNS zone:
You can extend this model to peered virtual networks associated to the same Private Endpoint. Add new
virtual network links to the private DNS zone for all peered virtual networks.
A single private DNS zone is required for this configuration. Creating multiple zones with the same name
for different virtual networks would need manual operations to merge the DNS records.
If you're using a Private Endpoint in a hub-and-spoke model from a different subscription, reuse the
same private DNS zone on the hub.
In this scenario, there's a hub and spoke networking topology. The spoke networks share a Private
Endpoint. The spoke virtual networks are linked to the same private DNS zone.
This configuration can be extended for an on-premises network that already has a DNS solution in place.
The on-premises DNS solution is configured to forward DNS traffic to Azure DNS via a conditional
forwarder. The conditional forwarder references the DNS forwarder deployed in Azure.
424
●● On-premises network with a custom DNS solution in place
●● Virtual network connected to on-premises
●● DNS forwarder deployed in Azure
●● Private DNS zones privatelink.database.windows.net with type A record
The following diagram illustrates the DNS resolution from an on-premises network. DNS resolution is
conditionally forwarded to Azure. The resolution is made by a private DNS zone linked to a virtual
network.
The conditional forwarding must be made to the recommended public DNS zone forwarder. For example:
database.windows.net instead of privatelink.database.windows.net.
On-premises workloads using a DNS forwarder

For on-premises workloads to resolve the FQDN of a Private Endpoint, use a DNS forwarder to resolve
the Azure service public DNS zone in Azure. A DNS forwarder is a Virtual Machine running on the Virtual
Network linked to the Private DNS Zone that can proxy DNS queries coming from other Virtual Networks
or from on-premises. This is required as the query must be originated from the Virtual Network to Azure
DNS. A few options for DNS proxies are: Windows running DNS services, Linux running DNS services,
Azure Firewall.
The following scenario is for an on-premises network that has a DNS forwarder in Azure. This forwarder
resolves DNS queries via a server-level forwarder to the Azure provided DNS 168.63.129.16.
425

●● On-premises network
The following diagram illustrates the DNS resolution sequence from an on-premises network. The
configuration uses a DNS forwarder deployed in Azure. The resolution is made by a private DNS zone
linked to a virtual network:
Virtual network and on-premises workloads using a DNS

forwarder
For workloads accessing a Private Endpoint from virtual and on-premises networks, use a DNS forwarder
to resolve the Azure service public DNS zone deployed in Azure.
The following scenario is for an on-premises network with virtual networks in Azure. Both networks
access the Private Endpoint located in a shared hub network.
This DNS forwarder is responsible for resolving all the DNS queries via a server-level forwarder to the
Azure-provided DNS service 168.63.129.16.
A single private DNS zone is required for this configuration. All client connections made from
on-premises and peered virtual networks must also use the same private DNS zone.
●● On-premises network
426
●● Peered virtual network

The following diagram shows the DNS resolution for both networks, on-premises and virtual networks.
The resolution is using a DNS forwarder. The resolution is made by a private DNS zone linked to a virtual
network:
Multiple choice
How can one ensure that communications with Azure Storage pass through the Service Endpoint?
Add an outbound rule to allow access to storage. {{Correct! Create an Allow_Storage outbound rule to
allow access to Storage.}}
Add an inbound rule to allow access to storage. {{Incorrect, create an Allow_Storage outbound rule to
Do nothing, it is automatically configured. {{Incorrect, create an Allow_Storage outbound rule to allow
access to Storage.}}
427
Multiple choice
What is the significance of IP address 168.63.129.16?
It is a virtual public IP address that is used to facilitate a communication channel to Azure platform
resources. {{Correct! Additionally, customers can define any address space for their private virtual
network in Azure.}}
It is a non-virtual (Classic) public IP address that is used to facilitate a communication channel to
Azure platform resources. {{Incorrect, in a non-virtual network scenario, a private IP address is used
instead of 168.63.129.16. This private IP address is dynamically discovered through DHCP. In a virtual
network, 168.63.129.16 is a virtual public IP address that is used to facilitate a communication channel
to Azure platform resources.}}
It is a static address of a DNS forwarder. {{Incorrect, 168.63.129.16 is a virtual public IP address that is
used to facilitate a communication channel to Azure platform resources.}}
7-Integrate your App Service with Azure virtual

networks
Virtual network integration for Azure services
Integrating Azure services to an Azure virtual network enables private access to the service from virtual
machines or compute resources in the virtual network. You can integrate Azure services in your virtual
network with the following options:
●● Deploying dedicated instances of the service into a virtual network. The services can then be privately
accessed within the virtual network and from on-premises networks.
●● Using Private Link to access privately a specific instance of the service from your virtual network and
from on-premises networks.
●● You can also access the service using public endpoints by extending a virtual network to the service,
through Service Endpoints. Service Endpoints allow service resources to be secured to the virtual
network.
Azure VNet Limits

There are certain limits around the number of Azure resources you can deploy. Most Azure networking
limits are at the maximum values. However, you can increase certain networking limits as specified on the
VNet limits page5.
Configure App Service for regional VNET integration

With Azure Virtual Network (VNets), you can place many of your Azure resources in a non-internet-routa-
ble network. The VNet Integration feature enables your apps to access resources in or through a VNet.
VNet Integration doesn't enable your apps to be accessed privately.
Azure App Service has two variations on the VNet Integration feature:
●● The multitenant systems that support the full range of pricing plans except Isolated.
●● The App Service Environment, which deploys into your VNet and supports Isolated pricing plan apps.
5 https://docs.microsoft.com/azure/azure-resource-manager/management/azure-subscription-service-limits
428
The VNet Integration feature is used in multitenant apps. If your app is in App Service Environment, then
it's already in a VNet and doesn't require use of the VNet Integration feature to reach resources in the
same VNet.
VNet Integration gives your app access to resources in your VNet, but it doesn't grant inbound private
access to your app from the VNet. Private site access refers to making an app accessible only from a
private network, such as from within an Azure virtual network. VNet Integration is used only to make
outbound calls from your app into your VNet. The VNet Integration feature behaves differently when it's
used with VNet in the same region and with VNet in other regions. The VNet Integration feature has two
variations:
●● Regional VNet Integration: When you connect to Azure Resource Manager virtual networks in the
same region, you must have a dedicated subnet in the VNet you are integrating with.
●● Gateway-required VNet Integration: When you connect to VNet in other regions or to a classic virtual
network in the same region, you need an Azure Virtual Network gateway provisioned in the target
VNet.
The VNet Integration features:
●● Require a Standard, Premium, PremiumV2, PremiumV3, or Elastic Premium pricing plan.
●● Support TCP and UDP.
●● Work with Azure App Service apps and function apps.
There are some things that VNet Integration does not support, like:
●● Mounting a drive.
●● Active Directory integration.
●● NetBIOS.
Gateway-required VNet Integration provides access to resources only in the target VNet or in networks
connected to the target VNet with peering or VPNs. Gateway-required VNet Integration doesn't enable
access to resources available across Azure ExpressRoute connections or work with Service Endpoints.
Regardless of the version used, VNet Integration gives your app access to resources in your VNet, but it
doesn't grant inbound private access to your app from the VNet. Private site access refers to making your
app accessible only from a private network, such as from within an Azure VNet. VNet Integration is only
for making outbound calls from your app into your VNet. Follow the steps below to learn how VNet
integration is enabled.
Configure the virtual network for integration with App

Service
Go to the Networking UI in the App Service portal. Under VNet Integration, select Click here to
configure.
Select Add VNet.
429
The drop-down list contains all of the Azure Resource Manager virtual networks in your subscription in
the same region. Underneath that is a list of the Resource Manager virtual networks in all other regions.
Select the VNet you want to integrate with.
430
If the VNet is in the same region, either create a new subnet or select an empty preexisting subnet.
To select a VNet in another region, you must have a VNet gateway provisioned with point to site enabled.
To integrate with a classic VNet, instead of selecting the Virtual Network drop-down list, select Click
here to connect to a Classic VNet. Select the classic virtual network you want. The target VNet must
already have a Virtual Network gateway provisioned with point-to-site enabled.
During the integration, your app is restarted. When integration is finished, you will see details on the
VNet you're integrated with.
Associate the App Service with the virtual network

Using regional VNet Integration enables your app to access:
●● Resources in a VNet in the same region as your app.
●● Resources in VNets peered to the VNet your app is integrated with.
●● Service Endpoint secured services.
●● Resources across Azure ExpressRoute connections.
●● Resources in the VNet you are integrated with.
●● Resources across peered connections, which include Azure ExpressRoute connections.
Private Endpoints
When you use VNet Integration with VNets in the same region, you can use the following Azure network-
ing features:
Network security groups (NSGs): You can block outbound traffic with an NSG that is placed on your
integration subnet. The inbound rules do not apply because you can't use VNet Integration to provide
inbound access to your app.
Route tables (UDRs): You can place a route table on the integration subnet to send outbound traffic
where you want.
431
By default, your app routes only RFC1918 traffic into your VNet. If you want to route all your outbound
traffic into your VNet, use the following steps to add the WEBSITE_VNET_ROUTE_ALL setting in your app:
1. Go to the Configuration UI in your app portal. Select New application setting.
2. Enter WEBSITE_VNET_ROUTE_ALL in the Name box and enter 1 in the Value box.
3. Select OK.
4. Select Save.
When you route all your outbound traffic into your VNet, it's subject to the NSGs and UDRs that are
applied to your integration subnet. When WEBSITE_VNET_ROUTE_ALL is set to 1, outbound traffic is still
sent from the addresses that are listed in your app properties, unless you provide routes that direct the
traffic elsewhere.
Regional VNet integration can't use port 25.
Specify networking settings for application, including DNS

and routing
Service Endpoints
Regional VNet Integration enables you to reach Azure services that are secured with Service Endpoints. To
access a Service Endpoint-secured service, you must do the following:
Configure regional VNet Integration with your web app to connect to a specific subnet for integration.
Go to the destination service and configure Service Endpoints against the integration subnet.
Network security groups
432
You can use network security groups to block inbound and outbound traffic to resources in a VNet. An
app that uses regional VNet Integration can use a network security group to block outbound traffic to
resources in your VNet or the internet. To block traffic to public addresses, you must have the application
setting WEBSITE_VNET_ROUTE_ALL set to 1. The inbound rules in an NSG don't apply to your app
because VNet Integration affects only outbound traffic from your app.
To control inbound traffic to your app, use the Access Restrictions feature. An NSG that is applied to your
integration subnet is in effect regardless of any routes applied to your integration subnet. If WEBSITE_
VNET_ROUTE_ALL is set to 1 and you do not have any routes that affect public address traffic on your
integration subnet, all your outbound traffic is still subject to NSGs assigned to your integration subnet.
When WEBSITE_VNET_ROUTE_ALL is not set, NSGs are only applied to RFC1918 traffic.
Routes
You can use route tables to route outbound traffic from your app to wherever you want. By default, route
tables only affect your RFC1918 destination traffic. When you set WEBSITE_VNET_ROUTE_ALL to 1, all
your outbound calls are affected. Routes that are set on your integration subnet will not affect replies to
inbound app requests. Common destinations can include firewall devices or gateways.
If you want to route all outbound traffic on-premises, you can use a route table to send all outbound traf-
fic to your ExpressRoute gateway. If you do route traffic to a gateway, be sure to set routes in the external
network to send any replies.
Border Gateway Protocol (BGP) routes also affect your app traffic. If you have BGP routes from something
like an ExpressRoute gateway, your app outbound traffic is affected. By default, BGP routes affect only
your RFC1918 destination traffic. When WEBSITE_VNET_ROUTE_ALL is set to 1, all outbound traffic can be
affected by your BGP routes.
Azure DNS private zones
After your app integrates with your VNet, it uses the same DNS server that your VNet is configured with.
By default, your app won't work with Azure DNS private zones. To work with Azure DNS private zones,
you need to add the following app settings:
WEBSITE_DNS_SERVER with value 168.63.129.16
WEBSITE_VNET_ROUTE_ALL with value 1
These settings send all your outbound calls from your app into your VNet and enable your app to access
an Azure DNS private zone. With these settings, your app can use Azure DNS by querying the DNS
private zone at the worker level.
Private Endpoints
If you want to make calls to Private Endpoints6, then you must make sure that your DNS lookups resolve
to the Private Endpoint. You can enforce this behavior in one of the following ways:
●● Integrate with Azure DNS private zones. When your VNet doesn't have a custom DNS server, this is
done automatically.
●● Manage the Private Endpoint in the DNS server used by your app. To do this you must know the
Private Endpoint address and then point the endpoint you are trying to reach to that address using an
A record.
●● Configure your own DNS server to forward to Azure DNS private zones.
6 https://docs.microsoft.com/azure/app-service/networking/private-endpoint
433
Configure Azure Kubernetes Service (AKS) for regional

VNET integration
In many environments, you have defined virtual networks and subnets with allocated IP address ranges.
These virtual network resources are used to support multiple services and applications. To provide
network connectivity, AKS clusters can use kubenet (basic networking) or Azure CNI (advanced network-
ing).
With kubenet, only the nodes receive an IP address in the virtual network subnet. Pods can't communi-
cate directly with each other. Instead, User Defined Routing (UDR) and IP forwarding is used for connec-
tivity between pods across nodes. By default, UDRs and IP forwarding configuration is created and
maintained by the AKS service, but you have to the option to bring your own route table for custom
route management. You could also deploy pods behind a service that receives an assigned IP address and
load balances traffic for the application. The following diagram shows how the AKS nodes receive an IP
address in the virtual network subnet, but not the pods:
Limitations & considerations for kubenet

●● An additional hop is required in the design of kubenet, which adds minor latency to pod communica-
tion.
●● Route tables and user-defined routes are required for using kubenet, which adds complexity to
operations.
●● Direct pod addressing isn't supported for kubenet due to kubenet design.
●● Unlike Azure CNI clusters, multiple kubenet clusters can't share a subnet.
●● Features not supported on kubenet include:
●● Azure network policies7, but Calico network policies are supported on kubenet
●● Windows node pools8
●● Virtual nodes add-on9
7 https://docs.microsoft.com/azure/aks/use-network-policies
8 https://docs.microsoft.com/azure/aks/windows-faq
9 https://docs.microsoft.com/azure/aks/virtual-nodes
434
The choice of which network plugin to use for your AKS cluster is usually a balance between flexibility and
advanced configuration needs. The following considerations help outline when each network model may
be the most appropriate.
Use kubenet when:
●● You have limited IP address space.
●● Most of the pod communication is within the cluster.
●● You don't need advanced AKS features such as virtual nodes or Azure Network Policy. Use Calico
network policies10.
Use Azure CNI when:
●● You have available IP address space.
●● Most of the pod communication is to resources outside of the cluster.
●● You don't want to manage user defined routes for pod connectivity.
●● You need AKS advanced features such as virtual nodes or Azure Network Policy. Use Calico network
policies11.
8-Summary
●● Plan, create, configure, and create access to Private Endpoints
●● Integrate a Private Link with DNS and on-premises clients
●● Create, configure, and provide access to Service Endpoints
●● Configure VNET integration for App Service
●● Repeat the title page learning objectives in this list.
Resources
●● private endpoint overview12
●● virtual network service endpoints overview13
●● design ip addressing for Azure14
●● secure and isolate with nsg and service endpoints15
●● private link and dns integration at scale16
●● app-service overview17
10 https://docs.projectcalico.org/v3.9/security/calico-network-policy
11 https://docs.projectcalico.org/v3.9/security/calico-network-policy
12 https://docs.microsoft.com/azure/private-link/private-endpoint-overview
13 https://docs.microsoft.com/azure/virtual-network/virtual-network-service-endpoints-overview
14 https://docs.microsoft.com/learn/modules/design-ip-addressing-for-azure
15 https://docs.microsoft.com/learn/modules/secure-and-isolate-with-nsg-and-service-endpoints
16 https://docs.microsoft.com/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale
17 https://docs.microsoft.com/azure/app-service/overview
435
Answers
Multiple choice
What is the key technology behind Private Links?
■■ Private Endpoint.{{Correct! Private Links are dependent on Private Endpoints.}}
DNS Resolution.{{Incorrect, though the recommended practice is to use a single Private Endpoint for a
given Private Link resource to avoid duplicate entries or conflicts in DNS resolution. Private Links are
dependent on Private Endpoints.}}
Virtual Networks.{{Incorrect. Though Private Endpoint must be deployed in the same region and
subscription as the virtual network, Private Links are dependent on Private Endpoints. }}
Explanation
Multiple choice
What is the difference between a Service Endpoint and a Private Endpoint?
■■ A Service Endpoint connects to external systems and services.{{Correct! A Service Endpoint connects
to external resources. A Private Endpoint enables a private and secure connection between your
virtual network and Azure.}}
A Private Endpoint connects to external systems and services.{{Incorrect, a Private Endpoint enables a
private and secure connection between your virtual network and Azure. A Service Endpoint connects
to external resources.}}
Insert the second incorrect answer text in this cell.{{Insert the second incorrect answer feedback in this
cell.}}
Explanation
Multiple choice
How can one ensure that communications with Azure Storage pass through the Service Endpoint?
■■ Add an outbound rule to allow access to storage. {{Correct! Create an Allow_Storage outbound rule to
Add an inbound rule to allow access to storage. {{Incorrect, create an Allow_Storage outbound rule to
Do nothing, it is automatically configured. {{Incorrect, create an Allow_Storage outbound rule to allow
access to Storage.}}
Explanation
436
Multiple choice
What is the significance of IP address 168.63.129.16?
■■ It is a virtual public IP address that is used to facilitate a communication channel to Azure platform
resources. {{Correct! Additionally, customers can define any address space for their private virtual
network in Azure.}}
It is a non-virtual (Classic) public IP address that is used to facilitate a communication channel to
Azure platform resources. {{Incorrect, in a non-virtual network scenario, a private IP address is used
instead of 168.63.129.16. This private IP address is dynamically discovered through DHCP. In a virtual
network, 168.63.129.16 is a virtual public IP address that is used to facilitate a communication channel
to Azure platform resources.}}
It is a static address of a DNS forwarder. {{Incorrect, 168.63.129.16 is a virtual public IP address that is
used to facilitate a communication channel to Azure platform resources.}}
Explanation
Module 8 Design and implement network
monitoring
Design and implement network monitoring

1-Introduction
As a network engineer you will design and implement various solutions to complete your enterprise
network. As you deploy and manage the network infrastructure, you will need to monitor and analyze
your environment. There are several tools in Azure, such as Azure Monitor and Azure Network Watcher,
to monitor and analyze your networks and connected resources to ensure they are in good health and
working by design.
Suppose you are the Azure network engineer at a company. You are tasked with diagnosing network
connectivity issues of a VM. You need to learn how to troubleshoot and fix the problem so you can
establish reliable connections to this VM.
In this module, you will learn about Network Watcher features and Azure Monitor as it relates to Azure
networking resources. You will be able to monitor and gain useful insights into the behavior and perfor-
mance of the services and traffic on your networks.
Learning objectives
●● Configure monitoring environment for networking
●● Configure network health alerts and logging by using Azure Monitor
●● Create and configure a Connection Monitor instance
●● Configure and use Traffic Analytics
●● Configure NSG flow logs
●● Enable and configure diagnostic logging
●● Configure Azure Network Watcher
438
Prerequisites
(DNS), and routing
2-Monitor your networks using Azure monitor
What is Azure Monitor?

Azure Monitor helps you maximize the availability and performance of your applications and services. It
delivers a comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and
on-premises environments. This information helps you understand how your applications are performing
and proactively identify issues affecting them and the resources they depend on.
Just a few examples of what you can do with Azure Monitor include:
●● Detect and diagnose issues across applications and dependencies with Application Insights.
●● Correlate infrastructure issues with VM insights and Container insights.
●● Drill into your monitoring data with Log Analytics for troubleshooting and deep diagnostics.
●● Support operations at scale with smart alerts and automated actions.
●● Create visualizations with Azure dashboards and workbooks.
●● Collect data from monitored resources using Azure Monitor Metrics.
The diagram below offers a high-level view of Azure Monitor. At the center of the diagram are the data
stores for metrics and logs, which are the two fundamental types of data used by Azure Monitor. On the
left are the sources of monitoring data that populate these data stores. On the right are the different
functions that Azure Monitor performs with this collected data. This includes such actions as analysis,
alerting, and streaming to external systems.
439
Monitor data types in Azure Monitor

The data collected by Azure Monitor fits into one of two fundamental types:
●● Metrics - Metrics are numerical values that describe some aspect of a system at a particular point in
time. They are lightweight and capable of supporting near real-time scenarios.
●● Logs - Logs contain different kinds of data organized into records with different sets of properties for
each type. Telemetry such as events and traces are stored as logs in addition to performance data so
that it can all be combined for analysis.
Azure Monitor metrics

Azure Monitor Metrics is a feature of Azure Monitor that collects numeric data from monitored resources
into a time series database. Metrics are numerical values that are collected at regular intervals and
describe some aspect of a system at a particular time. Metrics in Azure Monitor are lightweight and
capable of supporting near real-time scenarios making them particularly useful for alerting and fast
detection of issues. You can analyze them interactively with metrics explorer, be proactively notified with
an alert when a value crosses a threshold or visualize them in a workbook or dashboard.
The table below provides a summary of the various types of tasks you can perform by utilizing metrics in
Azure Monitor:
Task Description
Analyze Use metrics explorer to analyze collected metrics
on a chart and compare metrics from different
resources.
Alert Configure a metric alert rule that sends a notifica-
tion or takes automated action when the metric
value crosses a threshold.
Visualize Pin a chart from metrics explorer to an Azure
dashboard.
Create a workbook to combine with multiple sets
of data in an interactive report.Export the results
of a query to Grafana to leverage its dashboarding
and combine with other data sources.
Automate Use Autoscale to increase or decrease resources
based on a metric value crossing a threshold.
Retrieve Access metric values from a command line using
PowerShell cmdlets.
Access metric values from custom application
using REST API.
Access metric values from a command line using
CLI.
Export Route Metrics to Logs to analyze data in Azure
Monitor Metrics together with data in Azure
Monitor Logs and to store metric values for longer
than 93 days
Stream Metrics to an Event Hub to route them to
external systems.
440
Archive Archive the performance or health history of your

resource for compliance, auditing, or offline
reporting purposes.
Azure Monitor metrics sources

There are three fundamental sources of metrics collected by Azure Monitor. Once these metrics are
collected in the Azure Monitor metric database, they can be evaluated together regardless of their
source.
●● Azure resources - Platform metrics are created by Azure resources and give you visibility into their
health and performance. Each type of resource creates a distinct set of metrics without any configura-
tion required. Platform metrics are collected from Azure resources at one-minute frequency unless
specified otherwise in the metric's definition.
●● Applications - Metrics are created by Application Insights for your monitored applications and help
you detect performance issues and track trends in how your application is being used. This includes
such values as Server response time and Browser exceptions.
●● Virtual machine agents - Metrics are collected from the guest operating system of a virtual machine.
Enable guest OS metrics for Windows virtual machines with Windows Diagnostic Extension (WAD) and
for Linux virtual machines with InfluxData Telegraf Agent.
●● Custom metrics - You can define metrics in addition to the standard metrics that are automatically
available. You can define custom metrics in your application that is monitored by Application Insights
or create custom metrics for an Azure service using the custom metrics API.
Metrics Explorer
For several of your resources in Azure, you will see the data collected by Azure Monitor illustrated directly
in the Azure portal on the Monitoring tab of a resource's Overview page.
In the screenshot below for example, you can see the Monitoring tab from the Overview page of a virtual
machine.
441
Note the various charts displaying several key performance metrics for system components such as CPU,
Network, and Disk.
You can click on these graphs to open the data in Metrics Explorer in the Azure portal, which allows you
to interactively analyze the data in your metric database and chart the values of multiple metrics over
time. You can also pin the charts to a dashboard to view them with other visualizations later. You can also
retrieve metrics by using the Azure monitoring REST API.
The data collected by Azure Monitor Metrics is stored in a time-series database which is optimized for
analyzing time-stamped data. Each set of metric values is a time series with the following properties:
●● The time the value was collected
●● The resource the value is associated with
●● A namespace that acts like a category for the metric
●● A metric name
●● The value itself
Some metrics may have multiple dimensions, and custom metrics can have up to 10 dimensions.
442
Access Metrics in the Azure portal

You can access metrics from the Metrics option in the Azure Monitor menu.
You can also access metrics from the Metrics menu of most other services and resources in the Azure
portal. The screenshot below for example, displays the Metrics page for a virtual network resource.
Create metric charts with metrics explorer

Azure Monitor Metrics Explorer is a component of the Microsoft Azure portal that allows plotting charts,
visually correlating trends, and investigating spikes and dips in metrics' values. Use the metrics explorer
to investigate the health and utilization of your resources.
Start in the following order:
1. Pick a resource and a metric and you see a basic chart. Then select a time range that is relevant for
your investigation.
2. Try applying dimension filters and splitting. The filters and splitting allow you to analyze which
segments of the metric contribute to the overall metric value and identify possible outliers.
443
3. Use advanced settings to customize the chart before pinning to dashboards. Configure alerts to
receive notifications when the metric value exceeds or drops below a threshold.
4. To create a metric chart, from your resource, resource group, subscription, or Azure Monitor view,
open the Metrics tab and follow these steps:
5. Click on the “Select a scope” button to open the resource scope picker. This will allow you to select
the resource(s) you want to see metrics for. If you opened metrics explorer from the resource's menu,
the resource should already be populated.
6. For some resources, you must pick a namespace. The namespace is just a way to organize metrics so
that you can easily find them. For example, storage accounts have separate namespaces for storing
Files, Tables, Blobs, and Queues metrics. Many resource types only have one namespace.
7. Select a metric from the list of available metrics. This list will vary depending on what resource and
scope you select.
444
8. Optionally, you can change the metric aggregation. For example, you might want your chart to show
minimum, maximum, or average values of the metric.
Monitor network resources with Azure Monitor Network

Insights
You can use the Insights>Networks section in Azure Monitor to obtain a broad view of health and
metrics for all your deployed network resources, without requiring any configuration. It also provides
access to network monitoring features such as Connection Monitor, flow logging for network security
groups (NSG) flow logs, and Traffic Analytics, and it provides other network diagnostic features.
Azure Monitor Network Insights is structured around these key components of monitoring:
●● Network health and metrics
●● Connectivity
●● Traffic
●● Diagnostic Toolkit
445
Network health and metrics

The Network health tab of Azure Monitor Network Insights offers a simple method for visualizing an
inventory of your networking resources, together with resource health and alerts. It is divided into four
key functionality areas: search and filtering, resource health and metrics, alerts, and dependency view.
Search and filtering
You can customize the resource health and alerts view by using filters such as Subscription, Resource
Group, and Type.
You can use the search box to search for network resources and their associated resources. For example,
a public IP is associated with an application gateway, so a search for the public IP's DNS name would
return both the public IP and the associated application gateway.
Network resource health and metrics

446
You can use the health and metrics information to get an overview of the health status of your various
network resources.
In the example screenshot below, each tile represents a particular type of network resource. The tile
displays the number of instances of that resource type that are deployed across all your selected sub-
scriptions. It also displays the health status of the resource. Here you can see that there are 19 Load
balancers deployed, 17 of which are healthy, 1 is degraded, and 1 is unavailable.
If you select one of the tiles, you get a view of the metrics for that network resource. In the example
screenshot below, you can see the metrics for the ER and VPN connections resource.
You can select any item in this grid view. For example, you could select the icon in the Health column to
get resource health for that connection, or select the value in the Alert column to go to the alerts and
metrics page for the connection.
Alerts
The Alert box on the right side of the page provides a view of all alerts generated for the selected
resources across all your subscriptions. If there is a value for the alerts on an item, simply select the alert
count for that item to go to a detailed alerts page for it.
Dependency view
Dependency view helps you visualize how a resource is configured. Dependency view is currently availa-
ble for Azure Application Gateway, Azure Virtual WAN, and Azure Load Balancer. For example, for
447
Application Gateway, you can access dependency view by selecting the Application Gateway resource
name in the metrics grid view. You can do the same thing for Virtual WAN and Load Balancer.
Connectivity
The Connectivity tab of Azure Monitor Network Insights provides an easy way to visualize all tests
configured via Connection Monitor and Connection Monitor (classic) for the selected set of subscriptions.
Tests are grouped by Sources and Destinations tiles and display the reachability status for each test.
Reachable settings provide easy access to configurations for your reachability criteria, based on Checks
failed(%) and RTT(ms).
After you set the values, the status for each test updates based on the selection criteria.
448
From here, you can then select any source or destination tile to open it up in metric view. In the example
screenshot below, the metrics for the Destinations>Virtual machines tile are being displayed.
Traffic
The Traffic tab of Azure Monitor Network Insights provides access to all NSGs configured for NSG flow
logs and Traffic Analytics for the selected set of subscriptions, grouped by location. The search function-
ality provided on this tab enables you to identify the NSGs configured for the searched IP address. You
can search for any IP address in your environment. The tiled regional view will display all NSGs along with
the NSG flow logs and Traffic Analytics configuration status.
449
If you select any region tile, a grid view will appear which shows NSG flow logs and Traffic Analytics in a
view that is simple to interpret and configure.
In this grid view you can select an icon in the Flow log Configuration Status column to edit the NSG
flow log and Traffic Analytics configuration. Or you can select a value in the Alert column to go to the
traffic alerts configured for that NSG, and you can navigate to the Traffic Analytics view by selecting the
Traffic Analytics Workspace.
450
Diagnostic Toolkit
The Diagnostic Toolkit feature in Azure Monitor Network Insights provides access to all the diagnostic
features available for troubleshooting your networks and their components.
The Diagnostic Toolkit drop-down list provides to access to the following network monitoring features:
●● Capture packets on virtual machines - opens the Network Watcher packet capture network diag-
nostic tool to enable you create capture sessions to track traffic to and from a virtual machine. Filters
are provided for the capture session to ensure you capture only the traffic you want. Packet capture
helps to diagnose network anomalies, both reactively, and proactively. Packet capture is a virtual
machine extension that is remotely started through Network Watcher.
●● Troubleshoot VPN - opens the Network Watcher VPN Troubleshoot tool to diagnose the health of a
virtual network gateway or connection.
●● Troubleshoot connectivity - opens the Network Watcher Connection Troubleshoot tool to check a
direct TCP connection from a virtual machine (VM) to a VM, fully qualified domain name (FQDN), URI,
or IPv4 address.
●● Identify next hops - opens the Network Watcher Next hop network diagnostic tool to obtain the
next hop type and IP address of a packet from a specific VM and NIC. Knowing the next hop can help
you establish if traffic is being directed to the expected destination, or whether the traffic is being
sent nowhere.
●● Diagnose traffic filtering issues - opens the Network Watcher IP flow verify network diagnostic tool
to verify if a packet is allowed or denied, to or from a virtual machine, based on 5-tuple information.
The security group decision and the name of the rule that denied the packet is returned.
Multiple choice
What two types of data are used by Azure Monitor?
Metrics and logs {{Correct, metrics and logs are the two fundamental data types used by Azure
Monitor.}}
Policies and locks {{Incorrect, policies and locks are not data types.}}
Database and storage {{Incorrect, databases and storage are not data types.}}
451
Multiple choice
Which of the following statements about Azure Monitor Logs is correct?
Azure Monitor Logs collects and organizes log and performance data from monitored resources.
{{Correct. Azure Monitor Logs is a feature of Azure Monitor that collects and organizes log and
performance data from monitored resources.}}
Azure Monitor Logs collects data from all Azure resources automatically. {{Incorrect. When you have
created a Log Analytics workspace, you must configure different sources to send their data. No data is
collected automatically.}}
You can use Azure Monitor Logs with or without a workspace. {{Incorrect. You must create at least one
workspace to use Azure Monitor Logs.}}
3-Exercise: monitor a load balancer resource us-

ing Azure monitor
In this exercise, you will create an internal load balancer for the fictional Contoso Ltd organization. Then
you will create a Log Analytics workspace, and use Azure Monitor Insights to view information about your
internal load balancer. You will view the Functional Dependency View, then view detailed metrics for the
load balancer resource, and view resource health information for the load balancer. Finally, you will
configure the load balancer's diagnostic settings to send metrics to the Log Analytics workspace you
created.
The diagram below illustrates the environment you will be deploying in this exercise.

●● Task 1: Create the virtual network
●● Task 2: Create the load balancer
452
●● Task 3: Create a backend pool

●● Task 4: Create a health probe
●● Task 5: Create a load balancer rule
●● Task 6: Create backend servers
●● Task 7: Add VMs to the backend pool
●● Task 8: Install IIS on the VMs
●● Task 9: Test the load balancer
●● Task 10: Create a Log Analytics Workspace
●● Task 11: Use Functional Dependency View
●● Task 12: View detailed metrics
●● Task 13: View resource health
●● Task 14: Configure diagnostic settings
Task 1: Create the virtual network

In this section, you will create a virtual network and a subnet.
1. Log in to the Azure portal.
2. On the Azure portal home page, click Create a resource, then Networking, then select Virtual
Network (if this resource type is not listed on the page, use the search box at the top of the page to
search for it and select it).
3. Click Create.
4. On the Basics tab, use the information in the table below to create the virtual network.
Setting Value
453
Resource group Select Create new
Name: IntLB-RG
Name IntLB-VNet
Region (US) West US
5. Click Next : IP Addresses.
6. On the IP Addresses tab, in the IPv4 address space box, type 10.1.0.0/16.
7. Under Subnet name, select the word default.
8. In the Edit subnet pane, provide a subnet name of myBackendSubnet, and a subnet address range
of 10.1.0.0/24.
9. Click Save.
10. Click Next : Security.
11. Under BastionHost select Enable, then enter the information from the table below.
Setting Value
Bastion name myBastionHost
AzureBastionSubnet address space 10.1.1.0/24
Public IP address Select Create new
Name: myBastionIP
13. Click Create.
Task 2: Create the load balancer

In this section, you will create an internal Standard SKU load balancer. The reason we are creating a
Standard SKU load balancer here in the exercise, instead of a Basic SKU load balance, is for later exercises
that require a Standard SKU version of the load balancer.
2. In the search box at the top of the page, type Load Balancer, then press Enter (Note: do not select
one from the list).
3. Scroll down to the bottom of the page and select Load Balancer (the one that says ‘Microsoft’ and
'Azure Service' under the name).
4. Click Create.
454
5. On the Basics tab, use the information in the table below to create the load balancer.
Setting Value
Name myIntLoadBalancer
Region (US) West US
Type Internal
SKU Standard
IP address assignment Dynamic
7. Click Create.
Task 3: Create a backend pool

The backend address pool contains the IP addresses of the virtual NICs connected to the load balancer.
resources list.
2. Under Settings, select Backend pools, and then click Add.
3. On the Add backend pool page, enter the information from the table below.
Setting Value
Name myBackendPool
Associated to Virtual machines
4. Click Add.
455
Task 4: Create a health probe

The load balancer monitors the status of your app with a health probe. The health probe adds or removes
VMs from the load balancer based on their response to health checks. Here you will create a health probe
to monitor the health of the VMs.
1. From the Backend pools page of your load balancer, under Settings, click Health probes, then click
Add.
2. On the Add health probe page, enter the information from the table below.
Setting Value
Name myHealthProbe
Protocol HTTP
Port 80
Path /
Interval 15
Unhealthy threshold 2
3. Click Add.
456
Task 5: Create a load balancer rule

A load balancer rule is used to define how traffic is distributed to the VMs. You define the frontend IP
configuration for the incoming traffic and the backend IP pool to receive the traffic. The source and
destination port are defined in the rule. Here you will create a load balancer rule.
1. From the Backend pools page of your load balancer, under Settings, click Load balancing rules,
then click Add.
2. On the Add load balancing rule page, enter the information from the table below.
Setting Value
Name myHTTPRule
IP Version IPv4
Frontend IP address LoadBalancerFrontEnd
Protocol TCP
Port 80
Backend port 80
Backend pool myBackendPool
Health probe myHealthProbe
Session persistence None
Idle timeout (minutes) 15
Floating IP Disabled
3. Click Add.
457
Task 6: Create backend servers

In this section, you will create three VMs, that will be in the same availability set, for the backend pool of
the load balancer, add the VMs to the backend pool, and then install IIS on the three VMs to test the load
balancer.
click Upload and upload the following files azuredeploy.json, azuredeploy.parameters.vm1.json,
azuredeploy.parameters.vm2.json and azuredeploy.parameters.vm3.json into the Cloud Shell home
directory. Azure Resource Manager Templates for this task1
3. Deploy the following Azure Resource Manager templates to create the virtual network, subnets, and
VMs needed for this exercise:
$RGName = "IntLB-RG"

Exercises/M04
458
Task 7: Add VMs to the backend pool

resources list.
2. Under Settings, select Backend pools., and then select myBackendPool.
3. In the Associated to box, select Virtual machines.
4. Under Virtual machines, click Add.
5. Select the checkboxes for all 3 VMs (myVM1, myVM2, and myVM3), then click Add.
6. On the myBackendPool page, click Save.
Task 8: Install IIS on the VMs

1. On the Azure portal home page, click All resources, then click on myVM1 from the resources list.
Connect.
5. The myVM1 window will open in another browser tab.
7. Click the Windows Start icon in the bottom left corner of the window, then click the Windows
PowerShell tile.
8. To install IIS, run the following command in PowerShell: Install-WindowsFeature -name Web-Server
-IncludeManagementTools
9. To remove the existing default web home page, run the following command in PowerShell: Re-
move-Item C:\inetpub\wwwroot\iisstart.htm
459
10. To add a new default web home page and add content to it, run the following command in Power-
Shell: Add-Content -Path “C:\inetpub\wwwroot\iisstart.htm” -Value $("Hello World from " + $env:com-
putername)
11. Close the Bastion session to myVM1 by closing the browser tab.
12. Repeat steps 1-11 above twice more to install IIS and the updated default home page on the myVM2
and myVM3 virtual machines.
Task 9: Test the load balancer

In this section, you will create a test VM, and then test the load balancer.
Create test VM
1. On the Azure portal home page, click Create a resource, then Compute, then select Virtual machine
(if this resource type is not listed on the page, use the search box at the top of the page to search for
it and select it).
2. On the Create a virtual machine page, on the Basics tab, use the information in the table below to
create the first VM.
Setting Value
Virtual machine name myTestVM
Region (US) West US
Size Standard_DS1_v2 - 1 vcpu, 3.5 GiB memory
Username TestUser
3. Click Next : Disks, then click Next : Networking.
4. On the Networking tab, use the information in the table below to configure networking settings.
Setting Value
Public IP Change to None
NIC network security group Advanced
Configure network security group Select the existing myNSG
Place this virtual machine behind an existing load Off (unchecked)
balancing solution?
6. Click Create.
7. Wait for this last VM to be deployed before moving forward with the next task.
460
Connect to the test VM to test the load balancer

resources list.
2. On the Overview page, make a note of the Private IP address, or copy it to the clipboard.
3. Click Home, then on the Azure portal home page, click All resources, then click on the myTestVM
virtual machine that you just created.
Connect.
7. The myTestVM window will open in another browser tab.
9. Click the Internet Explorer icon in the task bar to open the web browser.
10. Click OK on the Set up Internet Explorer 11 dialog box.
11. Enter (or paste) the Private IP address (e.g. 10.1.0.4) from the previous step into the address bar of
the browser and press Enter.
12. The default web home page of the IIS Web server is displayed in the browser window. One of the
three virtual machines in the backend pool will respond.

13. If you click the refresh button in the browser a few times, you will see that the response comes
randomly from the different VMs in the backend pool of the internal load balancer.
Task 10: Create a Log Analytics Workspace

1. On the Azure portal home page, click All services, then in the search box at the top of the page type
Log Analytics, and select Log Analytics workspaces from the filtered list.
461
2. Click Create.
3. On the Create Log Analytics workspace page, on the Basics tab, use the information in the table
below to create the workspace.
Setting Value
Name myLAworkspace
Region West US
4. Click Review + Create, then click Create.
Task 11: Use Functional Dependency View

1. On the Azure portal home page, click All resources, then in the resources list, select myIntLoadBal-
ancer.
462
2. Under Monitoring, select Insights.

3. In the top right corner of the page, click the X to close the Metrics pane for now. You will open it
again shortly.
4. This page view is known as Functional Dependency View, and in this view, you get a useful interactive
diagram, which illustrates the topology of the selected network resource - in this case a load balancer.
For Standard Load Balancers, your backend pool resources are color-coded with Health Probe status
indicating the current availability of your backend pool to serve traffic.
5. Use the Zoom In (+) and Zoom Out (-) buttons in the bottom right corner of the page, to zoom in
and out of the topology diagram (alternatively you can use your mouse wheel if you have one). You
can also drag the topology diagram around the page to move it.
6. Hover over the LoadBalancerFrontEnd component in the diagram, then hover over the myBackend-
Pool component.
7. Notice that you can use the links in these pop-up windows to view information about these load
balancer components and open their respective Azure portal blades.
463
8. Hover over the myVM3 virtual machine component. Note that you can open the resource blade for
the virtual machine, and you can open the VM Insights page, or you can run the Connection trou-
bleshoot tool from Network Watcher - all from this part of the topology diagram.
9. To download a .SVG file copy of the topology diagram, click Download topology, and save the file in
your Downloads folder.
10. In the top right corner, click View metrics to reopen the metrics pane on the right-hand side of the
screen.
11. The Metrics pane provides a quick view of some key metrics for this load balancer resource, in the
form of bar and line charts.
464
465
Task 12: View detailed metrics
1. To view more comprehensive metrics for this network resource, click View detailed metrics.
2. This opens a large full Metrics page in the Azure Network Insights platform. The first tab you land on
is the Overview tab, which shows the availability status of the load balancer and overall Data
Throughput and Frontend and Backend Availability for each of the Frontend IPs attached to your Load
466
Balancer. These metrics indicate whether the Frontend IP is responsive and the compute instances in
your Backend Pool are individually responsive to inbound connections.

3. Click the Frontend & Backend Availability tab and scroll down the page to see the Health Probe
Status charts. If you see values that are lower than 100 for these items, it indicates an outage of
some kind on those resources.

4. Click the Data Throughput tab and scroll down the page to see the other data throughput charts.
467
5. Hover over some of the data points in the charts, and you will see that the values change to show the
exact value at that point in time.

6. Click the Flow Distribution tab and scroll down the page to see the charts under the VM Flow
Creation and Network Traffic section.
Task 13: View resource health

1. To view the health of your Load Balancer resources, on the Azure portal home page, click All services,
then select Monitor.
2. On the Monitor>Overview page, in the left-hand menu click Service Health.
3. On the Service Health>Service issues page, in the left-hand menu click Resource Health.
468
4. On the Service Health>Resource health page, in the Resource type drop-down list, scroll down the
list and select Load balancer.
5. Then select the name of your load balancer from the list.
6. The Resource health page will identify any major availability issues with your load balancer resource.
If there are any events under the Health History section, you can expand the health event to see
more detail about the event. You can even save the detail about the event as a PDF file for later review
and for reporting.
Task 14: Configure diagnostic settings

1. On the Azure portal home page, click Resource groups, then select the IntLB-RG resource group
from the list.
2. On the IntLB-RG page, click the name of the myIntLoadBalancer load balancer resource in the list of
resources.
3. Under Monitoring, select Diagnostic settings, then click Add diagnostic setting.
469
4. On the Diagnostic setting page, in the name box, type myLBDiagnostics.

5. Select the AllMetrics checkbox, then select the Send to Log Analytics workspace checkbox.
6. Select your subscription from the list, then select myLAworkspace (westus) from the workspace
drop-down list.
7. Click Save.

470
command:
4-Monitor your networks using Azure network

watcher
Azure Network Watcher

Azure Network Watcher is a regional service that enables you to monitor and diagnose conditions at a
network scenario level in, to, and from Azure. Scenario level monitoring enables you to diagnose prob-
lems at an end-to-end network level view. Network diagnostic and visualization tools available with
Network Watcher help you understand, diagnose, and gain insights to your network in Azure. Network
Watcher is enabled through the creation of a Network Watcher resource, which allows you to utilize
Network Watcher capabilities. Network Watcher is designed to monitor and repair the network health of
IaaS products which includes Virtual Machines, Virtual Networks, Application Gateways, and Load Balanc-
ers.
●● Automate remote network monitoring with packet capture. Monitor and diagnose networking
issues without logging in to your virtual machines (VMs) using Network Watcher. Trigger packet
capture by setting alerts, and gain access to real-time performance information at the packet level.
When you observe an issue, you can investigate in detail for better diagnoses.
●● Gain insight into your network traffic using flow logs. Build a deeper understanding of your
network traffic pattern using Network Security Group flow logs. Information provided by flow
logs helps you gather data for compliance, auditing and monitoring your network security profile.
●● Diagnose VPN connectivity issues. Network Watcher provides you the ability to diagnose your
most common VPN Gateway and Connections issues. Allowing you, not only, to identify the issue
but also to use the detailed logs created to help further investigate.
Verify IP Flow: Quickly diagnose connectivity issues from or to the internet and from or to the on-prem-
ises environment. For example, confirming if a security rule is blocking ingress or egress traffic to or from
a virtual machine. IP flow verify is ideal for making sure security rules are being correctly applied. When
used for troubleshooting, if IP flow verify doesn’t show a problem, you will need to explore other areas
such as firewall restrictions.
Next Hop: To determine if traffic is being directed to the intended destination by showing the next hop.
This will help determine if networking routing is correctly configured. Next hop also returns the route
table associated with the next hop. If the route is defined as a user-defined route, that route is returned.
Otherwise, next hop returns System Route. Depending on your situation the next hop could be Internet,
Virtual Appliance, Virtual Network Gateway, VNet Local, VNet Peering, or None. None lets you know that
while there may be a valid system route to the destination, there is no next hop to route the traffic to the
destination. When you create a virtual network, Azure creates several default outbound routes for
471
network traffic. The outbound traffic from all resources, such as VMs, deployed in a virtual network, are
routed based on Azure's default routes. You might override Azure's default routes or create additional
routes.
Effective security rules: Network Security groups are associated at a subnet level or at a NIC level. When
associated at a subnet level, it applies to all the VM instances in the subnet. Effective security rules view
returns all the configured NSGs and rules that are associated at a NIC and subnet level for a virtual
machine providing insight into the configuration. In addition, the effective security rules are returned for
each of the NICs in a VM. Using Effective security rules view, you can assess a VM for network vulnerabili-
ties such as open ports.
VPN Diagnostics: Troubleshoot gateways and connections. VPN Diagnostics returns a wealth of informa-
tion. Summary information is available in the portal and more detailed information is provided in log files.
The log files are stored in a storage account and include things like connection statistics, CPU and
memory information, IKE security errors, packet drops, and buffers and events.
NSG Flow Logs: NSG Flow Logs maps IP traffic through a network security group. These capabilities can
be used in security compliance and auditing. You can define a prescriptive set of security rules as a model
for security governance in your organization. A periodic compliance audit can be implemented in a
programmatic way by comparing the prescriptive rules with the effective rules for each of the VMs in
your network.
Packet Capture: Network Watcher variable packet capture allows you to create packet capture sessions
to track traffic to and from a virtual machine. Packet capture helps to diagnose network anomalies both
reactively and proactively. Other uses include gathering network statistics, gaining information on
network intrusions, to debug client-server communications and much more.
Connection Troubleshoot: Azure Network Watcher Connection Troubleshoot is a more recent addition
to the Network Watcher suite of networking tools and capabilities. Connection Troubleshoot enables you
to troubleshoot network performance and connectivity issues in Azure.
Network Topology: The topology capability enables you to generate a visual diagram of the resources in
a virtual network, and the relationships between the resources.
[!Note]
To use Network Watcher, you must be an Owner, Contributor, or Network Contributor. If you create a
custom role, the role must be able to read, write, and delete the Network Watcher.
configure Network Watcher

When you create or update a virtual network in your subscription, Network Watcher will be enabled
automatically in your Virtual Network's region. There is no impact to your resources or associated charge
for automatically enabling Network Watcher.
To create a Network Watcher in the Azure portal:
1. Navigate to All services> Networking>Network Watcher.
472
2. Right-click your subscription and choose Enable network watcher in all regions.
3. Note that the status is now showing as Enabled.

473
4. If you expand the regions, you will see that all regions within this subscription are enabled.
5. When you enable Network Watcher using the portal, the name of the Network Watcher instance is
automatically set to NetworkWatcher_region_name where region_name corresponds to the Azure
region where the instance is enabled. For example, a Network Watcher enabled in the West US region
is named NetworkWatcher_westus.
6. The Network Watcher instance is automatically created in a resource group named NetworkWatcher-
RG. The resource group is created if it does not already exist.
474
7. To disable a Network Watcher for a region in the Azure portal, expand the regions section, right click
the name of the region you wish to disable the Network Watcher on, and click Disable network
watcher.
Configure NSG Flow Logs

Network security groups (NSG) allow or deny inbound or outbound traffic to a network interface in a VM.
NSG flow logs is a feature of Azure Network Watcher that allows you to log information about IP traffic
flowing through an NSG. The NSG flow log capability allows you to log the source and destination IP
address, port, protocol, and whether traffic was allowed or denied by an NSG. You can analyze logs using
a variety of tools, such as Power BI and the Traffic Analytics feature in Azure Network Watcher.
Common use cases for NSG flow logs are:
●● Network Monitoring - Identify unknown or undesired traffic. Monitor traffic levels and bandwidth
consumption. Filter flow logs by IP and port to understand application behavior. Export Flow Logs to
analytics and visualization tools of your choice to set up monitoring dashboards.
475
●● Usage monitoring and optimization - Identify top talkers in your network. Combine with GeoIP data
to identify cross-region traffic. Understand traffic growth for capacity forecasting. Use data to remove
overtly restrictive traffic rules.
●● Compliance - Use flow data to verify network isolation and compliance with enterprise access rules.
●● Network forensics and security analysis - Analyze network flows from compromised IPs and
network interfaces. Export flow logs to any SIEM or IDS tool of your choice.
You can enable NSG flow logs from any of the following:
●● Azure portal2
●● PowerShell3
●● Azure CLI4
●● REST5
●● Azure Resource Manager6
1. To configure the parameters of NSG flow logs in the Azure portal, navigate to the NSG Flow Logs
section in Network Watcher.
2. Click the name of the NSG to bring up the Settings pane for the Flow log.
2 https://docs.microsoft.com/azure/network-watcher/network-watcher-nsg-flow-logging-portal
3 https://docs.microsoft.com/azure/network-watcher/network-watcher-nsg-flow-logging-powershell
4 https://docs.microsoft.com/azure/network-watcher/network-watcher-nsg-flow-logging-cli
5 https://docs.microsoft.com/azure/network-watcher/network-watcher-nsg-flow-logging-rest
6 https://docs.microsoft.com/azure/network-watcher/network-watcher-nsg-flow-logging-azure-resource-manager
476
3. Change the parameters you want and click Save to deploy the changes.
Connection Monitor
Connection Monitor overview

Connection Monitor provides unified end-to-end connection monitoring in Azure Network Watcher. The
Connection Monitor feature supports hybrid and Azure cloud deployments. Network Watcher provides
tools to monitor, diagnose, and view connectivity-related metrics for your Azure deployments.
477
Here are some use cases for Connection Monitor:

●● Your front-end web server VM communicates with a database server VM in a multi-tier application.
You want to check network connectivity between the two VMs.
●● You want VMs in the East US region to ping VMs in the Central US region, and you want to compare
cross-region network latencies.
●● You have multiple on-premises office sites in Seattle, Washington, and in Ashburn, Virginia. Your office
sites connect to Microsoft 365 URLs. For your users of Microsoft 365 URLs, compare the latencies
between Seattle and Ashburn.
●● Your hybrid application needs connectivity to an Azure Storage endpoint. Your on-premises site and
your Azure application connect to the same Azure Storage endpoint. You want to compare the
latencies of the on-premises site to the latencies of the Azure application.
●● You want to check the connectivity between your on-premises setups and the Azure VMs that host
your cloud application.
Connection Monitor combines the best of two features: the Network Watcher Connection Monitor
(Classic) feature and the Network Performance Monitor (NPM) Service Connectivity Monitor, Express-
Route Monitoring, and Performance Monitoring feature.
Here are some benefits of Connection Monitor:
●● Unified, intuitive experience for Azure and hybrid monitoring needs
●● Cross-region, cross-workspace connectivity monitoring
●● Higher probing frequencies and better visibility into network performance
●● Faster alerting for your hybrid deployments
●● Support for connectivity checks that are based on HTTP, TCP, and ICMP
●● Metrics and Log Analytics support for both Azure and non-Azure test setups
478
Set up Connection Monitor

There are several key steps you need to perform in order to setup Connection Monitor for monitoring:
1. Install monitoring agents - Connection Monitor relies on lightweight executable files to run connec-
tivity checks. It supports connectivity checks from both Azure environments and on-premises environ-
ments. The executable file that you use depends on whether your VM is hosted on Azure or on-prem-
ises. For more information, visit Install monitoring agents7.
2. Enable Network Watcher on your subscription - All subscriptions that have a virtual network are
enabled with Network Watcher. When you create a virtual network in your subscription, Network
Watcher is automatically enabled in the virtual network's region and subscription. This automatic
enabling doesn't affect your resources or incur a charge. Ensure that Network Watcher isn't explicitly
disabled on your subscription.
3. Create a connection monitor - Connection Monitor monitors communication at regular intervals. It
informs you of changes in reachability and latency. You can also check the current and historical
network topology between source agents and destination endpoints. Sources can be Azure VMs or
on-premises machines that have an installed monitoring agent. Destination endpoints can be Micro-
soft 365 URLs, Dynamics 365 URLs, custom URLs, Azure VM resource IDs, IPv4, IPv6, FQDN, or any
domain name.
4. Set up data analysis and alerts - The data that Connection Monitor collects is stored in the Log
Analytics workspace. You set up this workspace when you created the connection monitor. Monitoring
data is also available in Azure Monitor Metrics. You can use Log Analytics to keep your monitoring
data for as long as you want. Azure Monitor stores metrics for only 30 days by default. For more
information, visit Data collection, analysis, and alerts8.
5. Diagnose issues in your network - Connection Monitor helps you diagnose issues in your connec-
tion monitor and your network. Issues in your hybrid network are detected by the Log Analytics
agents that you installed earlier. Issues in Azure are detected by the Network Watcher extension. You
can view issues in the Azure network in the network topology. For more information, visit Diagnose
issues in your network9.
Create a Connection Monitor

In connection monitors that you create by using Connection Monitor, you can add both on-premises
machines and Azure VMs as sources. These connection monitors can also monitor connectivity to
endpoints. The endpoints can be on Azure or on any other URL or IP.
Connection Monitor includes the following entities:
●● Connection monitor resource – A region-specific Azure resource. All of the following entities are
properties of a connection monitor resource.
●● Endpoint – A source or destination that participates in connectivity checks. Examples of endpoints
include Azure VMs, on-premises agents, URLs, and IPs.
●● Test configuration – A protocol-specific configuration for a test. Based on the protocol you chose,
you can define the port, thresholds, test frequency, and other parameters.
●● Test group – The group that contains source endpoints, destination endpoints, and test configura-
tions. A connection monitor can contain more than one test group.
7 https://docs.microsoft.com/azure/network-watcher/connection-monitor-overview
479
●● Test – The combination of a source endpoint, destination endpoint, and test configuration. A test is
the most granular level at which monitoring data is available. The monitoring data includes the
percentage of checks that failed and the round-trip time (RTT).
You can create a connection monitor using Azure portal, ARMClient or PowerShell.
To create a monitor in Connection Monitor by using the Azure portal:
1. On the Azure portal home page, go to Network Watcher.
2. In the left pane, under Monitoring, select Connection monitor, and then click Create.
480
3. On the Basics tab of the Create Connection Monitor page, you need to enter the following informa-
tion for your new connection monitor:
Field Information
Connection Monitor Name Enter a name for your connection monitor. Use the
standard naming rules for Azure resources.
Subscription Select your Azure subscription from the list.
Region Select a region for your connection monitor. You
can select only the source VMs that are created in
this region.
Workspace configuration Choose a custom workspace or the default
workspace. Your workspace holds your monitoring
data.
To use the default workspace, select the check box.
To choose a custom workspace, clear the check

box. Then select the subscription and region for
your custom workspace.
481
4. Click Next: Test groups >>.

5. On the next page, you can add sources, test configurations, and destinations in your test groups. Each
test group in a connection monitor includes sources and destinations that get tested on network
parameters. They are tested for the percentage of checks that fail and the round-trip-time (RTT) over
test configurations.
482
6. Click Add Test Group.
7. Click Next: Create Alerts >>.

8. On the Create alert tab, you can set up alerts on tests that are failing based on the thresholds set in
test configurations.
9. You need to enter the following information for your alert:
483
●● Create alert (check box): You can select this check box to create a metric alert in Azure Monitor. When
you select this check box, the other fields will be enabled for editing. (Note: Additional charges for the
alert will be applicable.)
●● Scope (Resource/Hierarchy): The values here are automatically filled in for you, based on the values
you specified on the Basics tab.
●● Condition: The alert is created on the Test Result(preview) metric. When the result of the connection
monitor test is a failing result, the alert rule will fire.
●● Action group: You can enter your email directly or you can create alerts via action groups. If you enter
your email directly, an action group with the name NPM Email ActionGroup is created. The email ID is
added to that action group. If you choose to use action groups, you need to select a previously
created action group.
●● Alert rule name: This is the name of the connection monitor and is already filled in for you.
●● Enable rule upon creation: Select this check box to enable the alert rule based on the condition
(default setting). Disable this check box if you want to create the rule without enabling it - perhaps for
evaluation and testing purposes, or because you are just not ready to deploy it yet.
10. Click Next: Review + create >>.

484
11. Review your information, and then click Create.
Traffic Analytics
Traffic Analytics is a cloud-based solution that provides visibility into user and application activity in cloud
networks. Traffic Analytics analyzes Network Watcher network security group (NSG) flow logs to provide
insights into traffic flow in your Azure cloud and provide rich visualizations of data written to NSG flow
logs.
With Traffic Analytics, you can:
●● Visualize network activity across your Azure subscriptions and identify hot spots.
●● Identify security threats to, and secure your network, with information such as open-ports, applica-
tions attempting internet access, and virtual machines (VM) connecting to rogue networks.
●● Understand traffic flow patterns across Azure regions and the internet to optimize your network
deployment for performance and capacity.
●● Pinpoint network misconfigurations leading to failed connections in your network.
How Traffic Analytics works

Traffic analytics examines the raw NSG flow logs and captures reduced logs by aggregating common
flows among the same source IP address, destination IP address, destination port, and protocol. For
example, Host 1 (IP address: 10.10.10.10) communicating to Host 2 (IP address: 10.10.20.10), 100 times
over a period of 1 hour using port (for example, 80) and protocol (for example, http). The reduced log has
one entry, that Host 1 & Host 2 communicated 100 times over a period of 1 hour using port 80 and
protocol HTTP, instead of having 100 entries. Reduced logs are enhanced with geography, security, and
topology information, and then stored in a Log Analytics workspace.
The diagram below illustrates the data flow:
485
The key components of Traffic Analytics are:

●● Network security group (NSG) - Contains a list of security rules that allow or deny network traffic to
resources connected to an Azure Virtual Network. NSGs can be associated to subnets, individual VMs
(classic), or individual network interfaces (NIC) attached to VMs (Resource Manager). For more
information, see Network security group overview.
●● Network security group (NSG) flow logs - Allow you to view information about ingress and egress
IP traffic through a network security group. NSG flow logs are written in json format and show
outbound and inbound flows on a per rule basis, the NIC the flow applies to, five-tuple information
about the flow (source/destination IP address, source/destination port, and protocol), and if the traffic
was allowed or denied. For more information about NSG flow logs, see NSG flow logs.
●● Log Analytics - An Azure service that collects monitoring data and stores the data in a central
repository. This data can include events, performance data, or custom data provided through the
Azure API. Once collected, the data is available for alerting, analysis, and export. Monitoring applica-
tions such as network performance monitor and traffic analytics are built using Azure Monitor logs as
a foundation. For more information, see Azure Monitor logs.
●● Log Analytics workspace - An instance of Azure Monitor logs, where the data pertaining to an Azure
account, is stored. For more information about Log Analytics workspaces, see Create a Log Analytics
workspace.
●● Network Watcher - A regional service that enables you to monitor and diagnose conditions at a
network scenario level in Azure. You can turn NSG flow logs on and off with Network Watcher. For
more information, see Network Watcher.
To analyze traffic, you need to have an existing network watcher, or enable a network watcher in each
region that you have NSGs that you want to analyze traffic for. Traffic analytics can be enabled for NSGs
hosted in any of the supported regions.
Before enabling NSG flow logging, you must have a network security group to log flows for. If you do not
have a network security group, then you must create one using the Azure port, the Azure CLI, or Power-
Shell.
To view Traffic Analytics, search for Network Watcher in the portal search bar. In Network Watcher, to
explore traffic analytics and its capabilities, select Traffic Analytics from the left menu.
The example screenshot below shows the Traffic Analytics dashboard.
486
Multiple choice
Which of the following statements about Network Watcher is correct?
Network Watcher is enabled automatically when you create a virtual network. {{Correct. When you
create or update a virtual network in your subscription, Network Watcher will be enabled automatical-
ly in your Virtual Network's region.}}
Network Watcher must be manually enabled for each virtual network. {{Incorrect. When you create or
update a virtual network in your subscription, Network Watcher will be enabled automatically in your
Virtual Network's region.}}
Network Watcher is enabled by default for all regions. {{Incorrect. Network Watcher is enabled
automatically in your Virtual Network's region, when you create or update a virtual network in your
subscription.}}
Multiple choice
Which of the following is a component of Traffic Analytics?
Network security group (NSG) flow logs {{Correct. Allow you to view information about ingress and
egress IP traffic through a network security group.}}
Backend pool {{Incorrect. A backend pool is not required for traffic analytics.}}
Availability zones {{Incorrect. Availability zones are not required for traffic analytics.}}

●● Configure network health alerts and logging by using Azure Monitor
●● Create and configure a Connection Monitor instance
487
●● Configure and use Traffic Analytics

●● Configure NSG flow logs
●● Enable and configure diagnostic logging
●● Configure Azure Network Watcher
Resources
Network monitoring solutions10
10 https://docs.microsoft.com/azure/networking/network-monitoring-overview
488
Answers
Multiple choice
What two types of data are used by Azure Monitor?
■■ Metrics and logs {{Correct, metrics and logs are the two fundamental data types used by Azure
Monitor.}}
Policies and locks {{Incorrect, policies and locks are not data types.}}
Database and storage {{Incorrect, databases and storage are not data types.}}
Explanation
Multiple choice
Which of the following statements about Azure Monitor Logs is correct?
■■ Azure Monitor Logs collects and organizes log and performance data from monitored resources.
{{Correct. Azure Monitor Logs is a feature of Azure Monitor that collects and organizes log and
performance data from monitored resources.}}
Azure Monitor Logs collects data from all Azure resources automatically. {{Incorrect. When you have
created a Log Analytics workspace, you must configure different sources to send their data. No data is
collected automatically.}}
You can use Azure Monitor Logs with or without a workspace. {{Incorrect. You must create at least one
workspace to use Azure Monitor Logs.}}
Explanation
Multiple choice
Which of the following statements about Network Watcher is correct?
■■ Network Watcher is enabled automatically when you create a virtual network. {{Correct. When you
create or update a virtual network in your subscription, Network Watcher will be enabled automatical-
ly in your Virtual Network's region.}}
Network Watcher must be manually enabled for each virtual network. {{Incorrect. When you create or
update a virtual network in your subscription, Network Watcher will be enabled automatically in your
Virtual Network's region.}}
Network Watcher is enabled by default for all regions. {{Incorrect. Network Watcher is enabled
automatically in your Virtual Network's region, when you create or update a virtual network in your
subscription.}}
Explanation
Multiple choice
Which of the following is a component of Traffic Analytics?
■■ Network security group (NSG) flow logs {{Correct. Allow you to view information about ingress and
egress IP traffic through a network security group.}}
Backend pool {{Incorrect. A backend pool is not required for traffic analytics.}}
Availability zones {{Incorrect. Availability zones are not required for traffic analytics.}}
Explanation

Az 700

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

Az 700

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Az 700

Uploaded by

Copyright:

Available Formats

Microsoft

© 2019 Microsoft Corporation. All rights reserved.

Microsoft and the trademarks listed at http://www.microsoft.com/trademarks 1are trademarks of the

MICROSOFT LICENSE TERMS

3. LICENSED CONTENT BASED ON PRE-RELEASE TECHNOLOGY. If the Licensed Content’s subject

This limitation applies to

■■ Module 0 Course introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  1

Module 06 - Design and Implement network security

AZ-700 Certification Exam

AZ-700 Study Areas Weights

Additional Study Resources

Introduction to Azure virtual networks

2-Explore Azure Virtual Networks

Capabilities of Azure Virtual Networks

Design considerations for Azure Virtual Networks

Address space and subnets

Determine a naming convention

Understand Regions and Subscriptions

Azure Availability Zones

Create a Virtual Network in Azure

Create a Virtual Network by using the portal

On the Virtual Network page, select Create.

Resource group Select an existing resource group or Create a new

Click Create to create your virtual network.

3-Configure public IP services

Use dynamic and static public IP addresses

Choose the appropriate SKU for a public IP address

Create a public IP address prefix

Check your knowledge

4-Exercise: Design and implement a virtual net-

You will create the following resources:

Virtual Network Region Virtual network Subnet Subnet

●● Task 2: Create the CoreServicesVnet virtual network and subnets

Task 1: Create the Contoso resource group

3. In Resource groups, select + Create.

Tab Option Value

Task 2: Create the CoreServicesVnet virtual network and

2. In Search services and marketplace, enter virtual network.

3. In Marketplace, in Virtual Network, select Create > Virtual network.

‎Remove or overwrite the default IP Address space

Tab Option Value

Subnet Option Value

Task 3: Create the ManufacturingVnet virtual network and

Subnet Option Value

SensorSubnet1 Subnet name SensorSubnet1

Task 4: Create the ResearchVnet virtual network and sub-

Subnet Option Value

Task 5: Verify the creation of VNets and Subnets

7. Repeat steps 4 - 6 for each VNet.

5-Design name resolution for your virtual net-

Public DNS services

Delegate DNS Domains

cached by clients before being requeried.

Private DNS services

Azure provided DNS

Azure Private DNS Zones

Create a private DNS zone by using the portal

■■ Module 0 Course introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1