Support resource deployment configuration options

[WhitWaldo]

I've only experimented with a few of the Aspire components so far and I've wanted to make changes to how several of them deployed in Azure. Would you be open to some PRs that add options to several of these components that would be configured in the AppHost and passed to the Bicep templates to handle some of their configuration properties?

The idea would be not unlike what I proposed for the Front Door/DNS PR.

For example, off the top of my head:

• Allow serverless CosmosDB instead of strictly provisioned
• Apply max RUs to a provisioned CosmosDB database
• Specify backup policy for CosmosDB instance
• Toggle whether Key Vaults enable soft-delete

Thanks for the consideration!

[davidfowl]

cc @mitchdenny

[mitchdenny]

@WhitWaldo we recently just merged in some changes which introduce a callback on resources like AddCosmosDB(...) which allows you to mutate the resource. It builds on a new library coming from the Azure SDK team (Azure.Provisioning).

We actually use it internally to configure the Azure resources, but you can setup a callback like this:

builder.AddAzureCosmosDB("mycosmos", (resource, construct, account, databases) =>
{
    var database = databases.Single();
    database.AssignProperty(x => x.Options.AutoscaleMaxThroughput, "1000");
});

The API is still experimental but it will allow for quite a bit of customization. This ultimately affects the Bicep that is produced that AZD uses when deploying the resources.

[WhitWaldo]

@mitchdenny Is this expected to make it into the next preview?

This definitely addresses the concern I had here more meaningfully than what I took from the latest preview 4 release notes. They seemed to indicate a greater reliance on the creation and maintenance of Bicep files as part of the AppHost project and that Aspire would be limited to simply passing parameters into these self-maintained adjacent files. That's nice as a fallback, but where Aspire otherwise generates all the rest of the Bicep from scratch, with a rare exception, this feels like it'd be a notable step backwards to be generating all manner of deployment markup just to have to opt out of it for whole swaths of resources that need minor configuration tweaks.

How well does this handle Azure resources with several levels of nested objects (e.g. Front Door or Event Hubs)? And is it able to handle specifying quirky behavior like assigning existing user-assigned managed identities to resources?

I looked around but was unable to find anything about Azure.Provisioning (Bing just pulls up Entra and IoT provisioning scripts). Is there anything public about it yet?

Thanks for the follow-up!

[mitchdenny]

This builds on that layer and is in preview 5.