2026年8月 AWS アップデート情報まとめ

はじめに

今回は、直近で発表された12件のAWSアップデートを紹介します。ネットワークセキュリティ、AI/ML、コンタクトセンター、コスト管理など、幅広い領域でサービスが強化されています。特に注目すべきは、AWS Network Firewallのルールヒットカウント機能、Amazon BedrockのOpenAIモデル対応拡張とクロスリージョン推論、EC2 Auto Scalingのバッチ終了機能など、運用効率とコスト最適化に直結するアップデートが複数含まれている点です。また、Amazon Quickの一連のガバナンス機能強化は、エンタープライズ環境での生成AI活用を加速させる重要な布石となっています。

本記事では、これらのアップデートの中から特に運用面でのインパクトが大きいものをピックアップし、技術的な詳細とSRE視点での活用ポイントを深掘りしていきます。

注目アップデート深掘り

AWS Network Firewall - ステートフルルールヒットカウント機能

AWS Network Firewallに、ステートフルルールのヒットカウント機能が追加されました。この機能により、ファイアウォールポリシー内の各ルールがネットワークトラフィックにマッチした回数を可視化できるようになります。

なぜこのアップデートが重要なのか

従来のファイアウォール運用では、「このルールは本当に必要なのか」「廃止されたサービス向けのルールが残っていないか」といった疑問に答えることが困難でした。ルールの有効性を評価するには、ログを手動で分析するか、トラフィックフローを推測するしかなく、大規模な環境ではこの作業自体が大きな負担となっていました。

ヒットカウント機能は、この課題を根本的に解決します。各ルールがどれだけの頻度でトリガーされているかが定量的に把握できるため、データに基づいたファイアウォールポリシーの最適化が可能になります。

メトリクスの確認と活用

メトリクスは最短5分間隔で更新され、カスタムルールグループとマネージドルールグループの両方に対応しています。デフォルトで有効化されているため、既存環境でも即座に活用を開始できます。

CloudWatchメトリクスとして提供されるため、既存の監視基盤に統合することが可能です。例えば、ヒット数がゼロのルールを定期的にレポートするダッシュボードを構築したり、特定のルールのヒット数が急増した際にアラートを発報する仕組みを実装できます。

ファイアウォールポリシーの最適化プロセス

この機能を活用した具体的な最適化プロセスは以下の通りです：

ステップ1：ベースライン測定
まず、1〜2週間程度のヒットカウントデータを収集し、各ルールの使用頻度のベースラインを確立します。この期間は、ビジネスサイクル（週次、月次のトラフィックパターン）を考慮して設定することが重要です。

ステップ2：廃止候補の特定
ヒット数がゼロ、または極端に少ないルールを洗い出します。ただし、災害対策やセキュリティインシデント対応用のルールなど、通常時にはトリガーされないが必要なルールもあるため、ビジネスコンテキストを考慮した判断が必要です。

ステップ3：冗長性の検出
複数のルールが同じトラフィックパターンにマッチしている場合、より広範なルールに統合できる可能性があります。ヒットカウントの相関分析により、こうした冗長性を発見できます。

ステップ4：優先度の見直し
ヒット頻度が高いルールは、パフォーマンス最適化の観点から、ルール評価順序の上位に配置することを検討します。Network Firewallは上から順にルールを評価するため、頻繁にマッチするルールを上位に配置することで、全体の評価時間を削減できます。

コスト面での考慮

この機能自体は AWS Network Firewall の一部として追加料金なしで利用できますが、ログデータの保存とクエリには標準料金が適用されます。大規模環境では、メトリクス保存期間を適切に設定し、不要な長期保存を避けることでコストを抑制できます。

Amazon Bedrock - OpenAIモデルのクロスリージョン推論

Amazon BedrockがOpenAIのGPT-5.6モデル（Sol、Terra、Luna）のサポートを拡張し、さらに重要な機能としてクロスリージョン推論を導入しました。

クロスリージョン推論の2つのモード

クロスリージョン推論には、ユースケースに応じて選択できる2つのモードが用意されています：

グローバルモード
複数のAWSリージョンから自由にルーティングを行い、最高のスループットと最低コストを実現します。需要スパイク時に特定リージョンの容量が逼迫している場合でも、自動的に他リージョンにリクエストを振り分けることで、安定したレスポンスタイムを維持できます。

Geoモード（US Geo対応）
特定の地理的領域内でのみ推論処理を実行します。今回追加されたのは US Geo（US CRIS）のサポートです。データレジデンシー要件がある環境では、このモードを選択することで、要件を満たしながらマルチリージョンの恩恵を受けられます。

APIの統合と使い分け

Bedrock-runtimeエンドポイント上で、以下の3つのAPIが利用可能になります：

• Responses API
• Converse API
• Chat Completions API

告知ではこの3つが bedrock-runtime エンドポイント上で利用可能になるとされています。各 API の使い分けや引数仕様は告知に記載がないため、Bedrock の公式ドキュメントを確認してください。

CloudWatchとCost Explorerによる統合管理

Bedrock のモデル呼び出しログと連携し、CloudWatch メトリクスとして呼び出し回数・トークン数・レイテンシ・スロットル・エラーが記録されます。これにより、既存のAWS監視基盤に統合し、一元的なダッシュボードで管理できます。

利用額は AWS Cost Explorer および AWS Cost and Usage Report に反映され、モデル単位でコストを按分できます。

データレジデンシーとコストのトレードオフ

グローバルモードは最低コストを実現しますが、データが複数リージョン間を移動する可能性があります。一方、Geoモードはデータを特定地域内に留めますが、若干のコスト増加とスループット制限が発生する場合があります。

規制要件がある場合は明確にGeoモードを選択すべきですが、そうでない環境では、まずグローバルモードで運用を開始し、コストとパフォーマンスのベースラインを確立することを推奨します。

EC2 Auto Scaling - バッチインスタンス終了機能

EC2 Auto Scalingに、単一のAPI呼び出しで最大100個のインスタンスをまとめて終了できるバッチ終了機能が追加されました。

従来の課題とその解決

従来のTerminateInstanceInAutoScalingGroup APIは、1回の呼び出しで1つのインスタンスしか終了できませんでした。大規模なAI/MLトレーニングジョブやバッチ処理で数十〜数百のインスタンスを使用する環境では、スケールダウン時に同数のAPI呼び出しが必要となり、以下の問題が発生していました：

• API呼び出し回数の増加によるレート制限リスク
• 終了処理の長時間化による不要なインスタンス稼働時間の発生
• スクリプトの複雑化（リトライロジック、並列処理制御など）

バッチ終了機能により、これらの課題が一挙に解決されます。

ライフサイクルフックとの互換性

重要な点として、バッチ終了でもライフサイクルフックや接続ドレイニングなどの既存のAuto Scaling動作は各インスタンスに対して個別に実行されます。つまり、バッチで指定した100個のインスタンスそれぞれに対して、以下のような処理が並行して実行されます：

• ライフサイクルフックによるカスタムシャットダウン処理
• ロードバランサーからの接続ドレイニング（登録解除遅延期間の適用）
• インスタンスメタデータの更新

実装時の考慮点

バッチ内の全インスタンスは終了前にアトミックに検証されます。これは、バッチに含まれるインスタンスの1つでも終了不可能な状態（例：保護されている、既に終了処理中など）がある場合、バッチ全体がエラーとなることを意味します。

大規模なスケールダウンを実装する際は、事前にインスタンスの状態を確認し、確実に終了可能なインスタンスのみをバッチに含めるロジックを実装することが推奨されます。

API 呼び出し回数の削減

公式告知で示されているのは「最大 100 個のインスタンス ID を TerminateInstanceInAutoScalingGroup API に渡してバッチ終了でき、Auto Scaling グループのスケールダウンに必要な API 呼び出し回数を削減する」という点です。

例えば 500 台を終了する場合、従来は 500 回の API 呼び出しが必要でしたが、100 台ずつのバッチであれば 5 回に集約できます。実際の所要時間はライフサイクルフックの処理内容や接続ドレイニングの設定に依存するため、自環境で計測してください（告知に所要時間の数値は示されていません）。

SRE視点での活用ポイント

セキュリティとコンプライアンスの可視化

AWS Network Firewallのヒットカウント機能は、セキュリティ運用の透明性を大きく向上させます。月次のセキュリティレビューや監査時に、「このルールは過去1ヶ月で何回トリガーされたか」という質問に即座に答えられることは、コンプライアンス対応の観点から非常に重要です。

Terraformでファイアウォールポリシーを管理している環境では、ヒットカウントメトリクスをCI/CDパイプラインに組み込むことで、ルール変更のインパクトを事前評価できます。例えば、新規ルール追加後の最初の1週間でヒット数を監視し、期待通りのトラフィックをキャッチしているかを自動検証するフローを構築できます。

注意点として、ヒット数がゼロのルールを即座に削除すべきではありません。セキュリティインシデント対応用のルールや、季節性のあるトラフィック向けのルールなど、長期的な視点での評価が必要です。

AI/ML基盤のコスト最適化とレジリエンス

Amazon Bedrockのクロスリージョン推論は、生成AIアプリケーションの可用性とコスト効率を同時に改善します。突発的なトラフィック増加時に、特定リージョンの容量不足でリクエストが失敗するリスクを軽減できるため、ユーザー体験の向上に直結します。

CloudWatchアラームと組み合わせて、リージョンごとのレイテンシを監視することで、パフォーマンス劣化を早期に検知できます。また、Cost Explorerの定期的なレビューにより、推論コストの異常な増加を発見し、アプリケーションの使用パターン変化やバグを検知する手段としても活用できます。

データレジデンシー要件がある環境では、Geoモードの選択が必須ですが、その場合でも地理的領域内の複数リージョンを活用することで、単一リージョン構成よりも高い可用性を実現できます。初期構築時から、コンプライアンス要件とアーキテクチャの制約を明確にすることが重要です。

大規模スケーリングの運用改善

EC2 Auto Scalingのバッチ終了機能は、特にイベント駆動型アーキテクチャや機械学習パイプラインで威力を発揮します。Kubernetesクラスタの迅速なスケールダウン、バッチ処理完了後の即座なリソース解放など、従来は複雑なスクリプトが必要だったシナリオがシンプルに実装できます。

障害対応のランブックに組み込む際は、バッチサイズを環境に応じて調整することを推奨します。例えば、ステージング環境では100台の上限をフル活用し、本番環境では安全性を重視して50台ずつなど、段階的な終了を行う戦略も有効です。

コスト最適化の観点では、スケールダウンに要する API 呼び出し回数が減ることで、終了処理の完了までの時間短縮が見込めます。短縮幅は環境によって異なるため、Cost Explorer で実際の削減額を可視化し、チーム内で共有することで、継続的な改善のモチベーションにつながります。

全アップデート一覧

まとめ

今回紹介したアップデートは、AWS環境の運用効率、セキュリティ、コスト最適化に焦点を当てたものが多く見られました。特にAWS Network Firewallのヒットカウント機能や、EC2 Auto Scalingのバッチ終了機能は、データドリブンな運用改善を可能にする重要なアップデートです。

Amazon Bedrockのクロスリージョン推論は、生成AIアプリケーションのスケーラビリティと可用性を大きく向上させる一方で、データレジデンシー要件への対応も同時に実現しています。グローバル展開とデータレジデンシー要件の両立が求められる環境では、Global と Geo の使い分けが設計上の要点になります。

また、Amazon Quickの一連のガバナンス機能強化（Deny by Default、承認ポリシー、DLP統合、リソース制限）は、エンタープライズ環境における生成AI活用の基盤を整えるものです。これらの機能により、セキュリティとイノベーションのバランスを取りながら、組織全体でAI技術を安全に展開できるようになります。

各アップデートの詳細はリリースノートや公式ドキュメントを参照し、自組織の環境に適した実装方法を検討することをお勧めします。

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

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

• AWS公式ドキュメント