Thought experiment

In this thought experiment, apply what you have learned about this objective. You can find answers to these questions in the next section.

Your company, Contoso, wishes to lift and shift an existing HR application to Azure. The application architecture comprises two web servers, and a database tier implemented using three servers in a SQL Server Always-On Availability Group. The web application uses an in-memory session state that requires each user to be consistently routed to the same web server instance. The application should be accessible only to the company Intranet, and not exposed to the Internet.

In addition, Contoso has already migrated several other applications to Azure. A recent finance review, however, has highlighted the increasing of Azure spend, and your manager has identified the duplication of infrastructure components (such as domain controller virtual machines) across each migrated application as a potential area where savings can be made. Each of these applications is managed by a separate team, and the team should have administrative access only to their application.

1. How should the web tier be load-balanced?

2. How should the database tier be load-balanced?

3. How can you restrict network traffic between application tiers, and prevent on-premises uses from having direct access to the database tier?

4. How should the application be integrated into the company Intranet, avoiding exposing an Internet endpoint?

5. How can you reduce costs by consolidating duplicated components?

6. How does your design maintain administrative separation between applications?

Thought experiment answers

This section contains the solution to the thought experiment for the chapter.

1. The web tier should be load-balanced using Application Gateway. This option is chosen in preference to Azure load balancer because it supports cookie-based session affinity, which enables each user to be consistently routed to the same backend server. The App Gateway will be deployed in a separate subnet of the same virtual network that is used to host the web tiers and database tiers of the HR application (each tier uses a separate subnet). NSGs associated with each subnet are used to restrict network flows, such as to ensure that only the web tier has access to the database.

2. The database tier should be load balanced using Azure Load Balancer. The load balancer will be configured with an internal (Intranet) IP address only. Since the load balancer is being used as a SQL Server Always-On Availability Group Listener, the Floating IP (Direct Server Return) option should be enabled.

3. Network security groups should be used to restrict inbound and outbound traffic for the subnets used by each application tier. Optionally, application security groups can be used to simplify the IP address management and reduce the number of subnets and NSGs required.

4. Connectivity between the application and the on-premises network can be achieved in two ways. The simplest option is to establish a Site-to-Site VPN between the on-premises network and the Azure virtual network. This creates an encrypted tunnel (over the Internet) linking the two networks together. A compatible om-premises VPN device with a static Internet-facing IPv4 address is required, together with a VPN gateway in Azure (hosted in a dedicated gateway subnet). Alternatively, an ExpressRoute connection can be used. This provides a more reliable and consistent connection over a dedicated connection from a connectivity provider. In this case, an ExpressRoute gateway is used to connect the ExpressRoute circuit to the Azure virtual network.

5. A dedicated VNet should be created to contain common services (such as Active Directory servers), which are consumed by multiple applications. Each application should remain in its own VNet, which should only contain application-specific components. The application VNets should be peered with the shared services VNet, in a hub-and-spoke configuration (with the shared services VNet as the hub). This peering will give the applications network access to the shared components.

6. Because each application retains its own VNet containing all application-specific components, there is no loss of isolation or control for the application owners. These application components can even be deployed in separate subscriptions, making separate role-based access and billing straightforward. Peering of Resource Manager VNets is supported across subscription boundaries.

Chapter summary

This chapter covered many of the advanced networking features available in Azure. Below are some of the key takeaways from this chapter.

• Azure virtual networks (VNets) are isolated networks using a private IP address space.

• Virtual networks are divided into subnets, which allow you to isolate workloads.

• Azure reserves the first 4 and last IP address in each subnet. The first IP address allocated to VMs is therefore typically the .4 IP address.

• Private IP addresses for a VM are assigned from a subnet and configured as settings on the IP configuration of a network interface resource.

• A VM can be associated with one or more network interfaces, and each network interface can contain multiple IP configurations.

• Private IP addresses support two allocation methods: dynamic or static. Dynamic IP addresses are released when the VM is stopped (deallocated).

• Public IP addresses are managed as a standalone resource, which can be associated with a network interface IP configuration.

• Public IP addresses support two pricing tiers (SKUs). The Basic tier supports dynamic and static assignment and provides open connectivity (which can be restricted using NSGs). The Standard tier supports zone-redundant deployments, use static allocation only, and is closed by default (access is enabled using NSGs).

• User Defined Routes (UDRs) change the default behavior of subnets allowing you to direct outbound traffic to other locations. Typically, traffic is sent through a virtual appliance such as a firewall.

• If a UDR is used to send traffic to a virtual appliance, IP forwarding must be enabled on the NIC of the virtual appliance VM.

• Routing outbound Internet traffic via a VPN connection to a network security device is known as forced tunneling.

• The effective routes for each network interface can be reviewed to help diagnose routing issues.

• VNets can be connected using either VNet peering or VNet-to-VNet VPN connections.

• To connect two VNet, they must have non-overlapping IP address spaces.

• Virtual networks can be connected using VNet peering. This is supported both within a region or across regions.

• By default, peered VNets appear and perform as a single network. There is an option to limit connectivity, in which case NSG rules must be used to define the permitted connections.

• VNet peering allows VMs to see each other as one network, but their relationships are non-transitive. If VNETA and VNETB are peered and VNETB and VNETC are peered VNETA and VNETC are not peered.

• A common approach is to use a hub and spoke network architecture, in which separate spoke VNets are used by each application, peered to a hub VNet containing a network virtual appliance (NVA). The peering connections must enable Allow Forwarded Traffic.

• Using VNet peering to provide access to a central VNet containing shared services, such as Active Directory domain controllers, is known as service chaining.

• Alternatively, virtual networks can be connected using a VNet-to-VNet VPN connection.

• A virtual network gateway can be used to create VPN connections between virtual networks (and is then called a VPN gateway).

• The size of the VPN gateway should be chosen based on the throughput required.

• The GatewaySubnet is a special subnet that is only used for virtual network gateways.

• A VPN gateway can be shared by peered VNets. The peering connections must enable the settings to Use Remote Gateway (on the peering towards the gateway) and Allow Gateway Transit (on the peering from the gateway).

• Both global VNet peering and VNet-to-VNet VPN connections route traffic between Azure regions over the Microsoft backbone network, not the public Internet.

• Azure DNS provides an authoritative DNS service for hosting Internet-facing domains.

• DNS zones in Azure DNS must be delegated from the parent domain. This is achieved by setting up appropriate NS records in the parent domain, pointing to the name servers assigned by Azure DNS.

• DNS records in Azure DNS are managed using record sets, which are the collection of records with the same name and the same type.

• DNS records at the zone apex use the record name @. You cannot create records with the CNAME record type at the zone apex.

• Azure DNS Alias records allow DNS records to reference other Azure resources, such as a public IP address.

• DNS zone files are a standard format used to transfer DNS records between DNS systems. DNS zone files can only be imported into or exported from Azure DNS by using the Azure CLI.

• Azure-provided DNS, also known as Internal DNS, provides VM-to-VM DNS lookups within a virtual network.

• Alternatively, a customer can implement their own DNS servers, which can be configured either at the VNet or the network interface level.

• Azure DNS also supports private DNS zones, which can also be used to enable VM-to-VM DNS lookups.

• Network security groups are used to create firewall rules to control network flows.

• NSGs can be applied at the subnet level, or on individual VM network interfaces.

• Each NSG includes a list of default rules, which can be overridden using user-defined rules. Rules are applied in priority order (processing stops at the first rule matching the traffic in question).

• Source and destination IP address ranges in NSG rules can be specified explicitly using CIDR ranges.

• IP address ranges can also be specified using service tags which are platform shortcuts for the IP ranges for key Azure services. Commonly-used service tags include VirtualNetwork, Internet, AzureCloud, Storage, and SQL.

• IP address ranges can also be specified using application security groups (ASGs). ASGs allow NSG rules to be defined for groups of VMs without needing to allocate the VMs into separate subnets.

• Tools to help identifying the required NSG rules include service map and NSG flow logs.

• Effective security rules can be reviewed for each network interface. This allows you to see the exact IP ranges used by each service tag and ASG.

• Azure Load Balancer (ALB) is a fully-managed, high performance load-balancing service for TCP and UDP traffic. It operates at the transport layer (OSI Layer 4). Unlike App Gateway, it does not have visibility into application-level traffic.

• ALB can be deployed with either a public (Internet) or private (Intranet) frontend IP address.

• ALB comes in two pricing tiers (SKUs): Basic or Standard. The Standard tier supports availability zones, larger and more flexible backend pools, and a number of other features. The Basic tier is free of charge.

• An ALB load-balancing configuration comprises frontend IP configuration, backend pool, health probes, and load-balancing rule.

• ALB also supports port forwarding, using inbound NAT rules. This maps a specific frontend port to a specific backend port on a specific backend server.

• Network Performance Monitor provides monitoring for hybrid networks. It supports performance monitor (for monitoring connections between two endpoints), connectivity monitor (to monitor outbound connections to a given IP or FQDN), and ExpressRoute monitor to monitor ExpressRoute connections.

• Network Watcher is a central hub providing access to a wide range of networking tools in Azure.

• IP Flow Verify is a Network Watcher feature used to test if a given network flow is allowed in or out of an Azure VM.

• Next Hop is used to determine the next hop address and routing rule for a given network flow.

• Packet Captures enables network traffic on a given VM to be captured, either locally or to an Azure storage account.

• Network Topology creates a diagrammatic representation of the resources in your virtual network.

• VPN Troubleshoot provides automated, in-depth troubleshooting of VPN connections.

• Connection Troubleshoot allows you to test the connectivity between two Azure VMs, or between a VM and an arbitrary external endpoint.

• Connection Monitor enables long-term connection monitoring, using similar diagnostics as used by Connection Troubleshoot.

• Site-to-Site VPN connections provide connectivity between an on-premises network and an Azure virtual network, using an encrypted tunnel over the public Internet.

• VPN gateways are virtual network gateways deployed with gateway type VPN. They are used to terminate site-to-site VPN connections.

• Site-to-Site VPNs support BGP routing and active-active gateways and connections to enable high availability.

• A wide variety of physical (and software) devices are supported as the on-premises Site-to-Site VPN endpoint. The device must have an Internet-facing static IPv4 address.

• A local network connection is an Azure resource used to represent the on-premises VPN device and network in Azure.

• An ExpressRoute connection provides connectivity between an on-premises network an Azure virtual network, using a dedicated connection from a connectivity provider.

• You can connect to ExpressRoute either via your co-location facility provider, via a point-to-point ethernet connection, or by extending your IPVPN WAN.

• ExpressRoute provides Microsoft Peering (connectivity to Azure PaaS endpoints, and other Microsoft services) or Private Peering (connectivity to Azure virtual networks). The former uses Internet address and the latter uses Intranet addresses. Azure Public Peering, for Azure PaaS services only, is deprecated for new ExpressRoute circuits.

• ExpressRoute circuits provide different levels of bandwidth, from 50Mbps to 10Gbps. They also provide redundant connections.

• ExpressRoute circuits are connected to an Azure virtual network using an ExpressRoute gateway (a virtual network gateway of type ExpressRoute).

• By default, ExpressRoute provides connectivity to all Microsoft datacenters in a given geopolitical region. The ExpressRoute Premium Add-On extends coverage to all datacenters, globally. It also increases the number of private peering routes and the number of virtual networks, which can be connected to a circuit.