Netcity's Guardians: Azure Firewall and Network Security Groups (NSGs)

In my last blog, I mentioned that Netcity is tightly governed and there are no violations. But how is this possible?

Let's go back to our imaginary city. Netcity, in its raw state, allows its occupants to talk to each other and the outside world. But in most cases, you don't want that freedom — you want control. Maybe the storage account called XYZ isn't for everyone. It's not for the public. It's reserved for just a few internal members of the city. Likewise, you wouldn't want outsiders (from the internet) walking into your city and talking to your resources freely.

This philosophy aligns perfectly with the modern security principle of Zero Trust: never trust, always verify. It means no user, device, or application, whether inside or outside your network, is inherently trusted. Every access request must be rigorously authenticated and authorized.

So how does Netcity secure itself?

Enter: the Firewall and Network Security Groups (NSGs).

Azure provides a protective umbrella with a restricted gateway to the virtual network using Azure Firewall. For the resources inside the subnets, Azure gives you personal bodyguards — NSGs.

---

🔐 Firewall = The Iron Gate of Netcity

It's a city-level guard, your first line of control. The firewall sits at the perimeter, inspecting all traffic trying to enter or leave, and only allows what you've explicitly approved. This centralized control simplifies policy management for your entire Netcity's external access. Azure Firewall also operates at Layer 3 to Layer 7, understands domain names (FQDNs), can inspect secure traffic (TLS), supports NAT, and integrates with Microsoft's threat intelligence to block known malicious IPs and domains. It acts as a centralized security gateway.

🛡️ NSGs = Personal Bodyguards

These control traffic in and out of specific resources — at the subnet or VM level. They look at things like IP, port, and protocol, and enforce what's allowed or denied. NSGs are also stateful, meaning if you allow outbound traffic on a certain port, the return inbound traffic for that connection is automatically allowed. NSGs operate at Layer 3 and 4 (IP, port, protocol), and are great for internal VNet or subnet-level control, providing distributed, granular control.

They might sound similar, but they work differently. NSGs provide distributed, granular control at the subnet or VM level, while Azure Firewall offers centralized, advanced threat protection for your entire virtual network.

In most production-grade networks, both are used together — NSGs as the distributed guardrails and Azure Firewall as the central inspector. Understanding how these two work in concert is key to building a robust and secure Azure environment for your own 'Netcity'.

---

Our Netcity Security Setup: A Layered Defense in Azure

To demonstrate how Azure Firewall and Network Security Groups (NSGs) work together to protect a virtual network, we've established a simplified "Netcity" in Azure. This setup showcases a layered defense model, where the Azure Firewall acts as the city's main "Iron Gate" for external traffic, and NSGs serve as "Personal Bodyguards" enforcing rules within different neighbourhoods (subnets).

Here's a breakdown of our Netcity's infrastructure:

Netcity-VNet (Our Virtual City)

This is the core virtual network, representing our entire Netcity. It provides the isolated private network space where all our resources reside and communicate.

Specialized Subnets (Netcity Neighborhoods)

• Web-Subnet (Public-Facing District): Houses our WebVM, simulating public-facing web applications.

• App-Subnet (Application Zone): Contains our AppVM, representing the middle tier where application logic runs.

• DB-Subnet (Secure Data Vault): Home to our DBVM, simulating sensitive database servers that require strict isolation.

• AzureFirewallSubnet (Guard Post): A dedicated subnet where our Azure Firewall resides.

• AzureBastionSubnet (Secure Entry Point): A dedicated subnet for Azure Bastion, providing a highly secure, browser-based entry point to manage our VMs without exposing them to the internet.

Virtual Machines (Netcity Occupants)

• WebVM: Simulates a web server, configured with IIS.

• AppVM: Simulates an application server.

• DBVM: Simulates a database server, designed to listen on a specific port (like 1433) to illustrate database connectivity rules.

Azure Firewall (The Iron Gate)

• Role: Positioned at the perimeter of our Netcity-VNet, the Azure Firewall acts as the first line of defense. It inspects all traffic attempting to enter or leave the city's boundaries.

• Configuration: We've deployed it with specific Application Rules to control outbound internet access (e.g., allowing WebVM to reach www.microsoft.com and www.google.com but denying all other internet access by default).

• Integration (UDRs): User-Defined Routes (UDRs) are associated with our workload subnets (Web, App, DB). These UDRs force all outbound internet-bound traffic from these subnets through the Azure Firewall for centralized inspection and control.

Network Security Groups - NSGs (Personal Bodyguards)

• Role: NSGs are applied at the subnet level (one for Web-Subnet, one for App-Subnet, one for DB-Subnet). They act as internal "bodyguards," controlling traffic between the neighborhoods and to individual resources.

• Configuration:

  • Inbound Rules: Restrict what traffic can enter a subnet (e.g., only traffic from Azure Firewall for Web, only App-Subnet for DB, and only Bastion for management).

  • Outbound Rules: Control what traffic can leave a subnet (e.g., WebVM can talk to AppVM, AppVM can talk to DBVM, but WebVM cannot talk directly to DBVM). They also enforce strict "no internet access" rules for sensitive tiers like DB-Subnet.

How They Work Together (Layered Defence)

This setup creates a robust, layered security posture. The Azure Firewall manages the broad city-level perimeter, while the NSGs provide granular, internal micro-segmentation. This ensures that only explicitly authorized traffic flows between different application tiers and that sensitive data (like our DBVM) is protected from unauthorized access, both from outside the city and from other less-trusted neighborhoods within Netcity. This comprehensive approach is a practical application of the Zero Trust security model.

Credits

The conceptualization, detailed setup instructions, and all image generation (including the blog cover, Zero Trust diagram, and network setup visualizations) were carried out with the assistance of Gemini.

👉 If this helped you (or if something could be improved), please drop your thoughts in the comments! I’d love to hear what worked, what didn’t, and what you'd like to see next.

Feel free to share it with anyone else learning Azure — we’re all building this Netcity together. 😊

If you’d like to support my writing, you can buy me a coffee — it means a lot!