Azure Bastion Developer SKU, The Hidden Trap That Breaks Production-Grade Network Security

Why your “secure by default” NSG rules mysteriously stop working

Have you ever spent hours debugging why Azure Bastion refuses to connect to your VMs, only to discover that your perfectly valid Network Security Group (NSG) rules are being entirely ignored?

If you’re using Azure Bastion Developer SKU to simulate a production environment with strict security boundaries, I have bad news: you’re testing the wrong thing.

This article explains a critical but poorly documented difference between Bastion Developer and Standard SKUs that can invalidate your entire security testing strategy.

The Setup: A Standard Production Pattern

Let’s start with a typical hub-and-spoke architecture that any cloud architect would recognize:

Network Design:

• Hub VNet hosting Azure Bastion in AzureBastionSubnet (10.10.1.0/26)
• Management VM in a separate subnet snet-mgmt-dev
• No public IPs on VMs (security best practice)

NSG Security Model (Standard Production Pattern):

• Priority 100: Allow SSH from 10.10.1.0/26 (Bastion subnet)
• Priority 130: Deny SSH from VirtualNetwork (block lateral movement)

This is textbook zero-trust networking:

• Explicitly allow for legitimate traffic (Bastion).
• Explicit deny for everything else in the VNet
• Prevent lateral movement if one VM is compromised.

Architecture With standard Bastion

Legend:

• 🛡️ Bastion in AzureBastionSubnet (10.10.1.0/26)
• 💻 Management VM in snet-mgmt-dev (10.10.0.0/24)
• ✅ Authorized Traffic in NSG rule priority 100
• 🚫 Blocked Traffic in NSG rule priority 130

Expected behavior: Bastion can SSH to the VM, but no other VNet resource can.

Actual behavior with Developer SKU: Bastion fails completely.

Remove the deny rule? Suddenly it works. Add it back? Fails again.

Something is fundamentally wrong here.

The Problem: Developer SKU Doesn’t Do What You Think

After troubleshooting with NSG flow logs and effective security rules, the root cause becomes clear:

Azure Bastion Developer SKU does not source traffic from the Bastion subnet.

Architecture With Developer Bastion

Legend (Developer SKU):

• 🛡️ Bastion configured in subnet 10.10.1.0/26 but actually uses 168.63.129.16
• 💻 Management VM cannot be reached
• ❌ All traffic blocked because source IP doesn’t match NSG rule
• 🚫 NSG deny rule still blocks other VMs

Instead, it routes traffic through 168.63.129.16 , a special Azure platform IP address used for:

• Azure DHCP Services
• DNS resolution
• Health probes
• Platform management traffic

This IP exists outside your VNet’s address space and is treated differently by NSG evaluation rules.

How NSG Evaluation Actually Works

Let’s trace what happens when Bastion Developer tries to SSH to your VM:

What you configured:

• Source: 10.10.1.0/26 (Bastion subnet)
• Destination: VM private IP
• Port: 22

What NSG actually sees:

• Source: 168.63.129.16 (platform IP)
• Destination: VM private IP
• Port : 22

NSG Rule Evaluation:

Actual source seen by the NSG: 168.63.129.16 (not 10.10.1.0/26)

                             ↓

Rule Priority 100 (allow from 10.10.1.0/26) → NO MATCH → skip

                             ↓

Rule Priority 130 (deny from VirtualNetwork) → MATCH → DENIED

Why Removing the Deny Rule “Fixes” It

When you remove the explicit deny rule:

1. Priority 100 still doesn’t match (168.63.129.16 ≠ 10.10.1.0/26)
2. No more explicit deny at Priority 130
3. Traffic falls through to default rule: AllowVNetInBound (Priority 65000)
4. SSH succeeds.

This proves that Bastion Developer fundamentally bypasses your Bastion subnet rules.

Your carefully designed security boundary never gets evaluated.

The Critical Difference: Developer vs. Standard SKU

With Bastion Standard:

• Traffic genuinely originates from AzureBastionSubnet
• Your Priority 100 allow rule matches correctly
• Your Priority 130 deny rule protects against lateral movement
• The entire security model works as designed.

This is why Microsoft documentation and production examples assume Standard SKU.

When Developer SKU Makes Sense (And When It Doesn’t)

Use Developer SKU for:

• Quick personal connectivity tests
• Cost-optimized dev environments without strict security
• Simple VM access validation

Do NOT use Developer SKU for:

• Production environment simulation
• Security posture testing
• Hub-and-spoke architecture validation
• NSG rule design and testing
• Compliance or audit scenarios
• Any scenario where “prod-like” matters

The Real Cost of Using the Wrong SKU

Beyond the immediate technical issue, using Developer SKU for production simulation creates these problems:

1. False Security Assumptions

• Your NSG rules appear broken when they’re actually correct
• You end up designing around platform exceptions instead of real security boundaries.

2. Non-Portable Architecture

• NSG exceptions for 168.63.129.16 don’t exist in real production
• Your lab environment diverges from actual production behavior.

3. Wasted Troubleshooting Time

• Hours debugging “NSG issues” that are actually SKU behavior differences
• Misleading symptoms that don’t reflect real-world problems

4. Incorrect Documentation

• Security runbooks based on Developer SKU won’t work in production
• Team knowledge becomes unreliable.

The Bottom Line

If your goal is to simulate production environments, test security controls, or validate network architectures, use Bastion Standard SKU.

The cost difference is minimal compared to the architectural correctness you gain:

• NSG rules behave predictably.
• Security boundaries work as designed
• Your lab environment accurately represents production.
• Time saved debugging fake issues

Azure Bastion Developer SKU serves a purpose, but that purpose is not “production environment simulation.”

Standard SKU isn’t more expensive because Microsoft wants more money; it’s because it implements the full production-grade networking model that makes your security rules actually work.

Key Takeaways

1. Bastion Developer SKU routes traffic through platform IP 168.63.129.16
2. This bypasses subnet-based NSG rules completely.
3. Standard production NSG patterns will fail with Developer SKU
4. Standard/Premium SKU is required for production-accurate testing
5. Always validate SKU behavior matches your testing objectives.

Additional Resources

• Azure Bastion Overview
• Azure Bastion and NSG Configuration
• Azure Bastion Developer SKU Documentation
• Understanding Azure Platform IP 168.63.129.16
• Network Security Groups Rule Evaluation

Have you encountered similar SKU behavior differences in Azure? Share your experiences in the comments.

Tags: Azure, Cloud Security, Network Security, Bastion, NSG, DevOps, Infrastructure as Code

Credential to our Cloud & Devops Expert Salmen Hitana