Feedback Request - AVM Integration and Accelerator Enhancements

[oZakari]

Let us know the feedback or general question

Overview

We're currently evaluating the future of ALZ-Bicep and would like to hear your input, before we make any decisions.
We have several ideas up for consideration, and we're looking forward to your feedback on which proposals are most sought after. Or maybe there is something we have missed that you have been thinking about, let us know!

Important

Please add any additional comments or scenarios you would like to discuss either using the comment section below. Looking forward to hearing from you all!

Proposal - Utilize Azure Verified Modules

We're considering migrating towards utilizing AVM into the ALZ Bicep framework to replace the existing ALZ-Bicep built and maintained modules, where possible and appropriate.

Note

There will still be some modules we need to maintain as the ALZ Bicep team, but these will be published as AVM modules also.

What This Means for ALZ-Bicep?

Put very simply, all ALZ Bicep modules will be deprecated and instead a new version of ALZ Bicep will be released that will be built solely of AVM Bicep modules (Resource & Pattern). The ALZ Bicep repo will transition to become the home of the accelerator providing examples and reference code bases of how to deploy the various ALZ reference architectures (Contoso (Virtual WAN), Adventure Works (Hub & Spoke), etc.)

Transition Plan: We are planning to transition all modules to be AVM modules

• Whether ALZ Bicep Team maintained or not, they will all live in AVM as their home
• Seamless Integration: We will provide detailed steps, and possibly tooling, to ensure a smooth transition.

Benefits for You (Consumers)

• Enhanced customization & greater flexibility to tailor modules, via input parameters, to your specific needs as the AVM modules are way more flexible by design
• Enhanced specifications/standards, testing, CI framework to benefit from promoting consistency and quality further in the modules that build ALZ Bicep
• Closer alignment with the Well-Architected Framework as this is an AVM requirement
• Larger community to help implement feature requests and fix any bugs
• Breaking up some of the monolithic modules into smaller pieces, e.g. Hub Network ALZ Bicep module will be no more and instead composed of various AVM Resource Modules

Current Architecture

flowchart TD
    subgraph ALZ-Bicep Maintained Modules
        Management_Group_Module --- Custom_Policy_Definitions_Module
        Custom_Policy_Definitions_Module --- Custom_Policy_Exemptions_Module
        Custom_Policy_Exemptions_Module --- Custom_RBAC_Role_Definitions_Module
        Custom_RBAC_Role_Definitions_Module --- Logging_and_Security_Module
        Logging_and_Security_Module --- MG_Diagnostic_Settings_Module
        MG_Diagnostic_Settings_Module --- Hub_Networking_Module
        Hub_Networking_Module --- RBAC_Role_Assignments_Module
        RBAC_Role_Assignments_Module --- Subscription_Placement_Module
        Subscription_Placement_Module --- Policy_Assignments_Module
        Policy_Assignments_Module --- Corp_Connected_Spoke_Networking_Module
    end

Loading

Proposed AVM Integration

flowchart TD
    subgraph "AVM Maintained Modules (Already exist unless stated)"

        subgraph Governance Modules
            mg["Management Groups (inc. Diag Settings) <br>(avm/res/management/management-group)"]
            subplacement["Subscription Placement <br> *Requires creation/development*"]
            alzpoldef["ALZ Custom Policy Definitions & Initiatives <BR> *Pattern requires creation/development*"]
            ownpoldef["Custom Policy Definitions & Initiatives <BR> *Resource/Pattern requires creation/development*"]
            ownpolexm["Custom Policy Exemptions <BR> *Pattern requires creation/development*"]
            alzpolasi["ALZ Default Policy Assignments <BR> *Pattern requires creation/development*"]
            ownpolasi["Policy Assignments <BR> (avm/ptn/authorization/policy-assignment)"]
            alzroledef["ALZ Custom Role Definitions <BR> *Resource/Pattern requires creation/development*"]
            ownroledef["Custom Role Definitions <BR> *Resource/Pattern requires creation/development*"]
            roleasi["Role Assignments <BR> (avm/ptn/authorization/role-assignment)"]
        end

        subgraph "Logging & Monitoring Modules"
            law["Log Analytics Workspace <BR> (avm/res/operational-insights/workspace)"]
            lawsol["Log Analytics Workspace Solution <BR> (avm/res/operational-insights/solution)"]
        end

        subgraph Hub Networking Replacement Modules
            vnet["Virtual Network <br> (avm/res/network/virtual-network)"]
            fw["Azure Firewall <br> (avm/res/network/azure-firewall)"]
            fwp["Azure Firewall Policy <br> (avm/res/network/firewall-policy)"]
            pdnszones["Private Link Private DNS Zones <br> (avm/ptn/network/private-link-private-dns-zones) <br> *Under Development*"]
            vng["VPN/ExpressRoute Gateway <br> (avm/res/network/virtual-network-gateway)"]
            bst["Azure Bastion <br> (avm/res/network/bastion-host)"]
        end

        subgraph VWAN Networking Replacement Modules
            vwfw["Azure Firewall <br> (avm/res/network/azure-firewall)"]
            vwpdnszones["Private Link Private DNS Zones <br> (avm/ptn/network/private-link-private-dns-zones) <br> *Under Development*"]
            vwvpnvng["VPN Gateway <br> (avm/res/network/vpn-gateway)"]
            vwexrvng["ExpressRoute Gateway <br> (avm/res/network/express-route-gateway)"]
            vw["Virtual WAN<br> (avm/res/network/virtual-wan)"]
            vwhub["Virtual WAN Hub<br> (avm/res/network/virtual-hub)"]
        end
    end

Loading

Proposal - Provide Different and/or More Complex Deployment Scenarios within the Accelerator

• Currently, we only have one "flavor" of deployments within the ALZ-Bicep Accelerator. We're considering adding different models, such as:
• Offering a deployment scenario that only deploys the core modules (management groups, policies, and RBAC) - to match our Terraform implementation options

A note on Deployment Stacks

As you may know Deployment Stacks are now GA and therefore as part of this effort for ALZ Bicep, our intent is to also migrate our suggested deployment method to use Deployment Stacks. We are collaborating with the product groups for Deployment Stacks to work through any current limitations and will adapt the re-write to AVM of ALZ Bicep to either accommodate or highlight these for resolution so that Deployment Stacks can be used with the AVM re-write of ALZ Bicep 👍

Call to action

Thanks for getting this far 😂 Please do leave your comments and questions below to help us shape the future of ALZ Bicep

Code of Conduct

• I agree to follow this project's Code of Conduct

[picccard]

Looks looks promising! 💯

The proposed AVM integration does not mention a module for policy exemptions, this was added recently in
#762.
This module would also be labeled Pattern requires creation/development

[oZakari]

Looks looks promising! 💯

The proposed AVM integration does not mention a module for policy exemptions, this was added recently in #762. This module would also be labeled Pattern requires creation/development

Good callout @picccard, have updated the diagrams with the new module. 👍🏼

[MarcoJanse]

Moving to AVM sounds like the logical step to take to move forward with ALZ-Bicep, although I realize it's quite a project. As more and more people are starting to adopt AVM, it would be illogical for ALZ-Bicep to stay behind.

Some of the things I would like to see when switching to AVM:

• Switch from JSON-parameter files to .bicepparam files.
• Make the Hub Networking pattern module more flexible to optionally deploy additional subnets in the hub vNet with attached NSG's.
• Make the spoke networking pattern module more flexible to optionally deploy additional subnets in the spoke vNets with attached NSG's
• Consider support for deployment stacks.

[tulpy]

I think this is the next logical evolution of this repo, as a partner we have created Bicep Landing Zone assets that are based on the LZ vending and this ALZ-Bicep repos to form part of our Platform and Application Landing Zone offerings.

As outlined by @MarcoJanse, some of the things we have done include,

• Update to use .bicepparam files
• Use AVM modules tactically to replace the Public IP, Resource Group and other specific resource modules.
• Extend the spoke networking module to include an array of subnets with logic for the attached route tables and NSGs
• Create pattern modules for Platform Landing Zones for Management, Identity and Connectivity that use a mixture of the existing ALZ modules and AVM modules for deployment.

[oZakari]

Thank you @MarcoJanse and @tulpy for your feedback! We have considered transitioning to .bicepparams in the past but there was some complexity/time constraints with the existing modules and having to handle the path references in terms of the Accelerator. However, with using the AVM modules, I think this is something we can take another look at for potentially incorporating.

Adding flexibility to the Hub Networking module is definitely one of the core goals for this initiative so glad you feel the same!

@MarcoJanse could you clarify what you are referring to in regards to "deployment slots", are you referring to Azure DevOps/GitHub environments for canary testing?

@tulpy Very cool to hear that you have created pattern modules for platform landing zones, I'd be interested in hearing any downfalls or concerns (if any) that you have had to address with this.

[MarcoJanse]

Hi @oZakari. Sorry, for the confusion. I meant Bicep deployment stacks. I have now updated my original comment as well.

[oZakari]

@MarcoJanse ah thank you for the clarification! Deployment Stacks are indeed something we are considering again now that they are generally available (GA). We still need to investigate a bit more to be conclusive, but we should be able to shed some more light on this in the near future.

[tulpy]

Hi @oZakari No major issues or downfalls outside minor things like outputs for some AVM modules that don't exist that are passed between modules. The other thing that was a little challenging (not to do with AVM specifically) was Day 2 operations for Azure Firewall Rules and VPN connections, running the Hub module for Azure Firewall rules is quite risky and time-consuming so we created a module that creates the IP Groups and Firewall rules using Bicep Import/Export to make it more modular. We use the existing Hub module to create the Azure Firewall Policy resource and then the new module does the rest.

Happy to chat separately if you find that of value.

[oZakari]

Thanks everyone for your feedback, locking this down and will close out once complete!