Deploy Azure Landing Zone Accelerator with a Canary Pattern for Non-Production

Question

A proof of concept is being developed for deploying an Azure Landing Zone using the Azure Landing Zone Accelerator, specifically focusing on a Hub and Spoke Virtual Network with Azure Firewall.

The goal is to fulfill the requirements for a Non-Production environment that mirrors the Production Azure Landing Zone, specifically implementing a Canary pattern. Has anyone encountered a similar scenario, and what guidance or best practices can be shared?

Answer 1

Hi ,

Thanks for reaching out to Microsoft Q&A.

Canary Pattern in Infrastructure

Canary pattern is not only for app deployments. In infra, it means:

Test network or infra changes (like NSG, UDR, Firewall rules) in a limited segment (canary spoke).

  Promote these to wider environments after validation.
  
     Prevents blast radius for infra misconfigurations.
     

Azure Landing Zone Accelerator:

Uses Terraform or Bicep for deployment.

Provides modular and opinionated infra-as-code templates.

Includes Hub-and-Spoke, Firewall, Route tables, Policies, Log Analytics, etc.

Recommended Approach youcan try:

Phase 1: Set up Core Landing Zone with Canary Design

1. Deploy Hub-and-Spoke using ALZ Accelerator:

Deploy the Hub with core services: Azure Firewall, DNS, Log Analytics.

• Deploy a Nonprod Spoke that will act as a Canary spoke.

1. Tag Canary Spoke:
   • Use a clear naming/tagging convention: ex: env=canary, purpose=infra-validation.
   Scoped Routing & Firewall Policies: Isolate this spoke with dedicated UDRs and Firewall policy.

     Allow only outbound and test-specific rules.
   
        Avoid peering it directly to other non-prod spokes initially.
   
        Deploy a CI/CD Pipeline:
   
           Build pipelines that allow Canary spoke deployment with controlled parameter sets.
   
              Include test scripts for NSGs, route validation, firewall egress, etc.
   

Best Practices

Security & Isolation

• Isolate Canary Vnet fully from other non-prod resources using NSGs and Firewall.

Do not allow inbound traffic from other VNets unless explicitly needed for testing.

Promote via GitOps

• Maintain a GitOps-based branching strategy:
  • Canary branch -> Non-Prod branch -> Prod branch.
  Canary commits are promoted only after validation.

Observability

Use Log Analytics to collect Firewall, NSG, and Traffic Flow logs.

Validate rule effectiveness in Canary before promoting.

Canary Scope

• Canary should reflect changes you want to validate:

New route configurations.

Firewall policies (DNS, FQDN tags, etc.).

• New spoke Vnet patterns.
• Platform automation (ex: Azure Policy DeployIfNotExists).

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.