Generated banner for Azure Enterprise Infra Planner
Generated logo for Azure Enterprise Infra Planner

Azure Enterprise Infra Planner

MicrosoftOfficialCreated by Microsoft

  • Skill
  • Workflow
  • Cloud and DevOps
  • MIT
  • No issues found

From the author

Architect and provision enterprise Azure infrastructure from workload descriptions. For cloud architects and platform engineers planning networking, identity, security, compliance, and multi-resource topologies with WAF alignment. Generates Bicep or Terraform directly (no azd). WHEN: 'plan Azure infrastructure', 'architect Azure landing zone', 'design hub-spoke network', 'plan multi-region DR topology', 'set up VNets firewalls and private endpoints', 'subscription-scope Bicep deployment', 'Azure Backup for VM workloads'. PREFER azure-prepare FOR app-centric workflows.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill guides users through a 7-phase pipeline to design and deploy Azure infrastructure. It processes workload descriptions to generate Bicep or Terraform code, supporting both greenfield deployments and additive updates to existing environments. The process includes research, planning, user approval, and automated validation using security and syntax checks before deployment.

What it does

  • Extracts insights from workload descriptions to inform infrastructure planning.
  • Researches Azure best practices and service-specific documentation.
  • Generates infrastructure plans and corresponding Bicep or Terraform code.
  • Validates generated IaC using syntax checks and security scanning tools.
  • Supports additive deployments for existing environments without modifying referenced resources.
  • Manages multi-resource topologies including networking, identity, and compliance configurations.

When to use it

  • When planning Azure infrastructure from a workload or architecture description.
  • When designing hub-spoke networks, landing zones, or multi-region topologies.
  • When setting up networking components like VNets, firewalls, and private endpoints.
  • When generating subscription-scope or multi-resource-group infrastructure code.

Advantages

  • Follows a structured, gated pipeline to ensure plan approval and code validation.
  • Integrates security scanning and syntax validation into the generation workflow.
  • Provides support for referencing existing resources to avoid accidental recreation.
  • Utilizes specific Azure schema data to ensure accurate resource definitions.

Usage examples

“Plan Azure infrastructure for a hub-spoke network with firewalls.”
The agent initiates the 7-phase pipeline, researching networking best practices and generating the corresponding IaC for the requested topology.
“Architect an Azure landing zone.”
The agent guides the user through requirements extraction and resource planning, resulting in a structured infrastructure plan and Bicep or Terraform files.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/azure-enterprise-infra-planner/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip azure-enterprise-infra-planner.zip -d .agents/skills

Documentation by Microsoft

Azure Enterprise Infra Planner

When to Use This Skill

Activate this skill when user wants to:

  • Plan enterprise Azure infrastructure from a workload or architecture description

  • Architect a landing zone, hub-spoke network, or multi-region topology

  • Design networking infrastructure: VNets, subnets, firewalls, private endpoints, VPN gateways

  • Plan identity, RBAC, and compliance-driven infrastructure

  • Generate Bicep or Terraform for subscription-scope or multi-resource-group deployments

  • Plan disaster recovery, failover, or cross-region high-availability topologies

Quick Reference

PropertyDetails
MCP toolsinsights_get, get_azure_bestpractices_get, wellarchitectedframework_serviceguide_get, microsoft_docs_fetch, microsoft_docs_search, bicepschema_get
CLI commandsaz deployment group create, az bicep build, az resource list, terraform init, terraform plan, terraform validate, terraform apply, checkov
Output schemaschema.md
Key referencesworkflow.md, waf-checklist.md, resources/, constraints/

Workflow (Start Here)

Follow the step-by-step instructions in workflow.md to execute the 7 phases of infrastructure planning and provisioning.

Architecture

The skill runs a 7-phase, gated pipeline. Input is triaged into one of two flows:

  • Greenfield — only new requirements; run the phases straight through.

  • Referenced (brownfield) — the user supplies something that already exists (a live resource / resource group / subscription, IaC or an infra plan, or a requirements doc). The same phases run, plus referenced-workload.md: existing resources are inventoried and referenced (never recreated), the new workload is wired into them, and Phase 7 deploys additively (incremental only — never modifying or destroying the referenced resources).

Every phase advances only after its gate passes. Phase 5 requires explicit user approval; Phase 6 is a hardened, self-verifying gate — the generated IaC must be secure-by-default, pass local validation (az bicep build / terraform validate) with zero errors, pass a checkov security scan with no unresolved high/critical findings, and the skill must show the command output and emit a completion self-check before advancing; Phase 7 requires an explicit, risk-acknowledged deploy confirmation.

flowchart TD
    IN([Input]) --> TRIAGE{Existing infra<br/>referenced?}
    TRIAGE -- "No (greenfield)" --> P1
    TRIAGE -- "Yes (referenced)" --> RW[/referenced-workload.md:<br/>inventory + assign roles<br/>reference, never recreate/]
    RW --> P1

    subgraph PIPE [7-phase gated pipeline]
        direction TB
        P1[Phase 1 · Extract insights] --> P2[Phase 2 · Research best practices]
        P2 --> P3[Phase 3 · Research resources]
        P3 --> P4[Phase 4 · Generate plan]
        P4 --> P5{Phase 5 · Verify<br/>user approves?}
        P5 -- "no" --> P4
        P5 -- "approved" --> P6[Phase 6 · Generate IaC]
        P6 --> VAL{Validate<br/>az bicep build /<br/>terraform validate}
        VAL -- "errors" --> P6
        VAL -- "clean" --> P7{Phase 7 · Deploy<br/>risk-ack confirm?}
    end

    P7 -- "greenfield" --> DEP[az deployment / terraform apply]
    P7 -- "referenced" --> DEPADD[Additive deploy · incremental only<br/>what-if preview · no destroy of<br/>referenced resources]
    DEP --> OUT([Deployed])
    DEPADD --> OUT

    classDef gate fill:#fff3cd,stroke:#d39e00,color:#000;
    classDef ref fill:#e2f0d9,stroke:#548235,color:#000;
    class P5,VAL,P7,TRIAGE gate;
    class RW,DEPADD ref;

Artifacts (written under <project-root>/): .azure/insights.json (Phase 1), .azure/infrastructure-plan.json (Phase 4, status draft→approved→deployed), and infra/main.bicep + infra/modules/* or infra/main.tf + infra/modules/** (Phase 6).

MCP Tools

ToolPurpose
insights_getRetrieve insights about the user's existing Azure environment to guide planning decisions
get_azure_bestpractices_getAzure best practices for code generation, operations, and deployment
wellarchitectedframework_serviceguide_getWAF service guide for a specific Azure service
microsoft_docs_searchSearch Microsoft Learn for relevant documentation chunks
microsoft_docs_fetchFetch full content of a Microsoft Learn page by URL
bicepschema_getBicep schema definition for any Azure resource type (latest API version)

Error Handling

ErrorCauseFix
MCP tool error or not availableTool call timeout, connection error, or tool doesn't existRetry once; fall back to reference files and notify user if unresolved
Plan approval missingmeta.status is not approvedStop and prompt user for approval before IaC generation or deployment
IaC validation failureaz bicep build or terraform validate returns errorsFix the generated code and re-validate; notify user if unresolved
Pairing constraint violationIncompatible SKU or resource combinationFix in plan before proceeding to IaC generation
Infra plan or IaC files not foundFiles written to wrong location or not createdVerify files exist at <project-root>/.azure/ and <project-root>/infra/; if missing, re-create the files by following workflow.md exactly

Files

references/constraints/networking-core.md

Networking (Core) Pairing Constraints

Virtual Network
Paired WithConstraint
SubnetsAddress prefixes of all subnets must fall within the VNet address space. Subnet CIDRs cannot overlap.
VNet PeeringPeered VNets cannot have overlapping address spaces.
Azure FirewallRequires a subnet named exactly AzureFirewallSubnet with minimum /26 prefix.
Azure BastionRequires a subnet named exactly AzureBastionSubnet with minimum /26 prefix (recommended /26).
VPN GatewayRequires a subnet named exactly GatewaySubnet with minimum /27 prefix (recommended /27).
Application GatewayRequires a dedicated subnet (no mandatory name, but must not contain other resource types).
AKSAKS subnet must have enough IP addresses for nodes + pods. With Azure CNI, each node reserves IPs for max pods.
Subnet
Paired WithConstraint
NSGCannot attach NSG to GatewaySubnet — NSGs are not supported for either VPN or ExpressRoute gateways. NSG on AzureBastionSubnet requires specific required rules.
DelegationsA subnet can only be delegated to one service. Delegated subnets cannot host other resource types.
Service EndpointsMust match the service being accessed (e.g., Microsoft.Sql for SQL Server VNet rules).
Private EndpointsSet privateEndpointNetworkPolicies: 'Enabled' to apply NSG/route table to private endpoints (default is Disabled).
AKSAKS subnet needs enough IPs for all nodes + pods. Cannot be delegated or have conflicting service endpoints.
Application GatewayDedicated subnet required — cannot coexist with other resources except other App Gateways. Cannot mix v1 and v2 App Gateway SKUs on the same subnet.
Azure FirewallSubnet must be named AzureFirewallSubnet, minimum /26. Cannot have other resources.
App Service VNet IntegrationSubnet must be delegated to Microsoft.Web/serverFarms. Minimum size /28 (or /26 for multi-plan subnet join). This subnet must be different from any subnet used for App Service Private Endpoints.
GatewaySubnet UDRDo not apply UDR with 0.0.0.0/0 next hop on GatewaySubnet. ExpressRoute gateways require management controller access. BGP route propagation must remain enabled on GatewaySubnet.
NSG
Paired WithConstraint
GatewaySubnetNSGs are not supported on GatewaySubnet. Associating an NSG may cause VPN and ExpressRoute gateways to stop functioning.
AzureBastionSubnetNSG on Bastion subnet requires specific inbound/outbound rules (see Azure Bastion NSG).
Application GatewayNSG on App Gateway subnet must allow GatewayManager service tag on ports 65200–65535 (v2) and health probe traffic.
Load BalancerMust allow AzureLoadBalancer service tag for health probes. Standard LB requires NSG — it is secure by default and blocks inbound traffic without an NSG.
Virtual NetworkNSG is associated to subnets, not directly to VNets. Each subnet can have at most one NSG.
Route Table
Paired WithConstraint
SubnetRoute table is associated on the subnet side: set subnet.properties.routeTable.id to the route table resource ID. Each subnet can have at most one route table.
Azure FirewallFor forced tunneling, create a default route (0.0.0.0/0) with nextHopType: 'VirtualAppliance' pointing to the firewall private IP.
VPN GatewaySet disableBgpRoutePropagation: true to prevent BGP routes from overriding UDRs on the subnet.
GatewaySubnetUDRs on GatewaySubnet have restrictions — cannot use 0.0.0.0/0 route pointing to a virtual appliance.
AKSAKS subnets with UDRs require careful route design. Must allow traffic to Azure management APIs. kubenet and Azure CNI have different routing requirements.
Virtual AppliancenextHopIpAddress must be a reachable private IP in the same VNet or a peered VNet. The appliance NIC must have enableIPForwarding: true.
Network Interface
Paired WithConstraint
Virtual MachineEach VM requires at least one NIC. NIC must be in the same region and subscription as the VM.
SubnetNIC must reference a subnet. The subnet determines the VNet, NSG, and route table that apply.
NSGNSG can be associated at the NIC level or at the subnet level (or both). NIC-level NSG is evaluated after subnet-level NSG.
Public IPPublic IP and NIC must be in the same region. When associated with a Load Balancer, Public IP SKU must match the LB SKU (Basic with Basic, Standard with Standard).
Load BalancerNIC IP configuration can reference loadBalancerBackendAddressPools and loadBalancerInboundNatRules. Load balancer and NIC must be in the same VNet.
Accelerated NetworkingNot all VM sizes support accelerated networking. Must verify VM size compatibility.
VM Scale SetNICs for VMSS instances are managed by the scale set — do not create standalone NICs for VMSS.
Application GatewayNIC IP configuration can reference applicationGatewayBackendAddressPools.
Public IP
Paired WithConstraint
Standard SKUMust use Static allocation method. Dynamic only works with Basic SKU.
Load BalancerPublic IP SKU must match Load Balancer SKU (Standard ↔ Standard, Basic ↔ Basic).
Application GatewayStandard_v2 App Gateway requires Standard SKU public IP with Static allocation.
Azure BastionRequires Standard SKU with Static allocation.
VPN GatewayBasic VPN Gateway SKU requires Basic public IP. Standard+ gateway SKUs require Standard public IP.
Azure FirewallRequires Standard SKU with Static allocation.
ZonesStandard SKU is zone-redundant by default. Specify zones only to pin to specific zone(s).
NAT Gateway
Paired WithConstraint
SubnetNAT Gateway is associated on the subnet side: set subnet.properties.natGateway.id to the NAT Gateway resource ID. A subnet can have at most one NAT Gateway.
Public IPPublic IP must use Standard SKU and Static allocation. Public IP and NAT Gateway must be in the same region.
Public IP PrefixPublic IP prefix must use Standard SKU. Provides contiguous outbound IPs.
Availability ZonesNAT Gateway can be zonal (pinned to one zone) or non-zonal. Public IPs must match the same zone or be zone-redundant.
Load BalancerNAT Gateway takes precedence over outbound rules of a Standard Load Balancer when both are on the same subnet.
VPN Gateway / ExpressRouteGatewaySubnet does not support NAT Gateway association.
Azure FirewallNAT Gateway can be associated with the AzureFirewallSubnet for deterministic outbound IPs in SNAT scenarios.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills · .github/plugins/azure-skills/skills/azure-enterprise-infra-planner · commit 0696600
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from .github/plugins/azure-skills/LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
microsoft/azure-skills

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download azure-enterprise-infra-planner.zip