2025年12月18日のAmazon ECS/Fargate 新機能：タスク廃止の週次イベントウィンドウ

公式ドキュメント
これまでの課題と解決策
- Before: 待機期間（Wait Period）のみ
- After: イベントウィンドウ（Event Windows）
仕様：優先順位と制約
- 1. 適用される優先順位
- 2. 時間設定の制約
設定手順（CLI ベース）
設定の確認・修正・削除
運用上の注意点
まとめ
余談

公式ドキュメント

ドキュメント（現在は英語のみ）：Prepare for AWS Fargate task retirement on Amazon ECS - Amazon Elastic Container Service
ニュース：Amazon ECS で AWS Fargate でのタスク廃止をスケジュールするための週次イベントウィンドウが定義可能に - AWS

2025年12月18日のニュースです。

これまでの課題と解決策

これまで「いつ行われるかAWS次第（または通知からX日後）」だった Fargate のインフラ更新に伴うタスクの廃止（Retirement）を、ユーザーが指定した曜日・時間帯（イベントウィンドウ）に固定できるようになりました。

本記事では、公式ドキュメントの仕様に基づき、この新機能の仕組み、優先順位、そして具体的な CLI による設定手順を解説します。

AWS Fargate は基盤となるインフラのセキュリティパッチやOS更新のために、定期的にタスクを「リタイア（停止・入れ替え）」させます。

Before: 待機期間（Wait Period）のみ

これまでは fargateTaskRetirementWaitPeriod という設定で、通知が来てから AWS が強制的にタスクを停止するまでの「猶予期間（0日/7日/14日）」を設定できるのみでした。（参考：AWS Fargate タスクのリタイア通知による運用の可視性の向上 | Amazon Web Services ブログ）

この期限が到来すると、AWS はタスクの停止と入れ替えを実行します。この際、ECS サービスのデプロイ設定（minimumHealthyPercent 等）に従って順次入れ替えが行われるため、サービスへの影響は極小化されています。

しかし、「影響が小さい」とはいえ、本番環境で「デプロイ（タスクの再起動）」が走ることは確かです。

もしこのタイミングが、トラフィックのピーク時や重要なバッチ処理の最中と重なってしまった場合、予期せぬパフォーマンス低下やエラーを招く恐れがあります。そのため、「意図しないタイミングでの強制実行」を確実に防ぐには、この猶予期間内にユーザー自身が手動（またはスクリプト）で先行してタスクの入れ替え（デプロイ）を行う必要があり、これが運用の手間となっていました。

After: イベントウィンドウ（Event Windows）

今回のアップデートで、Amazon EC2 イベントウィンドウ の仕組みを Fargate に適用できるようになりました。「毎週日曜日の深夜 2:00〜6:00」のように指定することで、Fargate はその時間枠が来るまでタスクの廃止を待機してくれます。

仕様：優先順位と制約

設定に入る前に、重要なルールを押さえておきましょう。

1. 適用される優先順位

Fargate は、タスクをどのウィンドウに従って廃止するかを以下の順序で判断します。最も具体的な設定が優先されます。

Service レベル: タスクが属する ECS サービスに紐付けられたウィンドウ
Cluster レベル: タスクが属する ECS クラスターに紐付けられたウィンドウ
Account レベル (全タスク): アカウント全体 (aws:ecs:fargateTask) に紐付けられたウィンドウ
該当なし: 従来の fargateTaskRetirementWaitPeriod 設定を使用

この仕組みにより、「開発環境（Cluster）は週末ならいつでもOK」「決済サービス（Service）だけは日曜深夜のみ」といった柔軟な使い分けが可能です。

2. 時間設定の制約

イベントウィンドウを作成する際は、以下の条件を満たす必要があります。

週あたりの合計時間: 最低 4時間
1回あたりの時間枠: 最低 2時間

公式の推奨: 大規模なクラスターの場合、8時間以上の枠を取るか、3日に1回以上の頻度で枠を設けることが推奨されています。枠が狭すぎると、すべてのタスクの入れ替えが終わらない可能性があります（ベストエフォート型）。指定したウィンドウ内でタスクの入れ替えが終わらなかった場合、「イベントウィンドウ外（指定した時間以外のタイミング）」でタスクの廃止・入れ替えが強行されます。「大規模な」の具体的な数値は公開されていませんでした。「イベントウィンドウ外でタスクが廃止されていることに気付いた場合は、期間を延長（8時間以上）するか、頻度を増やす（少なくとも3日に1回）ことを検討してください。」と公式には記載があります。手動でのデプロイの際に 4 時間以上かかるようなサービスは注意した方が良さそうです。

設定手順（CLI ベース）

現在まだマネジメントコンソールに対応していないため、AWS CLI での手順を紹介します。

Step 0: 機能の有効化（初回のみ）

まず、この機能を使用することを宣言します。

aws ecs put-account-setting-default \
    --name fargateEventWindows \
    --value enabled

設定できたことを確認します。

aws ecs list-account-settings --effective-settings --name fargateEventWindows

私の環境では、CloudShell で実施してみました。

Step 1: イベントウィンドウの作成 (EC2 API)

ここで注意が必要なのは、ECS ではなく EC2 の API を使う点と、タイムゾーンの落とし穴です。

AWS のスケジュール設定はすべて UTC (協定世界時) で解釈されます。日本時間 (JST) とは -9時間 の時差があるため、深夜帯を指定する場合は曜日が前日にズレることに注意が必要です。

以下に、実運用でよくある3つのパターンのウィンドウ作成コマンドを用意しました。

① 重要サービス用（日曜の深夜のみ）

「日曜の AM 02:00〜06:00 (JST)」の狭い枠を設定します。

JST: 日曜 02:00 〜 06:00
UTC: 土曜 17:00 〜 21:00 (-9h)

# ウィンドウ作成
export WINDOW_ID_CRITICAL=$(aws ec2 create-instance-event-window \
    --name "JST-Sun-EarlyMorning-Critical" \
    --cron-expression "* 17-21 * * 6" \
    --query 'InstanceEventWindow.InstanceEventWindowId' --output text)

echo "Critical Window ID: $WINDOW_ID_CRITICAL"

② 開発環境用（週末の日中）

開発者が作業しない「土日の AM 09:00〜21:00 (JST)」の広い枠を設定します。

JST: 土・日 09:00 〜 21:00
UTC: 土・日 00:00 〜 12:00 (-9h)

# ウィンドウ作成
export WINDOW_ID_DEV=$(aws ec2 create-instance-event-window \
    --name "JST-Weekend-Daytime-Dev" \
    --cron-expression "* 0-12 * * 0,6" \
    --query 'InstanceEventWindow.InstanceEventWindowId' --output text)

echo "Dev Window ID: $WINDOW_ID_DEV"

③ デフォルト設定用（毎日の早朝）

その他のタスク用として「毎日の AM 03:00〜07:00 (JST)」を設定します。

JST: 毎日 03:00 〜 07:00
UTC: 毎日 18:00 〜 22:00 (JSTの当日朝は、UTCでは前日の夕方になります）

# ウィンドウ作成
export WINDOW_ID_DEFAULT=$(aws ec2 create-instance-event-window \
    --name "JST-Daily-EarlyMorning-Default" \
    --cron-expression "* 18-22 * * *" \
    --query 'InstanceEventWindow.InstanceEventWindowId' --output text)

echo "Default Window ID: $WINDOW_ID_DEFAULT"

私の環境での実行結果です。それぞれの ID が発行されているのがわかります。

作成したウィンドウの確認

ウィンドウの設定を確認してみましょう。

aws ec2 describe-instance-event-windows

大丈夫そうです。

Step 2: ウィンドウを ECS リソースに関連付ける

作成した3つのウィンドウ ID を、用途に合わせて ECS リソースに関連付けます。

パターンA：特定の ECS サービスに適用する場合

「決済サービスは止めたくないので、①の『日曜深夜枠』を適用する」ケースです。

# ターゲットのサービスARNを設定
export TARGET_SERVICE_ARN="arn:aws:ecs:region:account:service/prod-cluster/payment-service"

# 重要サービス用ウィンドウ(ID_CRITICAL)を紐付け
aws ec2 associate-instance-event-window \
    --instance-event-window-id $WINDOW_ID_CRITICAL \
    --association-target "InstanceTags=[{Key=aws:ecs:serviceArn,Value=${TARGET_SERVICE_ARN}}]"

私の環境での実行結果です。
"State": "associating" (=適用中) となっているので結果はまた後で確認することにしましょう。

パターンB：特定の ECS クラスター全体に適用する場合

「開発環境のクラスターは、②の『週末日中枠』でまとめてメンテする」ケースです。

# ターゲットのクラスターARNを設定
export TARGET_CLUSTER_ARN="arn:aws:ecs:region:account:cluster/dev-cluster"

# 開発用ウィンドウ(ID_DEV)を紐付け
aws ec2 associate-instance-event-window \
    --instance-event-window-id $WINDOW_ID_DEV \
    --association-target "InstanceTags=[{Key=aws:ecs:clusterArn,Value=${TARGET_CLUSTER_ARN}}]"

パターンC：アカウント内の全 Fargate タスクに適用する場合

「特に指定がないタスクは、③の『毎日早朝枠』で随時メンテする」ケースです。これがアカウント全体のデフォルト設定となります。

# デフォルト用ウィンドウ(ID_DEFAULT)を全タスクに紐付け
aws ec2 associate-instance-event-window \
    --instance-event-window-id $WINDOW_ID_DEFAULT \
    --association-target "InstanceTags=[{Key=aws:ecs:fargateTask,Value=true}]"

設定の確認・修正・削除

CLI で設定を行っていると、「紐付けるサービス ARN を間違えた」「テストで作ったウィンドウを消したい」といった場面に遭遇します。 EC2 イベントウィンドウの API には、関連付けを直接「上書き（Update）」するコマンドがないため、「確認 → 解除 → 再登録」 という手順を踏む必要があります。

よく使う運用コマンドをまとめました。

1. 現在の設定を確認する

ウィンドウの設定を確認してみましょう。

aws ec2 describe-instance-event-windows

登録された ECS サービスが出ています。
ARN が誤っていても登録できています。EC2 API側ではECSリソースの存在確認（バリデーション）を行わないため、誤字があってもエラーにならず登録されてしまう点に注意が必要です。

標準の describe コマンドは出力が長いため、--query オプションを使って「どのウィンドウに、どのリソースが紐付いているか」を抽出すると関連付けがわかるので便利です。

# ID指定で確認する場合（全件出す場合は --instance-event-window-id を省略）
aws ec2 describe-instance-event-windows \
    --instance-event-window-id $WINDOW_ID \
    --query "InstanceEventWindows[].{Name:Name, ID:InstanceEventWindowId, Targets:AssociationTarget.Tags}"

私の環境での実行例です。
Targets が [] (空配列) の場合、そのウィンドウはどの ECS リソースにも適用されていません。

Targets ありの場合です。

--instance-event-window-id $WINDOW_ID を付与しない場合は全てのウィンドウが出力されます。

aws ec2 describe-instance-event-windows \
    --query "InstanceEventWindows[].{Name:Name, ID:InstanceEventWindowId, Targets:AssociationTarget.Tags}"

2. 間違った紐付けを解除する

もし「開発用ウィンドウに、本番サービスの ARN を登録してしまった」といった場合は、disassociate コマンドで解除します。解除する際も、登録時と同じように Key と Value を正確に指定 する必要があります。

# 解除したい設定
export WINDOW_ID="iew-xxxxx"
export WRONG_SERVICE_ARN="arn:aws:ecs:..."

# 紐付けの解除
aws ec2 disassociate-instance-event-window \
    --instance-event-window-id $WINDOW_ID \
    --association-target "InstanceTags=[{Key=aws:ecs:serviceArn,Value=${WRONG_SERVICE_ARN}}]"

私の環境での実行結果です。

"State": "disassociating" (=適用解除中)となったので、この後に先ほどの確認コマンドを実行し、実際に消えたことを確認しました。
※ 修正したい場合は、この後に正しい ARN で associate コマンドを実行してください。

3. イベントウィンドウ自体を削除する

不要になったイベントウィンドウは delete コマンドで削除します。

aws ec2 delete-instance-event-window \
    --instance-event-window-id $WINDOW_ID

ターゲットがある場合は消せないので、先にターゲットとの紐付けを解除してください。

運用上の注意点

3日間の猶予期間 イベントウィンドウを使用する場合、Fargate はタスクが起動してから最低3日間は（緊急のハードウェア劣化などを除き）リタイアさせません。3日経過後の、最初に来るイベントウィンドウでリタイアがスケジュールされます。
ベストエフォート 指定したウィンドウ内でタスクの入れ替えが完了するように AWS は努力しますが、タスク数が非常に多い場合やウィンドウが短すぎる場合、ウィンドウ外にはみ出す可能性があります。ログで「ウィンドウ外でのリタイア」が観測された場合は、ウィンドウ時間を拡張してください。
通知との連携 タスクのリタイア予定は引き続き AWS Health Dashboard に通知されます。EventBridge と連携して Slack 通知などを構築している場合、そのフローは維持されます。

まとめ

Fargate は「サーバーレス」ですが、その裏側の更新タイミングを制御できるようになったことで、エンタープライズ環境での使い勝手が格段に向上しました。実際にメンテナンスが行われるところは未確認です。何か変わった挙動があれば追記しますが、ドキュメント通りに一通り設定できました。
マネジメントコンソールにも対応してほしいですね。

余談

正月早々、近所の山に登ってきました。今年は初日の出も見れたので良いことありそうです。