Cost-aware guidance for .NET Aspire apps on Azure (ISV Success context)

[sultanaalyami]

Hi @davidfowl,

A quick follow-up to our earlier WebDeploy/Aspire discussion. I’m preparing to work within Microsoft’s ISV Success track, and I’d like to ask for practical guidance on building cost-aware Aspire ecosystems on Azure.

Context:

• I received ~$5,000 in Azure credits two months ago.
• I deployed a classic .NET 8 MVC app in a container for 1–2 days (mainly for testing).
• I also tried an e-commerce sample built with .NET Aspire, pushed to an app/container with a monthly budget cap set to ~$150.
• During the first week, just by opening the site a few times (high CPU usage while testing), my personal Azure subscription was charged about $7.
• Despite stopping the MVC container after brief tests, something in the background seemed to keep consuming resources and the overall credits were drained within ~2 months.

What I’m looking for: cost-first patterns and defaults for Aspire apps so developers don’t accidentally burn credits while experimenting. Concretely:

1. Scale-to-zero & autoscale defaults

   • Recommended way to configure Aspire services (web/worker/background) on Azure Container Apps or App Service so idle = near-zero cost.
   • Guidance on min/max replicas, CPU/memory requests/limits, and request-driven scale rules to avoid paying for idle capacity.

2. Background processors

   • Preferred pattern for jobs/queues (e.g., using event- or schedule-triggered workers) so they spin up only on demand.
   • How to avoid “always-on” behavior that keeps a container warm without traffic.

3. Observability overhead

   • Recommended settings for OTel/Logging/Tracing (sampling rates, exporter choices) to keep both compute and telemetry/storage costs low during dev/test.

4. Service composition

   • When would you suggest mixing serverless (Functions/Logic Apps/Queues) with Aspire services to reduce baseline cost?
   • Any guidance on externalizing heavy dependencies (DB emulators, message brokers) in dev, or using lighter local dev resources to avoid cloud charges.

5. “Low-cost profile” in templates

   • Would the team consider shipping an Aspire “Cost-Saver” profile (or doc) with:
     • conservative CPU/memory defaults,
     • scale-to-zero where possible,
     • optional/disabled-by-default diagnostics,
     • clear notes on Azure SKUs that can accumulate idle cost?

Any pointers, sample Aspire.AppHost snippets, or official docs you recommend would be super helpful—especially for ISVs who need predictable spend while they prototype.

Thanks a lot for your time and for all the amazing work on Aspire and the surrounding ecosystem!

—Sultan Alyami