Feature Request: Add support for generating Bicep using Azure Verified Modules (AVM)

Aspire’s infrastructure generation currently emits *direct resource-level Bicep*, but does not support using **Azure Verified Modules (AVM)**. As AVM becomes the recommended standard for authoring secure, consistent, and production-ready Azure IaC, Aspire-generated infrastructure should ideally align with it.

**Reference:**
Azure Verified Modules (AVM) documentation – [https://azure.github.io/Azure-Verified-Modules/](https://azure.github.io/Azure-Verified-Modules/)

---

## **Problem**

Aspire’s infrastructure generation produces raw Bicep files instead of leveraging AVM modules. This creates several challenges:

* **Security & Compliance:** AVM modules embed Microsoft-reviewed best practices, outputs, parameter schemas, and security defaults. Raw Bicep lacks these guarantees.
* **Consistency:** Teams adopting AVM for everything else must deviate when using Aspire-generated IaC.
* **Maintainability:** AVM provides ongoing updates and improvements, but Aspire consumers currently must hand-manage resource definitions.
* **Scenarios like networking, identity, diagnostics, and storage** become especially verbose when not modeled through AVM.

---

## **Feature Request**

Add an option for Aspire to generate Bicep using **Azure Verified Modules (AVM)** rather than raw resource definitions.

### **Proposed behavior**

* Introduce a configuration switch such as:

```jsonc
"infrastructure": {
"useAvm": true
}
```
* When enabled, Aspire should map its infrastructure resources to the corresponding AVM modules (e.g., Storage Account, Key Vault, Managed Identity, Container App Environment, Networking modules, etc.).
* The output should:

* Reference AVM modules rather than `resource` definitions.
* Preserve Aspire’s current parameter and environment integration behavior.
* Provide a clear override path for developers who need more customization.

---

## **Why this matters**

Moving Aspire-generated IaC toward AVM unlocks immediate benefits:

* **Enterprise readiness** by aligning with Microsoft-endorsed patterns.
* **Simplified code** with fewer lines of Bicep to manage.
* **Easier upgrade path** as AVM evolves.
* **Better alignment with IaC teams** who already standardize on AVM for security reviews.
* **Consistent developer experience** across Aspire, Terraform, Pulumi, and other AVM-based tooling.

---

## **Suggested Next Steps**

1. Identify which Aspire resources have direct AVM equivalents.
2. Add an extensibility point to allow users to opt in to AVM-based generation.
3. Consider generating side-by-side examples to help users migrate.

---

This enhancement would strongly improve the quality and maintainability of infrastructure produced by Aspire workloads and bring them in line with the broader Azure IaC ecosystem.