Part 33 ~🔐 Azure NSGs in Action: From Theory to Real-World Security

Intermidiate Bonus~ Azure Networking

You’ve explored the theory behind NSGs. You know what they are, where they go, and how they work.

But theory isn’t enough.

Now it’s time to apply it — step by step — with real scenarios, best practices, and the kind of decisions cloud architects make every day.

Let’s move from “what is an NSG” to “how do I use it to secure my network?”

🧪 Scenario: A Simple Two-Tier Architecture

You’re building a basic web app in Azure:

• A Frontend subnet with web servers
• A Backend subnet with database servers

Your goals:

• ✅ Allow users to access the website
• ✅ Let web servers talk to the database
• ❌ Block backend servers from reaching the internet
• 🔐 Secure admin access with RDP (temporarily)

Let’s build the NSGs to make this happen.

🔧 Step 1: Create NSGs

You’ll need two NSGs:

• frontend-nsg → attach to the frontend subnet
• backend-nsg → attach to the backend subnet

🧠 One subnet = one NSG. But one NSG can be reused across subnets if needed.

🔐 Step 2: Define Custom Rules

🔐 Step-by-Step: Building NSGs

🏢 Frontend NSG (Web Department)

✅ Allow HTTP (Port 80) → So users can access your website

✅ Allow RDP (Port 3389) → For admin access (but consider Bastion for production)

🧠 Best Practice: Never allow RDP from “Any” in production. Use IP whitelisting or Bastion.

🗄️ Backend NSG (Database Department)

✅ Allow SQL (Port 1433) → So web servers can query the database → Restrict source to frontend subnet for tighter control

✅ Allow RDP (Port 3389) → For admin access

❌ Deny Internet Outbound → Prevent data exfiltration or accidental exposure

🧠 Industry Principle: Backend systems should be shielded from direct internet access. Always.

🔍 Step 3: Understand Default Rules

Azure includes default rules in every NSG:

🧠 You can’t delete these — but you can override them with custom rules (priority 100–4096).

🧠 Rule Evaluation: Who Wins?

NSG rules are evaluated by priority:

• Lower number = higher priority
• First match wins
• Later rules are ignored

Example:

• Rule 100: Deny internet outbound
• Rule 200: Allow outbound to 8.8.8.8 → Result: Deny wins

❗ Always check for rule conflicts. One misordered rule can break or expose your app.

🧪 Are These Rules Doing Anything Yet?

Not until a VM is deployed.

NSGs are like guards waiting at empty desks. Once a VM is connected to a NIC, traffic starts flowing — and the NSG starts filtering.

🧠 Subnet-level NSGs apply to all NICs inside. NIC-level NSGs override or complement them.

✅ Best Practices You Should Follow

Here’s what experienced teams do:

• 🔐 Start with deny-all, then allow only what’s needed
• 🧱 Use subnet NSGs for broad control, NIC NSGs for exceptions
• 🧪 Test with Network Watcher before going live
• 🚫 Avoid “Any” in production — use IP ranges or service tags
• 📦 Group similar VMs into subnets for easier rule management
• 🧭 Name rules clearly: Allow-HTTP-From-Internet, Deny-All-Outbound, etc.
• 🧠 Use service tags (like Internet, VirtualNetwork) for cleaner rule
• 🧭 Document rule intent in the NSG name and description

🧭 Final Takeaways

• NSGs are stateless: they don’t remember past traffic
• Rules apply in both directions — inbound and outbound
• Priority matters: lower number wins
• NSGs are your first layer of defense — simple, fast, and essential

🔜 What’s Next?

You’ve built NSGs. You’ve defined rules. You’ve secured your subnets.

But here’s a real-world challenge:

What happens when you deploy 1,000 VMs into a single subnet?

Let’s say half of them are web servers, some are app servers, and others are database nodes. You want to allow HTTP only to web servers, SQL only to databases, and RDP only to a few admin boxes.

Now imagine writing NSG rules for each IP manually. Or worse — trying to track which IP belongs to which role.

That’s where things break down.

❗ NSGs don’t understand “roles.” They only understand IPs.

So how do you group VMs by function, not by address?

In the next session, we’ll explore Application Security Groups (ASGs) — Azure’s way of tagging VMs by purpose and writing NSG rules that target those tags.

It’s like saying:

“Allow HTTP to all machines tagged as WebServers.” “Block internet access from anything tagged as Backend.”

No IPs. No manual tracking. Just clean, scalable logic.

Let’s make NSGs smarter — by combining them with ASGs.