In chapter 4, you explored the Azure Storage service. One of the other core services for cloud applications is Azure Networking. Azure has a lot of powerful network features to secure and route your traffic on a truly global scale. These features are designed to help you focus on how to build and maintain your apps, so you don’t have to worry about details like IP addresses and route tables. If you build and run an online store to handle pizza orders, it must securely transmit the customer data and process payment transactions.

This chapter examines Azure virtual networks and subnets, and discusses how to create virtual network interfaces. To secure and control the flow of traffic, you create network security groups and rules. If networking is new to you, or if it’s been a while since you had to work with IP addresses and network cards, this chapter may take a little longer to work through. It has a lot of Try It Now exercises. It’s worth your while to take the time to understand this chapter, however, as networking is key to many of the services in Azure.

5.1 Virtual network components

Think of how many cables are behind your computer desk or in your entertainment center. Now think of all the cables required to connect the computers on a given floor of an office building. What about the entire office building? Have you ever been in a data center or seen photos of one? Try to imagine how large the Azure data centers are. Now try to imagine dozens of Azure data centers all around the world. Math isn’t my strong point, so I can’t calculate how many miles and miles of network cables are used to carry all the traffic in Azure!

Network connectivity is a crucial part of modern life. In Azure, the network is central to how everything communicates. For all the thousands of physical network devices and miles of network cables that connect everything in an Azure data center, you work with virtual network resources. How? Software-defined networks. When you create a VM or a web app, a technician doesn’t have to run around the Azure data center to physically connect cables for you and assign IP addresses (although that would be funny to watch!). Instead, all the network resources that define your entire network environment are logically handled by the Azure platform. Figure 5.1 shows the virtual network components you’ll build as you work through this chapter.

Figure 5.1 Software-defined network connections in Azure

Some of the network components are abstracted if you use PaaS resources. The main components that you use for VMs are as follows:

• Virtual networks and subnets (including IP address pools)

• Virtual network interface cards

• One or more public IP addresses

• Internal DNS name and optional public DNS names for external name resolution

• Network security groups and rules, which secure and control the flow of network traffic the way a regular firewall does

5.1.1 Virtual networks and subnets

When you created a VM in chapter 2, you didn’t have to adjust any network parameters. The Azure platform can create these resources for you with default names and IP address scopes. In this section, you’ll create the network resources ahead of time and see how they come together for a VM.

Try it now Networking is often easier to visualize when you see it in action. You’re going to use the Azure portal to get started, which ends up taking quite a few separate steps, but you’ll see the power of the Azure CLI later in the chapter. Don’t worry too much about how to use your own address spaces or custom DNS names right now. To build out your virtual network and subnet, complete the following steps:

1. Open the Azure portal, and select Create a Resource in the top-left corner of the dashboard.

2. Select Networking from the list of Marketplace services, and then choose Virtual Network.

3. Enter a name for the virtual network, such as vnetmol.

4. To give yourself a little more room to play with, change the address space to 10.0.0.0/16.

   IP address ranges Virtual networks span a certain range of IPs--an address space. If you’ve ever seen an IP address, you may have noticed the subnet mask, which is often something like 255.255.255.0. This subnet mask is often used in a short form that specifies how big that range is, such as /24. The Azure portal defaults to a /24 address space. You want to increase the number of additional IP ranges here without too much network knowledge, so you increase the address space to /16. You don’t give this type of IP address straight to a VM; in the next step, you’ll create a subnet that covers a smaller section of this address space. If network address spaces are totally foreign to you, don’t worry. For the most part, you won’t deal with them on a daily basis. Sensible Azure governance may work the same way it does in your existing on-premises IT world; one group of folks may manage the Azure virtual networks, and you drop your applications into a precreated space.

5. Create a resource group, such as azuremolchapter5, and then select an Azure region close to you.

6. Provide a subnet name, such as a websubnet, and enter the subnet address range 10.0.1.0/24. This address range is part of the wider virtual network you specified earlier. Later, you’ll add another subnet.

7. Look at some of the other options, such as distributed denial of service (DDoS) protection, service endpoints, and Azure Firewall. Leave the defaults for now, but I hope this example gives you some hints about what’s possible beyond a basic virtual network.

8. When you’re ready, create the virtual network and subnet.

5.1.2 Virtual network interface cards

Now that you’ve created a virtual network and subnet, you need to connect a VM. Just as you do with a regular desktop PC, laptop, or tablet, you use a network interface card (NIC) to connect to the virtual network. And no, there’s no free Wi-Fi! But there are VM sizes in Azure that currently provide up to eight NICs with speeds of up to 32 Gbps. Even if I were good at math, I could tell you that these figures add up to some serious bandwidth!

You may wonder why you’d create each of these resources ahead of time. You can do all this when you create a VM. That’s true, but take a step back and think about network resources as long-lived resources.

Network resources exist separately from VM resources and can persist beyond the lifecycle of a given VM. This concept allows you to create the fixed network resources and create, delete, and create again a VM that maintains the same network resources, such as IP addresses and DNS names. Think of a lab VM or a development-and-test environment. You can reproduce the exact same environment quickly because only the VM changes.

Try it now To create a NIC, complete the following steps:

In the Azure portal, select Create a Resource in the top-left corner of the dashboard.

Search for and select Network Interface, and then select Create.

Provide a name for your network interface, such as webvnic; then select the virtual network and subnet you created in the previous exercise.

I talked about long-lived resources earlier; now you can see how they work. Create a static IP address assignment that uses the address 10.0.1.4.

Tip Why .4? What about the first three addresses in the address space? Azure reserves the first three IP addresses in each range for its own management and routing. The first usable address you can use in each range is .4.

1. Don’t create a network security group for now; you’ll come back to this in a few minutes. If you’re one of the cool kids who knows all about IPv6, you can check the Private IP Address (IPv6) box and provide a name; otherwise, stick with IPv4.

2. Select the existing resource group from the previous exercise, and then choose to create the NIC in the same region as the virtual network.

3. When you’re ready, create the NIC.

Role separation in Azure You don’t have to create other compute resources within the same resource group as your virtual network. Think back to the concept of Azure governance, discussed earlier. You may have a group of network engineers who manage all the virtual network resources in Azure. When you create resources for your applications, such as VMs, you create and manage them in your own resource groups. Later chapters discuss some of the security and policy features in Azure that allow you to define who can access and edit certain resources. The idea is that if you don’t know, or don’t want to know, a great deal about the network resources, you can connect to what’s given to you, and that’s it. The same applies to other engineers or developers; they may be able to see your application resources but not edit or delete them. This kind of governance model in Azure is nice, but take care to avoid the trap of working in silos. In large enterprises, it may be inevitable that you’re constrained along department lines. But one of the big advantages of cloud computing providers like Azure is speeding time to deployment of applications, because you don’t have to wait for physical network resources to be cabled up and configured. Plan to have the Azure network resources created and configured, and you should be able to create and manage your application resources seamlessly.

5.1.3 Public IP address and DNS resolution

No one can access your resources yet, because no public IP addresses or DNS names are associated with them. Again, follow the principle of long-lived resources to create a public IP address and public DNS name and then assign them to your network interface.

Try it now To create a public IP address and DNS entry for your network interface, complete the following steps:

1. In the Azure portal, select Create a Resource in the top-left corner of the dashboard.

2. Search for and select Public IP Address, and then select Create.

3. Create a basic SKU and IPv4 address. Standard SKUs and IPv6 addresses are for use with load balancers (chapter 8). Don’t worry too much about the differences right now.

4. Enter a name, such as webpublicip, that uses a dynamic assignment.

   IP address assignment types A dynamic assignment allocates a public IP address when the VM is started. When the VM is stopped, the public IP address is deallocated. There are a couple of important points here: You won’t have a public IP address until you assign it to a VM and start it. The public IP address may change if you stop, deallocate, and start the VM. A static assignment is a public IP address allocated without an associated VM, and that address won’t change. This assignment is useful when you’re using an SSL certificate mapped to an IP address or a custom DNS name and record that point to the IP address. Right now, you’re using a single VM. For production use, you’ll ideally run your application on multiple VMs with a load balancer in front of them. In that scenario, the public IP address is assigned to the load balancer and typically creates a static assignment at that point.

5. Enter a unique DNS name. This name forms the fully qualified domain name (FQDN) for your resource that’s based on the Azure region you create it in. If you create a DNS name called azuremol in the East US region, for example, the FQDN becomes azuremol.eastus.cloudapp.azure.com.

   DNS entries What about a custom DNS name? The default FQDN isn’t exactly user friendly! Use a static public IP address, and then create a CNAME record in your registered DNS zone. You retain control of the DNS record and can create as many entries as you wish for your applications. As an example, in the manning.com DNS zone, you might create a CNAME for azuremol that points to a static public IP address in Azure. A user would access azuremol.manning.com to get your application. This address is a lot more user-friendly than webmol.eastus.cloudapp.azure.com!

6. Select the existing resource group from the previous exercise, and then choose to create the public IP address in the same region as the virtual network.

7. When you’re ready, create the public IP address.

8. Associate the public IP address and DNS name label with the network interface you created in section 5.1.2. Browse to and select Resource Group on the navigation bar on the left side of the Azure portal. Then choose the resource group in which you created your network resources, such as azuremolchapter5.

9. Select your public IP address from the list of resources, and then choose Associate.

10. Choose to associate with a network interface (but notice what else you can associate the public IP address with); then choose the network interface you created, such as webvnic.

After a few seconds, the public IP address window updates to show that the IP address is now associated with your network interface. If you selected Dynamic as the assignment type, the IP address is still blank, as shown in figure 5.2. Remember that a public IP address is allocated when an associated VM is powered on.

Figure 5.2 The public IP address is associated with a network interface. With a dynamic assignment, no public IP address is shown until a VM is created and powered on.

5.2 Securing and controlling traffic with network security groups

Pop quiz time: should you connect a VM to the internet without a firewall to control and restrict the flow of traffic? If you answered, “Sure, why not?” maybe you should take the rest of your lunch break to read a little about network security on the Wild Wide Web!

I hope your answer was a resounding, “No!” Unfortunately, there’s too much potential for your VM to come under an automated cyberattack soon after you turn it on. You should always follow best practices to keep the OS and application software up to date, but you don’t even want the network traffic to hit your VM if it’s not necessary. A regular macOS or Windows computer has a built-in software firewall, and every (competent) on-premises network I’ve seen has a network firewall between the internet and the internal network. In Azure, firewall and traffic rules are provided by network security groups.

5.2.1 Creating a network security group

In Azure, an NSG logically applies a set of rules to network resources. These rules define what traffic can flow in and out of your VM. You define what ports, protocols, and IP addresses are permitted, and in which direction. These groups of rules can be applied to a single network interface or an entire network subnet. This flexibility allows you to finely control how and when the rules are applied to meet the security needs of your application.

Figure 5.3 shows the logic flow of an inbound network packet as it passes through an NSG. The same process would apply for outbound packets. The Azure host doesn’t differentiate between traffic from the internet and traffic from elsewhere within your Azure environment, such as another subnet or virtual network. Any inbound network packet has the inbound NSG rules applied, and any outbound network packet has the outbound NSG rules applied.

Figure 5.3 Inbound packets are examined, and each NSG rule is applied in order of priority. If an Allow or Deny rule match is made, the packet is either forwarded to the VM or dropped.

Here’s what happens to each network packet:

1. The first NSG rule is applied.

2. If the rule doesn’t match the packet, the next rule is loaded until there are no more rules. Then the default rule to drop the packet is applied.

3. If a rule matches, check whether the action is to deny the packet. If so, the packet is dropped.

4. Otherwise, if the rule is to allow the packet, the packet is passed to the VM.

Next, you’ll create an NSG so these concepts start to make sense.

Try it now To create a network security group, complete the following steps:

1. In the Azure portal, select Create a Resource in the top-left corner of the dashboard.

2. Search for and select Network Security Group, and then select Create.

3. Enter a name, such as webnsg, and choose to use the existing resource group.

That’s it! The bulk of the configuration for an NSG comes when you create the filtering rules. Section 5.2.2 discusses how you do that and put your NSG to work.

5.2.2 Associating a network security group with a subnet

The NSG doesn’t do much to protect your VMs without any rules. You also need to associate it with a subnet, the same way you associated your public IP address with a network interface earlier. You’ll associate your NSG with a subnet first.

Try it now To associate your virtual network subnet with your network security group, complete the following steps:

1. Browse to and select Resource Group on the navigation bar on the left side of the Azure portal. Then choose the resource group you created your network resources in, such as azuremolchapter5.

2. Select your NSG, such as webnsg.

3. On the left side, in the Settings options, are Network Interfaces and Subnets. Choose Subnets.

4. Select the Associate button; select the virtual network and network subnet you created earlier; and then select OK to associate your NSG with the subnet.

   The flexibility of NSGs means that you can associate multiple subnets, across various virtual networks, with a single NSG. The mapping is one-to-many, which allows you to define core network security rules that apply to a wide range of resources and applications.

   Now you can see what your NSG looks like and what default rules are applied.

5. On the left side of your NSG, select Inbound Security Rules. No security rules are listed--at least, none that you’ve created.

6. Select Default Rules to see what the Azure platform creates for you, as shown in figure 5.4.

Figure 5.4 Default security rules are created that permit internal virtual network or load-balancer traffic but deny all other traffic.

Three default rules have been created for you. These rules are important to understand:

• AllowVnetInBound --Allows any traffic that’s internal to the virtual network. If you have multiple subnets in your virtual network, the traffic isn’t filtered by default and is allowed.

• AllowAzureLoadBalancerInBound --Allows any traffic from an Azure load balancer to reach your VM. If you place a load balancer between your VMs and the internet, this rule ensures that the traffic from the load balancer can reach your VMs, such as to monitor a heartbeat.

• DenyAllInBound --The final rule that’s applied. Drops any inbound packets that make it this far. If there are no previous Allow rules, this rule drops all traffic by default. All you need to do is allow any specific traffic you want; the rest is dropped.

The priority of an NSG rule is important. If an Allow or Deny rule is applied, no additional rules are applied. Rules are applied in ascending numerical priority order; a rule with a priority of 100 is applied before a rule with a priority of 200, for example.

As in previous discussions of the governance of Azure resources, these NSG rules may already be created for you and applied to a given subnet. You create your VMs and run your applications, and someone else manages the NSGs.

It’s important to understand how the traffic flows in case something goes wrong. A couple of tools in Azure can help you determine why traffic may not reach your application when you think it should!

5.2.3 Creating network security group filtering rules

Now that you have your NSG associated with the network subnet and we’ve reviewed the default rules, create a basic NSG rule that allows HTTP traffic.

Try it now To create your own rules with the network security group, complete the following steps:

1. To create an NSG rule from the previous Azure portal window, select Add in the Inbound Security Rules section.

2. You have two options for creating rules: Basic and Advanced. To create prebuilt rules quickly, select Basic at the top of the window.

3. Choose HTTP from the Service drop-down menu. Many default services are provided, such as SSH, RDP, and MySQL. When you select a service, the appropriate port range is applied--in this case, port 80. The default action on basic rules allows the traffic.

4. A priority value is assigned to each rule. The lower the number, the higher the priority. Accept the default low priority, such as 100.

5. Accept the default name or provide your own; then select OK.

5.3 Building a sample web application with secure traffic

So far, you’ve created a virtual network and subnet. Then you created a network interface and associated a public IP address and DNS name label. You created an NSG and applied it to the entire subnet, and you created an NSG rule to allow HTTP traffic. You’re missing one thing: the VM.

5.3.1 Creating remote access network connections

In production, you shouldn’t open remote access, such as SSH or RDP, to VMs that run your applications. Typically, you have a separate jump-box VM that you connect to from the internet, and you access additional VMs over the internal connection. So far, you’ve created all the virtual network resources in the Azure portal. Let’s switch over to the Azure CLI to see how quickly you can create these resources from the command line.

Try it now You created the first NSG in the Azure portal. To create another NSG with the Azure CLI, complete the following steps:

1. Select the Cloud Shell icon at the top of the Azure portal dashboard. Make sure that the Bash shell opens, not PowerShell.

2. Create an additional NSG in the existing resource group. As in earlier chapters, the backslashes () in the following command examples are to help with line breaks; you don’t have to type them if you don’t want to. Provide a name, such as remotensg:

   az network nsg create 
     --resource-group azuremolchapter5 
     --name remotensg

3. Create an NSG rule in the new NSG that allows port 22. Provide the resource group and NSG you created in the previous step along with a name, such as allowssh:

   az network nsg rule create 
     --resource-group azuremolchapter5 
     --nsg-name remotensg 
     --name allowssh 
     --protocol tcp 
     --priority 100 
     --destination-port-range 22 
     --access allow

4. Create a network subnet for your remote VM. Provide a subnet name, such as remotesubnet, along with an address prefix inside the range of the virtual network, such as 10.0.2.0/24. You also attach the NSG you created in step 3 to the subnet, such as remotensg:

   az network vnet subnet create 
     --resource-group azuremolchapter5 
     --vnet-name vnetmol 
     --name remotesubnet 
     --address-prefix 10.0.2.0/24 
     --network-security-group remotensg

Three commands are all it takes to create a subnet, create an NSG, and create a rule. Can you start to see the power of the Azure CLI? Azure PowerShell is equally powerful, so don’t feel like you must create all resources in the Azure portal. As you move forward in the book, you’ll use the Azure CLI rather the portal in most cases.

5.3.2 Creating VMs

With all the network components in place, you’re ready to create two VMs. One VM is created in the subnet that allows HTTP traffic so that you can install a web server. The other VM is created in the subnet that allows SSH so that you have a jump box to further secure your application environment and begin to replicate a production deployment. Figure 5.5 reminds you what you’re building.

Figure 5.5 You’re bringing together two subnets, NSGs, rules, network interfaces, and VMs. This example is close to a production-ready deployment in which one VM runs the web server and is open to public traffic, and another VM in a separate subnet is used for remote connections to the rest of the application environment.

When you create a VM, you can provide the virtual network interface that you created earlier. If you didn’t specify this network resource, the Azure CLI creates a virtual network, subnet, and NIC for you, using built-in defaults. That’s great for creating a VM quickly, but you want to follow the principle of using long-lived network resources that another team may manage and in which you’ll create your VMs.

Try it now To use the Azure CLI to create your web server and jump-box VMs, complete the following steps:

1. Create the first VM for your web server, and provide a name, such as webvm. Attach the network interface, such as webvnic, and enter an image, such as UbuntuLTS. Provide a username, such as azuremol. The final step, --generate-ssh-keys, adds to the VM the SSH keys you created in chapter 2:

   az vm create 
     --resource-group azuremolchapter5 
     --name webvm 
     --nics webvnic 
     --image UbuntuLTS 
     --size Standard_B1ms 
     --admin-username azuremol 
     --generate-ssh-keys

2. Create the second VM for the jump box. This example shows how you can use an existing subnet and NSG, and let the Azure CLI create the network interface and make the appropriate connections. You create a public IP address, such as remotepublicip, as part of this command:

   az vm create 
     --resource-group azuremolchapter5 
     --name remotevm 
     --vnet-name vnetmol 
     --subnet remotesubnet 
     --nsg remotensg 
     --public-ip-address remotepublicip 
     --image UbuntuLTS 
     --size Standard_B1ms 
     --admin-username azuremol 
     --generate-ssh-keys

The output from both commands shows a public IP address. Make a note of these IP addresses. In the next exercise, if you try to SSH to your first VM for the web server, it fails. Why? You can SSH to the remote VM because you created an NSG rule to allow only HTTP traffic to the web VM.

5.3.3 Using the SSH agent to connect to your VMs

I need to introduce one piece of magic with SSH that allows you to use your jump box correctly and connect to the web VM over the Azure virtual network: the SSH agent. This agent applies only to Linux VMs, so if you mainly work with Windows VMs and Remote Desktop Protocol connections, don’t worry if the SSH talk is new. You can create RDP connections to Windows VMs from your jump box with the local remote credentials or with domain credentials if you configure the server appropriately.

An SSH agent can store your SSH keys and forward them as needed. Back in chapter 2, when you created an SSH public-key pair, I talked about the public and private keys. The private key is something that stays on your computer. Only the public key is copied to the remote VMs. Although the public key was added to both VMs you created, you can’t just SSH to your jump box and then SSH to the web VM. Why? That jump box doesn’t have a copy of your private key. When you try to make the SSH connection from the jump box, it has no private key to pair up with the public key on the web VM for you to authenticate.

The private key is something to safeguard, so you shouldn’t take the easy way out by copying the private key to the jump box. Any other users who access the jump box could potentially get a copy of your private key and then impersonate you anywhere that key is used. Here’s where the SSH agent comes into play.

If you run the SSH agent in your Cloud Shell session, you can add your SSH keys to it. To create your SSH connection to the jump box, you specify the use of this agent to tunnel your session. This technique allows you to effectively pass through your private key for use from the jump box without ever copying the private key. When you SSH from the jump box to the web VM, the SSH agent tunnels your private key through the jump box and allows you to authenticate.

Try it now To use SSH with your jump-box VM, complete the following steps:

1. In Cloud Shell, start the SSH agent as follows:

   eval $(ssh-agent)

2. Add the SSH key you created in chapter 2 to the agent as follows:

   ssh-add

3. SSH to your jump-box VM. Specify the use of the SSH agent with the -A parameter. Enter your own public IP address that was shown in the output when you created the jump-box VM:

   ssh -A azuremol@<publicIpAddress>

4. This is the first time you’ve created an SSH connection to the jump-box VM, so accept the prompt to connect with the SSH keys.

5. Remember how you created a static private IP address assignment for the web VM in section 5.1.2? This static address makes it a lot easier to SSH to it. SSH to the web VM as follows:

   ssh 10.0.1.4

6. Accept the prompt to continue the SSH connection. The SSH agent tunnels your private SSH key through the jump box and allows you to successfully connect to the web VM. Now what? Well, you have a lab to see this work!

5.4 Lab: Installing and testing the LAMP web server

You’ve already done the hard work throughout the chapter. This quick lab reinforces how to install a web server and lets you see the NSG rule on your VM in action:

1. Install a basic Linux web server. Think back to chapter 2 when you created an SSH connection to the VM and then installed the LAMP web server package with apt. From the SSH connection to your web VM created in section 5.3.2, install and configure the default LAMP web stack.

2. Browse to the default website. When the LAMP web stack is installed, open your web browser to the DNS name label you entered when you created a public IP address in section 5.1.3. In the example, that was azuremol.eastus.cloudapp.azure.com. You can also use the public IP address that was output when you created the web VM. Remember, though: that public IP address is different from the jump-box VM you SSHed to!