Amazon MWAAとは？東京の料金・Airflow 3.3.1対応とServerlessとの違い【2026年10月】

Amazon MWAA（Amazon Managed Workflows for Apache Airflow）は、オープンソースのApache AirflowをAWSが環境ごと運用するマネージドサービスです。cronとシェルスクリプトで回してきた夜間バッチを、依存関係を持つジョブ群として組み直すとき、EC2へ自前でAirflowを立てる案と並んで候補に上がります。この記事では、2026年10月時点の版・単価・制約を、公式ドキュメントとAWSの料金APIで確かめた値で整理します。

まとめ：MWAAの守備範囲と料金・Serverlessとの使い分け

MWAAは、スケジューラ・ワーカー・ウェブサーバ・メタデータベースをAWSが用意し、パッチを当て、負荷に応じてワーカーを増減させます。利用者が持つのは、S3に置くDAG・requirements.txt・プラグインと、VPCやIAMの設定です。

MWAAで選べる最新のApache Airflowは3.3.1で、2026年9月1日から提供されています。環境は mw1.micro から mw1.2xlarge までの6クラスで、東京の単価は1時間0.29〜3.96ドル。環境には停止の状態がなく、DAGが走らない時間も課金されます。

2025年11月に加わったMWAA Serverlessは、東京で1タスク1時間0.104ドル（最低1分）です。mw1.small の環境基本料は、Serverlessの月約3,400時間ぶんの課金対象時間に相当します。例えば1日50回、各5タスク、平均3分、30日稼働なら月375時間で39.00ドルとなり、環境基本料357.70ドルの約11％です。Airflowの画面が要る、60分を超えるタスクがある、独自のオペレータやプラグインを使う。どれかに当たるなら環境を立てる従来のMWAAを選びます。

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

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

2026年8月に追加された責任共有モデルのページによると、AWSが持つのは、Airflowのセットアップ、Fargate上のスケジューラ・ワーカー・ウェブサーバ、メタデータベースの運用、バージョンイメージの作成とパッチ、ワーカーとウェブサーバの自動増減です。利用者が持つのは、DAGのコード、依存関係、プラグインと起動スクリプト、ネットワークと権限、日々のワークフロー運用です。

見落としやすいのはメタデータベースのデータ量です。運用はAWSでも、肥大化させない責任は利用者側にあると同ページは明記しています。実行履歴を溜め続けるとスケジューラと画面の応答が遅くなるため、古い履歴を消すDAGを定期実行しておきます。

処理の実体はAirflowの外に置くのが基本で、AirflowはAWS Glue・Amazon EMR・AWS Batch・Amazon Redshiftなどを呼び出して完了を待つ役に徹します。役割の分け方はAWS Glueとは？機能・料金・使い方とWorkflowsの仕組みまで徹底解説と読み比べると輪郭がはっきりします。

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

スケジューラとワーカーはAWS Fargateのコンテナとして、自分のVPCのプライベートサブネットに接続されます。ウェブサーバとAurora PostgreSQLのメタデータベースは、AWSが所有する別のVPCに置かれます。スケジューラとワーカーはCloudWatch・S3・SQS・KMSに到達できなければ動かないため、インターネットに出られないVPCではVPCエンドポイントを自分で作ります。

環境に指定したVPCは作成後に変えられません（環境の更新手順）。閉域にするかどうかは作成前に決めてください。

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

DAG、plugins.zip、requirements.txt は指定したS3バケットに置きます。バケットはパブリックアクセスを全てブロックし、バージョニングを有効にします。requirements.txt と plugins.zip は環境設定でオブジェクトバージョンを指定し、DAGはフォルダの中身が30秒ごとに自動同期されます。Airflow 2.7.2以降は requirements.txt の先頭に --constraint 行が必須で、書かなければMWAAが自動で付けます。

--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.3.1/constraints-3.12.txt"
apache-airflow-providers-snowflake

依存ライブラリの公式ガイドは合計1GB未満を推奨しています。10分以内にインストールが終わらないとFargateがタイムアウトし、環境は直前の状態へロールバックされます。失敗の詳細はCloudWatch Logsの requirements_install_ip ログストリームに残るので、本番に上げる前に aws-mwaa-docker-images で同じイメージをローカルに立てて試します。

6つの環境クラスと東京リージョンの時間単価

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

環境クラスは、Celery Executorが動くFargateコンテナとメタデータベースのサイズをまとめて決める設定です。単価はAWSの料金API（Price List API）の東京リージョン（2026年9月11日版）から取り、月額は730時間で計算しました。東京とバージニア北部は同額です。

クラス選びの起点は、DAGの本数でなく同時に走るタスクの数です。DAGが10本でも、朝6時に一斉に走って各20タスクを持つなら、ワーカー1台あたり既定5並列の mw1.small では、ワーカーが増えるまで待ち行列が伸びます。mw1.micro は自動スケーリングに対応せずスケジューラも1台なので、開発・検証用に安く分ける位置づけです。

追加ワーカー・スケジューラ・ウェブサーバの単価と増減幅

含まれる台数を超えた分はクラスごとの単価（1時間あたり）で加算され、メタデータベースのストレージは1GB月0.10ドルです。

mw1.microを除き、ワーカーは設定した最小台数と最大台数の間で自動増減します。最大台数の初期設定は10台で、標準クォータは25台ですが、引き上げを申請できます。スケジューラは mw1.micro 以外で2〜5台、既定は2台。遅延タスクを管理するtriggererはスケジューラと同じFargateタスクに同居するため、deferrableなオペレータを多用するならスケジューラの台数がそのまま効きます。サービスクォータは環境数がアカウント・リージョンあたり10で、開発・検証・本番をチームごとに分けると早く当たります。

対応するApache Airflowバージョンと2系から3系への上げ方

サポート中のバージョン一覧とPythonの版

MWAAのバージョンページには2026年10月時点で10の版が並び、版を指定せずに作ると最新版になります。

MWAAは同時に少なくとも3つのマイナー版をサポートし、各版を提供開始から12か月以上維持し、終了日を180日以上前に告知する方針です。2.4.3・2.5.1・2.6.3は2025年12月30日に終了しました。終了後も既存環境は動きますが、新規作成とその版への変更はできず、技術サポートも受けられません。本家は3.3.2（2026年9月17日）まで進んでおり、MWAAで選べる版とは1〜2か月の差があります。

Airflow 3.3で入った変更とMWAAで使えない機能

3.3.0のリリースノート（2026年7月6日）で、DAG設計に効くのは3つです。アセットのパーティション拡張（RollupMapper・FanOutMapper などで、日付で分けたS3パスを条件にした後続起動を組みやすくなった）、リトライや実行をまたいで値を保持する状態ストア（AIP-103）、例外の種類で再実行を決められるリトライポリシー（AIP-105）。状態ストアの既定の保存先はメタデータベースなので、MWAAではデータ量の管理が利用者に乗ります。

同じ3.3.0のJava・GoのタスクSDKは本家が実験的機能と明記しており、MWAAで使えるとは案内されていません。複数チームでスケジューラを共有するmulti-teamモードは、MWAAの認証やCeleryExecutorと両立しないため非対応です。3系そのものの変更点はApache Airflowとは？Jenkinsとの違い・DAGの書き方と3.3の導入手順にまとめています。

2系から3系へ上げる条件と停止時間

バージョン変更の手順では、メジャー版の変更に条件があります。

• 2系から3系へは、先に2.11.x（現行は2.11.2）へ上げてから3系へ上げる
• 2.10.3以前から2.11.xを経由せず3系へ移す場合は、新しい環境を作って移行する
• 3系から2.11.xへのダウングレードは可能

変更中は実行中のタスクが全て終了し、最大2時間ほど環境が使えません。MWAAはメタデータベースのスナップショットを取ってから入れ替えるので、事前に古い履歴を掃除すると短くなります。失敗すると ROLLING_BACK を経て UPDATE_FAILED（環境は使える）、ロールバックにも失敗すると UNAVAILABLE です。aws-mwaa-docker-images の移行先ブランチでDAGを試し、--constraint のURLを移行先の版に替え、検証環境で一度通してから本番を上げてください。2026年10月15日には、版上げを扱う upgrading-mwaa-environments を含むMWAA向けのAIエージェントスキル4種も公開されています。

Airflow 3のMWAAで踏みやすい通信と更新の落とし穴

Airflow 3のパブリックモードとNATなし構成でのタスク失敗

Airflow 3系では、ワーカーがタスクの状態をTask API経由でウェブサーバへ報告します。2系には無かった通信なので、2系の構成のまま3系へ上げたときに初めて表面化します。アクセスモードの公式ページは、ウェブサーバがパブリックネットワークモードの3系環境で、ワーカーのサブネットがインターネットに出られない（NAT Gatewayの無いプライベートサブネット）と、DAGのタスクが失敗すると警告しています。

対処は、3.2.1以降に上げて、2026年5月に追加された3つ目のアクセスモード「Both public and private network access」へ切り替えることです。画面はパブリックのロードバランサで受け、ワーカーからの通信はMWAAが自動で作るVPCエンドポイントを通ります。NAT Gatewayを置かずに、社外から画面を開ける構成になります。

環境更新時の既定FORCEDと実行中タスクへの影響

設定変更やパッチで環境を更新するとき、既定のFORCEDは実行中のワーカーを即座に止め、走っていたタスクは失敗します（所要20〜30分）。GRACEFULを選ぶと、既存ワーカーの実行中タスクを最大12時間継続させ、新しいタスクは更新済みワーカーへ送ります。有効化にはAirflow 2.4.3以降と、一度のFORCED更新が必要です。

落とし穴は、WorkerReplacementStrategy が更新のたびにFORCEDへ戻ると更新手順のページに書かれている点です。CloudFormationやTerraformで管理しているなら、更新のたびにGRACEFULを明示します。環境がメンテナンス中（MAINTENANCE）に投げた更新も、GRACEFULはFORCEDに切り替わります。

MWAA Serverlessとの違いと2026年8月のPython対応

タスクごとにコンテナを起動する仕組みと課金単位

MWAA Serverlessは2025年11月17日に始まった、環境を持たない提供形態です。タスクごとに隔離されたコンピュートを起動し、ワークフローごとに別のIAM実行ロールを割り当て、スケジュールはEventBridge Schedulerが担います。Airflowは3系、Pythonは3.12です。

料金ページによると課金はタスクの実行時間で、秒単位で計測し最低1分です。料金APIの単価は東京0.104ドル、バージニア北部0.080ドルで、環境方式と違い東京が3割高い設定です。10秒で終わるタスクも1分として数えるため、短いタスクを大量に並べる設計では実際の6倍が課金されます。提供リージョンは2026年10月時点で34に広がり、東京と大阪の両方で使えます。

ワークフローの状態は、Scheduled・Disabled・Manual onlyの3つです。DisabledやManual onlyに切り替えても走っている実行は止まらず、止めるには StopWorkflowRun を呼びます。

PythonOperatorとBashOperatorで書ける範囲と条件

提供開始時のServerlessはAWSサービス向けのオペレータに限られ、独自の処理はLambdaやGlueへ切り出す必要がありました。2026年8月の更新でPythonOperatorとBashOperatorが使えるようになり、料金は他のタスクと同じです。コードはYAMLの定義とは別に、create-workflow の --code 引数で .py・.sh・.zip のS3の場所を渡します。

つまずきやすいのは3点です。ライブラリは pip install --target に --platform manylinux2014_x86_64 --python-version 3.12 --only-binary=:all: を付けてLinux向けを取り、zipの最上位に並べます（Mac向けのままだと実行時のimportで落ちる）。boto3など同梱済みのパッケージは、zipに別の版を入れても同梱版が優先されます。外部APIを呼ぶタスクは、インターネットに出られるVPCを NetworkConfiguration で指定しない限り通信できません。コードは作成・更新時にスナップショットされ、S3を差し替えても次の更新まで反映されません。

Python DAGをYAMLへ変換する手順と実行結果

既存のPython DAGは、AWSが公開する変換ツールでYAMLにします。2026年10月26日に、公式イメージ apache/airflow:3.0.6-python3.12 のコンテナで最新版0.1.4（2026年6月16日公開）を動かしました。最初に、Glueジョブの後へ地域別のAthenaクエリをforループで2本つなぎ、通知用のPythonOperatorを1本足したDAGを渡すと、静的検証で InvalidOperatorError: Operator PythonOperator is not supported を返して止まりました。0.1.4はPythonOperator対応より前の版で、Serverless本体は動かせても変換ツールはまだ通しません。

PythonOperatorを抜いた次の24行のDAGは、変換に成功しました。再現する場合は、このコードを dags/daily_sales_aws.py に保存し、前述のコンテナ内で後続のコマンドを実行します。

from datetime import datetime
from airflow import DAG
from airflow.providers.amazon.aws.operators.glue import GlueJobOperator
from airflow.providers.amazon.aws.operators.athena import AthenaOperator

with DAG(
    dag_id="daily_sales_aws",
    start_date=datetime(2026, 10, 1),
    schedule="0 6 * * *",
    catchup=False,
) as dag:
    transform = GlueJobOperator(
        task_id="transform",
        job_name="sales-transform",
        wait_for_completion=True,
    )
    for region in ["east", "west"]:
        check = AthenaOperator(
            task_id=f"check_{region}",
            query=f"SELECT count(*) FROM sales WHERE region = '{region}'",
            database="analytics",
            output_location="s3://example-athena-results/",
        )
        transform >> check

pip install python-to-yaml-dag-converter-mwaa-serverless==0.1.4
dag-converter convert dags/daily_sales_aws.py --output out2

出力は112行のYAMLで、forループは check_east・check_west の2タスクに静的に展開され、それぞれに依存関係が付きました。retries: 0 や deferrable: false など、DAGで省略した設定の一部も明示的に書き出されました。

    check_east:
      operator: airflow.providers.amazon.aws.operators.athena.AthenaOperator
      database: analytics
      workgroup: primary
      dependencies:
      - transform

GlueJobOperatorには waiter_delay: 60 と waiter_max_attempts: 75 も入りますが、これは deferrable: true のときのトリガーにだけ渡る値です。Serverlessに同梱のamazonプロバイダ9.32.0のソースでは、deferrable: false の同期待ちは job_poll_interval（既定6秒）ごとに状態を確かめ、回数の上限なく完了まで待ちます。Serverlessでは待っている時間もタスクの実行時間なので、60分を超えるGlueジョブを完了待ち付きで呼ぶとタスク上限に当たります。起動タスクを wait_for_completion: false にしてセンサーで待つ形に分けても、センサー側に同じ60分の上限が掛かります。1回の待ちが60分を超えるジョブは、環境方式のMWAAに残すのが確実です。

Airflow UIが無い運用とクォータの上限

ServerlessにはAirflow UIへの直接アクセスはありませんが、AWS Management Consoleでワークフローを監視できます。ログとメトリクスはCloudWatch、API操作の監査はCloudTrailで確認します。画面で組みたい場合はAmazon SageMaker Unified Studioとワークフローを双方向に同期できます。2026年6月11日からはワークフローとタスクの状態変化をEventBridgeへ送れるようになり、失敗時の通知はポーリングを書かずに組めます。

プロビジョンド版の月額とServerlessとの料金逆転ライン

東京で小規模環境を1か月動かしたときの内訳

環境方式の課金は作成から削除まで積み上がります。MWAAのAPI操作の一覧にあるのは作成・更新・削除などで、停止と再開の操作はありません。東京で mw1.small を730時間動かすと、環境357.70ドル、常時1台の追加ワーカー40.15ドル、メタデータベース10GBで1.00ドル、合計398.85ドルです。

見積もりが崩れやすいのは通信費です。インターネットに出られないVPCでは、必要なVPCエンドポイントの一覧どおり、CloudWatch（monitoringとlogs）・SQS・KMSと、Airflow用の airflow.api・airflow.env・airflow.ops の計7つをインターフェース型で作ります（S3はゲートウェイ型で無料）。東京のインターフェース型は1つ・1AZあたり0.014ドル毎時なので、2AZで7×2×0.014×730＝143.08ドル、これにデータ処理料金が加わり、リージョン内のインターフェースエンドポイントの月間合計で最初の1PBまでは1GBあたり0.01ドルです。NAT Gatewayで外に出す構成でも、AZごとの時間料金とデータ処理料金が代わりに掛かります。

月間のタスク実行時間から引くコスト逆転ライン

mw1.small の環境費357.70ドルを東京のServerless単価0.104ドルで割ると約3,439時間です。これは環境基本料だけとの料金上の等価点で、課金対象時間（最低1分を反映した時間）がここを超えるとServerlessのタスク料金が環境基本料を上回ります。1日あたり約113時間、タスクが常時4〜5本走り続ける規模です。ただし料金だけの比較で、両方式で同じ処理能力や実行時間になることは保証しません。追加ワーカーを1台常時足した398.85ドルの構成なら等価点は約3,835時間に上がり、通信費まで含めるとさらに上がります。mw1.large（722.70ドル）なら約6,949時間まで逆転しません。

1日50回のDAG実行で各5タスク、平均3分なら、30日で375時間、Serverlessは39.00ドルで mw1.small の1割強です。最低1分課金が最も効く例として、5秒のタスクを毎分1本流しても月43,200本で720時間、74.88ドルに収まります。Serverlessはタスクごとにコンピュートを用意するため常駐ワーカーより開始が遅れ、起動待ちを許さない処理は環境方式に残ります。

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

環境方式のMWAAを採用してよい条件と下限のライン

環境を立てるMWAAが合うのは、ジョブ間に依存関係があって失敗したタスクから再実行したい、処理の実体はAWSサービス側にある、DAGをPythonで書いてGitで管理する体制がある、そして画面での運用か60分超のタスクか独自のオペレータが必要でServerlessでは足りない、という条件がそろうときです。

ジョブが10本前後で直列にしかつながらず、失敗しても翌朝に手で流し直せば済むなら、EventBridge SchedulerとLambdaのほうが費用も学習コストも小さく済みます。DAGが数十本を超えて担当者が複数になり、実行履歴を画面で共有する必要が出たら、削減できる月間運用時間に時間単価を掛け、月400ドル前後の環境費と通信費などの追加費用を上回るかで採用を判断します。

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

中身がAWSサービスの呼び出しに閉じていてAirflowの資産も無いなら、AWS Step Functionsのほうが軽く、実行単位の課金で固定費も掛かりません（AWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説）。

必要なプロバイダの依存関係をMWAAに導入できない、MWAAで変更できないコア設定が必須、multi-teamモードで1つのクラスタを分けたい、といった制約に当たるなら自前運用を選びます。ただしメタデータベースと版上げを自分で持ちます。データウェアハウスがBigQueryにあるなら、Googleのマネージド版であるManaged Service for Apache Airflow（旧Cloud Composer）のほうが権限も通信経路も素直です（Cloud Composerとは？マネージドApache Airflowの仕組み・料金と採用判断を実装者目線で解説）。Airflow以外ではアセット中心で設計するDagsterも候補になります。

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

見積書では、環境クラスと想定同時タスク数の根拠、通信経路（NAT GatewayかVPCエンドポイントか）とその月額の別記、DAGの受け入れ基準（リトライ・タイムアウト・失敗通知・冪等性）、版上げの作業範囲の4つを確認します。「AWS利用料は別途」で通信費が一括りだと、稼働後に月100ドル単位の差で揉めます。冪等性の考え方はデータパイプラインとは？種類・構成要素と冪等性から考える設計判断を解説で整理しています。サポート終了は180日前に告知され、2系から3系へは2.11.xを経由するため、年1回程度の版上げを誰が持つかは契約時点で決めておきます。要件整理からパイプラインの運用設計までの相談は、データ分析基盤構築・MLOps構築支援で受けています。

よくある質問

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

既存のAirflow資産があり、PythonでDAGを書く体制があるならMWAA、AWSサービスの呼び出しに閉じているならStep Functionsです。MWAAは定期的で並列数が一定のバッチ、Step Functionsは同時実行数が読めない処理やほぼリアルタイムの処理に向きます。

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

そのままでは載りません。定義はYAMLで、Python DAGは変換ツールでYAMLにします。PythonOperatorは2026年8月から実行できますが、変換ツール0.1.4はPythonOperatorを含むDAGを拒否するため、その部分のYAMLは手で書きます。関数はPython 3.12・x86_64向けのコードパッケージとして別に渡します。

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

環境方式に停止はなく、費用を止める手段は削除だけです。開発環境なら mw1.micro（東京で月約212ドル）を選ぶか、CloudFormationやTerraformで使い終わったら削除して作り直します。DAGと requirements.txt はS3に残りますが、実行履歴はメタデータベースと一緒に消えます。

MWAAで使えるPythonのバージョンはいくつですか？

Airflowの版で決まり、3.3.1・3.2.1・3.0.6・2.11.2・2.11.0はPython 3.12、現在サポート中の2.7.2〜2.10.3はPython 3.11です。Pythonの版だけを選ぶことはできません。Serverlessは2026年10月時点でPython 3.12です。

東京リージョンで使えますか？Serverlessと料金は同じですか？

環境方式もServerlessも、東京（ap-northeast-1）と大阪（ap-northeast-3）で使えます。環境方式の単価は東京とバージニア北部で同額ですが、Serverlessは東京0.104ドル、バージニア北部0.080ドルで東京の方が高くなります。

関連記事

• Apache Airflowとは？Jenkinsとの違い・DAGの書き方と3.3の導入手順
• Cloud Composerとは？マネージドApache Airflowの仕組み・料金と採用判断を実装者目線で解説
• AWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説
• AWS Batchとは？ジョブキュー型マネージドバッチ処理の仕組みと採用判断【2026年版】
• Amazon EMRとは？最新版7.14・Spark 4対応の8.1と東京の料金、サポート期限【2026年10月】