Aspire + enterprise Azure naming standard + DTAP-aware topology - what's the idiomatic pattern?

[Kieron (kieronlanning)]

Hey all 👋 — looking for the community's view on the cleanest Aspire-native way to handle two intertwined requirements. Bicep-by-hand works, but I'd rather lean on the AppHost as the single source of truth if I can.

The setup

I'm building an Aspire AppHost targeting Azure, deploying via aspire deploy, but I have two constraints from the platform team:

1. Custom Azure resource naming

We have an enforced enterprise naming standard — Azure Policy will reject anything that doesn't match. The shape is roughly:

<resource-prefix>-<division>-<environment>-<service>-<region><nn>

Concrete examples:

sql-acme-prod-payments-uks01
str-acme-dev-payments-uks01      (storage account; no hyphens, lowercased)
kv-acme-prod-payments-uks01
rg-acme-prod-payments-uks01

Notes that make this awkward:

• Some resources allow hyphens, some don't (storage accounts, ACR), some have tight length limits.
• The <resource-prefix> is org-defined, not the Azure CAF abbreviations Aspire defaults to (e.g. we use str not st for storage).
• <division> and <environment> need to be injected from outside the AppHost - CI/CD vars for example based on the deployment pipeline's targetted environment.
• We also need 4 mandatory tags applied to every RG and ideally inherited.

2. DTAP environments with diverging topologies

Standard DTAP — Dev, Test, Acceptance, Prod — but the topology genuinely differs, not just SKU sizes:

Environment	SKU profile	DR / HA
Dev	Smallest possible (Basic SQL, B1 App Service, LRS storage)	None
Test	Same as Dev	None
Acceptance	Production-like (S3 SQL, P1v3, ZRS)	Geo-replica + failover group
Prod	Same as Acceptance, scaled	Geo-replica + failover group, second region

So Acceptance/Prod aren't just "Dev with bigger numbers" — they have additional resources (secondary SQL server, secondary storage, Traffic Manager / Front Door for failover) that simply don't exist in Dev/Test.

What I've looked at

• ConfigureInfrastructure lets me reach into the generated Bicep and rename / re-SKU resources per call. Works, but if I have 15 resources it's 15 lambdas full of string interpolation, and I'd rather centralise.
• Aspire parameters (AddParameter) for SKUs work fine for scalar differences, but don't help when the resource graph itself differs between environments.
• Branching in C# on something like builder.ExecutionContext.IsPublishMode + a custom Environment parameter — feels like the right axis but I haven't seen a clean idiom for "only add this resource in Acceptance/Prod".
• Drop down to raw Bicep modules referenced from the AppHost — works but feels like giving up on Aspire's value prop.

Questions

1. Naming. Is there an idiomatic way to plug in a naming provider that Aspire calls for every Azure resource it generates, rather than overriding each one in ConfigureInfrastructure? Something like an IAzureResourceNamer I could register once?
2. Conditional resources. What's the recommended pattern for "this resource only exists in higher environments"? Is if (env is "acc" or "prod") builder.AddAzureSqlServer(...).WithGeoReplica(...) actually the way, or is there a more declarative shape people use?
3. Per-env SKU. Are folks using AddParameter + Bicep @allowed decorators, separate appsettings.{env}.json consumed in the AppHost, azd env vars, or something else? What's held up best in practice?
4. Tags. Any clean way to apply mandatory tags to every Azure resource Aspire generates, including the RG, without repeating WithAnnotation everywhere?
5. Escape hatch. When does the community recommend giving up and writing the Bicep directly vs. fighting Aspire's defaults? I want the AppHost as source of truth but not at the cost of a thousand ConfigureInfrastructure calls.

Bonus: if anyone has a public sample repo doing real DTAP with Aspire (not just dev vs prod), I'd love a link 🙏

Thanks!

[Kumima (Kumima)]

Kieron (@kieronlanning), a great question which makes me think 😀
For now I dont think we can get rid of the ConfigureInfrastructure. Because there is no direct relationship between Aspire resource and the root Azure resource for that resource. As an example, the AzureContainerRegistryResource is not aware of that the root azure resource is the ContainerRegistryService. So we have to manually get that Azure resource from the resource infrastructure.

Since we have to keep the ConfigureInfrastructure, then no way becomes fully central. And I'm mostly using C# branching.

But appsettings.{env}.json should work, since there is -e, --environment for aspire deploy. You can use that file for parameters, or just use builder.Configuration to read it directly. I'd prefer using builder.Configuraion for naming.

For Conditional Resources, at least branching is my way. And I dont think there is a way to avoid branching, since the environments itself is a branching concept.