Failing to plan is planning to fail.
When organizations first begin implementing Azure networking, the focus is often on the immediate requirements: connectivity, security, and performance for your databases and applications. While that is important, the reality is that your environment will change at some point in the future. Developers will deploy new resources, more users will connect, hybrid scenarios will evolve, and security needs will continue to grow and adapt. If you only plan for today, you risk painting yourself into a corner tomorrow.
The decisions you make now can drastically shape the future. Why not take advantage of that and lay down a foundation that can adapt when necessary?
Quite often, I see a flat network topology, such as a single virtual network (vNet), regardless of the Azure resources deployed within it. Or very wide subnets in terms of address spaces (do you really need 1000 IP addresses for VMs when you only have five VMs in total?), or a lack of consistent subnet naming.
I’m only going to mention naming conventions because that is a whole other topic for discussion; however, get one before you start. Even a simple one that can adapt will go a long way.
Assume Things Will Change
In the cloud, change is not an exception — it’s the rule. You will see workloads move, resources scaling, and newly deployed services. A design that looks perfect now may become limiting in six months, or sooner even. For example, you may start with a single vNet topology, only to discover later that you need to add additional subscriptions in another region that requires connectivity.
By assuming change will come, when I deploy new resources, I will avoid having to re-architect things.
Building for the Future
Flexible Network Topologies
Start with patterns like hub-and-spoke that scale as your environment grows. Even if you don’t need multiple spokes today, laying the groundwork now ensures you can add them later without major redesigns. In this case, I like to put infrastructure things into the hub (like vNets) and then application or database-specific things into another virtual network. The two virtual networks can then be peered together so that things can communicate back and forth appropriately.
Naming Convention
Even if you have a single virtual network, go ahead and name resources, as you will eventually have more than one. I personally like to number my vNets 01, 02, 03, etc. (and other things) because it is then easy to quickly identify how many “things”, in this case virtual networks, I have deployed. When I need to add others down the line, increment the end number to ensure consistency with current deployments.
Keeping Things Seperate
Keeping things separate from the start will help to isolate them as well. Isolation is another reason I like the hub and spoke model, regardless of the size of the environment. There is often a lack of network segmentation in the cloud, which, if exposed, can lead to serious attack vectors into your corporate environment.
The Unknown
No one can predict every future need, but you can prepare by:
- Building modular and flexible network designs.
- Documenting your architecture and decisions. Even if it is a small network, document the topology. It will be helpful later.
Summary
Azure networking is not a one-and-done exercise. In my opinion, it is a dynamic entity that must grow and evolve with your organization. By designing with change in mind from the start, you position your environment to adapt smoothly rather than requiring painful overhauls. Trust me, overhauling an Azure network can be tedious. The best Azure networking strategies are those that anticipate tomorrow’s needs, not just today’s.
Also, if you are new to Azure networking or even need to brush up on the best practices, you can check out Microsoft’s documentation.
© 2025, John Morehouse. All rights reserved.
The post Azure Networking: Designing for Change first appeared on John Morehouse.