Designing and Implementing Microsoft Azure Networking Solutions E-Book

David Okeyode

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 436

Veröffentlichungsjahr: 2023

Beschreibung

Designing and Implementing Microsoft Azure Networking Solutions is a comprehensive guide that covers every aspect of the AZ-700 exam to help you fully prepare to take the certification exam.
Packed with essential information, this book is a valuable resource for Azure cloud professionals, helping you build practical skills to design and implement name resolution, VNet routing, cross-VNet connectivity, and hybrid network connectivity using the VPN Gateway and the ExpressRoute Gateway. It provides step-by-step instructions to design and implement an Azure Virtual WAN architecture for enterprise use cases.
Additionally, the book offers detailed guidance on network security design and implementation, application delivery services, private platform service connectivity, and monitoring networks in Azure. Throughout the book, you’ll find hands-on labs carefully integrated to align with the exam objectives of the Azure Network Engineer certification (AZ-700), complemented by practice questions at the end of each chapter, allowing you to test your knowledge.
By the end of this book, you’ll have mastered the fundamentals of Azure networking and be ready to take the AZ-700 exam.

Leseprobe

Designing and Implementing Microsoft Azure Networking Solutions

Exam Ref AZ-700 preparation guide

David Okeyode

BIRMINGHAM—MUMBAI

Designing and Implementing Microsoft Azure Networking Solutions

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Pavan Ramchandani

Publishing Product Manager: Prachi Sawant

Senior Editor: Athikho Sapuni Rishana

Technical Editor: Irfa Ansari

Copy Editor: Safis Editing

Project Coordinator: Ashwin Kharwa

Proofreader: Safis Editing

Indexer: Subalakshmi Govindhan

Production Designer: Joshua Misquitta

Marketing Coordinator: Marylou De Mello

First published: July 2023

Production reference: 1260723

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB

ISBN 978-1-80324-203-3

www.packtpub.com

This book is dedicated to the incredible individuals who continue to lovingly nurture me in the complex art of life: my father, Oluwagbenga; my mother, Oluwayemisi; my three sisters, Oluwapemi, Oluwagbolade, and Ajulooluwa; and my wife, Po Kei.

Additionally, a profound dedication goes to the individuals who patiently mentored me in the fields of networking, system administration, and security. I express my deepest gratitude to Tom Elgar, Rajeev Kapur, Ope Babayemi, Bara Mustafa, and Ross McKerchar.

– David Okeyode

Contributors

About the author

David Okeyode is the EMEA Chief Technology Officer for Azure at Palo Alto Networks. Before that, he was an independent consultant helping companies secure their Azure environments through private expert-level training and assessments. He also runs a specialized training company, Charis Cloud, that is focused on cloud security training for professionals and organizations. He has authored two other books on Azure security: Penetration Testing Azure for Ethical Hackers and Microsoft Azure Security Technologies Certification and Beyond. He has also authored multiple cloud computing courses for popular training platforms such as LinkedIn Learning. He holds over 15 cloud certifications across the Azure and AWS platforms, including the Azure Security Engineer, Azure DevOps, and AWS Security Specialist certifications.

He regularly speaks on cloud security at user groups and major industry events such as Microsoft Build, Microsoft Ignite, Azure Lowlands, Future Decoded, and the European Information Security Summit.

David is married to a lovely girl who makes the best banana cake in the world. They love traveling the world together!

About the reviewers

Michel Jatobá is a highly qualified and experienced professional with more than 10 years of experience in the cloud and infrastructure. He has an extensive understanding of technologies such as Office 365, EMS, and Azure, and has helped customers efficiently implement and improve their environments. With his technical skills (hard skills) and interpersonal skills (soft skills), Michel Jatobá is able to provide high-impact solutions for clients, ensuring project satisfaction and success.

I would like to thank everyone for their confidence in this project. Thanks to my family, who always support me; my wife, Luana de Barros; and my children, Luíza and Bento.

Leke Oluwatosin is a senior network and information security engineer, with over 15 years of relevant and progressive information technology experience, responsible for network and information security solution initiatives including network infrastructure design, security assessment, cloud security assessment, vulnerability management, and ongoing incident response.

He currently holds a master’s degree in cybersecurity technology from the University of Maryland Global Campus and multiple expert-level vendor-focused certifications, such as CCIE and JNCIE, and vendor-neutral certifications, such as GIAC GCED, GDSA, and GCIH.

I’d like to thank the author for considering me worthy to provide my input to help readers learn about this technology and for making a positive impact in the technology community at large.

Table of Contents

Preface

Part 1: Design and Implement Core Networking Infrastructure in Azure

1

Azure Networking Fundamentals

Technical requirements

Understanding Azure VNet

Azure VNet versus traditional networks

Planning Vnet naming

Planning VNet location

Planning Vnet IP address spaces

Planning Vnet subnet segmentation

Working with platform services in subnets

Hands-on exercise – creating a single-stack VNet in Azure

Task 1 – creating the CharisTech resource group

Task 2 – creating the CoreServicesVNet VNet and subnets

Task 3 – verifying the creation of the VNet and subnets

Hands-on exercise – creating a dual-stack VNet in Azure

Task 1 – creating the dual-stack EngineeringVNet VNet and subnets

Task 2 – verifying the creation of the dual-stack VNet and subnets

Understanding private IP address assignment for subnet workloads

Hands-on exercise – determining the VM location and sizes for future exercises

Task 1 – determining the CPU quota limits for recommended subscription regions

Hands-on exercise – exploring private IP assignments

Task 1 – deploying VMs with dynamic and static private IP assignments

Hands-on exercise – cleaning up resources

Summary

Further reading

2

Designing and Implementing Name Resolution

Technical requirements

A hands-on exercise – provisioning resources for the chapter’s exercises

Name resolution scenarios and options

Internal name resolution scenarios and options

Option 1 – Azure-provided name resolution

A hands-on exercise – exploring Azure-provided name resolution

Option 2 – customer-managed DNS servers

A hands-on exercise – implementing a customer-managed DNS server

Option 3 – Azure Private DNS

A hands-on exercise – implementing Azure Private DNS

Option 4 – Azure Private DNS Resolver and Azure Private DNS zones

External name resolution scenarios and options

A hands-on exercise – implementing Azure Public DNS

A hands-on exercise – clean up resources

Summary

Further reading

3

Design, Implement, and Manage VNet Routing

Technical requirements

Understanding the default routing for Azure VNet workloads

Understanding default routing for dual-stack subnets

Hands-on exercise – provisioning resources for the chapter’s exercises

Hands-on exercise – explore the default routing of Azure subnet workloads

Modifying the default routing behavior

Implementing custom routing with user-defined routes

Hands-on exercise – route network traffic with a route table

Implementing dynamic custom routing with BGP

Hands-on exercise – implementing BGP dynamic routing with Azure Route Server

Route selection and priority

Hands-on exercise – cleaning up resources

Summary

Further reading

4

Design and Implement Cross-VNet Connectivity

Technical requirements

Understanding cross-VNet connectivity options

Connecting VNets using VNet peering

Planning VNet peering implementation

Understanding VNet peering architecture considerations

Understanding VNet peering and transitive routing

Configuring VNet peering

VNet peering in a hub-and-spoke architecture

Connecting VNets using a VPN gateway connection

Understanding VPN Gateway architecture considerations

Connecting VNets using a vWAN

Hands-on exercise – provisioning resources for the chapter

Task 1 – initializing the template deployment in GitHub

Hands-on exercise – implementing cross-region VNet connectivity using the vWAN

Task 1 – creating a vWAN

Task 2 – creating a virtual hub in each VNet location in the vWAN

Task 3 – connecting the VNets to the regional virtual hubs

Task 4 – verifying effective routes on the VNets and the virtual hubs

Task 5 – verifying the connectivity between the VNets

Comparing the three cross-VNet connectivity options

Hands-on exercise – clean up resources

Summary

Further reading

Part 2: Design, Implement, and Manage Hybrid Networking

5

Design and Implement Hybrid Network Connectivity with VPN Gateway

Technical requirements

Understanding Azure hybrid network connection options

Understanding the Azure VPN gateway

Choosing the right VPN gateway SKU and generation

Selecting between route-based or policy-based VPN types

Selecting high-availability options for VPN connections

Understanding third-party device compatibility

Hands-on exercise – provision resources for chapter exercises

Task 1: Initialize template deployment in GitHub, complete parameters, and deploy the template to Azure

Hands-on exercise: implement a BGP-enabled VPN connection in Azure

Task 1: Create the gateway subnet

Task 2: Deploy the VPN gateway into the subnet (with an existing public IP)

Task 3: Create the local network gateway

Task 4: Configure the VPN connection

Task 5: Verify VPN connection status and BGP peering

Task 6: Verify connectivity between the on-premises network and the Azure VNet

Understanding point-to-site connections

Defining a connection pool for P2S VPN connectivity

Selecting the tunnel type(s) for P2S VPN connectivity

Selecting the authentication type for P2S VPN connectivity

Hands-on exercise – implement a P2S VPN connection with Azure certificate authentication

Task 1: Connect to the remote user’s PC via RDP

Task 2: Configure the P2S VPN gateway settings

Task 3: Configure settings for VPN clients

Task 4: Verify connectivity between the remote PC and the Azure VNet

Troubleshoot Azure VPN Gateway using diagnostic logs

Hands-on exercise – clean up resources

Summary

6

Designing and Implementing Hybrid Network Connectivity with the ExpressRoute Gateway

Technical requirements

Understanding what ExpressRoute is and its main use cases

Choosing between private peering and public peering

Understanding ExpressRoute components

Deciding on an ExpressRoute connectivity model

Understanding the provider model

Understanding the ExpressRoute direct model

Selecting the right ExpressRoute circuit SKU

Selecting the right ExpressRoute gateway SKU

Implementing ExpressRoute with zone redundancy

Modifying a gateway SKU

Implementing the gateway subnet

Improving data path performance with ExpressRoute FastPath

Understanding FastPath unsupported scenarios

Configuring FastPath for new or existing connections

Designing and implementing cross-network connectivity over ExpressRoute

Enhancing cross-network connectivity using VNet peering

Enhancing cross-network connectivity using multiple ExpressRoute VNet connections

Enhancing cross-network connectivity using ExpressRoute Global Reach

Understanding the implementation of encryption over ExpressRoute

Understanding the implementation of BFD

Hands-on exercise – implementing an ExpressRoute gateway

Task 1 – create a VNet and gateway subnet

Task 2 – deploy the ExpressRoute VNet gateway service

Task 3 – create and provision an ExpressRoute circuit

Task 4 – retrieve your service key (you need to send this to your SP)

Task 5 – check serviceProviderProvisioningState status

Task 6 – connect the ExpressRoute gateway to the ExpressRoute circuit

Task 7 – deprovision an ExpressRoute circuit

Task 8 – clean up resources

Summary

7

Design and Implement Hybrid Network Connectivity with Virtual WAN

Technical requirements

Designing a scalable network topology in Azure

The standard hub-and-spoke topology

The Azure vWAN hub-and-spoke topology

Understanding the design considerations of a vWAN hub

Selecting the regions for the VWAN hub

Selecting an IP address space for the VWAN hub

Configuring the routing infrastructure for the VWAN hub

Configuring the VWAN hub routing preference

Connecting VNets together using VWAN

Understanding the routing and SD-WAN configuration in a virtual hub

Understanding VNet connection route table association

Understanding VNet connection route propagation

Implementing BGP peering between an NVA and a virtual hub

Implementing a third-party SD-WAN NVA in a virtual hub

Hands-on exercise 1 – provision resources for chapter exercises

Task 1 – initialize template deployment in GitHub

Configuring Site-to-Site connectivity using VWAN

Understanding the scalability considerations of a VWAN hub S2S VPN

Understanding the availability considerations of a VWAN hub S2S VPN

Understanding the performance considerations of a VWAN hub S2S VPN

Hands-on exercise 2 – implement site-to-site VPN connectivity using VWAN

Task 1 – add a site-to-site gateway to VWAN

Task 2 – create a VPN site in VWAN

Task 3 – connect the VPN site to a VWAN hub

Task 4 – obtain VPN configuration information

Task 5 – configure the “on-premises” VPN device

Task 6 – verify routes and connectivity to the “on-premises” site through VWAN

Task 7 – clean up the resources

Implementing a global transit network architecture using VWAN

Understanding the security considerations of a virtual hub

Approach 1 – deploy Azure Firewall in the virtual hub

Approach 2 – deploy a third-party security virtual appliance in the virtual hub

Approach 3 – deploy a third-party network virtual appliance in a connected VNet and route traffic to it for inspection

Comparing virtual hub NVA deployment options

Summary

Further reading

8

Designing and Implementing Network Security

Technical requirements

Securing the Azure virtual network perimeter

Implementing DDoS protection

Understanding Azure DDoS Protection service tiers

Hands-on exercise 1 – provisioning resources for Chapter 8’s exercises

Hands-on exercise 2 – implementing DDoS Protection, monitoring, and validation

Task 1 – creating a DDoS Protection plan

Task 2 – enabling DDoS Protection on a virtual network

Task 3 – reviewing DDoS metrics for telemetry

Task 4 – configure DDoS diagnostic logs forwarding

Task 5 – configuring DDoS alerts

Task 6 – creating a BreakingPoint Cloud account and authorizing your Azure subscription

Task 7 – running a DDoS Test

Task 8 – reviewing DDoS test results

Implementing Azure Firewall

Understanding Azure Firewall service tiers

Understanding Azure Firewall’s features

Understanding some considerations for an Azure Firewall deployment

Hands-on exercise 3 – deploying Azure Firewall into a VNet and a Virtual WAN Hub

Task 1 – deploying an Azure Firewall test environment template with the Azure CLI

Task 2 – reviewing the firewall service and the firewall policy

Task 3 – testing connectivity through the firewall

Implementing a WAF in Azure

Understanding managed rule sets and WAF policies

Understanding custom rule sets

Understanding WAF policy modes and rule actions

Understanding WAF policy associations

Understanding WAF policy limitations

Implementing central management with Firewall Manager

Summary

Further reading

Part 3: Design and Implement Traffic Management and Network Monitoring

9

Designing and Implementing Application Delivery Services

Technical requirements

Understanding Azure’s load-balancing and application delivery services

Understanding Azure load-balancing and application delivery services categories

Designing and implementing an Azure Load Balancer service

Understanding use cases for the Basic SKU

Understanding use cases for the Standard SKU

Hands-on exercise 1 – Provisioning resources for this chapter’s exercises

Hands-on exercise 2 – Creating and configuring a global (cross-region) load balancer

Designing and implementing an Azure Application Gateway service

Understanding Azure Application Gateway tiers

Understanding the scalability and performance of the tiers

Considerations for the Application Gateway subnet

Understanding Azure Application Gateway components

Designing and implementing an Azure Front Door load balancer service

Understanding Azure Front Door tiers

Understanding Front Door components

Hands-on exercise 1 – Creating and configuring an Azure Front Door service

Designing and implementing an Azure Traffic Manager service

Configuring a traffic routing method

Configuring Traffic Manager endpoints

Choosing an optimal load-balancing and application delivery solution

Summary

10

Designing and Implementing Platform Service Connectivity

Technical requirements

Implementing platform service network security

Understanding the platform service firewall and its exceptions

Understanding service endpoints

Hands-on exercise 1 – provisioning the resources for this chapter’s exercises

Hands-on exercise 2 – configuring service endpoints for a storage account

Designing and implementing Azure Private Link and Azure private endpoints

Hands-on exercise 3 – configuring an Azure private endpoint for an Azure WebApp

Summary

Further reading

11

Monitoring Networks in Azure

Technical requirements

Introducing Azure Network Watcher for monitoring, network diagnostics, and logs

Understanding the network monitoring tools of Network Watcher

Topology visualization

Connection monitor

Understanding the Network diagnostic tools of Network Watcher

Connection troubleshoot

IP flow verify

NSG diagnostics

Next hop

VPN troubleshoot

Packet capture

Hands-on exercise 1 – provisioning the resources for the chapter's exercises

Task 1 – initialize template deployment in GitHub, complete the parameters, and deploy a template to Azure

Hands-on exercise 2 – implementing the network monitoring tools of Network Watcher

Task 1 – visualize the topology of an Azure VNet

Task 2 – create an Azure Network Watcher connection monitor

Task 3 – Trigger a network issue and review Connection Monitor

Understanding NSG flow logs

NSG flow logs limitations and use cases

Hands-on exercise 3 – enabling NSG flow logs

Task 1 – enable an NSG flow log

Task 2 – download and review the flow log

Summary

Further reading

Index

Other Books You May Enjoy

Preface

In a world heavily dependent on cloud services, understanding and managing cloud network infrastructure is critical. In this book, you will gain both the knowledge and the practical skills to plan, design, implement, manage, and secure networks in the Azure cloud.

This book is also a comprehensive guide designed for those who are preparing for the Azure Network Engineer certification exam (AZ-700) and for those interested in mastering the Azure networking infrastructure. You will dive deep into concepts such as hybrid networking, routing, securing, and monitoring networks, as well as implementing private access to Azure services using native Azure capabilities.

Complete with hands-on labs, this book will take you beyond foundational knowledge to having a clear understanding of key design principles and implementation best practices. By the end of this book, you will be fully equipped and ready to architect and deploy highly scalable, performance-efficient networks in the Azure cloud.

Who this book is for

This book is aimed at new and experienced IT professionals, network engineers, cloud administrators, and architects with interests in planning, designing, implementing, managing, and securing networks in the cloud.

Technical professionals who are preparing to take the Azure Network Engineer certification exam (AZ-700) will also benefit tremendously from reading this book.

What this book covers

Chapter 1, Azure Networking Fundamentals, introduces core concepts of Azure networking, such as virtual networks, public and private IP addressing, network segmentation using subnets, and routing concepts.

Chapter 2, Design and Implement Name Resolution, covers the four DNS implementation options for virtual networks in Azure and their use cases: Azure-provided name resolution, customer-managed DNS servers, Azure DNS private zones, and Azure DNS public zones.

Chapter 3, Design, Implement, and Manage VNet Routing, explains Azure routing, and you will create custom routes to control traffic flow. You will learn how to redirect traffic through network virtual appliances so you can inspect the traffic before it’s allowed through. You will also learn how to implement Azure Route Server – a fully managed service that simplifies dynamic routing between your network virtual appliance (NVA) and Azure Virtual Network.

Chapter 4, Design and Implement Cross-VNet Connectivity, covers the design and implementation of cross-VNet connectivity using VNet peering.

Chapter 5, Design and Implement Hybrid Network Connectivity with VPN Gateway, covers one of the diverse options to connect remote users and networks to networks in Azure offered by the Azure cloud – the Azure VPN Gateway service, which allows us to create a secure connection between remote networks and Azure VNets over the public internet.

Chapter 6, Design and Implement Hybrid Network Connectivity with an ExpressRoute Gateway, explores the implementation of ExpressRoute, another gateway service offered by Azure, as an alternative solution for remote network connectivity. ExpressRoute connections bypass the public internet, which means that traffic takes fewer hops and has fewer points of failure that could cause network disruption.

Chapter 7, Design and Implement an Azure Virtual WAN Architecture, explains how to design a scalable network architecture in Azure using the VWAN service.

Chapter 8, Design and Implement Network Security, looks into securing the Azure network perimeter and VNet workloads using native capabilities such as DDoS protection, Azure Firewall, and Azure Firewall Manager.

Chapter 9, Design and Implement Application Delivery Services, discusses the four main load balancing services in Azure (Load Balancer, Application Gateway, Front Door, and Traffic Manager) and aspects to consider when designing and implementing these services.

Chapter 10, Design and Implement Platform Service Connectivity, looks at the three main options to control network connections to services when deploying platform services outside of customer-managed virtual networks in Azure (a platform service firewall, a service endpoint, and a private endpoint). This chapter will provide you with a clear understanding of these three options and how to design and implement them.

Chapter 11, Monitoring Networks in Azure, covers network monitoring and diagnostics – essential components in maintaining the smooth functioning and optimal performance of a network infrastructure. In this chapter, we will cover the tools available in Azure Network Watcher that we can use to monitor and diagnose network services.

To get the most out of this book

Foundation-level knowledge of the Azure cloud platform as well as a general knowledge of networking concepts are required to get the most out of this book.

Software/hardware covered in the book

Operating system requirements

A PC with an internet connection and a web browser

Windows, macOS, or Linux

An Azure subscription

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Designing-and-Implementing-Microsoft-Azure-Networking-Solutions. If there’s an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “In the search box at the top of the portal, enter Load balancer.”

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Select System info from the Administration panel.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share your thoughts

Once you’ve read Designing and Implementing Microsoft Azure Networking Solutions, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781803242033

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1: Design and Implement Core Networking Infrastructure in Azure

Welcome to this comprehensive guide on Azure networking, where we will embark on a journey through the fundamental principles and practical implementations of networking within the Azure cloud environment. Over the course of this part, we will explore four key chapters that delve into the crucial aspects of Azure networking. Throughout this part, we will combine theoretical knowledge with practical hands-on examples, empowering you to design, implement, and manage Azure networking solutions confidently. So, let’s embark on this enriching journey and unlock the true potential of networking in the Azure cloud. Let’s get started!

This part comprises the following chapters:

Chapter 1, Azure Networking FundamentalsChapter 2, Design and Implement Name ResolutionChapter 3, Design, Implement, and Manage VNet RoutingChapter 4, Design and Implement Cross-VNet Connectivity

1

Azure Networking Fundamentals

As more organizations migrate business-critical workloads to the Azure cloud platform (or build new ones), they rely on applications and services being able to communicate with each other securely to provide services to their internal teams, business partners, and customers. Azure Virtual Network (VNet) is the core service for implementing secure private networking in Azure. A VNet is a virtual version of a physical network, implemented on the Azure cloud platform.

In this chapter, we will focus on the foundational concepts of implementing private network connectivity in Azure. We will walk through what Azure VNet is, its capabilities, the key differences between Azure VNet and a traditional on-premises network, and supported services that can be launched into Azure VNet (spoiler: as well as a virtual machine (VM), we can also deploy 20 other services into Azure VNet).

We’ll then go on to discuss key implementation options such as designing/assigning IP address spaces, segmentation using subnets, and resource IP address assignments – how resources are allocated an IP address (another spoiler: you can’t use self-managed DHCP!).

Lastly, we’ll talk about the routing and traffic flow functionalities of Azure VNet. In other words, how does routing work and how do we control traffic flow?

In this chapter, we will cover the following topics:

Understanding Azure VNetPlanning VNet naming and locationPlanning VNet IP address spacesPlanning VNet subnet segmentationHands-on exercise – creating a single-stack VNet in AzureHands-on exercise – creating a dual-stack VNet in AzureUnderstanding private IP address assignment for subnet workloadsHands-on exercise – determining the VM location and sizes for future exercisesHands-on exercise – exploring private IP assignmentsCleaning up resources

Each topic has been structured to align with the recommended network connectivity best practices in Azure. Let us get into this!

Technical requirements

To follow along with the instructions in this chapter, you will need the following:

A PC with an internet connectionAn Azure subscription

Before we proceed to cover the security best practices, let us prepare our Azure subscription for the hands-on exercises that we will complete later in the chapter.

Understanding Azure VNet

Before we get too far into Azure networking concepts, let’s establish what Azure VNet is and the capabilities that it provides.

A VNet is a virtual version of a physical network, implemented on the Azure cloud platform. The main advantage that it has over a traditional network is that we don’t need to implement or maintain the underlying physical hardware for this network (these responsibilities are offloaded to our cloud provider – Microsoft). But for the most part, we can achieve similar capabilities and architectures that we can achieve on-premises. We can even implement more flexible architectures with Azure VNets due to the software-defined nature.

So, what capabilities does Azure VNet provide? Here is a short list of some use cases:

Connectivity for supported Azure services including VM, virtual machine scale sets (VMSSs), and 32 other servicesNative Internal TCP/UDP Load Balancing and proxy systems for Internal HTTP(S) Load BalancingConnects to on-premises networks using Cloud VPN tunnels and Cloud Interconnect attachments

Limitation

An Azure subscription can have up to 1,000 VNets as of the time of writing (April, 2022). An additional subscription will be needed to grow beyond this limit.

Azure VNet versus traditional networks

Even though Azure VNet is similar to a traditional on-premises network in many ways, there are still important differences, mainly due to restrictions that have been put in place by Microsoft to ensure security in a multi-tenant platform such as Azure. Here are some key ones:

Azure VNet does not support Layer-2 semantics (Only Layer-3 and Layer-4). This means that concepts such as virtual LANs (vLANs) and Layer-2 broadcasts don’t work in Azure VNet. Figure 1.1 shows the output of running the arp -a command on a VM that is deployed in Azure VNet. You will notice that the MAC address resolution for VMs in the same subnet results in the same 12:34:56:78:9a:bc value. This is because we are on a shared platform and the VNet is a Layer-3 overlay instead of Layer-2:

Figure 1.1 – ARP table on an Azure VM

Another key difference between a traditional network and Azure VNet is that some protocols and communication types are restricted from being used in Azure VNet. Protocols such as multicast, broadcast, DHCP unicast, UDP source port 65330, IP-in-IP encapsulated packets, and Generic Routing Encapsulation (GRE) packets are not allowed in Azure VNet. Any application or service capability that requires these protocols or communication types will need to be refactored before deployment into Azure VNet for it to work. The only protocols that are allowed are TCP, UDP, ICMP, and Unicast communication (except source port UDP/68 /, destination port UDP/67, and UDP source port 65330, which is reserved for the host).

Note

For more information on the differences of Azure VNet and traditional networks, refer to the document at https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq.

Now that you have some fundamental information on what Azure VNet is, let’s discuss how you would go about planning one, starting with considerations around naming it.

Planning Vnet naming

All Azure resources have a name that must be unique within a scope. The scope is different for each resource type. When creating a Vnet, its name must be unique within the scope of the resource group. This means that it is possible to have two Vnets in your Azure subscription with the same name as long as they don’t belong to the same resource group! This can be useful in a design that involves having the same Vnet resource name for both development and production environments, as shown in Figure 1.2.

Figure 1.2 – Vnet names must be unique for the resource group scope

Even though it is possible to have duplicate names within a subscription, it is not a recommended practice as it could later lead to confusion when investigating security incidents using logging information (we will cover network logging and monitoring later in this book). When investigating security incidents, it helps to be able to quickly identify affected resources and having a unique resource naming strategy for your Vnets helps with this.

Regarding naming best practices, it is best to define a naming convention as early as possible. This convention should be communicated to the teams with permission to create network resources in Azure, and preferably, the naming convention should be enforced using tools such as Azure Policy. To define a good naming strategy, consider these recommendations:

Review resource name restrictions for the Vnet and other network resources in Azure. For example, a Vnet name can have up to 64 characters made up of alphanumerics, underscores, periods, and hyphens. Your naming convention should take this into consideration. Information on Vnet naming restrictions can be found at https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules#microsoftnetwork.Consider including information about the following – resource type, resource location, deployment environment, and workload type in your naming convention. For example, a Vnet for production web services workloads in the East US region might be named prod-eastus-webservices-Vnet (Figure 1.3).

Figure 1.3 – Sample Vnet naming convention

For more thoughts on naming conventions, please refer to this document: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming.

Planning VNet location

Almost all Azure services are created in a regional location specified at creation time. I said almost all because there are some exceptions – so-called global or non-regional services that are not pinned to a region. Azure Vnet is a regional service.

As of the time of writing (April 2022), the Azure cloud has 55 active regions in which we can create Vnets (with nineteen announced regions coming soon).

So, which regions should you select when creating Vnets? Consider the following three points to guide your decision regarding this:

Business compliance requirements: This is the first point that you should consider when deciding the Azure region to locate your Vnets in. If there are organizational/industry compliance requirements that require data residency or data sovereignty in a geographic area, then you must adhere to that! You don’t want to end up in a situation where your organization is fined or charged for violating governmental regulations! For example, if you are providing services to a US government agency, the workloads that you are using to provide those services may be required to be in Vnets created in one of the Azure US government regions.Proximity to the users: This is the second key point to consider regarding Vnet location. You want your networks in locations close to the end users to ensure the lowest network latency. For example, if your organization is based in the UK and your network will host workloads that will provide services to your customers in the area, it will probably be best to create your Vnet(s) in either the UK South or the UK West Azure regions. You could perform your own tests to determine latency information for your end users or you could leverage unofficial sites such as https://azurespeedtest.azurewebsites.net/and https://cloudpingtest.com/azure.Resiliency requirements: This is another key point to consider when deciding where you should create your Vnets. Does your resiliency architecture require you to be able to distribute your network workloads in multiple data centers within the same region? If it does, then you need to select one of the regions that allow you to use availability zones (AZs) – distinct groups of data centers in the same region. Not all Azure regions currently support this capability. At the time of writing, only 25 of the 55 active regions support AZs. I will recommend checking this document for an up-to-date list before you create your network resources – https://docs.microsoft.com/en-us/azure/availability-zones/az-overview.

The following diagram shows an example of a Vnet with AZs:

Figure 1.4 – A Vnet with AZs

Also, keep in mind that the decision to distribute your network workloads in multiple AZs in a region results in an extra cost of 0.01 USD (0.008 GBP) per gigabyte of data transferred between AZs for both inbound and outbound traffic.

Planning Vnet IP address spaces

Every Vnet must have at least one IP address space assignment. A Vnet space assignment can either be single-stack (IPv4 address space only) or dual-stack (IPv4 and IPv6 address spaces). At the time of writing, an IPv6-only Vnet is not supported! You might be able to create an IPv6-only Vnet in the portal, but you will not be able to attach a virtual network interface card (NIC) to it. Attempting it will result in the error message shown in Figure 1.5:

Figure 1.5 – Your Vnet must have at least one IPv4 address space to use IPv6

Note

Azure does not yet support an IPv6-only Vnet and subnet, but you can implement dual-stack Vnets and subnets that support both IPv4 and IPv6.

Azure VNet is not limited to one IP address space assignment. We can add more IP address spaces as needed, which is great for scalability! For example, we may want to add an additional IPv4 address space to support an unexpected workload expansion.

Limitation

Regardless of how many addresses are contained in the IP address spaces assigned to a Vnet, the total number of private IP addresses assigned to workloads cannot exceed 65,536.

The IP address spaces assigned to a Vnet do not have to be contiguous. Figure 1.6 shows an example of this with a Vnet that is configured to have two IPv4 address spaces that are not contiguous – 10.1.0.0/16 and 192.168.1.0/24 and an additional IPv6 address space for a dual-stack implementation – fd00:db8:deca::/48.

Figure 1.6 – A Vnet with multiple address spaces

So, which IP address spaces should we use for our Vnets in Azure? Even though it is not required, it is highly recommended to use address ranges within the private, non-internet routable address spaces! For IPv4, this will be one of the IP ranges defined in RFC 1918 and for IPv6, this will be the Internet Engineering Task Force (IETF) defined Unique Local Addresses, which use the fc00::/7address range.

RFC 1918 private IPv4 address ranges

Private IP address ranges defined in RFC 1918 are IP ranges that have been set aside by the IETF for private network use. They include the following:

•10.0.0.0/8 (10.0.0.0 – 10.255.255.255)

•172.16.0.0/12 (172.16.0.0 – 172.31.255.255)

•192.168.0.0/16 (192.168.0.0 – 192.168.255.255)

Using any of the RFC 1918 private IP address ranges will require some form of address translation for internet routing and connectivity (we will cover this scenario later in this book).

Shared IPv4 address spaces reserved in RFC 6598 can also be used as they are treated as private IP address spaces in Azure. This range includes the following:

100.64/10 (100.64.0.0 – 100.127.255.255)

Other IP address spaces may work but they are not recommended as they could have undesirable routing side effects with instability! The following address ranges are not allowed to be used as Vnet IP address spaces:

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)

Whatever IP address ranges you decide to use for your Vnets, it is highly recommended to plan for non-overlapping IP address spaces across Azure regions and on-premises locations in advance. You can achieve this by defining an organization-wide IP address scheme that ensures that each network has its own unique private IP address space if it is an Azure network or an on-premises network.

Best practice

Define an organization-wide IP address scheme that ensures that each organization network has its own unique private IP address space.

One of the reasons why this is important is that it can impact your ability to connect networks together later or leave you in a situation where you need to implement sub-optimal network address translations that add to the complexity.

For example, you cannot connect two Vnets together via Vnet peering if they have the same address space! Figure 1.7 shows the error message that you will get if you attempt this:

Figure 1.7 – Vnets with overlapping address spaces cannot be peered

If you don’t know what Vnet peering is, don’t worry, we will cover it later in this book when we look at hybrid connectivity. You could use a VPN gateway to connect two networks with the same IP address spaces but this requires implementing address translation, which can make troubleshooting traffic flow very complex!

Planning Vnet subnet segmentation

To provide isolation within a Vnet, we can divide it into one or more subnets. Subnets are primarily used for workload segmentation (logical perimeters within a Vnet). Figure 1.8 shows an example of this. In the diagram, we have a Vnet with two subnets. Web services are deployed into their own subnet (Web tier Subnet) and data services are deployed into their own subnet (Data tier Subnet).

With this approach, we can use an Azure route table to control how traffic is routed between the subnets. We can also use a network security group (NSG) or a network virtual appliance (NVA) to define allowed inbound/outbound traffic flow from/to the subnets (segments). The result of this is that if a part of our application stack is compromised, we are better placed to contain the impact of the security breach and mitigate the risk of lateral movement through the rest of our network. This is an important Zero Trust principle implementation. We will cover route tables, NSGs, and NVAs later in this book.

Figure 1.8 – Segmentation using subnets

How many subnets can Azure VNet have? It can have up to 3,000 subnets! Each subnet must have a unique IP address range that is within the defined IP address spaces of the Vnet (overlap is not allowed). For example, a Vnet with an IPv4 address space of 10.1.0.0/16 cannot have a subnet with an IP address range of 10.1.1.0/24 and another subnet with an address range of 10.1.1.0/25 as these ranges overlap with each other. Attempting to do so will result in the error message shown in Figure 1.9:

Figure 1.9 – Subnets with overlapping addresses not allowed

After defining the IP address range for a subnet, Azure reserves five IP addresses within each subnet that can’t be used! The first four IP addresses and the last IP address in an Azure subnet cannot be allocated to resources for the following reasons:

x.x.x.<first address>: This is reserved for protocol conformance as the network addressx.x.x. <second address>: This is reserved by Azure for the default gateway of the subnetx.x.x. <third address> and x.x.x. <fourth address>: This is reserved by Azure to map the Azure DNS IPs to the Vnet spacex.x.x. <last address>: This is reserved for protocol conformance as the broadcast address (even though Azure Vnets don’t use broadcasts as we mentioned earlier)

For example, if the IP address range of your subnet is 10.1.0.0/24, the following addresses will be reserved:

10.1.0.0: Network address10.1.0.1: Default gateway address10.1.0.2 and 10.1.0.3: Used to map Azure DNS IPs to the Vnet space10.1.0.255: Broadcast address

This leaves a total of 250 addresses that can be allocated to subnet resources: 10.1.0.4 – 10.1.0.254. Because of the required address reservation, the smallest supported IPv4 address prefix is /29, which gives five reserved addresses and three usable addresses. Specifying anything less leaves zero usable IPv4 addresses, which results in the error message shown in Figure 1.10:

Figure 1.10 – The smallest supported IPv4 address prefix for a subnet is /29

Note

The smallest supported size for an Azure IPv4 subnet is /29. The largest is /2.

If you are implementing a dual-stack design, the standard size of the assigned IPv6 address space should be /64. This is in line with the standard defined by the IETF. A /64 space is the smallest subnet that can be used locally if auto-configuration is desired. Any attempt to add an IPv6 address space that is not a /64 will result in the error message shown in Figure 1.11:

Figure 1.11 – Only a /64 address space assignment allowed for a subnet

When planning your subnets, make sure that you design for scalability. Workloads in your subnets should not cover the entire address space, giving you no room to add more workloads if needed. Plan and reserve some address space for the future. Also, take into consideration that some network resources such as the VMSS may need to dynamically add more workloads based on incoming requests. Modifying the IP address range of an Azure subnet that has workloads deployed is no straightforward task. It involves you removing all existing resources! Attempting this will result in the error message shown in Figure 1.12:

Figure 1.12 – The error message when trying to resize a subnet with resources

Working with platform services in subnets

For most organizations, the main services that they will deploy into Azure VNet subnets are infrastructure-as-a-service (IaaS) services such as VMs and VMSSs but there are currently about 23 more services that can be deployed into a Vnet subnet, including platform services such as Azure SQL Managed Instance, App Service, Cache for Redis, and Azure Kubernetes Service. Deploying a supported platform service into a Vnet subnet is referred to as Vnet integration or Vnet injection.

A full list of services that are supported for VNet integration can be found at https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-for-azure-services#services-that-can-be-deployed-into-a-virtual-network.

There are about 25 services that can be deployed into a Vnet subnet, as shown in Figure 1.13:

Figure 1.13 – Various types of services supported for Vnet integration

Most PaaS services that support Vnet integration impose restrictions on the subnets that they can be deployed into, and this should be considered when planning your subnets. Here are some of the restrictions to consider:

About 14 services require a dedicated subnet — this means that they cannot be combined with other services in the same subnet. For example, a VPN gateway cannot be deployed together with another service in the same subnet – the subnet must be dedicated only to that service!Still, on dedicated subnets, some services allow multiple instances of the same service in the same dedicated subnet while some require a dedicated subnet per service instance! For example, the Azure SQL Managed Instance’s service allows multiple instances of the same service to be deployed into the dedicated subnet (Figure 1.14), while the Azure Spring Cloud service requires dedicated subnets per service instance (Figure 1.14):

Figure 1.14 – Two SQL-managed instances in the same dedicated subnet. Spring cloud requires dedicated subnets per instance

Some platform services require their subnets to be called a specific name. For example, the subnet that the Azure Firewall service is deployed into must be called AzureFirewallSubnet, the subnet that the VPN Gateway service is deployed into must be called GatewaySubnet, and the subnet that the Azure Bastion service is deployed into must be called AzureBastionSubnet. This is required for some automation components relating to the services to work.Some platform services require a minimum Classless Inter-Domain Routing (CIDR) block for their subnets. For example, the subnet that the Azure Bastion service is deployed into must have a minimum /26 prefix.Some platform services require permissions to establish basic network configuration rules for the subnet that they will be deployed into. The process of assigning this permission is called subnet delegation. For example, when a SQL-managed instance is deployed into a subnet, it automatically creates an NSG and a route table and applies them to that subnet.

The key takeaway here is this – before deploying platform services into subnets, ensure that you follow the guidance in the service documentation regarding the aforementioned considerations to avoid inconsistencies in service functionalities. Always refer to the documentation for up-to-date information: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-for-azure-services#services-that-can-be-deployed-into-a-virtual-network.

Now that you have some understanding of how to plan key aspects of Azure VNet, let us go ahead and get some implementation going!

Hands-on exercise – creating a single-stack VNet in Azure

In this exercise, we will create a single-stack IPv4 network for a fictional organization called CharisTech, which is in the process of migrating some on-premises applications to Azure. We will implement two VNets and subnets to support workloads that will be migrated. Here are the tasks that we will complete in this exercise:

Task 1: Creating the CharisTech resource groupTask 2: Creating the CoreServicesVNet VNet and subnetsTask 3: Verifying the creation of VNets and subnets

Figure 1.15 shows the outcome that we’ll get to at the end of the tasks:

Figure 1.15 – CharisTech Azure VNets and subnets

Task 1 – creating the CharisTech resource group

A resource group is a logical container for managing related Azure resources. In this task, we will create a resource group called CharisTechRG that will hold the networking resources that we will create in other tasks:

Open a web browser and browse to https://portal.azure.com.On the left-hand side, click on the portal menu icon, then click on Create a resource:

Figure 1.16 – Create a resource

In the search area, type Resource group and press Enter. Click on the Create button:

Figure 1.17 – Create a resource group

In the Basics tab, enter the following values:Subscription: Select your Azure subscription (1)Resource group: CharisTechRG (2)Region: East US (3)

Then, select Review + create (4):

Figure 1.18 – Creating a resource group

Select Create. It should only take a few seconds to create the resource group.In the top-right corner of the window, select the notification icon (the bell icon). Then, select Go to resource group to open the newly created resource group:

Figure 1.19 – Opening the newly created resource group

Leave this window open for the next task. Now that we have a resource group that we can use as a management container, let us proceed to create the VNets and subnets.

Task 2 – creating the CoreServicesVNet VNet and subnets

The first network that we will create is the CoreServicesVNet VNet (Figure 1.15). The network will be deployed in the East US region. It will be segmented into three subnets that will host the following workloads:

Public web services (PublicWebServiceSubnet)Databases (DatabaseSubnet)Shared services that are key to the operations of the business, such as domain controllers (SharedServicesSubnet)

Let’s get started:

In the CharisTechRG window, select + Create. In the search box, enter Virtual Network. Select Virtual Network in the search results:

Figure 1.20 – Creating a resource

On the Virtual Network page, select Create.On the Create virtual network window, in the Basics tab, enter the following values:Subscription: Select your Azure subscriptionResource group: CharisTechRGName: CoreServicesVNetRegion: East US

Then, click Next: IP Addresses >:

Figure 1.21 – Creating the VNet

In the IP Addresses tab, change the default IP address space to 10.10.0.0/16. Then, select + Add subnet:

Figure 1.22 – Setting the IP address

In the Add subnet window, configure the following:Subnet name: SharedServicesSubnetSubnet address range: 10.10.1.0/24NAT gateway: NoneService endpoint: 0 selected

Then, click Add:

Figure 1.23 – Adding a subnet

Click on + Add subnet and repeat Step 5 to add the following subnet configurations:

Subnet

Configuration option

Configuration value

DatabaseSubnet

Subnet name

DatabaseSubnet

Subnet address range

10.10.2.0/24

PublicWebServiceSubnet

Subnet name

PublicWebServiceSubnet

Subnet address range

10.10.3.0/24

Table 1.1 – Subnet configuration details

7. The configuration should look like Figure 1.24. Click on Review + create:

Figure 1.24 – Subnets added to the VNet configuration

8. Select Create. It should only take a few seconds to create the VNet and subnets.

Awesome! After the deployment completes, let us review what has been created.

Task 3 – verifying the creation of the VNet and subnets

In this task, we will review the resources created in the last task:

Click on Go to resource to open the newly created VNet:

Figure 1.25 –Microsoft VNet overview

In the CoreServicesVNet virtual network blade, in the Settings section, click on Subnets to review the subnets that were created:

Figure 1.26 – Reviewing the subnets

You can leave this window open for the next task. Now that we have a resource group that we can use as a management container, let us proceed to create the VNets and subnets.

Hands-on exercise – creating a dual-stack VNet in Azure

In this exercise, we will create a dual-stack network in Azure that supports both IPv4 and IPv6 for the fictional organization called CharisTech. The activities in this task will be completed using the Azure CLI to give you familiarity with the different Azure management tools. Here are the tasks that we will complete in this exercise:

Task 1: Creating the dual-stack EngineeringVNet VNet and subnetsTask 2: Verifying the creation of the dual-stack VNet and subnets

Figure 1.27 shows the outcome that we’ll get to at the end of the tasks:

Figure 1.27 – CharisTech Azure VNets and subnets

Let’s get started!

Task 1 – creating the dual-stack EngineeringVNet VNet and subnets

Open a web browser and go to the Azure Portal at https://portal.azure.com. Sign in with your admin user account credentials.In the Azure Portal, click on the Cloud Shell icon in the top right corner of the Azure Portal:

Figure 1.28 – Click the icon to open Cloud Shell

(Optional) If this is your first time launching Cloud Shell, you will be prompted to select between the Bash and PowerShell environments. Select Bash. You will also be prompted to create a storage account that will be used by Cloud Shell. Select Create Storage.If this is not your first launch, ensure you have Bash selected for your environment:

Figure 1.29 – Select the Bash shell environment

In Cloud Shell, enter the following commands to set the values that we will use for the following variables: resource group, location, and VNet:group=CharisTechRGlocation=westusVNet=EngineeringVNetCreate a VNet with the az network VNet create command. The following command creates a VNet named EngineeringVNet with one subnet named EngSubnet1. Both the VNet and the subnet are dual-stack:az network VNet create --name $VNet --resource-group $group --location $location --address-prefixes "10.20.0.0/16" "fd00:db8:deca::/48" --subnet-name EngSubnet1 --subnet-prefix "10.20.1.0/24" "fd00:db8:deca:1::/64"Add a second subnet with the az network VNet subnet create command. The following command adds a dual-stack subnet named EngSubnet2 to the EngineeringVNet network that we created earlier:az network VNet subnet create -n EngSubnet2 --address-prefixes "10.20.2.0/24" "fd00:db8:deca:2::/64" --resource-group $group --VNet-name $VNet

Now that the dual-stack VNets and subnets are created, let us verify them.

Task 2 – verifying the creation of the dual-stack VNet and subnets

Let’s get started!

In the Cloud Shell environment, enter the following command to list the VNets in the subscription and output the result in a table format:az network VNet list --resource-group CharisTechRG --output table

The output should be like the output shown in Figure 1.30:

Figure 1.30 – The VNet list output

As you can see, using command-line management tools such as the Azure CLI greatly streamlines resource management in Azure!

Understanding private IP address assignment for subnet workloads

When resources are deployed into an Azure VNet subnet, a private IP address is automatically assigned from the subnet’s