ワークフロー管理 - Amazon MWAA で Apache Airflow をマネージド運用する

MWAA の位置づけと Airflow の課題

Apache Airflow はデータパイプラインのオーケストレーションにおけるデファクトスタンダードです。Python で DAG (有向非巡回グラフ) を定義し、タスク間の依存関係・スケジュール・リトライ・アラートを宣言的に管理できます。しかし、Airflow を自前で運用するには、Web サーバー・スケジューラー・ワーカー・メタデータ DB (PostgreSQL) の構築と運用が必要で、バージョンアップやスケーリングの負荷が大きい課題がありました。Amazon MWAA (Managed Workflows for Apache Airflow) は 2020 年にリリースされたフルマネージドの Airflow サービスで、環境の構築・パッチ適用・スケーリング・可用性確保を AWS が管理します。ユーザーは S3 バケットに DAG ファイルと requirements.txt をアップロードするだけで、Airflow 環境が自動的に構成されます。MWAA は Python コードで DAG を定義するため、Git によるバージョン管理、コードレビュー、ユニットテストとの親和性が高く、ソフトウェアエンジニアリングのプラクティスをデータパイプラインに適用できます。なお MWAA には、Airflow 環境を常時稼働させる環境ベースのデプロイと、ワークフローの実行時間だけを課金する MWAA Serverless の 2 つのデプロイオプションがあります (2026 年 8 月時点)。

環境構築と DAG のデプロイ

MWAA 環境の作成には、DAG を格納する S3 バケット、VPC (2 つ以上のプライベートサブネット)、実行ロール (IAM) が必要です。環境ベースのデプロイで選べる環境クラスは mw1.micro ・ mw1.small ・ mw1.medium ・ mw1.large ・ mw1.xlarge ・ mw1.2xlarge の 6 段階で、同時実行可能なタスク数とスケジューラーの性能が異なります。単価は 2026 年 8 月時点でバージニア北部リージョンと東京リージョンが同額で、最小構成の mw1.micro が 0.29 USD/時、小〜中規模の検証環境に使う mw1.small が 0.49 USD/時、本番ワークロード向けの mw1.large が 0.99 USD/時です。

# DAG の例: Glue ジョブ → Athena クエリ → SNS 通知
from airflow import DAG
from airflow.providers.amazon.aws.operators.glue import GlueJobOperator
from airflow.providers.amazon.aws.operators.athena import AthenaOperator
from airflow.providers.amazon.aws.operators.sns import SnsPublishOperator
from datetime import datetime

with DAG('daily_etl', start_date=datetime(2026, 1, 1), schedule='@daily') as dag:
 extract = GlueJobOperator(task_id='run_glue', job_name='raw-to-clean')
 query = AthenaOperator(task_id='run_query', query='SELECT count(*) FROM clean.events',
 database='clean', output_location='s3://results/')
 notify = SnsPublishOperator(task_id='notify', target_arn='arn:aws:sns:ap-northeast-1:123:alerts',
 message='ETL completed')
 extract >> query >> notify

DAG ファイルを S3 にアップロードすると、MWAA が自動的に検出してスケジューラーに登録します。Python の追加パッケージは requirements.txt で指定し、プラグインは plugins.zip として S3 に配置します。 Airflow のバージョンは環境の作成時に指定し、指定しなかった場合は MWAA がサポートする最新バージョンで作成されます。2026 年 8 月時点の公式ドキュメントに掲載されているのは、3 系の v3.2.1 ・ v3.0.6 と、2 系の v2.11.2 ・ v2.11.0 ・ v2.10.3 ・ v2.10.1 ・ v2.9.2 ・ v2.8.1 ・ v2.7.2 で、最新は v3.2.1 (Python 3.12) です。既存の DAG を持ち込む場合は、2 系と 3 系で Operator の提供パッケージやスケジュール指定の書き方が変わるため、移行元の資産に合わせてバージョンを選びます。新規構築なら 3 系を選ぶのが素直です。v2.7.2 以降は requirements.txt に --constraint の記述が必要で、書かなかった場合は MWAA が互換性のある制約ファイルを自動的に適用します。バージョンアップはマイナーバージョン単位で実施でき、古いバージョンは順次サポートが終了するため、選定時点でサポート期間も確認しておくと後の移行計画が立てやすくなります。

デプロイ形態 - 環境ベースと MWAA Serverless

MWAA のデプロイ形態は 2 系統あります (2026 年 8 月時点)。1 つは前述の環境ベースで、mw1.micro から mw1.2xlarge までの環境クラスを指定して Airflow 環境 (Web サーバー・スケジューラー・ワーカー・メタデータ DB) を常時稼働させ、ワーカーだけを需要に応じて自動増減させる形態です。Airflow の Web UI をそのまま使えて、既存の Python DAG やカスタムプラグインを持ち込めるため、セルフホスト環境からの移行先として素直な選択肢になります。 もう 1 つが MWAA Serverless です。常時稼働の環境を持たず、ワークフローの実行に要した時間だけが課金対象になるため、アイドル時間に対するコストが発生しません。ワークフローごとに専用の実行ロールとワーカーが割り当てられるので、権限を細かく分離でき、分離のために環境を複数用意する必要がありません。ワークフローは YAML の定義ファイルで記述し、組み込みのバージョニング機能で過去の定義へ戻せます。タスクは指定した VPC 内で実行することもできます。ただし Apache Airflow v3 ・ Python 3.12 に固定されるため、2 系に依存した DAG はそのままでは載せられません。対応リージョンは環境ベースと同じとは限らないので、公式ドキュメントのリージョン一覧で確認してから選定します。 判断の目安は、実行が断続的で待機時間が長いワークフロー、あるいはワークフロー単位で権限を分けたい場合は Serverless、Airflow の Web UI や既存プラグインへの依存が強く、DAG が常時走り続ける規模であれば環境ベースです。

AWS サービスとの連携と運用

MWAA は apache-airflow-providers-amazon パッケージを通じて、 AWS サービスとの豊富な連携 Operator を提供します。 Glue (ETL ジョブ実行)、 Athena (SQL クエリ)、 EMR (Spark ジョブ)、 Redshift (データウェアハウスクエリ)、 Lambda (関数呼び出し)、 ECS (コンテナタスク実行)、 SageMaker (ML トレーニング/推論)、 Step Functions (ステートマシン実行) など、データパイプラインで必要なサービスをほぼ網羅しています。ワーカーの Auto Scaling により、タスクキューの深さに応じてワーカー数が自動的に増減します。最小ワーカー数と最大ワーカー数を設定でき、ピーク時のみスケールアウトしてコストを最適化できます。モニタリングは CloudWatch メトリクス (DAG 処理時間、タスク成功/失敗数、キュー深さ) と Airflow の Web UI の両方で行えます。 Web サーバーはパブリックアクセス (IAM 認証付き) またはプライベートアクセス (VPC 内のみ) を選択できます。

Step Functions との使い分け

MWAA と Step Functions はどちらもワークフローオーケストレーションサービスですが、設計思想と得意領域が異なります。Step Functions はイベント駆動型で、API Gateway や EventBridge からのトリガーに対して低レイテンシ (ミリ秒単位) で応答します。状態遷移を JSON (ASL) で定義し、Lambda ・ ECS ・ Bedrock などを組み合わせたサーバーレスワークフローに最適です。料金は状態遷移あたりの課金 (Standard: 0.025 USD/1,000 遷移) で、短時間・高頻度のワークフローに向いています (2026 年 8 月時点・バージニア北部リージョン)。一方、MWAA はスケジュール駆動型のバッチパイプラインに強みがあります。複雑な依存関係 (数十〜数百タスクの DAG)、リトライポリシー、SLA 監視、バックフィル (過去日付の再実行) など、データエンジニアリング固有の要件に対応します。既存の Airflow 資産 (DAG、プラグイン、カスタム Operator) をそのまま移行できる点も大きな利点です。判断基準として、リアルタイム処理や API 連携なら Step Functions、日次/時次のデータバッチ処理なら MWAA を選択するのが適切です。

MWAA の料金

環境ベースのデプロイでは、環境クラスの時間課金に、追加のワーカー・スケジューラー・Web サーバーの時間課金と、メタデータ DB のストレージ料金が加わります。以下は 2026 年 8 月時点の単価で、バージニア北部リージョンと東京リージョンは同額です。環境クラスは mw1.micro が 0.29 USD/時、mw1.small が 0.49 USD/時、mw1.medium が 0.74 USD/時、mw1.large が 0.99 USD/時、mw1.xlarge が 1.98 USD/時、mw1.2xlarge が 3.96 USD/時です。追加ワーカーは small で 0.055 USD/時、medium で 0.11 USD/時、large で 0.22 USD/時、メタデータ DB の標準ストレージは 0.10 USD/GB-月です。 環境ベースは環境を起動している間は課金が続くため、1 か月を 730 時間として計算すると、最小構成の mw1.micro を 1 環境だけ動かした場合の環境クラス分は約 212 USD/月、mw1.small なら約 358 USD/月になります (追加ワーカーやストレージは別途)。検証環境を夜間・週末に停止できるなら、この額は稼働時間に比例して下がります。 MWAA Serverless はワークフローの実行時間だけが課金対象で、AWS マネージドタスクの単価はバージニア北部で 0.08 USD/時、東京で 0.104 USD/時 (同じく 2026 年 8 月時点) です。常時稼働分がないため、日に数回しか走らないパイプラインでは環境ベースより大幅に安く収まります。逆に多数の DAG を絶えず走らせる構成では、常時稼働を前提とした環境ベースの方が 1 実行あたりのコストは下がります。 セルフホストの Airflow (EC2 + RDS + Redis) と比較する場合は、インスタンス料金の差だけでなく、パッチ適用・スケーリング・監視といった運用工数を含めた TCO で評価します。DAG の実行頻度が低く依存関係も単純であれば、状態遷移課金の Step Functions がさらに安く済むこともあります。

まとめ - MWAA の活用指針

Amazon MWAA は、Apache Airflow のマネージドサービスとして、データパイプラインのオーケストレーションを運用負荷なく実現します。Python による DAG 定義はバージョン管理やテストとの親和性が高く、AWS サービスとの豊富な Operator 連携により、ETL ・分析・ ML パイプラインを効率的に構築できます。デプロイ形態は、mw1.micro から mw1.2xlarge までの環境を常時稼働させる環境ベースと、実行時間だけを課金する MWAA Serverless の 2 系統があり、既存 Airflow 資産の持ち込みやすさと高い稼働率を重視するなら前者、実行が断続的でワークフロー単位の権限分離を重視するなら後者が向きます。Step Functions がイベント駆動・サーバーレスのワークフローに適するのに対し、MWAA はスケジュール駆動・複雑な依存関係を持つバッチ処理に最適です。既存の Airflow 環境からの移行先として、またデータエンジニアリングチームの生産性向上ツールとして、MWAA は有力な選択肢です。