Managed Apache Airflow
Last reviewed by Tyler Eastridge
AceMQ runs your Apache Airflow workflow orchestration platform for you: scheduler, workers, metadata database, upgrades and the pager. We operate it in your own cloud account, Kubernetes cluster or data centre (Tier 3), or on infrastructure AceMQ runs (Tier 4). If you are happy on Amazon MWAA, Google Cloud Composer or Astronomer, those can be the better choice, and the table below says where each one stops.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ Apache Airflow consulting and services.
Customers
Partners
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
We run the scheduler, DAG processor, workers and triggerer. Airflow supports more than one scheduler for resilience, and coordinates them through row-level locks in the metadata database, so we size that database for it. Executor choice, worker sizing, pools and queues are reviewed against the load you actually run, not left at defaults.
The metadata database is the part of Airflow that fails slowly. We watch connection counts, table growth and long-running queries, schedule airflow db clean against a retention rule you agree, back it up, and test the restore. A database that has never been restored is not a backup.
We manage monitoring of what predicts Airflow incidents: scheduler heartbeat, DAG parse time, tasks sitting in queued, pool slot use, zombie tasks and failed DAG runs. Then we take the pager, so an alert reaches an engineer who knows your topology and your DAG calendar.
Airflow, its provider packages and your Python dependencies move together. We pin them with constraint files, rehearse each upgrade on a copy of your DAGs, write the rollback down and run it in an agreed window. Version upgrades, including Airflow 2 to 3, run as projects inside the service.
We keep the path from your repository to the scheduler working: git-sync or image builds, DAG validation gates that catch import errors and cycles before promotion, and separate environments for test and production. Your engineers write the DAGs. We make sure a bad one cannot take the scheduler down.
Credentials belong in a secrets backend, not in Variables. We wire Airflow to the backend you already use, review who can edit connections and trigger DAGs, and track security releases against the exact version you run. Access to your environment follows your change process and is logged.
Why AceMQ
Run managed Airflow in your own account, cluster or data centre (Tier 3) when your connections, credentials and data must stay inside your boundary, or have AceMQ host it (Tier 4) when you want a working platform and no infrastructure to run. Either way the operator is an Airflow specialist under an AceMQ contract.
AceMQ is not a reseller of MWAA, Composer or Astronomer, and has no partner status with any of them. When one of them fits better than we do, we say so, and we support the DAG layer on them at Tier 1 or 2.
AceMQ holds the contract, the SLA and the escalation path, and brings in partner Airflow specialists as the work needs them. The 15-minute P1 response is a response time, not a resolution time, and every P1 ends with a written root-cause analysis.
Scheduler recovery, backfill and stuck-task runbooks, deployment code and monitoring configuration are maintained as yours. If you move between your infrastructure and ours, or take operations in-house, a current handover pack is ready.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Compared
Amazon MWAA, Google Cloud Composer and Astronomer run the Airflow platform inside their own service. AceMQ runs standard Airflow in your account or ours. These are the differences that decide it, from each vendor's own pages as checked on 31 October 2026.
| Question | Amazon MWAA | Google Cloud Composer | Astronomer (Astro) | AceMQ at Tier 3 or 4 |
|---|---|---|---|---|
| Who runs the platform | AWS runs the scheduler, workers and metadata database in a service-managed environment. | Google runs it. Google's docs now call the service Managed Service for Apache Airflow. | Astronomer, in its Hosted mode. Its Remote Execution mode runs task execution in your infrastructure and is listed on the Enterprise plan. | AceMQ engineers run standard Airflow in your account, Kubernetes cluster or data centre (Tier 3), or on infrastructure we run (Tier 4). |
| Which Airflow versions | Airflow 3.x and 2.x releases up to 3.3.1. MWAA commits to at least three minor versions, each for at least 12 months, with 180 days' notice of end of support. | Each build is supported for 12 months from release, then it is user-managed. Gen 3 lists Airflow 3.3.1, 3.2.2 and 2.11.1 among others. | Astro Runtime 3.x gets two years of maintenance, then six months of Basic Support, in which tickets are taken and no patches are released. | The version you choose, under the Apache project's rules. Apache ended Airflow 2 support on 22 April 2026. |
| Access and customisation | No SSH and no custom images. Requirements and plugins come from an S3 bucket. | Gen 3 does not support scheduler plugins or custom PyPI packages on the scheduler. | You deploy an Astro Runtime image built from your project. | System access to the cluster or hosts, custom images and your own provider pins. |
| Upgrade to Airflow 3 | MWAA upgrades between minor versions in place. A new major version is not an in-place upgrade. | Google lists in-place and snapshot upgrades of Gen 3 environments from Airflow 2 to Airflow 3 as not yet supported. | Move to a Runtime built on Airflow 3 by redeploying your project. | Planned and run by AceMQ as a project: 2.11 first, then Airflow 3, rehearsed on a copy. |
| How you are charged | Environment hours by size, extra workers, schedulers and web servers, and database storage. | Environment size in milliDCU-hours, database storage and network transfer. | A fixed hourly rate per deployment by size, plus metered workers, and hourly dedicated clusters. | Quote only. Your own infrastructure bill plus an operations fee at Tier 3, or a hosted quote at Tier 4. |
| Who answers when DAGs stop running | AWS support covers the environment. DAG parse time, pools and task logic stay with you. | Google support covers the environment. DAG code and scheduler load stay with you. | Astronomer support covers Astro. DAG design and task code stay with you. | A named engineer, a 15-minute emergency response and a written root-cause analysis after every P1, including the DAG-level causes. |
Sources: docs.aws.amazon.com MWAA Airflow versions and FAQ, cloud.google.com Composer versioning and pricing, astronomer.io pricing and Runtime lifecycle policy, airflow.apache.org supported versions. Vendors change terms, so check them before you commit. MWAA, Composer and Astronomer are run by their providers: AceMQ supports Airflow on them at Tiers 1 and 2, and operates Airflow itself at Tiers 3 and 4.
The same four tiers cover Kafka, Redis, PostgreSQL and RabbitMQ; the escalation-first option is set out in managed open-source operations.
Choosing
A cloud provider's Airflow service is a good answer for many teams, and AceMQ will say so. These are the situations that decide it.
You run in one cloud, a small team owns the DAGs, and you want the provider to carry the platform. The service-managed environment is then less to run than anything we build, and the limits above are ones you can live with.
You need a custom image or system access on the workers, a version or provider package the service does not allow, or Airflow outside the big three clouds, including air-gapped sites. You also choose it when one operator should cover Airflow, Kafka, PostgreSQL and the rest.
You are happy on MWAA, Composer or Astronomer but want a senior engineer for the DAG layer: parse time, tasks stuck in queued, pool and slot limits, executor sizing. That is Tier 1 or 2 on the support page, not a managed contract.
Moving off one means copying DAGs and variables, rebuilding connections and secrets, replacing provider-specific features and running the old and new environments in parallel until the output matches. We scope that as a project and then run the platform.
Not sure which? A platform review compares them for your DAG count, executor and compliance rules. Apache Airflow consulting
Airflow 3
Apache ended support for Airflow 2 on 22 April 2026, and 2.11.2 was its last release. The Apache upgrade guide recommends reaching the latest 2.x first, then moving to 3. These are the changes that break DAGs, from that guide as read on 31 October 2026.
Task code can no longer import Airflow's database sessions and models. Workers reach Airflow through the API server's Task Execution API. DAGs that query the metadata database from a task need rewriting to the Airflow Python client.
The DAG decorator, the DAG class and Asset (formerly Dataset) move to airflow.sdk. Old paths warn in 3.1 and are due for removal. The project's Ruff rules AIR301 and AIR302 find most of them.
SubDAGs, SLAs, the Sequential Executor, CeleryKubernetesExecutor and LocalKubernetesExecutor, and the /api/v1 REST API are gone. TaskGroups, Deadline Alerts, multiple executor configuration and /api/v2 replace them.
execution_date, next_execution_date, prev_ds, next_ds and similar keys are no longer in the task context. catchup_by_default is now False, and manual runs should not assume data_interval equals logical_date.
The DAG processor starts as its own process, the web server becomes an API server, and operators such as BashOperator and PythonOperator move to the standard provider package. Simple Auth is the default, so FAB users install the FAB provider.
MWAA upgrades between minor versions only, and Google lists in-place Gen 3 upgrades from Airflow 2 to 3 as not yet supported, so on both a new environment is the route. On infrastructure we run, we rehearse the move on a copy and cut over in an agreed window.
Sources: airflow.apache.org Supported versions and Upgrading to Airflow 3, docs.aws.amazon.com MWAA Airflow versions, cloud.google.com Composer versioning overview, checked 31 October 2026. Airflow support options after Airflow 2 end of life
Ownership
The line is written into the contract so that nobody finds it during an incident.
Scheduler, DAG processor, workers, triggerer, the metadata database, its backups, version upgrades, provider pins, monitoring and the pager.
What a DAG does, its schedule, its data and the task logic. Your engineers write and merge it through your pipeline.
When a DAG slows the scheduler through top-level code, saturates a pool or leaves tasks stuck in queued, we find the cause and tell you which file. Fixing the DAG is yours, or a consulting engagement.
Helm values, deployment code, runbooks and monitoring configuration are kept in your repository. If you bring operations back in-house, there is nothing to unpick.
Price drivers
AceMQ does not publish a price list for managed services. A managed Airflow quote is built from these inputs, and the written quote returns within 1 hour of your request.
How many Airflow environments, production and non-production, and how many DAGs and task runs a day they carry.
CeleryExecutor or KubernetesExecutor, the number of workers, and whether it runs on Kubernetes, virtual machines or in an air-gapped site.
From business hours to 24/7 on-call with the 15-minute P1 response.
At Tier 3 you pay your cloud provider for infrastructure and AceMQ for operations. At Tier 4 the infrastructure is part of the AceMQ quote. A version upgrade, if one is due, is scoped in the quote.
Not a fit for
We would rather say so up front.
AceMQ is a specialist service with a contract and senior engineers, not a self-service console. If you want to click to create an environment and pay by the hour, MWAA, Composer or Astronomer is the better fit.
Rewriting DAGs for Dagster or Prefect is a different project from running Airflow. We can tell you whether staying on Airflow is right, but we do not run those tools.
A managed platform keeps Airflow healthy. It does not turn slow or non-idempotent DAGs into good ones. That is consulting work, and we can scope it separately.
A few cron-like jobs with no uptime target do not need a managed Airflow contract. A current version and a backup is enough.
Running several engines? One contract can also cover Kafka, PostgreSQL, Redis and more. Data engineering consulting
Escalation Path
Every tier reaches a senior Apache Airflow engineer. There is no tier-1 triage layer to get through.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Typical engagements
Apache Airflow support work from AceMQ. Each card links to the full write-up: the Airflow estate, what AceMQ diagnosed or changed, and the result.
Global Insurance Group
Resolving pipeline runtime blowouts caused by queries spilling to remote storage on undersized warehouses while concurrent jobs queued behind them.
Snowflake
dbt
Airflow
TerraformRetail Analytics Provider
Ongoing support for Snowpipe, stream, and task failures including stale streams past their retention window and silent partial-load conditions.
SnowflakeSnowpipeAirflow
S3Financial Market Data Provider
Assessment of clustering keys, micro-partition pruning, and table design on large tables where queries had begun scanning most of the data.
SnowflakedbtAirflowTerraformNational Insurance Carrier
Restoring scheduling on Airflow deployments where zombie tasks hold executor slots and pools until nothing new gets queued.
Apache Airflow
KubernetesCelery
PostgreSQLDigital Retail Platform
Fixing scheduler delay caused by DAG files that make network or database calls at parse time, blocking every DAG in the deployment.
Apache AirflowKubernetesPostgreSQLRegional Utility Operator
Reviewing an Airflow deployment for reliability, DAG authoring practice, secrets handling, and upgrade readiness before it becomes unmaintainable.
Apache AirflowKubernetesPostgreSQL
Apache SparkSupport options
AceMQ offers Apache Airflow support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for platforms your team runs, proactive monitoring that finds parse delays and slot exhaustion first, managed Airflow on your own infrastructure, and fully managed Airflow on AceMQ infrastructure. Airflow 3 and Airflow 2 are covered, including MWAA, Cloud Composer and Astronomer environments.
You run it, we back you up
Best for: Data platform teams that run Airflow themselves and need senior escalation cover when a pipeline chain stops.
You run it, we watch it with you
Best for: Teams that want the stale dashboard prevented, not explained afterward.
We run it in your cloud or data centre
Best for: Regulated estates that must keep orchestration and credentials inside their own network.
We host it and run it, as a service
Best for: Teams that want Airflow without a platform rota or an upgrade project of their own.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Apache Airflow day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for Apache Airflow
Support is one part of what AceMQ does for Apache Airflow. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
FAQ
Still have questions about Apache Airflow? Email an Expert
MWAA and Cloud Composer run the platform inside their own service, with no SSH on MWAA, no custom images and a fixed set of versions. AceMQ operates standard Airflow in your account or ours with system access, custom images and your own provider pins, takes the pager with a 15-minute emergency response, and runs upgrades as projects. Both options leave DAG code with you.
Yes. Tier 3 runs Airflow on Kubernetes, virtual machines or Docker in your AWS, Azure or Google Cloud account or in your data centre, including air-gapped sites. You keep the account, the data and the credentials. Tier 4 is the alternative when you would rather not run any infrastructure.
We move to the latest Airflow 2.x first, as the Apache guide recommends, clear deprecation warnings, rehearse the upgrade to Airflow 3 on a copy, and cut over in an agreed window with a rollback written down. Provider packages and Python dependencies are pinned with constraint files so an upgrade changes one thing at a time.
You own the DAG code. AceMQ owns the platform, and triages DAG-level causes such as parse time and pool use but does not rewrite your DAGs unless you scope that. Helm values, deployment code and runbooks sit in your repository, so you can take operations in-house or move between tiers without unpicking anything.
Yes. AceMQ works on Apache Airflow in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Managed Apache Airflow is quoted per scope, with no list price: the price depends on the number of environments and nodes, the SLA, whether AceMQ runs Apache Airflow on your infrastructure (Tier 3) or on ours (Tier 4), and the access and change process you need. Request a quote and AceMQ replies within 1 hour.
Let's talk
Reactive cover, proactive reviews, or AceMQ running Apache Airflow for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
Production incident right now?Email an Apache Airflow Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
