Site icon Digital Thought Disruption

Automating Azure Local SDN with PowerShell, WAC, and Bicep: Step‑by‑Step Guide

Paul Bryant

TL;DR

Introduction

Azure Local SDN (formerly Azure Stack HCI SDN) introduces software-defined networking to on-premises infrastructure. As enterprises seek agility and consistent governance across hybrid environments, automating the configuration and management of SDN becomes essential. Using PowerShell, Windows Admin Center (WAC), and Bicep together allows infrastructure teams to move away from manual provisioning and toward scalable, repeatable, and compliant operations.

Prerequisites

Before beginning, ensure the following prerequisites are in place:

Infrastructure

Tools & Modules

Official Documentation

Refer to Microsoft’s up-to-date requirements here:
Microsoft Azure Local SDN Prerequisites

Step 1: Automating via Windows Admin Center

Windows Admin Center provides a graphical wizard to automate core SDN components such as the Network Controller, Software Load Balancer (SLB), and Gateway virtual appliances.

Steps:

  1. Open WAC and connect to your Azure Local cluster.
  2. Go to SDN Infrastructure and launch the wizard.
  3. Provide the necessary host, network, and storage configurations.
  4. Validate settings and complete the deployment.

Although WAC simplifies the process, its automation is limited to initial deployment. For full repeatability and portability, combine it with scripting (PowerShell and Bicep).

Step 2: PowerShell Automation

Use PowerShell for programmatic control over SDN resources.

Example: Create SDN Virtual Network & Subnet

Connect-AzAccount
$rg = "SDN-ResourceGroup"

$vnet = New-AzVirtualNetwork -Name "SDN-VNet" -ResourceGroupName $rg `
  -Location "centralus" -AddressPrefix "10.10.0.0/16"

Add-AzVirtualNetworkSubnetConfig -Name "TenantSubnet" `
  -AddressPrefix "10.10.1.0/24" -VirtualNetwork $vnet

$vnet | Set-AzVirtualNetwork

Example: Create NSG with ACL Rules

$nsg = New-AzNetworkSecurityGroup -Name "TenantNSG" `
  -ResourceGroupName $rg -Location "centralus"

Add-AzNetworkSecurityRuleConfig -Name "AllowInternal" `
  -NetworkSecurityGroup $nsg -Direction Inbound `
  -Priority 200 -Access Allow -Protocol * `
  -SourceAddressPrefix "10.10.1.0/24" `
  -DestinationAddressPrefix "10.10.1.0/24" `
  -SourcePortRange * -DestinationPortRange *

$nsg | Set-AzNetworkSecurityGroup

Step 3: Declarative Bicep Template

Use the following reusable Bicep file to provision the SDN fabric declaratively:

param location string = 'centralus'
param vnetName string = 'SDN-VNet'
param vnetPrefix string = '10.10.0.0/16'
param subnetName string = 'TenantSubnet'
param subnetPrefix string = '10.10.1.0/24'

resource vnet 'Microsoft.Network/virtualNetworks@2023-02-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: { addressPrefixes: [vnetPrefix] }
    subnets: [
      {
        name: subnetName
        properties: {
          addressPrefix: subnetPrefix
        }
      }
    ]
  }
}

resource nsg 'Microsoft.Network/networkSecurityGroups@2023-02-01' = {
  name: '${vnetName}-nsg'
  location: location
  properties: {
    securityRules: [
      {
        name: 'AllowInternal'
        properties: {
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '*'
          sourceAddressPrefix: subnetPrefix
          destinationAddressPrefix: subnetPrefix
          access: 'Allow'
          priority: 200
          direction: 'Inbound'
        }
      }
    ]
  }
}

output vnetId string = vnet.id
output subnetId string = vnet.properties.subnets[0].id

Deploy via CLI:

az deployment group create \
  --resource-group SDN-ResourceGroup \
  --template-file azure-local-sdn.bicep

Step 4: Integrating into CI/CD Pipelines

Azure Local automation fits into broader CI/CD strategies using GitHub Actions, Azure DevOps, or Jenkins. Here’s a simplified GitHub Actions job:

jobs:
  deploy-sdn:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install Bicep
        run: az bicep install

      - name: Azure Login
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Deploy SDN Infrastructure
        run: |
          az deployment group create \
            --resource-group SDN-ResourceGroup \
            --template-file azure-local-sdn.bicep

Real‑World Example: Multi‑Tenant SDN Provisioning

Scenario: An enterprise service provider manages three tenant environments, each requiring isolated SDN resources on shared Azure Local infrastructure.

Goal: Automate provisioning of VNets, ACLs, and service endpoints using templates and scripts for scale.

Steps Taken:

  1. Deployed Network Controller and SLB via WAC wizard.
  2. Created tenant-specific virtual networks and NSGs using parameterized PowerShell scripts.
  3. Used Bicep templates to maintain consistent subnet naming and ACL policies across tenants.
  4. Integrated deployment into a GitHub pipeline that triggers on pull requests for each tenant’s configuration repo.
  5. Used Azure Arc to monitor each SDN deployment remotely, ensuring compliance and availability.

Outcome: Reduced provisioning time per tenant from ~2 hours (manual) to under 15 minutes, with complete audit trails and version control.

Best Practices & Common Pitfalls

Best Practices

Common Pitfalls

Conclusion

Automating Azure Local SDN is no longer optional—it’s a strategic requirement for hybrid cloud success. With PowerShell, Bicep, and WAC working together, you can build secure, repeatable, and scalable SDN infrastructure that meets enterprise performance and compliance needs.

This guide gave you not just steps—but reusable templates, proven real-world implementation patterns, and a roadmap to integrate network automation into your DevOps ecosystem.

If you’re managing multiple tenants, SDN automation gives you a measurable ROI: faster time to deploy, stronger policy control, and repeatable governance.

What’s next?

*The thoughts and opinions in this article are mine and hold no reflect on my employer*

Exit mobile version