AWS and Google Cloud both provide established managed Apache Airflow offerings, but Azure's options still seem limited. The former managed Airflow integration with Azure Data Factory disappeared, and the newer Fabric Apache Airflow jobs come with a major restriction: private networks and virtual networks are not supported. That makes the service difficult to use in organizations where most resources are isolated in private environments. In a previous role, we ran Airflow ourselves on AKS, but maintaining upgrades, scaling, and operational support required significant effort. Marketplace products are another possibility, although many appear to be VM-based and would still require substantial administration, with managed services such as Astro being an exception. Why hasn't Microsoft provided a straightforward, fully managed Apache Airflow service that preserves the tool's normal capabilities instead of steering users toward Fabric-specific connectors?
3 Answers
The likely business reason is that Microsoft wants customers to standardize on Fabric. A generic, fully managed Airflow service would make it easier to use Airflow directly with Azure resources, while Fabric’s current design encourages users to rely on Fabric connectors and services instead. That may explain why the offering feels intentionally narrower than the managed Airflow products available from the other major cloud providers.
AKS can run Airflow through a Helm deployment, but that is self-hosting rather than a managed service. Your team would still need to handle upgrades, scaling, reliability, security, and operational support. A feature request for a managed Airflow service on AKS could be useful, although the existing Fabric implementation suggests Microsoft is prioritizing its broader data platform instead. Until private and virtual network support is added, it is probably unsuitable for many enterprise workloads.
Azure Marketplace has several third-party Airflow solutions, so those may be worth evaluating if the goal is to avoid running everything yourself. The main thing to check is the support and ownership model: many offerings are essentially VM deployments, which means your team may still be responsible for upgrades, scaling, networking, and parts of the platform lifecycle. A genuinely managed provider can fill that gap, but it needs to offer clear enterprise support and private-network connectivity.
That support model is the difficult part. Leadership is usually more comfortable approving a managed service because responsibility and escalation paths are clearer. Most marketplace options still look like self-managed infrastructure, while private networking is essential for many enterprise environments.
That is frustrating for organizations that are already committed to Azure but simply want Airflow as the orchestration layer. Being locked into Azure should not require replacing normal Airflow connectivity with Fabric-specific integrations.