【ECS爆速ロールバック】配置サーキットブレーカーが神アプデ！しきい値・カウント方式を自由自在に操れ

Amazon ECSのサービス配置において、失敗検知と自動ロールバックの挙動を制御する「配置サーキットブレーカー」の設定がカスタマイズ可能になりました。失敗のしきい値を「固定件数（COUNT）」、「一定割合（BOUNDED_PERCENT/UNBOUNDED_PERCENT）」で指定でき、失敗カウントを「連続（リセットあり）」または「累積（リセットなし）」のモデルから選択できるようになり、アプリケーションの起動特性に合わせた柔軟な運用が実現します。

🚀 ECS運用に革命が起きる！「これまでの悩み」を解消

これまでのECSサーキットブレーカーは、しきい値が固定されていたため、「起動に時間がかかるアプリで、正常に動き出す前に誤検知してロールバックしてしまう」といった、環境やアプリの特性に合わせた微調整ができないもどかしさがありました。今回のアップデートで、その悩みは過去のものです。

🛠️ 実装できることのイメージ

• 開発・テスト環境: 失敗を1回も許容しない「COUNT=1」設定で、不具合の即時検知とロールバックを。
• 本番環境: 起動時の多少のゆらぎを許容しつつ、継続的な失敗のみを検知する「連続モデル（resetOnHealthyTask=true）」で、安定したデプロイを。

🇯🇵 日本のエンジニアへの重要情報

最新のリージョン状況を確認したところ、東京リージョン (ap-northeast-1) および 大阪リージョン (ap-northeast-3) で既に提供されており、即座に活用可能です！

💡 実践的なアドバイス

1. コストと権限の注意: 本機能自体に料金はかかりませんが、頻繁なロールバックが発生するとFargate等のタスク起動コストが跳ね上がる可能性があります。また、ロールバック処理自体はAWS側で行われるため、ECSタスクロールに ecs:UpdateService 権限を与える必要はないという点もセキュリティ的に嬉しいポイントです。
2. 監視の強化: サーキットブレーカーが発動した際は、Amazon EventBridgeで SERVICE_DEPLOYMENT_FAILED イベントをキャッチして、即座にSlack等へ通知する仕組みをセットで作っておくのがベストプラクティスです。

✅ 次にやるべきこと

まずは既存のECSサービスの設定を aws ecs update-service コマンドやTerraform、CDKで確認し、アプリの特性に合わせて thresholdConfiguration を書き換えてみましょう！

参考リファレンス: Amazon ECS API Reference - DeploymentCircuitBreaker https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeploymentCircuitBreaker.html