Why Networking is the #1 Most Critical Skill in Microsoft Azure
Cloud adoption is moving at a breakneck pace, but with that speed comes a level of complexity that many organizations are unprepared to handle. In the modern era, networks are no longer just a collection of cables, switches, and physical routers. They are software-defined, automated, globally distributed, and expected to be secure from the very first second of deployment. Whether you are deploying a simple Azure Function or managing hundreds of virtual networks across multiple subscriptions, networking has become the most critical, and often most misunderstood, skill in the Azure ecosystem.
In a recent episode of the MC65 FM podcast, Rex de Koning, a Microsoft MVP and certified trainer with nearly 30 years of IT experience, shared his insights on the shifting landscape of cloud infrastructure. From his early days with a Commodore 64 to his current role as a leading expert in Infrastructure as Code (IaC), de Koning challenges several “industry standards” and provides a roadmap for mastering Azure networking.
The Dangerous Misconception: “Microsoft Handles the Network”
One of the most pervasive and dangerous myths in cloud computing is the idea that because you are moving to a managed platform, Microsoft handles the networking for you. While Microsoft provides the underlying physical infrastructure, the logical architecture is entirely the responsibility of the user. De Koning points out that many companies fall into a trap by assuming cloud networking is a direct mirror of their on-premise environments.
“Networking in Azure works completely different than most people think,” de Koning explains. In a traditional data center, you have physical VLANs and clear boundaries. In Azure, while the concepts of Virtual Networks (VNets) and subnets exist, the actual routing and differentiation are often handled at the resource level rather than the network level. Failing to understand this distinction leads to bloated architectures that are difficult to manage and even harder to secure.
The Controversial Reality of Subnets and NSGs
In perhaps his most polarizing take, de Koning suggests that the traditional obsession with creating numerous subnets is largely unnecessary in Azure. In the on-premise world, subnets were the primary way to segment traffic. In Azure, the Network Security Group (NSG) is the real hero.
De Koning argues that besides specific resources that require dedicated subnets, such as Azure Firewalls or Virtual Network Gateways, creating a complex web of subnets for the sake of organization is a legacy habit that provides little actual value. Instead, the focus should be on the resource itself. NSGs should be your first line of defense. By applying security rules directly to the resource or the NIC, you achieve a more granular and effective security posture than you ever could by simply relying on subnet-level isolation.
Choosing Your Architecture: Hub-and-Spoke vs. Virtual WAN
When it comes to connecting multiple environments, architects usually find themselves choosing between two main frameworks: the traditional Hub-and-Spoke model or the managed Azure Virtual WAN (vWAN). De Koning offers a nuanced, and somewhat critical, view of both.
The Hub-and-Spoke “Legacy”
The Hub-and-Spoke model is the “consultant’s favorite” because it is familiar. It mimics on-premise architecture, making it easy for traditional network engineers to understand. However, it has significant drawbacks. For instance, connecting two different branches through a Hub-and-Spoke setup is notoriously difficult without using complex tools like Azure Route Server.
The Virtual WAN “Black Box”
Microsoft created Virtual WAN to simplify global routing and connectivity. It is a managed service that handles much of the heavy lifting. However, de Koning warns of a significant trade-off: visibility. Because vWAN is a managed service, users have very little insight into what is happening “under the hood.” When routing issues occur, troubleshooting can become a nightmare because you cannot see the internal logic of the managed service. This lack of transparency is why many advanced users are gravitating back toward manual setups using Route Server for better control.
The Challenges of Multi-Region Deployments
As companies grow, they often expand into multi-region Azure setups. While this is great for global reach, it introduces two major hurdles that de Koning highlights: latency and cost.
Latency: While regions within Europe (like Western Europe and Northern Europe) are relatively close, connecting to regions in Singapore or China introduces unavoidable physical delays. If your application isn’t designed for these latencies, it will fail, regardless of how “fast” the cloud is.
Egress Costs: Moving data between regions isn’t free. High volumes of traffic between a primary region and a DR (Disaster Recovery) region can lead to massive, unexpected bills.
Resource Availability: De Koning also notes a controversial point regarding DR: you cannot always assume that resources will be available in a secondary region during a massive failure. If an entire region goes down, every other company will be trying to spin up resources in the backup region simultaneously, potentially leading to capacity shortages.
The Secret Weapon: Azure Virtual Network Manager (AVNM)
If there is one tool de Koning believes is criminally underused, it is the Azure Virtual Network Manager (AVNM). This service solves several of the most common pain points in large-scale Azure environments.
1. Centralized IP Address Management (IPAM)
AVNM includes IPAM capabilities that allow you to see your entire network footprint in one “pane of glass.” You can track which IP ranges are in use, which are free, and even include your on-premise ranges to prevent overlapping. This prevents the “IP overlap” disasters that often plague growing companies.
2. Automated Connectivity and Tagging
Instead of manually peering every new VNet, AVNM allows you to use tags. When a new network is created with a specific tag, AVNM automatically identifies it and pulls it into the Hub-and-Spoke architecture, setting up all necessary routing without human intervention.
3. Security Admin Rules
This is perhaps the most powerful feature of AVNM. Traditionally, NSG rules are processed from top to bottom (100 to 65,535). If you need to enforce a security rule across 500 different NSGs, doing it manually is impossible. AVNM Admin Rules sit in front of standard NSGs (ranking from 1 to 99). This allows security teams to “force” a rule, like blocking a specific port or allowing a management IP, across the entire organization, regardless of what the local NSG says.
Key Takeaways for Azure Professionals
Shift your mindset: Stop thinking about cloud networking as physical cables. It is software-defined and requires an automation-first approach.
Prioritize NSGs over Subnets: Don’t over-complicate your VNet structure. Focus on securing the resources directly.
Be wary of “Managed” services: While Virtual WAN simplifies things, understand that you lose visibility. If you need total control, look into Azure Route Server.
Master AVNM: Use Azure Virtual Network Manager to automate your peering, manage your IP space, and enforce global security policies.
Watch your egress: Multi-region is not a silver bullet; it requires careful cost and latency analysis.
Conclusion
Mastering Azure networking isn’t about memorizing every service Microsoft offers; it’s about understanding the fundamental shift from hardware to software. As Rex de Koning points out, the tools to manage massive, complex environments already exist, tools like Azure Virtual Network Manager and Infrastructure as Code, but they require a departure from “the way we’ve always done it.” By embracing automation and moving security closer to the resource, organizations can build cloud architectures that are not only scalable but truly resilient.