Wednesday, 24 July 2024

Azure networking services overview

 

Azure networking services overview

  • Networking foundation: Azure networking foundation services provide core connectivity for your resources in Azure - Virtual Network (VNet), Private Link, Azure DNS, Azure Virtual Network Manager, Azure Bastion, Route Server, NAT Gateway, Traffic Manager, Azure Network Watcher, and Azure Monitor.
  • Load balancing and content delivery: Azure load balancing and content delivery services allow for management, distribution, and optimization of your applications and workloads - Load balancer, Application Gateway, and Azure Front Door.
  • Hybrid connectivity: Azure hybrid connectivity services secure communication to and from your resources in Azure - VPN Gateway, ExpressRoute, Virtual WAN, and Peering Service.
  • Network security: Azure network security services protect your web applications and IaaS services from DDoS attacks and malicious actors - Firewall Manager, Firewall, Web Application Firewall, and DDoS Protection.

Networking foundation

This section describes services that provide the building blocks for designing and architecting a network environment in Azure - Virtual Network (VNet), Private Link, Azure DNS, Azure Virtual Network Manager, Azure Bastion, Route Server, NAT Gateway, Traffic Manager, Azure Network Watcher, and Azure Monitor.

Virtual network

Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. You can use VNets to:

  • Communicate between Azure resources: You can deploy virtual machines, and several other types of Azure resources to a virtual network, such as Azure App Service Environments, the Azure Kubernetes Service (AKS), and Azure Virtual Machine Scale Sets. To view a complete list of Azure resources that you can deploy into a virtual network, see Virtual network service integration.
  • Communicate between each other: You can connect virtual networks to each other, enabling resources in either virtual network to communicate with each other, using virtual network peering or Azure Virtual Network Manager. The virtual networks you connect can be in the same, or different, Azure regions. For more information, see Virtual network peering and Azure Virtual Network Manager.
  • Communicate to the internet: All resources in a virtual network 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 addresses or public Load Balancer to manage your outbound connections.
  • Communicate with on-premises networks: You can connect your on-premises computers and networks to a virtual network using VPN Gateway or ExpressRoute.
  • Encrypt traffic between resources: You can use Virtual network encryption to encrypt traffic between resources in a virtual network.

Network security groups

You can filter network traffic to and from Azure resources in an Azure virtual network with a network security group. For more information, see Network security groups.

Service endpoints

Virtual Network (VNet) service endpoints extend your virtual network private address space and the identity of your virtual network to the Azure services, over a direct connection. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Traffic from your virtual network to the Azure service always remains on the Microsoft Azure backbone network.

Diagram of virtual network service endpoints.

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. Traffic between your virtual network and the service travels through the Microsoft backbone network. Exposing your service to the public internet is no longer necessary. You can create your own private link service in your virtual network and deliver it to your customers.

Screenshot of private endpoint overview.

Azure DNS

Azure DNS provides DNS hosting and resolution using the Microsoft Azure infrastructure. Azure DNS consists of three services:

  • Azure Public DNS is a hosting service for DNS domains. By hosting your domains in Azure, you can manage your DNS records by using the same credentials, APIs, tools, and billing as your other Azure services.
  • Azure Private DNS is a DNS service for your virtual networks. Azure Private DNS manages and resolves domain names in the virtual network without the need to configure a custom DNS solution.
  • Azure DNS Private Resolver is a service that enables you to query Azure DNS private zones from an on-premises environment and vice versa without deploying VM based DNS servers.

Using Azure DNS, you can host and resolve public domains, manage DNS resolution in your virtual networks, and enable name resolution between Azure and your on-premises resources.

Azure Virtual Network Manager

Azure Virtual Network Manager is a management service that enables you to group, configure, deploy, and manage virtual networks globally across subscriptions. With Virtual Network Manager, you can define network groups to identify and logically segment your virtual networks. Then you can determine the connectivity and security configurations you want and apply them across all the selected virtual networks in network groups at once.

Diagram of resources deployed for a mesh virtual network topology with Azure virtual network manager.

Azure Bastion

Azure Bastion is a service that you can deploy in a virtual network to allow you to connect to a virtual machine using your browser and the Azure portal. You can also connect using the native SSH or RDP client already installed on your local computer. The Azure Bastion service is a fully platform-managed PaaS service that you deploy inside your virtual network. It provides secure and seamless RDP/SSH connectivity to your virtual machines directly from the Azure portal over TLS. When you connect via Azure Bastion, your virtual machines don't need a public IP address, agent, or special client software. There are various different SKU/tiers available for Azure Bastion. The tier you select affects the features that are available. For more information, see About Bastion configuration settings.

Diagram showing Azure Bastion architecture.

Route Server

Azure Route Server simplifies dynamic routing between your network virtual appliance (NVA) and your virtual network. It allows you to exchange routing information directly through Border Gateway Protocol (BGP) routing protocol between any NVA that supports the BGP routing protocol and the Azure Software Defined Network (SDN) in the Azure Virtual Network (VNet) without the need to manually configure or maintain route tables.

NAT Gateway

Virtual Network NAT(network address translation) simplifies outbound-only Internet connectivity for virtual networks. When configured on a subnet, all outbound connectivity uses your specified static public IP addresses. Outbound connectivity is possible without load balancer or public IP addresses directly attached to virtual machines. For more information, see What is Azure NAT gateway?

Diagram of virtual network NAT gateway.

Traffic Manager

Azure Traffic Manager is a DNS-based traffic load balancer that enables you to distribute traffic optimally to services across global Azure regions, while providing high availability and responsiveness. Traffic Manager provides a range of traffic-routing methods to distribute traffic such as priority, weighted, performance, geographic, multi-value, or subnet.

The following diagram shows endpoint priority-based routing with Traffic Manager:

Diagram of Azure Traffic Manager 'Priority' traffic-routing method.

For more information about Traffic Manager, see What is Azure Traffic Manager?.

Azure Network Watcher

Azure Network Watcher provides tools to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network.

Azure Monitor

Azure Monitor maximizes the availability and performance of your applications by delivering a comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments. It helps you understand how your applications are performing and proactively identifies issues affecting them and the resources they depend on.

Load balancing and content delivery

This section describes networking services in Azure that help deliver applications and workloads - Load Balancer, Application Gateway, and Azure Front Door Service.

Load Balancer

Azure Load Balancer provides high-performance, low-latency Layer 4 load-balancing for all UDP and TCP protocols. It manages inbound and outbound connections. You can configure public and internal load-balanced endpoints. You can define rules to map inbound connections to back-end pool destinations by using TCP and HTTP health-probing options to manage service availability.

Azure Load Balancer is available in Standard, Regional, and Gateway SKUs.

The following picture shows an Internet-facing multi-tier application that utilizes both external and internal load balancers:

Screenshot of Azure Load Balancer example.

Application Gateway

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. It's an Application Delivery Controller (ADC) as a service, offering various layer 7 load-balancing capabilities for your applications.

The following diagram shows url path-based routing with Application Gateway.

Image of Application Gateway example.

Azure Front Door

Azure Front Door enables you to define, manage, and monitor the global routing for your web traffic by optimizing for best performance and instant global failover for high availability. With Front Door, you can transform your global (multi-region) consumer and enterprise applications into robust, high-performance personalized modern applications, APIs, and content that reach a global audience with Azure.

Diagram of Azure Front Door service with Web Application Firewall.

Hybrid connectivity

This section describes network connectivity services that provide a secure communication between your on-premises network and Azure - VPN Gateway, ExpressRoute, Virtual WAN, and Peering Service.

VPN Gateway

VPN Gateway helps you create encrypted cross-premises connections to your virtual network from on-premises locations, or create encrypted connections between VNets. There are different configurations available for VPN Gateway connections. Some of the main features include:

  • Site-to-site VPN connectivity
  • Point-to-site VPN connectivity
  • VNet-to-VNet VPN connectivity

The following diagram illustrates multiple site-to-site VPN connections to the same virtual network. To view more connection diagrams, see VPN Gateway - design.

Diagram showing multiple site-to-site Azure VPN Gateway connections.

ExpressRoute

ExpressRoute enables you to extend your on-premises networks into the Microsoft cloud over a private connection facilitated by a connectivity provider. This connection is private. Traffic doesn't go over the internet. With ExpressRoute, you can establish connections to Microsoft cloud services, such as Microsoft Azure, Microsoft 365, and Dynamics 365.

Screenshot of Azure ExpressRoute.

Virtual WAN

Azure Virtual WAN is a networking service that brings many networking, security, and routing functionalities together to provide a single operational interface. Connectivity to Azure VNets is established by using virtual network connections. Some of the main features include:

  • Branch connectivity (via connectivity automation from Virtual WAN Partner devices such as SD-WAN or VPN CPE)
  • Site-to-site VPN connectivity
  • Remote user VPN connectivity (point-to-site)
  • Private connectivity (ExpressRoute)
  • Intra-cloud connectivity (transitive connectivity for virtual networks)
  • VPN ExpressRoute inter-connectivity
  • Routing, Azure Firewall, and encryption for private connectivity

Virtual WAN diagram.

Peering Service

Azure Peering Service enhances customer connectivity to Microsoft cloud services such as Microsoft 365, Dynamics 365, software as a service (SaaS) services, Azure, or any Microsoft services accessible via the public internet.

This section describes networking services in Azure that help protect your network resources - Protect your applications using any or a combination of these networking services in Azure - DDoS protection, Private Link, Firewall, Web Application Firewall, Network Security Groups, and Virtual Network Service Endpoints.

Network security

This section describes networking services in Azure that protects and monitor your network resources - Firewall Manager, Firewall, Web Application Firewall, and DDoS Protection.

Firewall Manager

Azure Firewall Manager is a security management service that provides central security policy and routing management for cloud based security perimeters. Firewall manager can provide security management for two different types of network architecture: secure virtual hub and hub virtual network. With Azure Firewall Manager, you can deploy multiple Azure Firewall instances across Azure regions and subscriptions, implement DDoS protection plans, manage web application firewall policies, and integrate with partner security-as-a-service for enhanced security.

Diagram of multiple Azure Firewalls in a secure virtual hub and hub virtual network.

Azure Firewall

Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. Using Azure Firewall, you can centrally create, enforce, and log application and network connectivity policies across subscriptions and virtual networks. Azure Firewall uses a static public IP address for your virtual network resources allowing outside firewalls to identify traffic originating from your virtual network.

Diagram of Firewall overview.

Web Application Firewall

Azure Web Application Firewall (WAF) provides protection to your web applications from common web exploits and vulnerabilities such as SQL injection, and cross site scripting. Azure WAF provides out of box protection from OWASP top 10 vulnerabilities via managed rules. Additionally customers can also configure custom rules, which are customer managed rules to provide extra protection based on source IP range, and request attributes such as headers, cookies, form data fields, or query string parameters.

Customers can choose to deploy Azure WAF with Application Gateway, which provides regional protection to entities in public and private address space. Customers can also choose to deploy Azure WAF with Front Door which provides protection at the network edge to public endpoints.

Screenshot of Web Application Firewall.

DDoS Protection

Azure DDoS Protection provides countermeasures against the most sophisticated DDoS threats. The service provides enhanced DDoS mitigation capabilities for your application and resources deployed in your virtual networks. Additionally, customers using Azure DDoS Protection have access to DDoS Rapid Response support to engage DDoS experts during an active attack.

Azure DDoS Protection consists of two tiers:

  • DDoS Network Protection, combined with application design best practices, provides enhanced DDoS mitigation features to defend against DDoS attacks. It's automatically tuned to help protect your specific Azure resources in a virtual network.
  • DDoS IP Protection is a pay-per-protected IP model. DDoS IP Protection contains the same core engineering features as DDoS Network Protection, but differs in the following value-added services: DDoS rapid response support, cost protection, and discounts on WAF.

Diagram of the reference architecture for a DDoS protected PaaS web application.

Create Azure network connection

 

Create Azure network connection

You can have up to 10 ANCs per tenant.

As part of the connection process, the Windows 365 service is granted the following permissions:

  • Reader permission on the Azure subscription.
  • Windows 365 Network Interface Contributor role on the specified resource group.
  • Windows 365 Network User role on the virtual network.

Requirements

To create an ANC, you must meet these requirements:

  • Have the Intune Administrator or Windows 365 Administrator role.
  • Have an Active Directory user account with sufficient permissions to join the AD domain into this Organizational Unit (hybrid Microsoft Entra join ANCs only).
  • Have the Subscription Reader role in the Azure Subscription where the VNET associated with the ANC was located.
  • If you want to create an ANC with a network or resource group that was never used in any pervious ANC creation, then you must have the Subscription owner or user administrator role.
  • For Disaster Recovery (DR) purposes, make sure that there are at least 50% of the IP addresses available in your subnet. If reprovisioning for DR is required, sufficient new IP addresses are required for each Cloud PC provisioned on the subnet.
  • For Windows 365 Government - GCC only and not GCC-H - make sure to complete the script options listed in Set up tenants for Windows 365 Government.
    • If you aren't using Azure CloudShell, make sure that your PowerShell execution policy is configured to allow Unrestricted scripts. If you use Group Policy to set execution policy, make sure that the Group Policy Object (GPO) targeted at the Organizational Unit (OU) defined in the ANC is configured to allow Unrestricted scripts. For more information, see Set-ExecutionPolicy.

When planning your ANC VNets with ExpressRoute as the on-premises connectivity model, refer to Azure’s documentation on VM limits. For the ExpressRoute Gateway SKU, make sure that you have the correct sized Gateway for the number of Cloud PCs planned within the VNet. Exceeding this limit could cause instability in your connectivity.


Create an ANC

  1. Sign in to the Microsoft Intune admin center, select Devices > Windows 365 (under Provisioning) > Azure network connection > Create.

  2. Depending on the type of ANC you want to create, choose Microsoft Entra Join or Hybrid Microsoft Entra Join.

    Screenshot of create connection dropdown

  3. On the Network details page, enter a Name for the new connection. The connection name must be unique within the customer tenant.

    Screenshot of Name field

  4. Select a Subscription and Resource group for the new connection. Create a new resource group to contain your Cloud PC resources. Optionally, you can instead select an existing resource group in the list (which grant Windows 365 permissions to the existing resource group). If you don’t have a healthy ANC, you won't be able to proceed.

  5. Select a Virtual network and Subnet.

  6. Select Next.

  7. For hybrid Microsoft Entra join ANCs, on the AD domain page, provide the following information:

    • AD domain name: The DNS name of the Active Directory domain that you want to use for connecting and provisioning Cloud PCs. For example, corp.contoso.com.

       Note

      If your on-premises Active Directory environment has more than one domain or parent-child domains, be sure to enter the specific domain in which the Cloud PCs need to be domain joined.

    • Organizational unit: (Optional.) An organizational unit (OU) is a container within an Active Directory domain, which can hold users, groups, and computers. Make sure that this OU is enabled to sync with Microsoft Entra Connect. Provisioning fails if this OU isn't syncing.

    • AD domain username: The username, in user principal name (UPN) format, that you want to use for connecting the Cloud PCs to your Active Directory domain. For example, svcDomainJoin@corp.contoso.com. This service account must have permission to join computers to the domain and, if set, the target OU.

    • AD domain password: The password for the user.

    • Confirm AD domain password: The password for the user.

Getting started with Microsoft DevBox

 

Getting started with Microsoft DevBox

Earlier today, Microsoft released DevBox into Public Preview (which is a feature that was announced at Microsoft build earlier this summer. Microsoft DevBox can be seen as an alternative to Windows 365 and Azure Virtual Desktop but is aimed at Developers, as it is still about providing developers with a VDI desktop in Azure running their software development stack.

You can see this by just seeing the resource underneath and also the references in Azure Monitor when deploying the resources

From an operations perspective, it is a combination of the Windows 365 front-end portal (https://devbox.microsoft.com/) where Developers gain access to a self-service front-end to their virtual machines, and the RDS components of Azure Virtual Desktop, which means that it is running much of the same core components underneath.

Now to set it up you need to understand some of the core concepts of the service.

You first have a resource called DevCenter which is a logical container for all other resources in DevBox. The DevCenter contains Network Connections which are essentially two things 1: VNET Integration 2: Machine configuration if it is either domain joined or Azure AD joined.

Within a DevCenter you can have one more multiple network connections. Then you have DevBox definitions which contains built-in Microsoft Images where you define the size of the machines. Lastly is compute galleries which can contain your custom images.

Then you can group together a Network Connection with a DevBox definition or Compute Gallery which are grouped together into a DevBox Pool which is deployed into a Project.

So can have a project which contains multiple DevBox Pools that can be grouped together into a single project.

NOTE: Before setting up the service you might encounter some issues with deployment, if so you need to register a new resource provider (EDIT: Has been fixed by Microsoft: Issue with provisioning network connection · Issue #97119 · MicrosoftDocs/azure-docs (github.com))

az provider register --namespace Microsoft.DevCenter

First we need to create the DevCenter Resource.

Here we have some different options that we need to configure to make this work

  • Networking Connections
  • DevBox definitions or Azure compute Galleries

Then we can create DevBox Definition using built-in images. Here we can define the Compute and images to use from the Microsoft Gallery.

Then we need to create a Network Connection, where we define which virtual network we should use and what kind of domain join we should have for resources that will be using this network connection.

Then once this is done provisioning we need to attach the network connection to the DevCenter resource. Once you add a network connection, Microsoft will do some healthchecks to ensure that it working as intended.

Now we have a Dev Box Definition and Network Connection the last part we need to do is create a project which will use both of those. Create a project and within the project resource click on create a dev box pool.

Here we define a name, privileges (local user or admin) then Dev Box definition and network connections.

Once this Dev Box pool is created (which can take some time) you need to assign permissions to the Project or else users will be seeing this error message once they try and access the end-user portal.

On the project level you can assign either Dev Box User or Project Admin permissions. Assigning Dev Box User will allow the developers to setup their own machine using the web portal.

Once the Dev Box role permissions are assigned, the users can access the portal on https://devbox.microsoft.com/

So far being a preview it seems to be pretty solid and I like the way that they design the product, however there are some caveats that I would like for them to approve.

Introducing Microsoft Dev Box

 Introducing Microsoft Dev Box

You can sign up for the waiting list to evaluate the private preview at http://aka.ms/devbox-signup and to see demos of the service watch the Build session, Delivering developer velocity through the entire engineering system.  

 

Transforming the developer workstation

thumbnail image 1 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Introducing Microsoft Dev Box

Contemporary dev workstations come with a plethora of challenges. New developers can spend days setting up a working environment and weeks before they make their first commit. Senior developers often work across multiple projects that can bring conflicting dependencies and bog down their dev workstation. And we’ve all made a change that unexpectedly left us with a broken environment.
With Microsoft Dev Box, dev teams create and maintain Dev Box images with all the tools and dependencies their devs need to build and run their applications. Teams can include their application source code and nightly built binaries, enabling devs to immediately start running and understanding the code without having to wait for long re-builds.


Developers stay in control of their Dev Boxes with a developer portal that enables them to create and delete their Dev Boxes for any of their projects. Developers can create Dev Boxes to experiment on a proof-of-concept, keep their projects separate, or even parallelize tasks across multiple Dev Boxes to avoid bogging down their primary environment. For devs working on legacy apps, they can maintain Dev Boxes for older versions of an application to quickly create an environment that can reproduce and diagnose critical customer issues as they emerge.


Microsoft Dev Box supports any developer IDE, SDK, or internal tool that runs on Windows. Dev Boxes can target any development workload you can build from a Windows desktop and are particularly well-suited for desktop, mobile, IoT, and gaming. You can even build cross-platform apps using Windows Subsystem for Linux.


And because Microsoft Dev Boxes are hosted in the Microsoft cloud, you can access them from anywhere: Windows, MacOS, Android, iOS, or your web browser.

 

Empowering Dev Teams

thumbnail image 2 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Introducing Microsoft Dev Box

Microsoft Dev Box ensures developers always have the right tools and resources based on project, task, and even role. When building Dev Boxes, dev teams select from a range of SKUs to define the right level of compute for each project and instantly scale up aging physical hardware. Thanks to Azure Active Directory integration, teams can rapidly onboard new team members by assigning them to Azure Active Directory groups that grant access to the Dev Boxes they need for their projects.


By deploying Dev Boxes in the developer’s local region and connecting via the Azure Global Network, dev teams ensure remote team members have a high-fidelity experience and gigabit connection speeds wherever they are in the world. When outsourcing to external teams, dev teams can tighten up network security by establishing role-based permissions that provide greater flexibility for internal developers while limiting access for external contractors.


To keep costs under control, teams can use start/stop schedules to spin up Dev Boxes at the beginning of the day and automatically hibernate them when devs go home. Developers can always wake up their Dev Boxes when needed and pick up right where they left off. Teams also get a single view of all costs from one place to understand costs across projects and teams.

 

Built-in security and management

thumbnail image 3 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Introducing Microsoft Dev Box

Critically, Microsoft Dev Box doesn’t just benefit developers—because the service integrates with Windows 365, it’s easy for IT administrators to manage Dev Boxes together with Cloud PCs in Microsoft Intune and Microsoft Endpoint Manager. Using Intune’s expedited quality updates, IT admins can deploy zero-day patches to all devices across their organization. If a Dev Box is compromised, IT admins can isolate the Dev Box while helping the developer get back up and running on a new Dev Box

Create and connect to a dev box by using the Microsoft Dev Box developer portal

 

Create and connect to a dev box by using the Microsoft Dev Box developer portal

Prerequisites

To complete this quickstart, you need:

  • Your organization must have configured Microsoft Dev Box with at least one project and dev box pool before you can create a dev box.
  • You must have permissions as a Dev Box User for a project that has an available dev box pool. If you don't have permissions to a project, contact your administrator.

Create a dev box

Microsoft Dev Box enables you to create cloud-hosted developer workstations in a self-service way. You can create and manage dev boxes by using the developer portal.

Depending on the project configuration and your permissions, you have access to different projects and associated dev box configurations. If you have a choice of projects and dev box pools, select the project and dev box pool that best fits your needs. For example, you might choose a project that has a dev box pool located near to you for least latency.

 

To create a dev box in the Microsoft Dev Box developer portal:

  1. Sign in to the Microsoft Dev Box developer portal.

  2. Select Add a dev box.

    Screenshot of the developer portal and the button for adding a dev box.

  3. In Add a dev box, enter the following values:


    Screenshot of the dialog for adding a dev box.

    After you make your selections, the page shows you the following information:

    • How many dev boxes you can create in the project that you selected, if the project has limits configured.
    • Whether Hibernation is supported or not.
    • Whether Customizations is enabled or not.
    • A shutdown time if the pool where you're creating the dev box has a shutdown schedule.
    • A notification that the dev box creation process can take 25 minutes or longer.
  4. Select Create to begin creating your dev box.

  5. Use the dev box tile in the developer portal to track the progress of creation.


    Screenshot of the developer portal that shows the dev box card with a status of Creating.


Connect to a dev box

After you create a dev box, you can connect remotely to the developer virtual machine. You can connect from your desktop, laptop, tablet, or phone. Microsoft Dev Box supports connecting to a dev box in the following ways:

  • Connect through the browser from within the developer portal
  • Connect by using a remote desktop client application

To connect to a dev box by using the browser:

  1. Sign in to the developer portal.

  2. Select Open in browser.

    Screenshot of dev box card that shows the option for opening in a browser.

A new tab opens with a Remote Desktop session through which you can use your dev box. Use a work or school account to sign in to your dev box, not a personal Microsoft account.

Clean up resources

When you no longer need your dev box, you can delete it:

  1. Sign in to the developer portal.

  2. For the dev box that you want to delete, from the Actions menu, select Delete.

    Screenshot of the dev box Actions menu with the Delete option.

  3. To confirm the deletion, select Delete.

    Screenshot of the confirmation message about deleting a dev box.