Using .NET Aspire with Azure API Management in an Azure Landing Zones architecture?

[mikkelh-SDU]

Hi Aspire team and community

---

TL;DR
We follow Microsoft Azure Landing Zones (CAF) with APIM as a mandatory ingress in dedicated platform subscriptions and independently deployed application workloads. We’re trying to understand whether .NET Aspire is intentionally scoped to local development only in such an architecture, or if there are any recommended patterns for using Aspire alongside APIM without undermining explicit API governance.

---

I’m trying to understand whether Aspire fits into our architecture, or if our use case is intentionally out of scope — and I’d appreciate a sanity check.

Our current setup (simplified)

We’re following Microsoft Azure Landing Zones (CAF) guidance:

• Separate subscriptions per environment (DEV / QA / PROD)
• Platform services (including Azure API Management) live in dedicated platform subscriptions
• Application workloads live in separate application subscriptions
• Azure API Management is the mandatory ingress for all APIs (including application-specific/internal APIs)
  • This is for governance, visibility, and policy enforcement
• Frontend applications (React/Vite) call APIs only via APIM
• Infrastructure is deployed using AZD templates + Bicep
• Backend and frontend live in separate repos and have independent lifecycles

Even APIs that are only consumed by their “own” frontend are still registered in APIM to maintain consistent governance.

What we’re trying to evaluate

We see the value of Aspire for:

• Local development
• Composing multiple backend services
• Improving inner-loop developer experience and observability

However, we struggle to see how Aspire fits when:

• APIM is a hard ingress boundary
• APIs are deployed independently into application subscriptions
• Aspire is not intended to be deployed to DEV/QA/PROD
• We don’t want Aspire to bypass or replace APIM, even in non-prod environments

We’ve also seen discussions (e.g. #59) indicating that native APIM integration is not planned, which is completely understandable.

The core question

Given an APIM-first Azure Landing Zones architecture:

• Is Aspire intended to be used only as a local-development composition tool, with no role in DEV/QA/PROD?
• Is the recommended approach to exclude APIM entirely from Aspire, treating it as a strict environment boundary that starts only after deployment?
• Or is there any supported or recommended pattern for combining Aspire with APIM without undermining explicit ingress and API governance?

I want to make sure we’re not trying to force Aspire into a space it was never designed for — and if the answer is “this is intentionally out of scope”, that’s perfectly fine.

Thanks for building Aspire and for any guidance you can share!

---

Note: I had some AI help drafting this post due to dyslexia — thank you for your understanding.

[aaronpowell]

This is probably the wrong place to ask, you'd be better asking in the dotnet/aspire or on the Aspire Discord

[mikkelh-SDU]

Thanks for the reply, I will try there instead 😊