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

[mikkelh-SDU]

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 how .NET Aspire fits into such an architecture today, and how the planned APIM host integration should be interpreted in an APIM-first, governance-driven setup.

---

Hi Aspire team 👋

I’m trying to understand whether Aspire fits into our architecture, or if parts of our use case are 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 clear value in 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 per CAF guidance
• 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

I’ve also seen the Aspire roadmap discussion indicating a planned host integration with Azure API Management:
#10644

That made me want to clarify how this integration is intended to be used in more governance-heavy architectures like ours.

The core question

Given an APIM-first Azure Landing Zones architecture:

• Is Aspire intended to be used only as a local-development composition tool today, with no role in DEV/QA/PROD?
• Should APIM be treated as a strict environment boundary, excluded from Aspire usage even in non-prod?
• How should teams following CAF interpret the planned APIM host integration:
  • As a local/dev convenience?
  • As a way to simplify registration/configuration?
  • Or as something that could play a role beyond local development in the future?

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 limited to local/dev scenarios”, 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.

[David Fowler (davidfowl)]

The team is spending time working on primitives to enable many scenarios. We have not given thoughts to what the best practices are for landing zones or very specific existing architectural patterns that require a very specific set of azure resources to be arranged with very specific configuration.

We intend for Aspire to be a swiss arny knife for modeling local dev environments, pipelines and deployment targets. At the moment deployment isn't mature enough to make this "just work like magic", there are missing azure resources (like APIM) that we have to design but we intend to get there.

[mikkelh-SDU]

Thanks David, that clarification helps a lot!

That matches what we were sensing while evaluating Aspire. We’re operating in an Azure Landing Zones (CAF) setup where APIM is a platform-level ingress and governance boundary, so it makes sense that Aspire isn’t currently opinionated about (or optimized for) those kinds of architectures.

It’s helpful to hear that the current focus is on primitives and local/dev modeling first, and that deployment and Azure resource coverage (like APIM) are still maturing rather than intended to “just work” today. That sets expectations clearly.

For now, we’ll treat Aspire—if we use it at all—as a local developer experience tool within individual application repos, and continue to rely on IaC/AZD and platform tooling for CAF-aligned deployment and APIM governance. We’ll keep an eye on how the APIM-related primitives evolve over time.

Appreciate the transparency and the work the team is doing here.