Amazon MWAA Serverlessのセンサーと課金の挙動を検証してみた

こんにちは。サービス開発室の武田です。

2025年11月に Amazon MWAA Serverless （Amazon Managed Workflows for Apache Airflow Serverless）が発表されました。Apache Airflowのワークフローをサーバーレスで実行できるサービスです。インフラ管理が不要で、タスク実行時間に応じた従量課金が魅力です。

このMWAA Serverlessで、SqsSensorを例に挙動を確認する機会がありましたので、検証した結果をまとめます。今回のreschedule modeと課金のしくみについてはセンサー全般に言えるものとなります。

そもそもなぜ検証したのか

MWAA Serverlessの課金モデル

MWAA Serverlessでは、タスク実行時間に対して最低1分の課金が発生します。たとえ数秒で完了するタスクでも1分ぶんの料金がかかります。

Airflowセンサーの2つのモード

Airflowのセンサー（外部条件の成立を待つタスク）には2つの動作モードがあります。

従来のMWAAでは、長時間の待機が必要な場合にreschedule modeが推奨されていました。ワーカースロットを解放することで、他のタスクの実行を妨げないためです。

知りたかったこと

MWAA Serverlessでreschedule modeを使った場合、課金はどうなるのか？

• poke毎にコンテナが新たに起動し、最低1分 × poke回数の課金になるのか
• それとも合計実行時間で課金されるのか

この疑問を解決するため、SqsSensorを使って実環境で検証しました。

検証環境の構成

リソース構成

ワークフロー定義（YAML）

MWAA Serverlessではdag-factoryフォーマットに基づいたYAML形式でワークフローを定義します。

test_poke_30s:
  dag_id: test_poke_30s
  schedule: null
  default_args:
    owner: airflow
    start_date: "2024-01-01"
  tasks:
    wait_for_message:
      operator: airflow.providers.amazon.aws.sensors.sqs.SqsSensor
      task_id: wait_for_message
      sqs_queue: https://sqs.us-east-1.amazonaws.com/123456789012/my-queue
      mode: poke          # または reschedule
      poke_interval: 30
      timeout: 900
      wait_time_seconds: 5
      max_messages: 1
      delete_message_on_reception: true

検証シナリオ

検証してみた

reschedule modeがMWAA Serverlessで動かない

まずこれが一番大きな発見でした。reschedule modeのセンサーは、最初のpokeで条件を満たさないと即座にFAILEDとなります。SqsSensorだけでなくS3KeySensorでも同様だったので、センサー固有ではなくプラットフォームレベルの挙動です。

SqsSensor（reschedule mode × メッセージなし）→ 即FAILED

Status: FAILED
DurationInSeconds: 2
StartedAt: 2026-02-15T08:23:15Z
EndedAt:   2026-02-15T08:23:17Z
AttemptNumber: 1

S3KeySensor（reschedule mode × 存在しないキー）→ 即FAILED

Status: FAILED
DurationInSeconds: 1
StartedAt: 2026-02-15T11:42:08Z
EndedAt:   2026-02-15T11:42:09Z
AttemptNumber: 1

いずれも1〜2秒で失敗しています。最初のpokeで条件を満たさなかった時点で、再スケジュールされずにタスクが失敗しました。

メッセージを事前投入した場合はどうなるか

メッセージを事前にキューへ投入した状態でreschedule modeのSqsSensorを実行してみました。

Status: SUCCESS
DurationInSeconds: 3
StartedAt: 2026-02-15T08:30:42Z
EndedAt:   2026-02-15T08:30:45Z
AttemptNumber: 1

最初のpokeで即座にメッセージを検知し、成功しました。つまり「再スケジュール」が発生しない場合に限りreschedule modeでも動作します。逆に言えば、reschedule modeとして意味のある使い方はできません。

なぜ動かないのか

通常のAirflowでは、reschedule modeのセンサーが条件未達の場合、次のように動作します（Airflowソースコードより）。

1. BaseSensorOperator.executeがAirflowRescheduleExceptionを発生させる
2. TaskInstanceの実行ロジックがこの例外をキャッチし、タスクの状態をUP_FOR_RESCHEDULEに変更する
3. スケジューラがUP_FOR_RESCHEDULE状態のタスクを検知し、poke_interval後に再度キューイングする

MWAA Serverlessではこの一連の流れが機能しません。条件未達時、タスクは即座にFAILEDとなります。

この挙動は2026年3月時点で 公式ドキュメントに明記されていない です。YAMLのmodeパラメーター自体は受け付けられるため、設定時はエラーにならず、実行してはじめて失敗に気付きます。注意しましょう。

poke modeの待機時間はすべて課金対象

poke modeは正常に動作します。poke_interval毎にSQSをポーリングし、メッセージが到着するまで待機を続けます。

DurationInSecondsの値は、タスクのStartedAtからEndedAtまでの実際の経過時間と一致しています。

つまり、poke modeではポーリング間のsleep時間も含めた全待機時間が課金対象です。10分待機すれば約10分ぶんの課金が発生します。

「最低1分課金」はタスク単位か合計か？

MWAA Serverlessでは「タスク実行時間に対して最低1分の課金」とされていますが、これがタスクインスタンス毎に1分最低なのか、合計秒数に対して1分最低なのかで、課金額が大きく変わります。

これを判別するため、SqsPublishOperator（SQSへのメッセージ送信）を5つ順次実行するワークフローを作成しました。各タスクは2〜3秒で完了します。

test_multi_publish:
  dag_id: test_multi_publish
  schedule: null
  default_args:
    owner: airflow
    start_date: "2024-01-01"
  tasks:
    publish_1:
      operator: airflow.providers.amazon.aws.operators.sqs.SqsPublishOperator
      task_id: publish_1
      sqs_queue: https://sqs.us-east-1.amazonaws.com/123456789012/my-queue
      message_content: '{"task": "publish_1"}'
    publish_2:
      operator: airflow.providers.amazon.aws.operators.sqs.SqsPublishOperator
      task_id: publish_2
      sqs_queue: https://sqs.us-east-1.amazonaws.com/123456789012/my-queue
      message_content: '{"task": "publish_2"}'
      dependencies:
        - publish_1
    # publish_3〜5 も同様（省略）

実行結果

Cost Explorerで確認してみた

25倍の差があるため、請求額からどちらのモデルかを判別できます。

請求データの結果

実際の請求データを確認しました。

USD 0.08 per Hour for MWAA Serverless AWS Managed task
0.33 Hrs
USD 0.03

0.33 Hrs = 1,188秒です。検証当日に実行した全タスクの課金時間を両モデルで計算するとこうなります。

モデルBの1,187秒（0.33 Hrs）が請求データと一致しました。

課金は 「タスクインスタンス毎に最低1分」 でした。1分未満で完了するタスクも1分ぶん課金されます。multi-publishテストの5タスク（実行時間合計12秒）に対して300秒（5分）ぶんの課金が発生していることが、これを裏付けています。

センサーを使う際に気をつけること

poke modeを使う

reschedule modeは機能しないため、poke modeを使いましょう。modeパラメーターを省略した場合のデフォルトはpoke modeですので、明示的に指定しなくても大丈夫です。

timeoutを適切に設定する

poke modeでは待機時間がそのまま課金に直結します。想定外の長時間待機を防ぐため、timeoutを短めに設定しておきましょう。

wait_for_message:
  operator: airflow.providers.amazon.aws.sensors.sqs.SqsSensor
  task_id: wait_for_message
  sqs_queue: https://sqs.us-east-1.amazonaws.com/123456789012/my-queue
  mode: poke
  poke_interval: 30
  timeout: 300        # 5分でタイムアウト
  soft_fail: true     # タイムアウト時にFAILEDではなくSKIPPEDにする

長時間待機が必要な場合はセンサー以外の手段を検討する

数十分〜数時間の待機が必要な場合、poke modeのセンサーだとコストがかさみます。センサーで待機する代わりに、メッセージ到着をトリガーにワークフローを起動する構成が有効です。

MWAA Serverlessでは、スケジュール実行（EventBridge Scheduler）とオンデマンド実行（StartWorkflowRun API）がサポートされています。「SQSにメッセージが来たら処理を開始する」ケースでは、SQSメッセージをトリガーにLambdaからStartWorkflowRun APIを呼び出す構成にすれば、待機中の課金を回避できます。

検証結果まとめ

まとめ

MWAA Serverlessは、DAGのYAML定義やタスク単位の従量課金など、従来のMWAAとは大きく異なるアーキテクチャです。従来のスケジューラに依存していた機能（今回のreschedule modeなど）は動作しないケースがあります。

今回の検証でわかったポイントは2つです。

1つ目は、reschedule modeが設定エラーにならず受け付けられるのに、実行時に失敗するということ。既存のDAGをMWAA Serverlessに移行する際は、センサーのmodeパラメーターを思い出してあげてください。

2つ目は、課金がタスクインスタンス毎に最低1分ということ。短時間タスクを多数実行するワークフロー設計はコスト増に直結します。タスクの粒度設計が従来のMWAA以上に大切です。

2026年3月時点では poke mode一択 です。

参考リンク

• Amazon MWAA Serverless ユーザーガイド
• MWAA Serverless サポートオペレータ一覧
• MWAA Serverless ワークフロー定義
• Introducing Amazon MWAA Serverless（AWS Blog）