My top 5 Azure networking tips

In this post, I’d like to share what I’ve learned along the way designing and deploying Azure networking services in the form of my top five Azure networking tips. And I promise you won’t need a shovel. But more on that later . . .

Azure has a range of networking services available, and they're constantly evolving and improving. When it comes to designing and deploying networking on Azure, there are a few things you should always keep in mind.

Deploying to Azure is easy. In fact, you can have an Azure Virtual Network deployed in as few as a couple of clicks. But changing that network, adding services to it, and deploying to new regions and subscriptions can be challenging if you haven’t taken the time to design and deploy your network in such a way that makes it easy to maintain, grow, and evolve.

I’ll give you an example of this. Let’s say you have a Virtual Network that has a number of subnets and hundreds of virtual machines deployed to it. 

What happens if you need to change the address space for a Virtual Network? Microsoft has some good documentation on how you can do this here.

But! Let’s take a look at the fine print.

To remove an address range, you must first delete any subnets (and any resources in the subnets) that exist in the address range.

Wait, what?

Yeah. That’s gonna be a lot of work. Deleting/replacing hundreds of virtual machines.

Ain’t nobody got time for that!

Let’s look at how we can minimize re-work and improve availability, security, and troubleshooting with my top five Azure networking tips.

What’s better than picking up new tech skills? Doing it for free. Check out this month’s free cloud courses.

Let’s first take a look at Virtual Networks. There are only a couple of decisions you need to make when you’re designing your virtual networks. They are: which region and which address range.

Which address range? You’ll want to pick an address range that is sized “just right” — not too large or too small — and you’ll want to make sure it doesn’t overlap with any existing networks. When you’re making sure it doesn’t overlap, don’t forget to check on-premises networks, VPN connection address ranges, and even other clouds. I’ve seen some interesting network architectures in my time, due to company expansions, acquisitions, and mergers, including a VPN connection between an AWS VPC and an Azure Virtual Network.

Now let’s take a look at subnets. The same as Virtual Networks, you’ll want to size them just right so you don’t exhaust your address space. But perhaps more importantly, you’ll want to make sure you group like resources together. You can control traffic between virtual machines at the network interface (NIC) level, but it’s much easier to control traffic more broadly at the subnet level.

Another important consideration is designing how you’ll control traffic flow between virtual networks. “Why is this important?” you might ask. Well, virtual networks are a security and communication boundary, and when you connect virtual networks together, those walls break down. Someone may make a security decision for a virtual network prior to being connected to another virtual network, and once you connect the virtual networks, the security controls aren’t adequate anymore.

So how can you avoid this? You can centralize the security by passing all the network traffic between virtual networks through a shared “hub” right away. That way, when you add more networks later the security controls still work as intended. This is known as the “Hub-and-Spoke” model, and Microsoft has more about this concept here.

Now let’s take a look at high availability, one of my favorite topics. One of the big advantages of public cloud providers like Azure is that they make high availability easy. I remember earlier in my career having to literally trench fiber optics between data centers in different cities to provide high availability. Let’s just say, it’s a lot easier now.

The heavy-hitting features that make high availability a possibility on Azure are Availability Zones and Regions. When your staff and customers connect to Azure services you deploy, this connectivity is heavily dependent on the network services that provide that connectivity.

When you’re deploying your Azure Resources and the supporting networking services, consider the requirements for high availability and deploy your services in multiple Availability Zones and Regions as required. And then, when you deploy your Azure networking services, you can opt to deploy these services so that they’re zone redundant, or support resources in multiple regions.

When you deploy resources to Azure, it’s really easy to make these resources Internet accessible through Public connectivity like Public IP Addresses. 

Now, your existing networks and users can connect through that public connectivity, but it’s often faster and more secure to provide connectivity to your internal-facing resources over a private network. Azure provides a number of services to enable connectivity between your existing networks and users over private connectivity or by tunneling over the Internet with a Virtual Private Network (VPN).

So my advice here is: if a resource is private, keep it that way — enable connectivity over a private network connection and prevent public access.

Get the Cloud Dictionary of Pain
Speaking cloud doesn’t have to be hard. We analyzed millions of responses to ID the top concepts that trip people up. Grab this cloud guide for succinct definitions of some of the most painful cloud terms.

Now let’s talk about network security. When you’re defending your resources against attacks, you can do everything possible to prevent an attack at the perimeter, but then something comes out of the left field that bypasses all the security you’ve put in place. 

A few years back, I was reviewing the results of the annual penetration test against our network infrastructure. One of the critical issues showed an exploit that allowed the remote attacker to access the root password and gain full administrative access to our perimeter device.

What can you do to slow their progress or reduce the impact? You can deploy multiple layers of security, like hurdles the attacker needs to jump over to access your secure data and applications.

This is known as “defense in depth.” Azure networking services and features provide the tools to secure your infrastructure at multiple layers, including the perimeter, between your networks, between your subnets, and on your virtual machines or services.

Azure not only records all the configuration information of your resources but makes it really easy to collect metric and log data from your resources and store them centrally.

No one ever said to me, “I wish you’d NOT collected all that metric and log data.” I’ve found it much more common to wish we had taken the time to collect the data. You never know when you're going to need data to work out “Is this normal?” or “What made that happen?”

My recommendation here? Azure makes it really easy to collect log and metric data, so turn it on when you deploy the resources. It may very well be invaluable later.

Just to recap, my top five Azure networking tips are:

• Design your virtual networks and subnets
• Design for high availability
• Connect existing networks and devices
• Layer your network security
• Collect logs and metrics

I hope you found this useful. If you’re interested in learning more about the Azure Networking services, check out my new course, Introduction to Networking on Azure.

It covers the core Azure networking services and explores when to use each of them. We'll explore virtual networks, security, connectivity, high availability and resiliency, and troubleshooting. You'll also get hands-on to create a virtual network and create a Virtual Machine and connect to it using Azure Bastion.

Start a free 7-day trial now and give it a go! Or, if you're already an ACG member, jump to the course here and get started.

Level up your career. Learn more about the most in-demand tech skills with A Cloud Guru. Check out this month’s free courses or get a free 7-day trial.