Amazon MWAAとは？Airflow 3.2対応とサーバーレス版の違い・料金・環境設計を実装者目線で解説

夜間バッチをcronとシェルスクリプトで回してきた基盤を、依存関係を持つジョブ群として組み直したい。この要件でApache Airflowを選ぶとき、EC2に自前で立てる案とAmazon MWAAに寄せる案が並びます。MWAAは、Airflowの各コンポーネントをAWSが管理するマネージドサービスです。

まとめ：MWAAの守備範囲と料金・サーバーレス版との使い分け

Amazon MWAA（Amazon Managed Workflows for Apache Airflow）は、オープンソースのApache Airflowをそのままの画面とコードで動かせる形で提供するマネージドサービスです。DAGはPythonで書いてAmazon S3のバケットへ置き、追加ライブラリは requirements.txt で入れます。

設計で決めるのは、環境クラス・Airflowバージョン・アクセスモード・ワーカーの増減幅の4つ。クラスは mw1.micro から mw1.2xlarge まで6段階で、DAGの収容目安が25本から4,000本まで変わります。2026年7月時点の最新はApache Airflow 3.2.1です。

料金の要点は1つ。環境そのものが時間課金で、DAGが1本も走らない時間帯も止まりません。バージニア北部の計算例では小規模環境が1時間0.49ドル、744時間で364.56ドル。2025年11月に加わったサーバーレス版はタスクの実行時間だけを課金するため、常時走り続ける規模でなければ費用は1桁下がります。ただし機能の制約が大きく、選べる案件は限られます。

Amazon MWAAが肩代わりする範囲と環境を構成する要素

自前のApache Airflow運用とMWAAで分かれる担当範囲

EC2にAirflowを立てて運用する構成と比べたとき、肩代わりされるのは5領域です。スケジューラとワーカーのコンテナ配置、メタデータベースの構築とバックアップ、ウェブサーバの公開と認証、負荷に応じたワーカーの増減、Airflow本体のパッチ適用とバージョンイメージの提供。

引き受けないものも明確です。DAGの設計と実装、ライブラリの依存解決、常時課金を前提とした稼働時間の設計、タスクが処理を投げる先のリソース管理。AirflowのオペレータはAWS BatchやAmazon EMR、AWS Glue、Amazon Redshiftなどを呼ぶ形が中心で、変換処理そのものはGlueやEMR側が担います。役割分担はAWS Glueの機能とWorkflowsの仕組みの解説と読み比べると輪郭がはっきりします。

スケジューラ・ワーカー・メタデータベースの構成とVPCの要件

1つの環境は、スケジューラ、ワーカー、ウェブサーバ、メタデータベース、DAG置き場のAmazon S3バケットで構成されます。スケジューラとワーカーはAWS Fargateのコンテナとして動き、自分のVPCのプライベートサブネットへ接続。メタデータベースはAWS管理のAurora PostgreSQLで、専用のVPCエンドポイント経由でのみ到達できます。

環境の外側にあるのはAmazon CloudWatch、Amazon S3、Amazon SQS、AWS KMSの4つで、Fargate上のスケジューラとワーカーから到達できることが前提。閉域構成なら必要なぶんのVPCエンドポイントを自分で用意します。ウェブサーバの公開範囲はパブリックとプライベートの2択で、どちらでもアクセス可否を決めるのはIAMのポリシー。なおApache Airflow v3以降はウェブサーバがexecution API serverも兼ねる構成です。

DAGとrequirements.txtをS3経由で反映する仕組み

DAGファイル、カスタムプラグインの plugins.zip、依存ライブラリの requirements.txt は、すべて指定したS3バケットへ置きます。このバケットにはパブリックアクセスブロックとバージョニングの有効化が必須。MWAAが使うファイルをオブジェクトバージョンで指定する仕様のためです。

依存ライブラリの反映では、MWAAがスケジューラと各ワーカーで pip3 install -r を走らせます。Apache Airflow 2.7.2以降は --constraint の記述が必須で、書かなければAWS側が自動で当てる挙動。制約に反するバージョンはインストールが失敗し、環境が壊れる事態を未然に止めます。

踏みやすい落とし穴が所要時間の制限です。ライブラリの合計サイズは1GB未満が推奨で、10分以内にインストールが終わらないとFargate側がタイムアウトし、環境は直前の安定状態へロールバックされます。事前検証はAWSが公開する aws-mwaa-docker-images で行い、失敗の詳細はCloudWatch Logsの requirements_install_ip というログストリームで確認します。

6つの環境クラスとApache Airflowバージョンの選び方

mw1.microからmw1.2xlargeまでのDAG収容数と同時タスク数

環境クラスは、Celery Executorが動くFargateコンテナとメタデータベースのサイズを同時に決める設定です。DAG収容数は定義の本数の目安で、実行数の上限ではありません。

選定の起点は同時タスク数です。DAGが10本でも、朝6時に全部が一斉に走って各20タスクを持つなら mw1.small の5並列では詰まります。なお mw1.micro だけは自動スケーリングに対応せず、開発や検証の環境を安く分ける位置づけです。

サポート中のApache Airflowバージョンと3.2の変更点

MWAAは複数のAirflowバージョンを並行提供し、少なくとも3つのマイナーバージョンを同時にサポートする方針です。個々のパッチ版は提供開始から最低12か月。終了日以降はそのバージョンでの新規環境作成ができなくなります。

2.4.3・2.5.1・2.6.3の3つは2025年12月30日でサポートが終了しました。該当する環境が残っているなら移行計画を先に立ててください。

2026年4月リリースのAirflow 3.2は、5月19日からMWAAで選べます。目立つ変更は、日付でパーティションされたS3のパスなどデータの一部分を条件に後続DAGを起動できるアセットのパーティション対応と、人の承認を挟むHITLの監査履歴表示。ほかにDeadline Alertsの同期コールバック、大規模DAGでのGrid View描画の高速化、画面上でのXCom管理が入りました。アップグレードは2.11以降の環境から可能と案内されています。3系の変更点の全体像はApache Airflowの仕組みとAirflow 3の新機能の解説で確認してください。

ワーカーとスケジューラの増減幅とアカウント単位で掛かるクォータ

ワーカーは最小1台から最大25台の範囲で自動増減し、既定の最大は10台。1台あたりの並列数は celery.worker_autoscale で上げられますが、メモリ不足でタスクが落ちる副作用と表裏です。

スケジューラは mw1.micro 以外で2〜5の範囲、既定は2。見落としやすいのが、遅延タスクを管理するtriggererがスケジューラと同じFargateタスクに同居する設計で、deferrableなオペレータを多用するならスケジューラ数がそのまま効きます。

環境の数はアカウントかつリージョンあたり10が既定の上限で、開発・検証・本番を環境だけで分ける運用はこの数字に早く当たります。量産したいなら mw1.micro か、後述のサーバーレス版へ寄せる判断です。

2025年11月に加わったMWAA Serverlessとの違い

2025年11月17日、タスク単位で課金する提供形態が加わりました。環境を常時立てる従来方式とは別物です。

タスクごとにECS Fargateで実行する仕組みと課金単位

サーバーレス版は、ワークフローのタスク1つひとつをAmazon ECS on AWS Fargateの独立したコンテナで実行します。タスクはAirflow 3のTask API経由でクラスタと通信する構造。環境という常駐リソースを持たないため、走っていない時間の課金は発生しません。提供リージョンは東京を含む15です。

課金はタスクの実行時間に対する時間単価で、1秒単位の計測ながら最小1分が課金されます。料金ページの計算例は、1分未満のタスク1,000本と2分のタスク1,000本で合計50時間、1時間0.080ドルとして4.00ドル（バージニア北部・2026年7月時点）。最小1分という条件は短命タスクを大量に並べる設計に効き、10秒で終わるタスクは実測の6倍が課金対象です。

Python DAGからYAML定義への変換とワークフロー単位のIAM

ワークフローの定義は、DAG Factory形式をベースにしたYAMLファイルです。S3へ置いたうえで aws mwaa-serverless create-workflow のように作成し、実行は StartWorkflowRun を呼びます。既存のPython DAGは python-to-yaml-dag-converter-mwaa-serverless でYAML化する流れで、ループで動的生成していたタスクは静的なリストへ展開されます。

設計上の利点が大きいのは、ワークフローごとにIAMロールを持てる点です。従来の環境では1つの実行ロールを全DAGが共有し、権限は最大公約数で広くなりがちでした。サーバーレス版なら実行時に限った権限へ絞り込めます。

ワークフローの状態は、スケジュール実行するScheduled、実行を止めるDisabled、手動実行だけ受けるManual onlyの3種類です。ここに注意が1つ。DisabledやManual onlyへ切り替えても既に走っている実行は止まらず、停止には StopWorkflowRun の呼び出しが別途要ります。

Airflow UIが無いサーバーレス版で外れる機能とクォータ上限

制約は明確です。使えるオペレータはAmazon Provider Packageのものに限られ、任意のPythonコードを直接タスクとして走らせる形は取れません。独自処理はAWS LambdaやAWS Batch、Amazon EKS、AWS Glueなどへ切り出し、それを呼ぶ形へ組み替える改修が要ります。

もう1つ、Airflowのウェブ画面がありません。監視はAmazon CloudWatchとAWS CloudTrailで行う設計で、Grid Viewでタスクの色を見ながら再実行する運用は成立しない。画面が要るならAmazon SageMaker Unified Studioと双方向に同期できますが、Airflow UIの置き換えではありません。

設計判断に直結するのは下3つ。実行タイムアウトが60分固定のため、数時間かかる集計はタスク内で完結しません。長い処理はGlueジョブやBatchジョブへ投げ、完了をセンサーで待つ形へ分解します。DAG定義50KBとXCom 100KBの制限も、大きなデータを渡す実装を許しません。

プロビジョンド版の料金内訳とサーバーレス版と逆転する分岐点の計算

環境・ワーカー・スケジューラ・ウェブサーバに掛かる時間単価の内訳

環境を立てる方式の課金は、DAGの実行有無と無関係です。作成してから削除するまで時間課金が積み上がり、停止という状態が用意されていないため、夜間だけ止める運用は取れません。

これらは米国東部バージニア北部の計算例に示された単価で、2026年7月時点の料金ページに東京リージョンの数値は例示されていません。見積もりはAWS Pricing Calculatorで引き直してください。

公式の計算例を置くと規模感が掴めます。小規模環境を1か月（744時間）動かすと364.56ドル、追加ワーカー1台で83.55ドル、メタデータベース10GBで1.00ドル、合計449.11ドル。大規模環境に追加コンポーネントを足した例は合計1047.46ドルです。

VPCエンドポイントとNAT Gatewayが上乗せする通信費用

見積もりが崩れる原因の多くは、環境費より通信まわりにあります。インターネット経由ならNAT Gatewayを各アベイラビリティーゾーンに置く構成、閉域ならインターフェース型のVPCエンドポイントを並べる構成で、第三者の検証記事では後者に10個前後が要ると報告されています。インターフェース型はエンドポイント数とアベイラビリティーゾーン数の積で時間課金されるため、10個を2つのAZに置けば20本ぶんが常時課金される計算です。

同じ検証記事の東京リージョンの試算では、小規模環境の月364ドル台に対し、NAT Gateway構成で400ドル前後、VPCエンドポイント構成で240ドル前後が上乗せされていました。第三者の試算値ではありますが、通信費が環境費と同じ桁で乗る点は前提に置いてください。

月間タスク実行時間から引く2つの方式のコスト逆転ラインの試算

小規模環境の1か月は364.56ドル、サーバーレス版の計算例の単価は1時間0.080ドル。単純に割ると4,557時間です。つまり月間のタスク実行時間の合計が約4,557時間、1日あたり約152時間ぶんを超えて初めてサーバーレス版が高くなる勘定。1日152時間とは、6本強のタスクが24時間走り続ける規模を指します。

現実的な数字も置きます。1日50回のDAG実行で各5タスク、1タスク平均3分なら1日750分＝12.5時間、月375時間で30ドル。小規模環境の10分の1以下です。最小1分課金の影響が最大になる例、5秒で終わるタスクを毎分1本流す構成でも、月43,200本で課金対象は720時間、57.6ドルに収まります。

費用だけを見れば、大半のバッチ規模でサーバーレス版が勝ちます。それでも環境を立てる方式が選ばれるのは、Amazon Provider Package以外のオペレータ、任意のPythonコード、Airflow UI、60分超のタスクという4要件があるため。判断軸はこの4つを外せるかどうかです。

Amazon MWAAを採用してよい条件と他へ寄せるべき場面

Amazon MWAAを採用してよい4つの条件と下限のライン

4条件を挙げます。1つ目、ジョブ間に依存関係があり、失敗時の再実行の起点を細かく指定したい。2つ目、処理の実体がAWSサービス側にあり、Airflowは呼び出しと待ち合わせに徹している。3つ目、DAGをPythonで書いてGitで管理する体制がある。4つ目、月10万円弱の固定費を払っても人の運用時間を削るほうが安い規模である。

下限のラインは4つ目です。ジョブが10本前後で依存関係も直列、失敗しても翌朝に手で流し直せば済むなら、EventBridge SchedulerとLambdaの組み合わせのほうが費用も学習コストも小さい。逆にDAGが数十本を超え、担当者が複数人になり、実行履歴を画面で共有する必要が出た時点で固定費は正当化されます。この判断の前に、サーバーレス版で足りないかを一度通してください。

Step Functions・自前運用・Cloud Composerへ寄せる場面

寄せ先は3つ。1つ目はAWS Step Functionsです。中身がAWSサービスの呼び出しに閉じていてAirflowの資産も無いなら、状態遷移をJSONで書くほうが軽く、実行単位の課金で固定費も掛かりません。判断材料はAWS Step Functionsのステートマシンと料金の解説にまとめています。

2つ目は自前運用。他のプロバイダを深く使う、コア設定を細かく詰める、複数チームで1つのクラスタを分割する。こうした要件ではマネージドの制約が足かせです。ただしメタデータベースの運用を自分で持つ前提になります。

3つ目はGoogle Cloudへの寄せ。データウェアハウスがBigQueryにあり、パイプラインの大半がGoogle Cloud側で完結するなら、同等のマネージドAirflowであるCloud Composerのほうが権限設計も通信経路も素直です。比較はCloud Composerの仕組みと料金・採用判断の整理を参照してください。

データ基盤の構築を外部へ委託するときに見積書で確認する4項目

データ基盤の構築を外部へ任せる場合、見積書で確認する項目は4つ。第1に、環境クラスと想定同時タスク数の根拠が書かれているか。第2に、通信経路がNAT GatewayかVPCエンドポイントかと、その月額が別項目で明示されているか。ここが「AWS利用料は別途」で一括りだと、稼働後に揉めます。

第3に、DAGの受け入れ基準。リトライ回数、タイムアウト、失敗通知の宛先、冪等性の担保方法が仕様として書かれているかを見ます。第4に、バージョンアップ時の作業範囲。サポート終了は180日前に告知されるため、年1回のアップグレードを誰が持つかは契約時点で決めておくほうが安全です。要件整理から運用設計までを含めた相談は、AWS・Google Cloud・Azureのインフラ構築支援で扱っています。

よくある質問

Amazon MWAAとAWS Step Functionsはどちらを選ぶべきですか？

既存のAirflow資産とPythonでDAGを書く文化があるならMWAA、AWSサービスの呼び出しに閉じているならStep Functionsです。判断を分けるのは課金構造で、Step Functionsは実行単位の従量課金、MWAAの環境方式は常時課金。DAGの本数が増えるほどAirflowの表現力が効きます。

MWAA Serverlessに既存のPython DAGをそのまま載せられますか？

そのままでは載りません。YAML定義への変換が要り、変換ツールはあるものの、使えるオペレータがAmazon Provider Packageに限られる制約は残ります。PythonOperatorの独自処理はLambdaやGlueジョブへ切り出す改修が必要です。

環境を止めて料金を抑えることはできますか？

環境を立てる方式に停止の状態はなく、費用を止める手段は削除だけです。開発環境なら mw1.micro を選ぶか、使い終わったらCloudFormationやTerraformで環境ごと削除し、必要になったら作り直す運用になります。DAGとrequirementsはS3側に残るため、作り直しのコストは高くありません。

Apache Airflow 2系から3系へそのままアップグレードできますか？

コンソール上でのバージョン変更に対応しており、Airflow 3.2は2.11以降の環境からアップグレードできると案内されています。ただし3系はコアの変更が大きく、DAGの書き方や一部のインポートパスに影響が出る点に注意。同じ構成の検証環境を別途作ってDAGを流し、差分を確認してから切り替えてください。

東京リージョンで使えますか？サーバーレス版も同じですか？

環境を立てる方式は東京（ap-northeast-1）と大阪（ap-northeast-3）にエンドポイントがあり、サーバーレス版も2025年11月の提供開始時点で東京が対象に含まれます。ただし料金ページの計算例はバージニア北部の単価のため、見積もり時はリージョンを切り替えて確認してください。

関連記事

• AWS Batchとは？ジョブキュー型マネージドバッチ処理の仕組みと採用判断【2026年版】：タスクの実処理を投げる先の選定に使えます
• Amazon EMRとは？料金・最新版7.13とサポート終了時期をわかりやすく解説：大規模データ処理側の基盤を整理しています
• Prefect（Python）とは？ワークフロー管理の使い方と3系の始め方：Airflow以外の選択肢を比較できます
• Temporal Workflowとは？コードで書く分散ワークフローエンジンの仕組みと比較：コードで書く分散実行の考え方を扱います
• Nextflowとは何か？データ解析パイプラインを自動化するワークフロー管理ツールの特徴とメリットを解説：解析パイプライン特化型の選択肢です