Blog Post

ITOps Talk Blog
6 MIN READ

Building Secure, Well-Architected Azure Workloads with Azure Verified Modules and GitHub Copilot

Pierre_Roman's avatar
Pierre_Roman
Icon for Microsoft rankMicrosoft
Jun 25, 2026

Hello Folks!

If you have been writing Bicep or Terraform for Azure over the last few years, you have probably lived this story. You pick a community module, it works great for six months, then the maintainer moves on, issues stop getting answered, and you are stuck owning code you never wrote. At the Microsoft Azure Infra Summit 2026, Jack Tracy and Jarrod Holgate (tech leads on the Azure Verified Modules project) walked us through how AVM solves that, and how pairing it with GitHub Copilot and Spec Kit changes the way IT pros build Azure workloads.

📺 Watch the session:

 

Why IT Pros Should Care

This is not a developer-only topic. If you are the person responsible for landing zones, platform engineering, or the IaC pipelines that other teams ship through, this hits you directly.

  • You stop owning home-grown storage account and VNet modules that no two teams write the same way.
  • You get secure-by-default resources without having to draft a 40-page internal coding standard.
  • You can let application teams move fast without sacrificing the Well-Architected Framework guardrails you care about.
  • You get a supported, Microsoft-backed module library with a clear lifecycle, instead of betting on an abandoned repo.
  • You finally have a deterministic way to put AI to work on infrastructure code without it inventing things you do not want in production.

If any of that sounds like a Tuesday for you, this session is worth 40 minutes.

What are Azure Verified Modules

Azure Verified Modules (AVM) is the official Microsoft infrastructure-as-code module library for both Bicep and Terraform. Jack put it plainly in the session: AVM is the one-time solution that is not going to go away, with ownership, a defined lifecycle, structure, and well-defined specifications.

Here is what makes AVM different from the previous landscape of community repos:

  • It is supported in multiple IaC languages today (Bicep and Terraform), with consistent specifications across both.
  • Modules are aligned to the Azure Well-Architected Framework by default. Zone redundancy on, public IPs off, sensible TLS minimums, right out of the box. Everything is still flexible, you can override any of it via a parameter or variable.
  • It is open source. People inside and outside Microsoft can contribute and maintain modules.
  • It consolidates the older CARML and Terraform Verified Modules efforts under one roof, owned by Microsoft FTEs and backed by the AVM core team.

AVM has three module classifications, and understanding them is half the battle:

  • Resource modules. A one-to-one mapping to a single resource type, like a storage account or a virtual network. Need ten of them, loop the module ten times.
  • Pattern modules. A collection of resources, usually built on top of resource modules, that delivers a bigger slice of an architecture. The Azure Landing Zone is roughly five pattern modules behind the scenes.
  • Utility modules. Helpers you probably never call directly, but that the library uses for things like region lookups, SKU availability, and naming standards.

One thing that gets undersold: AVM is not just for you. The Azure Developer CLI templates use it. Azure Landing Zone and Sovereign Landing Zone are built on it. Internal Microsoft service teams use it. When you adopt AVM, you are using the same building blocks Microsoft uses.

Pairing AVM with GitHub Copilot

This is where the session gets interesting. AVM gives you the trusted Lego bricks. GitHub Copilot gives you a coding assistant. The problem, as Jack called out, is that AI is non-deterministic by default. It is great at solving ambiguous problems, but you cannot just point it at a blank repo and trust it to stamp out production infrastructure.

That is the gap spec-driven development is designed to fill.

Spec-driven development is a documentation-first approach. Instead of telling Copilot “write me a Terraform module for a hub-spoke network,” you write a structured specification up front that captures intent, quality bar, security requirements, and coding standards. The AI then uses that spec as the contract, generates code, validates against it, and loops until the output matches what you asked for.

Jarrod walked through Spec Kit, the open source toolkit maintained by GitHub and Microsoft, which formalizes this into eight steps:

  1. Constitution. The non-negotiables. “We must use AVM. We must comply with PCI. Optimize for cost.” This is your project DNA.
  2. Specify. What you actually want to build, focused on user goals and outcomes, not implementation details.
  3. Clarify. Copilot scans the spec, finds ambiguities, and asks you targeted questions (IP ranges, bastion SKUs, anything that is fuzzy).
  4. Plan. A technical plan that maps the spec to your standards and constraints.
  5. Checklist. A quality checklist the agent uses later to validate its own work.
  6. Tasks. The plan broken down into small, reviewable steps.
  7. Analyze. A consolidated report across the spec, plan, and tasks so you can sanity check the whole package.
  8. Implement. Copilot finally writes the code, validating against everything above as it goes.

The critical detail: at every one of those gates, you review. You are still the human in the loop. The AI is not flying solo, and you are not signing off on a thousand-line code dump.

When you wire AVM into the constitution (“use AVM modules wherever possible”), Copilot stops trying to hand-roll raw resource declarations. It composes solutions out of trusted, tested, WAF-aligned modules. That is what makes the combination so powerful.

Spec Kit is not the only option. Jack mentioned two others worth knowing about:

  • OpenSpec. Leaner than Spec Kit, brownfield-first, aimed at smaller experienced teams.
  • Squad. A completely different model built by a Microsoft team. No specs. Instead, a virtual team of agent personas (IaC specialist, UX, deployment, an orchestrator called Ralph) that collaborate to deliver work. Worth a look if your style is more agent-team than document-first.

Real-world value

So what does this actually buy you when Monday morning hits?

  • Speed without sacrificing the bar. Application teams stop writing storage account boilerplate. They focus on what the workload needs to do, and the AVM modules handle the resilient, compliant defaults.
  • Compliance becomes additive, not a rewrite. If you need to add HIPAA or NIST compliance later, you add another spec on top of your existing constitution and iterate. You do not throw out your modules.
  • Less ambiguity loop, fewer tokens burned. A good spec up front means fewer Copilot iterations. You get to a working answer faster, with less back and forth.
  • Trust in the AI output. Because AVM modules are tested, supported, and WAF-aligned, what Copilot stitches together is built on solid foundations. You can review the spec instead of every line of Terraform.
  • Your developers shift up the stack. They stop writing IaC primitives and start designing architectures and requirements. That is where the business value lives anyway.

A note on tradeoffs. AVM modules are intentionally generic and flexible, so you sometimes get parameters you do not need, and the well-architected defaults can be opinionated for your scenario. The fix is simple, override the parameter. You are trading some control for a lot of consistency, and for most teams that trade is the right one.

Getting Started

If you want to try this for yourself, here is the path I would take:

  1. Go to aka.ms/AVM and bookmark it. Everything starts there.
  2. Browse the Bicep and Terraform module indexes. Find the resource you would normally hand-write and try the AVM version in a dev subscription.
  3. Read the AVM specifications so you understand the contract every module follows. It makes the parameter sets a lot less surprising.
  4. Install Spec Kit via the Specify CLI (the GitHub repo has the instructions) and try the AVM example under the experimental “AI-Assisted Solution Development” section on the AVM site.
  5. Run the eight-step Spec Kit flow against a small workload. Do not start with your production landing zone. Pick something contained, like a single app with a web tier, a database, and a Key Vault.
  6. Keep the human in the loop. Review every spec gate. That is where the quality comes from.

Resources

Watch the rest of the Summit

If you found this useful, there is a lot more where it came from. The Microsoft Azure Infra Summit 2026 playlist covers landing zones, deployment stacks, AKS networking, storage, and the AI side of platform operations. Block out an afternoon and binge it.

Microsoft Azure Infra Summit 2026 on YouTube

Cheers!

Pierre Roman

Published Jun 25, 2026
Version 1.0
No CommentsBe the first to comment