2026年5月20日 AWS アップデート情報

はじめに

2026年5月20日に公開されたAWSアップデートは4件です。Amazon Managed Grafanaのデュアルスタック対応、Amazon MWAAのApache Airflow 3.2サポート、Amazon ECSのデプロイメント一時停止・再開機能、そしてAmazon Inspectorの台北リージョン展開と、インフラの基盤機能からワークフロー制御まで幅広い領域がカバーされています。

特に注目すべきは、ECSのデプロイメント制御機能の強化です。従来の自動デプロイメントに加え、人間の判断が必要なポイントで一時停止できるようになったことで、コンプライアンスやガバナンス要件が厳しい環境でのCI/CDパイプライン構築がより柔軟になりました。またMWAAのAirflow 3.2対応により、データパイプラインの精密な制御が可能になった点も見逃せません。

注目アップデート深掘り

Amazon ECS デプロイメントの一時停止・再開機能

機能の背景と重要性

従来のECSデプロイメントでは、一度開始したデプロイメントは自動的に進行するか、失敗時に自動ロールバックするという二択でした。しかし実際の運用現場では、デプロイメントの途中で以下のような判断が必要になることが少なくありません：

• カナリアリリース後の運用チームによる実環境確認
• セキュリティチームによる最終承認
• 統合テストスイートの実行完了待ち
• 外部システムとの同期タイミング調整

今回追加された一時停止・再開機能は、こうした「人間の判断」や「外部プロセスの完了」を待つポイントをデプロイメントフローに組み込むことを可能にします。これにより、自動化と統制のバランスを保ちながら、組織のガバナンス要件を満たすCI/CDパイプラインを構築できるようになりました。

EventBridge連携による自動化パターン

この機能の強力な点は、一時停止時にAmazon EventBridgeイベントが発行される点です。これにより、単なる手動操作だけでなく、外部ワークフローツールやLambda関数と連携した高度な自動化が実現できます。

例えば、以下のようなEventBridgeルールを設定することで、デプロイメントが一時停止されたタイミングで自動的に承認ワークフローを起動できます：

{
  "source": ["aws.ecs"],
  "detail-type": ["ECS Service Deployment State Change"],
  "detail": {
    "deploymentStatus": ["PAUSED"]
  }
}

このイベントをトリガーに、Lambda関数で統合テストを実行したり、Slackに承認依頼を送信したり、外部のチケットシステムと連携したりできます。承認が完了したら、以下のCLIコマンドでデプロイメントを再開します：

$ aws ecs continue-service-deployment \
    --cluster my-cluster \
    --service my-service \
    --deployment-id d-12345abcde

既存デプロイ戦略との組み合わせ

重要なのは、この機能が既存のECSデプロイメント戦略と併用できる点です。例えば、Blue/Greenデプロイメントでトラフィックシフトを段階的に行い、各段階でPAUSEフックを設定することで、以下のような安全なデプロイメントフローを実装できます：

1. 新しいタスクセット（Green）を起動
2. トラフィックの10%をGreenにシフト（自動）
3. 一時停止 → メトリクス確認・運用チーム承認
4. トラフィックの50%をGreenにシフト（承認後再開）
5. 一時停止 → 統合テスト実行
6. トラフィックの100%をGreenにシフト（テスト成功後再開）
7. 旧タスクセット（Blue）を削除

デプロイメントは最大14日間一時停止状態を保持できます。この期間を超えた場合の挙動（自動続行または自動ロールバック）は設定によって選択できます。

Amazon Managed Grafana のデュアルスタック対応

IPv6対応の必要性

グローバルなIPv4アドレスの枯渇が現実問題となる中、多くの組織がIPv6への移行を計画しています。しかし、既存システムとの互換性を保ちながら段階的に移行する必要があるため、IPv4とIPv6の両方を同時にサポートするデュアルスタック構成が現実的なアプローチとなります。

Amazon Managed Grafanaのデュアルスタック対応により、監視インフラをIPv6に対応させながら、まだIPv4のみのデータソースやアプリケーションとも通信できる環境を構築できます。これは特にマルチリージョン展開する組織にとって重要です。異なるリージョンやVPCで重複するプライベートIPv4アドレス空間を使用している場合でも、IPv6を活用することでアドレス管理の複雑さを軽減できます。

適用条件と有効化

この機能はGrafanaバージョン10.4以降を実行しているワークスペースで利用可能です。既存のワークスペースをバージョン10.4以降にアップグレードすることで、デュアルスタック接続を有効化できます。

設定自体はワークスペースのネットワーク設定から行います。重要なのは、デュアルスタックを有効にしても、IPv4のみの環境で継続利用できる点です。つまり、組織のIPv6移行計画に合わせて柔軟に対応できます。

ネットワーク設計への影響

VPC内でGrafanaワークスペースをデュアルスタックで運用する場合、セキュリティグループとネットワークACLの設定にIPv6ルールを追加する必要があります。例えば、特定のIPv6 CIDR範囲からのアクセスのみを許可する場合：

$ aws ec2 authorize-security-group-ingress \
    --group-id sg-xxxxx \
    --ip-permissions IpProtocol=tcp,FromPort=443,ToPort=443,Ipv6Ranges='[{CidrIpv6=2001:db8::/32,Description="Grafana IPv6 access"}]'

データソースとしてVPC内のPrometheusやCloudWatchなどを使用している場合、それらのエンドポイントもIPv6に対応させることで、完全なIPv6環境での監視基盤を構築できます。

SRE視点での活用ポイント

ECS一時停止機能の運用への組み込み

ECSのデプロイメント一時停止機能は、SREチームが品質とスピードのバランスを取るための強力なツールになります。特に、段階的なカナリアリリースやBlue/Greenデプロイメントと組み合わせることで、自動化の利点を保ちながら重要な判断ポイントで人間が介入できる余地を残せます。

実際の運用フローとしては、EventBridgeとLambdaを組み合わせて、一時停止時に自動的にCloudWatchメトリクスを集計し、エラー率やレイテンシーが閾値を超えていないか確認するといった自動判定ロジックを実装できます。問題がなければ自動的に再開し、異常が検出されれば運用チームにSlack通知を送って手動判断を求める、というハイブリッドなアプローチが可能になります。

注意点としては、一時停止の最大期間が14日間であることを考慮し、承認フローが長期化しないようプロセス設計する必要があります。また、一時停止中もタスクは起動したままなので、コスト面での影響も考慮すべきです。

Grafanaデュアルスタック対応の移行計画

既存の監視基盤でManaged Grafanaを使用している場合、IPv6対応は長期的なインフラ戦略の一環として検討する価値があります。特にマルチリージョン構成でVPCピアリングやTransit Gatewayを使用している環境では、IPv4アドレス空間の重複管理が運用負荷になっているケースも少なくありません。

移行アプローチとしては、まずGrafanaワークスペース自体をバージョン10.4以降にアップグレードし、デュアルスタックを有効化した上で、データソース側のIPv6対応を段階的に進めるのが現実的です。この間、IPv4での接続は継続できるため、サービス断を発生させずに移行できます。

ただし、すべてのデータソースやプラグインがIPv6に対応しているわけではないため、事前に互換性を確認する必要があります。また、ネットワークACLやセキュリティグループのルールも両方のプロトコルに対応させる必要があるため、Terraform等のIaCツールでの管理が推奨されます。

全アップデート一覧

まとめ

今回のアップデートは、インフラの基盤技術（IPv6対応）からアプリケーションデプロイメントのガバナンス強化、データパイプラインの高度化まで、幅広い領域をカバーしています。

特にECSのデプロイメント制御機能は、「自動化」と「統制」のバランスを取るという、多くの組織が直面する課題に対する実践的な解決策を提供しています。EventBridge連携により、単なる手動承認だけでなく、既存のワークフローツールやCI/CDパイプラインとシームレスに統合できる点が、エンタープライズ環境での採用を後押しするでしょう。

またManaged GrafanaのIPv6対応は、今後数年で加速するIPv6移行トレンドを見据えた重要なアップデートです。監視インフラという基盤レイヤーでのデュアルスタック対応により、組織全体のIPv6移行計画をスムーズに進められる土台が整いました。

MWAAのAirflow 3.2対応も、アセットパーティショニングによる精密なデータパイプライン制御や、拡張されたHuman-in-the-Loop機能により、複雑化するデータ処理ワークフローの管理を改善する選択肢を提供しています。

📚 AWSをもっと深く学ぶなら

AWS認定ソリューションアーキテクト - アソシエイト 完全攻略（楽天ブックス）

• AWS公式ドキュメント