Elementor #2358 – Kazumaconsulting

Best Practices for Azure Non-Prod Environments

what is the best practice deployment of a dev, test and migration environment in an azure non-prod tenant?

Of course. This is a classic and critical question for Azure governance and cost management. A well-architected non-production environment setup is foundational for security, efficiency, and reliability.

Here is a comprehensive breakdown of the best practices for deploying Dev, Test, and Migration environments in a dedicated Azure non-production tenant.

Core Philosophy: Isolation, Consistency, and Cost Control

The guiding principles are:

Isolation: Prevent accidental impact between environments.
Consistency: Ensure environments are identical replicas to eliminate “it works on my machine” problems.
Cost Control: Aggressively manage and minimize spending in non-prod.

Tenant and Subscription Strategy

This is the highest level of isolation.

Best Practice: Use a separate Azure AD Tenant for your non-production workloads.
- Why? This provides a hard security boundary. Prod and Non-Prod user accounts, permissions, and policies are completely separate. A misconfiguration in non-prod cannot directly impact production.
Subscription Model: Within the non-prod tenant, use dedicated subscriptions for each environment type.
- Common Structure:
  - Sub – NonProd – Dev
  - Sub – NonProd – Test (or SIT/UAT)
  - Sub – NonProd – Migration
- Why?
  - Cost Management: You can set spending quotas and budgets at the subscription level. It’s easy to see “Test costs $X per month.”
  - Management Boundary: You can assign different teams (Dev, QA) different permissions per subscription.
  - Resource Limits: Isolates subscription-level resource limits (e.g., vCPU quotas).

Management Group Hierarchy

Use Management Groups to efficiently apply governance across your subscriptions.

text

Non-Prod Tenant Root Group

│

├── Non-Prod Landing Zones

│ │

│ ├── Platform (Optional: for shared services like a non-prod jumpbox, monitoring)

│ │

│ ├── Dev

│ │ └── (Sub – NonProd – Dev)

│ │

│ ├── Test

│ │ └── (Sub – NonProd – Test)

│ │

│ └── Migration

│ └── (Sub – NonProd – Migration)

│

└── Sandbox (Optional: for experimental, ungoverned work)

└── (Sub – Sandbox – *)

Networking Topology

The goal is to mimic production as closely as possible while maintaining isolation.

Hub-and-Spoke Model (Recommended):
- Hub VNet: Deploy a single, shared hub VNet in a dedicated subscription (e.g., the “Platform” subscription). This contains shared services:
  - Azure Firewall (for outbound/inbound traffic control)
  - VPN/ExpressRoute Gateway (if connecting to on-premises)
  - Domain Controllers (if needed for non-prod AD)
- Spoke VNets: Each environment (Dev, Test, Migration) gets its own spoke VNet in its respective subscription.
  - vnet-nonprod-dev-weu-001
  - vnet-nonprod-test-weu-001
  - vnet-nonprod-mig-weu-001
- Peering: Spoke VNets peer to the Hub VNet. Never peer spokes together to maintain isolation.
Simpler Alternative: Standalone VNets: For less complex scenarios, each environment can have a completely isolated VNet with its own firewall/NVA. This is simpler but can be more costly and less consistent with a prod hub-spoke design.

Identity and Access Management (IAM)

Leverage the separate Azure AD tenant.

Groups are Key: Create Azure AD Groups for access control.
- RG-NonProd-Dev-Contributors
- RG-NonProd-Test-Contributors
- RG-NonProd-Migration-Contributors
- RG-NonProd-Dev-Readers
Role-Based Access Control (RBAC):
- Assign the groups to the appropriate Resource Group with the Contributor or Reader role. Avoid subscription-level assignments.
Privileged Identity Management (PIM): Use Azure AD PIM for Just-In-Time (JIT) access for elevated roles (e.g., User Access Administrator, Subscription Owner). Nobody should have standing owner/contributor access.

Deployment and Consistency: Infrastructure as Code (IaC)

This is non-negotiable for best practices.

Tooling: Use Terraform or Azure Bicep.
Source Control: Store all IaC code in a Git repository (e.g., Azure DevOps Repos, GitHub).
Pipeline-Based Deployment: Use CI/CD pipelines (e.g., Azure DevOps, GitHub Actions) to deploy your environments.
- The same Bicep/Terraform code is used for Dev, Test, and Migration, with parameter files (dev.params.json, test.params.json) providing environment-specific values (e.g., VM size, SKU tier).
Benefits: Ensures environments are 100% consistent, repeatable, and self-documenting.

Environment-Specific Configurations

Environment	Purpose	Key Characteristics
Dev	Active development, debugging, and feature building.	– Lowest cost SKUs (e.g., B-series VMs, Basic tiers). – Auto-shutdown policies on VMs (e.g., off at 7 PM). – Permissive networking for developers (but still secured!). – Deployed from CI/CD on every commit to a main branch.
Test	Quality Assurance, Performance/Load Testing, User Acceptance Testing (UAT).	– Mirrors Production specs closely, but can often be scaled down. – Uses production-like data (anonymized/sanitized). – Stable & Long-lived. Not rebuilt on every commit. – More restrictive access than Dev (only QA team has write access).
Migration	Testing and validating the migration of workloads from on-prem/source cloud.	– Temporary and Ephemeral. Exists only for the duration of a migration project. – Network connectivity to source systems. – Mirrors Production exactly for cutover rehearsal. – Heavily monitored for performance and compatibility.

Cost Optimization Guardrails

Azure Policy: Apply policies via Management Groups to enforce rules.
- Allowed VM SKUs: Prevent deployment of expensive VMs in non-prod.
- Enforce Tagging: Require CostCenter, Environment=Dev, Project tags on all resources.
- Allowed Locations: Restrict deployments to only your primary regions.
Budgets and Alerts: Set Azure Budgets with alerts at 50%, 75%, 90%, and 100% of the allocated budget for each subscription.
Automated Shutdown/Startup: Use Azure Automation or Azure DevTest Labs (great for Dev/Test) to automatically turn off VMs outside business hours.

Monitoring and Security

Central Log Analytics Workspace: Send all diagnostic logs (Activity, VM insights, App Insights) from all non-prod environments to a central Log Analytics workspace in the “Platform” subscription.
Microsoft Defender for Cloud: Enable at least the free tier for all subscriptions. It provides foundational security assessments and recommendations.

Summary: The Ideal State

Separate Non-Prod Tenant with dedicated subscriptions for Dev, Test, and Migration.
Management Groups to streamline policy and RBAC assignment.
Hub-Spoke Network to balance isolation with consistency and cost.
Infrastructure as Code (Bicep/Terraform) deployed via CI/CD Pipelines for 100% consistency.
Azure AD Groups & RBAC for secure, group-based access management.
Azure Policy & Budgets to enforce governance and control costs.
Centralized Monitoring for a unified view of non-prod health and security.

By implementing this structure, you create a secure, cost-effective, and highly automated foundation that supports agile development and reliable testing without risking your production environment.

This response is AI-generated, for reference only.

what is the purpose of the non-prod migration environment

The Non-Prod Migration Environment serves as a critical staging area for cloud migration projects. It’s a specialized environment designed specifically for testing, validating, and rehearsing the migration of workloads from source systems (on-premises or other clouds) to Azure before going live in production.

Primary Purposes and Use Cases:

Migration Testing and Validation

Technical Validation: Test the actual migration process without affecting production
Compatibility Testing: Verify applications work correctly in Azure after migration
Performance Baseline: Establish performance benchmarks in the cloud environment
Dependency Mapping: Identify and validate all application dependencies

Cutover Rehearsal

Practice Runs: Conduct full migration dry runs to refine the process
Timing Validation: Measure how long migrations actually take
Rollback Testing: Practice reversing migrations if issues arise
Documentation Validation: Test and improve migration runbooks

Technical Proof of Concept

Tool Validation: Test migration tools like Azure Migrate, Data Migration Service, etc.
Methodology Testing: Validate lift-and-shift vs. rearchitecture approaches
Network Configuration: Test VPN/ExpressRoute connectivity and bandwidth
Security Configuration: Validate NSGs, firewalls, and security policies

Key Activities in the Migration Environment:

Application Migration Testing

text

Source → Migration Environment → Validation → (Iterate) → Production

Migrate copies of production applications
Test functionality and integration points
Identify and resolve compatibility issues
Optimize configurations for cloud

Data Migration Validation

Test data transfer methods (offline shipping, online replication)
Validate data integrity and consistency
Performance test database operations
Verify backup/restore procedures in Azure

Disaster Recovery Testing

Use the migration environment as a DR target
Test failover and failback procedures
Validate RTO/RPO objectives can be met

Characteristics of a Migration Environment:

Aspect	Configuration
Lifespan	Temporary (weeks to months per project)
Network	Connected to source systems, isolated from other non-prod
Data	Production-like (often sanitized) data
Cost	Higher during active migration, can be deprovisioned later
Access	Restricted to migration team and application owners

Typical Workflow:

Setup: Provision migration environment with network connectivity to source
Discovery: Use tools to analyze source workloads
Replication: Copy workloads to migration environment
Testing: Validate functionality, performance, security
Optimization: Tune configurations based on test results
Rehearsal: Conduct cutover practice runs
Production Cutover: Execute final migration to production
Decommission: Tear down migration environment after project completion

Benefits:

Risk Reduction: Identify and fix issues before production migration
Confidence Building: Prove migration success to stakeholders
Process Refinement: Optimize migration procedures through practice
Team Training: Get migration teams comfortable with tools and processes
Budget Control: Avoid costly mistakes during production migration

The migration environment is essentially a safe sandbox for proving your migration strategy works before betting the business on it in production.

This response is AI-generated, for reference only.

in a SDLC, how is an app in non-prod tenant migration subscription moved to a prod subscription in a prod tenant?

Excellent question. Moving an application from a non-prod migration subscription to a production subscription and tenant is a critical, high-stakes phase in the SDLC. This process, often called “Cutover” or “Go-Live,” must be methodical, automated, and reversible where possible.

Here is a detailed breakdown of the process, following SDLC and modern DevOps principles.

Core Concept: The “Promotion” is a Deployment, Not a Move

It’s crucial to understand that you generally do not “move” the resources themselves (like lifting a VM from one subscription and dropping it in another). Instead, you re-deploy the application’s infrastructure and code into the production environment using the same proven IaC and deployment pipelines that were validated in non-prod.

The High-Level Process Flow

The entire process can be visualized in this flowchart, which outlines the key stages from final validation in non-prod to monitoring in production:

Now, let’s dive into the detailed stages that make up this process.

Phase 1: Pre-Cutover Preparation (The Foundation)

This is the most critical phase. Success is determined here.

Infrastructure as Code (IaC) Ready:
- The exact same Bicep/Terraform templates used and tested in the migration environment are parameterized for production.
- A separate parameters file (e.g., prod.main.parameters.json) contains production-specific values:
  - Subscription ID & Tenant ID
  - Resource Group Names (e.g., rg-prod-app-weu-001)
  - Higher SKUs (e.g., D4s_v3 instead of B2s)
  - Production-scale node counts (e.g., 5 AKS nodes instead of 2)
  - Production DNS names (e.g., app.contoso.com)
  - Production Key Vault references and secrets
CI/CD Pipeline Prepared:
- The deployment pipeline has a production stage that is gated (requires manual approval).
- This stage is configured to target the production subscription and tenant.
- The pipeline uses a Service Principal that has the necessary permissions (e.g., Contributor) in the Production Tenant.
Data Migration:
- For applications with databases, this is a key step.
- Strategy: Use a final transactional sync just before cutover.
- Process:
  - The production database is initially seeded from a backup of the non-prod migration database.
  - During the cutover window, the source application is put into read-only mode.
  - A final data sync is performed to capture any last-minute transactions.
  - The production application starts against the newly synced database.
DNS and Traffic Management Prepared:
- The production environment is deployed with an internal or test URL first.
- DNS records (e.g., app.contoso.com) are prepared with a low TTL (e.g., 5 minutes) but still point to the old system (or are disabled).

Phase 2: The Cutover Plan (The Runbook)

A detailed, step-by-step runbook is created and rehearsed. It includes:

Communication Plan: Notifying stakeholders, support teams, and users.
Prerequisite Checks: Verifying the production subscription has sufficient quotas, budgets are in place, etc.
Detailed Steps: A chronological list of every command to run and button to press.
Rollback Plan: Clear instructions for how to abort the cutover and revert to the previous state if critical issues are found.
Verification Steps: How to confirm each step was successful (health checks, smoke tests).

Phase 3: Execution – Deployment and Go-Live

This is the execution of the plan, corresponding to the flowchart above.

Final Sync & Source Freeze:
- The source application (e.g., on-premises) is put into a read-only or maintenance mode state.
- The final data sync is initiated.
Trigger Production Deployment:
- An authorized person (e.g., Release Manager) approves the production stage in the CI/CD pipeline.
- The pipeline executes, deploying the validated IaC and application code to the production subscription in the prod tenant.
Health Verification:
- Automated smoke tests run against the newly deployed production application (using its internal URL).
- The operations team manually verifies key functionality.
DNS Cutover / Traffic Shift:
- Once health is verified, the DNS record is updated to point to the new Azure application (e.g., Azure Front Door, Application Gateway, or the public IP of the app).
- Modern Approach: Use Blue-Green or Canary deployment techniques with Azure Application Gateway or Front Door to route a small percentage of live traffic initially, then gradually increase to 100%.
Monitor Closely:
- Intense monitoring for errors, performance degradation, and infrastructure health using Azure Monitor, Application Insights, etc.

Phase 4: Post-Cutover

Decommission Old Environment:
- After a successful cutover and a predefined stabilization period (e.g., 48 hours), the old source environment can be powered down or decommissioned.
- The Non-Prod Migration Subscription is torn down until needed for the next migration project.
Update Documentation & Run Post-Mortem:
- Update all operational runbooks, network diagrams, and support documents to reflect the new production environment in Azure.
- Conduct a blameless post-mortem to capture lessons learned.

Key Technical Considerations

Identity & Secrets:
- Managed Identities must be reconfigured in the production subscription.
- All secrets and certificates must be rotated and stored in a Production Key Vault; never reuse non-prod secrets.
Networking:
- The production app will be in a new VNet, likely with stricter NSG rules and different firewall configurations. This must be part of the IaC.
Dependencies:
- The app might depend on other services (APIs, databases) that also need to be migrated. The cutover must be coordinated.

Summary: What is “Moved”?

You are not moving the VM/container. You are moving:

The Code: Via the deployment pipeline.
The Configuration: Via Infrastructure as Code.
The Data: Via the final database sync.
The Traffic: Via DNS or traffic manager changes.

This approach ensures consistency, reliability, and a clear path to rollback, making the production deployment a controlled and repeatable event rather than a risky “lift and shift.”

Should a Azure SDE subscription in a non-prod Azure tenant be used for development and testing?

No, an Azure SDE (Software Development Engineer) subscription should generally NOT be used for organized development and testing in an enterprise environment. Here’s why and what you should use instead:

What an SDE Subscription Is Actually For

SDE subscriptions are designed for:

Individual experimentation and learning Azure
Personal side projects and proof-of-concepts
Azure certification preparation and hands-on labs
Testing individual Azure features in isolation

Why SDE Subscriptions Are Problematic for Team Development

Lack of Enterprise Governance

No Azure Policy enforcement at scale
Limited management group support
Difficult to implement consistent tagging, naming standards, and cost controls
No centralized monitoring and security baseline

Identity and Access Management Challenges

Individual-based access rather than group-based RBAC
Difficult to manage team permissions consistently
No integration with enterprise PIM (Privileged Identity Management)
Personal Microsoft account dependencies

Cost Management Issues

No enterprise agreement pricing – you pay retail rates
Limited cost visibility and allocation capabilities
Difficult to charge back to projects or teams
No centralized budget management

Operational Limitations

Subscription limits and quotas are personal, not organizational
No integration with enterprise DevOps pipelines
Limited support options compared to enterprise support
Isolated from enterprise network topology (VPN, ExpressRoute)

Recommended Enterprise Approach

Use Enterprise Dev/Test Subscriptions

text

Non-Prod Tenant

├── Management Group – Dev

│ └── Subscription – Enterprise Dev/Test

├── Management Group – Test

│ └── Subscription – Enterprise Test

└── Management Group – Shared Services

└── Subscription – Platform

Benefits of Enterprise Dev/Test Subscriptions:

Significant cost savings – discounted rates for development workloads
Proper Azure Policy and governance enforcement
Group-based RBAC with Azure AD integration
Centralized cost management with budgets and alerts
Enterprise support inclusion
Integration with Azure DevOps and enterprise CI/CD

When SDE Subscriptions Might Be Acceptable

Limited Scenarios:

Individual developers learning Azure before enterprise onboarding
Very small startups without IT governance requirements
Temporary experimentation with new Azure services not yet approved for enterprise use
Personal projects completely separate from work

Even Then, Consider:

Azure Free Account for initial exploration
Visual Studio Dev/Test credits if available
Sandbox subscriptions in your enterprise tenant

Best Practice Alternative: Sandbox Model

If you need flexible environments for experimentation:

text

Non-Prod Tenant

├── Management Group – Sandbox

│ ├── Subscription – Sandbox – Team A

│ ├── Subscription – Sandbox – Team B

│ └── Subscription – Sandbox – Individual

└── Management Group – Governed Dev

└── Subscription – Enterprise Dev/Test

Sandbox subscriptions:

Are proper enterprise subscriptions
Have relaxed policies for experimentation
Still benefit from enterprise pricing and support
Can be easily monitored and controlled

Migration Path from SDE to Enterprise

If developers are currently using SDE subscriptions:

Provision enterprise Dev/Test subscriptions
Set up proper governance (policies, budgets, naming standards)
Migrate workloads using Infrastructure as Code
Train developers on the new enterprise processes
Establish sandbox subscriptions for ongoing experimentation

Key Takeaway

While SDE subscriptions serve a purpose for individual learning, they lack the governance, cost control, and enterprise integration needed for professional software development. Invest in proper enterprise Dev/Test subscriptions to ensure security, cost management, and operational excellence while still providing developers the flexibility they need.

This response is AI-generated, for reference only.

can different business projects have their own SDE subscription in a non-prod Azure tenant, whilst sharing a common test subscription?

No, this is not a recommended approach. While technically possible, using multiple SDE subscriptions for different business projects while sharing a test subscription creates significant operational complexity and violates several Azure governance best practices.

Why This Model Is Problematic

SDE Subscription Limitations

No Enterprise Pricing: Each SDE subscription pays retail rates vs. Enterprise Dev/Test discounts
Individual Accountability: Subscriptions are tied to individuals, not projects or teams
Governance Overhead: Managing policies, budgets, and access across multiple SDE subscriptions is cumbersome
Limited Integration: Difficult to implement consistent CI/CD pipelines across personal subscriptions

Architectural Inconsistency

text

Problematic Structure:

Non-Prod Tenant

├── SDE Subscription – Project A (Individual-owned)

├── SDE Subscription – Project B (Individual-owned)

├── SDE Subscription – Project C (Individual-owned)

└── Shared Test Subscription (Enterprise)

The development and test environments become fundamentally different in terms of:

Cost structure and billing
Access control models
Policy enforcement
Network topology
Security baselines

Recommended Enterprise Approach

Model 1: Dedicated Subscriptions per Project (Recommended)

text

Non-Prod Tenant

├── Management Group – Project Alpha

│ ├── Subscription – Dev

│ └── Subscription – Test

├── Management Group – Project Beta

│ ├── Subscription – Dev

│ └── Subscription – Test

└── Management Group – Shared Platform

└── Subscription – Shared Services

Benefits:

Consistent governance applied via management groups
Project-level cost tracking and accountability
Isolated security boundaries between projects
Same architecture in Dev and Test environments

Model 2: Shared Subscriptions with Resource Groups

text

Non-Prod Tenant

├── Subscription – Enterprise Dev/Test

│ ├── RG – Project Alpha – Dev

│ ├── RG – Project Alpha – Test

│ ├── RG – Project Beta – Dev

│ └── RG – Project Beta – Test

└── Subscription – Shared Platform

Benefits:

Simplified subscription management
Maximum resource sharing and cost efficiency
Still allows some project isolation at resource group level

Hybrid Approach: When Limited Sharing Makes Sense

If you must have some shared environments, here’s a better model:

text

Non-Prod Tenant

├── Management Group – Project Alpha

│ ├── Subscription – Dev

│ └── Subscription – Test

├── Management Group – Project Beta

│ ├── Subscription – Dev

│ └── Subscription – Test

├── Management Group – Shared

│ ├── Subscription – Shared Test (for integration testing)

│ └── Subscription – Performance Test

└── Management Group – Platform

└── Subscription – Shared Services

Shared Test Subscription would be used for:

Integration testing between projects
Performance/Load testing environments
Third-party system integration testing
User Acceptance Testing (UAT)

Key Governance Considerations

If You Must Use This Model:

Convert SDE to Enterprise Subscriptions
- Use Visual Studio Enterprise subscriptions with monthly credits
- Or proper Enterprise Dev/Test subscriptions
Implement Consistent Management

bash

# Apply same policies to all subscriptions

az policy assignment create \

–name ‘allowed-vm-skus’ \

–policy <policy-definition> \

–params ‘{ “listOfAllowedSKUs”: { “value”: [“Standard_B2s”, “Standard_D2s_v3”] } }’

Centralize Cost Management
- Create budgets for each SDE subscription
- Use Azure Cost Management + Budgets alerts
- Implement resource tagging standards

Real-World Compromise

If you’re constrained by budget or organizational politics:

text

Non-Prod Tenant

├── Management Group – Business Projects

│ ├── Subscription – Project A (Enterprise Dev/Test)

│ ├── Subscription – Project B (Enterprise Dev/Test)

│ └── Subscription – Shared Test (Enterprise Dev/Test)

└── Management Group – Sandbox

└── Subscription – Individual SDE (for experimentation only)

Bottom Line

Avoid mixing SDE subscriptions with enterprise test subscriptions. The inconsistency creates more problems than it solves. Instead, use:

Enterprise Dev/Test subscriptions for all project environments
Management groups for consistent governance
Resource groups or dedicated subscriptions for project isolation
Shared subscriptions only for legitimate shared services

This approach provides the right balance of isolation, consistency, and cost efficiency while maintaining enterprise-grade governance and security.

Xxx

what is Australian ASD requirement for segregation of dev and test environments in a SDE software development environment

Excellent and critical question. The Australian Signals Directorate (ASD) has stringent requirements for environmental segregation, especially for systems handling official or sensitive information.

Short Answer: While the ASD’s Information Security Manual (ISM) doesn’t prescribe a specific subscription model, it mandates strong logical separation between development, test, and production environments. Using a single SDE subscription for both dev and test would not comply with these mandates for any system beyond the lowest classification.

Key ASD ISM Principles for Environmental Segregation

The ISM is based on a risk-management framework. The following principles are directly relevant:

Fundamental Segregation Requirement (ISM-1758)

ISM-1758: Development and test environments are segregated from production environments.

Interpretation: This is non-negotiable. A “production environment” in the Azure context is the tenant and subscription hosting production data and applications. Your non-production tenant is the correct first step to achieve this.

Segregation WithinNon-Production (ISM-1803)

ISM-1803: Test data is not used in development environments.

Interpretation: This implicitly requires segregation between Dev and Test environments. Test environments often contain copies of production data (anonymised or not), which should never be present in a less-secure development environment. Sharing a single subscription makes it incredibly difficult to enforce this data governance rule.

Access Control (ISM-1233, ISM-1382, ISM-1401)

Principles of least privilege and separation of duties are paramount.

Interpretation:
- Developers should have write access to Dev, but only read (or no) access to Test.
- Testers should have write access to Test, but no write access to Dev to prevent untested code changes.
- Sharing a single SDE subscription makes it very difficult to implement granular Role-Based Access Control (RBAC) at this level, increasing the risk of unauthorized changes or data exposure.

Data Sanitisation (ISM-1529)

ISM-1529: Test data is generated, anonymised or sanitised production data.

Interpretation: The test environment must have security controls comparable to production to protect this (sanitised) data. Development environments typically have weaker controls. A shared subscription often means a shared network, shared Key Vaults, and shared security policies, which is non-compliant.

Compliance Analysis: SDE Subscription vs. ASD Requirements

ASD Requirement	Single SDE Subscription for Dev & Test	Recommended Compliant Approach
Segregation of Dev & Test (ISM-1803)	FAILS. Only resource group separation. High risk of accidental cross-environment access or configuration drift.	Separate Subscriptions for Dev and Test within the non-prod tenant.
Principle of Least Privilege	DIFFICULT. RBAC is at subscription/resource group level. Hard to prevent developers from accessing test resources.	Dedicated Subscriptions allow precise RBAC. Use Management Groups to apply consistent policy.
Protection of Test Data	HIGH RISK. Shared underlying subscription admin roles, potential for shared networking (VNet).	Isolated Subscriptions with separate VNets, firewalls, and Key Vaults.
System Hardening	DIFFICULT. Azure Policy assignments are scoped to subscription. You cannot have different security baselines for Dev and Test in one sub.	Separate Subscriptions allow different policy assignments (e.g., stricter rules for Test, more relaxed for Dev).

Recommended ASD-Compliant Architecture

Here is a compliant structure for an SDE project handling OFFICIAL: Sensitive or PROTECTED data:

Key Components:

Dedicated Subscriptions: Sub-DEV, Sub-TEST, Sub-SHARED.
Management Group: To apply baseline Azure Policies to all non-production environments.
Hub & Spoke Network:
- A central Hub VNet (in a dedicated subscription) with Azure Firewall.
- Separate Spoke VNets for Sub-DEV and Sub-TEST, peered to the Hub only, not to each other.
Identity and Access:
- Different Azure AD groups: SG-AZ-DEV-Contributors, SG-AZ-TEST-Contributors.
- Developers are members of the Dev group only. Testers are members of the Test group only.

What about an “SDE Software Development Environment”?

The term “SDE” is ambiguous in this context.

If “SDE” means a low-assurance, personal developer subscription: It is not suitable for any project involving OFFICIAL:Sensitive or PROTECTED data.
If “SDE” is being used to describe the nature of the project (Software Development Environment): You must build it using enterprise-grade, properly governed Azure subscriptions (like Enterprise Dev/Test) as per the architecture above.

Actionable Checklist for Compliance

Use Separate Subscriptions: Mandatory for Dev, Test, and any other environment tier.
Implement Network Segmentation: Use Hub-Spoke with separate spokes for each environment.
Enforce RBAC: Apply the principle of least privilege using Azure AD groups. Developers should not have write access to Test.
Classify and Protect Data: Ensure TEST data is sanitised. Use encryption and Azure Key Vault with access policies scoped per environment.
Automate with IaC: Use Infrastructure as Code (Terraform/Bicep) to ensure environment consistency and avoid manual configuration drift.
Apply Security Policies: Use Azure Policy to enforce security baselines (e.g., mandatory disk encryption, no public IPs) with stricter assignments for the TEST subscription.

Conclusion: For any Australian Government project or service provider bound by the ISM, using a single Azure SDE subscription for both development and testing would be a clear compliance failure. The ASD’s principles require strong logical separation, which is best and most securely achieved through dedicated subscriptions within a properly governed non-production tenant.

Xxx

in a Azure Landing Zone disaster recovery to a secondary region, are there any physical hardware required in the core network, such as express routes

No, you do not need additional physical hardware in the secondary region for ExpressRoute in an Azure Landing Zone disaster recovery setup. The physical connectivity is already part of the ExpressRoute architecture.

Here’s the detailed explanation:

ExpressRoute Physical Architecture for DR

How ExpressRoute Provides Built-in DR

text

Primary Region (e.g., Australia East) Secondary Region (e.g., Australia Southeast)

┌───────────────────────┐ ┌───────────────────────┐

│ Azure VNet (Hub) │ │ Azure VNet (Hub) │

│ ┌───────────────┐ │ │ ┌───────────────┐ │

│ │ExpressRoute │ │ │ │ExpressRoute │ │

│ │ Gateway │◄─────────────────────►│ Gateway │ │

│ └───────────────┘ │ │ └───────────────┘ │

└───────────┬───────────┘ └───────────┬───────────┘

│ │

└───────┬─────────────────────────────────┘

│

┌───────────────┴─────────────────┐

│ ExpressRoute Circuit │

│ (Same physical connection) │

└───────────────┬─────────────────┘

│

┌───────────────┴─────────────────┐

│ ExpressRoute Provider │

│ (e.g., Telstra, Megaport) │

└───────────────┬─────────────────┘

│

┌───────┴────────┐

│ Your On-Prem │

│ Data Center │

└────────────────┘

Key Components That Eliminate Additional Hardware

ExpressRoute Circuit Redundancy

Single Circuit, Multiple Peerings: One ExpressRoute circuit can connect to both primary and secondary Azure regions simultaneously
No additional physical ports or circuits needed for the secondary region
Global Reach: If using ExpressRoute Global Reach, the same circuit provides connectivity to multiple regions

ExpressRoute Gateway Scaling

bicep

// Primary region gateway (Active)

resource primaryGateway ‘Microsoft.Network/virtualNetworkGateways@2023-05-01’ = {

location: ‘australiaeast’

properties: {

gatewayType: ‘ExpressRoute’

sku: ‘ErGw1AZ’ // AZ-enabled SKU for high availability

}

// Secondary region gateway (Standby)

resource secondaryGateway ‘Microsoft.Network/virtualNetworkGateways@2023-05-01’ = {

location: ‘australiasoutheast’

properties: {

gatewayType: ‘ExpressRoute’

sku: ‘ErGw1AZ’

}

Network Virtual Appliances (NVAs)

Software-based: Firewalls like Azure Firewall, Palo Alto, FortiGate are virtual appliances
No physical hardware required in Azure
Can be pre-provisioned in secondary region in standby mode

Recommended ExpressRoute DR Configurations

Option 1: Single Circuit with Dual Peerings (Most Common)

text

ExpressRoute Circuit (Primary)

├── Private Peering → Australia East

└── Private Peering → Australia Southeast

Cost-effective: No additional circuit costs
RTO: Medium (automatic failover)
Dependency: Single circuit becomes SPOF

Option 2: Dual Circuits with Cross-Connects

text

ExpressRoute Circuit 1 (Primary) ExpressRoute Circuit 2 (Secondary)

↓ ↓

Australia East Australia Southeast

↓ ↓

Different physical providers/paths for true redundancy

High Availability: Eliminates circuit-level SPOF
Cost: Higher (2 circuits)
RTO: Lower (active-active possible)

Option 3: ExpressRoute + VPN Gateway

ExpressRoute primary + Site-to-Site VPN as backup
Provides connectivity if ExpressRoute fails entirely

What Actually Needs to Be Deployed in DR Region

Infrastructure Components (All Virtual/Software-Based)

ExpressRoute Gateway (in secondary region VNet)
Azure Firewall or third-party NVA
Route Tables and UDRs
Network Security Groups (NSGs)
Load Balancers (internal/external)
Application Gateways / WAF

Key Configuration Steps

bicep

// DR ExpressRoute connection in secondary region

resource drConnection ‘Microsoft.Network/connections@2023-05-01’ = {

location: ‘australiasoutheast’

properties: {

authorizationKey: authorizationKey

expressRouteCircuit: {

id: expressRouteCircuit.id // Same circuit as primary

}

peerings: [

{

id: ‘$(expressRouteCircuit.id)/peerings/AzurePrivatePeering’

}

]

}

Critical DR Considerations for ExpressRoute

BGP Route Management

Ensure BGP routes are advertised correctly to secondary region
Use AS Path prepending to influence route selection
Monitor route health with Network Watcher

DNS Strategy

Replicate DNS zones to secondary region
Consider Azure DNS Private Resolvers in both regions
Ensure DNS failover aligns with application failover

Capacity Planning

Size ExpressRoute gateways appropriately for DR traffic
Pre-provision sufficient bandwidth in secondary region
Test failover to validate capacity

Automation & Testing

powershell

# Example: Failover testing script

Start-AzVpnConnectionDiagnostic -ResourceGroupName “rg-network” `

-Name “er-connection-auseast-dr” `

-TargetResourceId $secondaryGateway.Id

Cost Optimization for DR

Use ErGw1AZ instead of higher SKUs if bandwidth requirements allow
Shut down secondary gateways during non-DR testing (if using non-AZ SKUs)
Leverage Azure Reservations for committed ExpressRoute circuit usage
Use cool/archive storage for DR backups and replicas

Bottom Line

No physical hardware is required in the secondary region. The entire Azure Landing Zone DR strategy for networking relies on:

The same physical ExpressRoute circuit serving multiple Azure regions
Virtual networking components (gateways, firewalls, load balancers)
Software-defined networking configurations
Cloud-native redundancy built into Azure’s global infrastructure

The investment is in configuration, licensing (for third-party NVAs), and circuit capacity—not physical hardware in the secondary region.