直近の AWS アップデート解説：Outposts のセルフサービス化、IAM Identity Center のクォータ分離、Batch の戦略拡張、Network Firewall の信頼性向上

はじめに

今回は、直近で発表された 4 件の AWS アップデートを紹介します。AWS Outposts のライフサイクル管理が完全にセルフサービス化され、構成から廃止までをコンソールや API で直接操作可能になりました。IAM Identity Center では AWS アカウントとアプリケーションのクォータが独立し、それぞれ最大 7,000 個まで設定できるようになっています。AWS Batch には顧客定義のインスタンス割り当て戦略が追加され、オンデマンドと Spot でワークロードに応じた優先順位制御が可能になりました。そして AWS Network Firewall のデフォルト設定が変更され、サーバー起点の正当な TCP パケットが誤ってドロップされる問題が解消されています。いずれも大規模運用やマルチアカウント環境、バッチ処理の最適化、ネットワークセキュリティの信頼性向上に関わる重要なアップデートです。

注目アップデート深掘り

AWS Outposts のセルフサービスライフサイクル管理

AWS Outposts のライフサイクル管理がセルフサービス化された背景には、企業のハイブリッドクラウド戦略が成熟し、オンプレミス環境の拡張や縮小を迅速かつ柔軟に行いたいというニーズの高まりがあります。従来は構成の見積もりや注文、サブスクリプション管理、契約更新、廃止といった操作を AWS チームに依頼する必要があり、プロセスの待ち時間やコミュニケーションコストが発生していました。

今回のアップデートにより、AWS Management Console、CLI、API から直接これらすべての操作を実行できるようになりました。特に注目すべきは、新しい構成・見積もりツールです。このツールはリアルタイムで費用を算出し、異なる支払いオプション（前払い、部分前払い、月次支払いなど）と契約期間（1年、3年など）を組み合わせた複数のシナリオを数秒で比較できます。見積もりは即座にオーダーに変換可能で、新規デプロイと既存 Outposts への容量追加の両方に対応しています。

さらに、注文前にアカウントと地域の制約を事前にチェックし、問題があれば通知してくれるため、後からデプロイがブロックされるリスクを減らせます。サブスクリプション情報（契約期間や請求情報）もコンソールとプログラムで確認できるようになり、AWS への問い合わせが不要になりました。契約期間終了時には、セルフサービスワークフローで新規期間への更新または廃止を選択でき、ガイド付きワークフローがリソースのクリーンアップまで処理してくれます。

従来との比較

特に複数リージョンに Outposts を展開する大規模な組織では、このセルフサービス化により調達リードタイムが大幅に短縮され、ビジネスの変化に迅速に対応できるようになります。CLI や API を活用すれば、インフラ管理の自動化やコスト最適化のシミュレーションも容易になるでしょう。

IAM Identity Center のクォータ独立化がもたらす柔軟性

AWS IAM Identity Center（旧 AWS SSO）は、AWS アカウントと SaaS アプリケーションへのシングルサインオンを一元管理するサービスです。これまで AWS アカウントとアプリケーションは同じクォータを共有していたため、アカウント数を増やすとアプリケーション登録に使える容量が減り、逆もまた然りでした。大規模なマルチアカウント戦略を取る組織では、この制約が IdP 統合アプリの拡張を妨げる要因になっていました。

今回のアップデートにより、AWS アカウント用とアプリケーション用のクォータが独立し、それぞれ最大 7,000 個まで設定できるようになりました。つまり、AWS アカウントを 7,000 個登録していても、アプリケーションも別途 7,000 個まで登録できます。片方の容量を使い切ってももう片方には影響しないため、容量計画が格段にシンプルになります。

さらに、AWS Service Quotas コンソールからクォータの増加をリクエストできるようになったため、7,000 個を超える規模でも対応可能です。既存で高いクォータを持つ顧客には、自動的に同じ制限が両方に適用されるため、追加の対応は不要です。

実用性の検証

AWS Management Console の IAM Identity Center セクションで、クォータ管理画面を確認すると、以下のように独立した表示が確認できます（告知に基づく概念的な構成）：

• AWS accounts: 7,000（または増加リクエスト後の値）
• Applications: 7,000（または増加リクエスト後の値）

Service Quotas コンソールでクォータ増加リクエストを行う手順は次の通りです：

1. AWS Management Console で Service Quotas を開く
2. サービス一覧から「AWS IAM Identity Center」を選択
3. 対象のクォータ（AWS accounts または Applications）を選択
4. 「Request quota increase」をクリックし、必要な値を入力
5. リクエスト理由を記載して送信

申請から承認までの時間は通常数営業日程度ですが、組織の利用状況や AWS サポートプランにより異なります。

従来との比較

エンタープライズ企業が数千の AWS アカウントを管理しながら、Slack、Salesforce、GitHub などの SaaS アプリケーションを統合管理する場合、この独立化により拡張性のボトルネックが解消されます。クラウド移行の初期段階で数百～数千のアカウント登録と SSO アプリ統合を同時並行で進める際にも、容量を気にせず計画を進められるでしょう。

SRE 視点での活用ポイント

Outposts のセルフサービス化と運用自動化

SRE の観点では、Outposts のセルフサービス化は調達プロセスの自動化と可視性の向上に大きく寄与します。CLI や API を活用すれば、Terraform や CloudFormation などの IaC ツールと統合し、Outposts の構成管理をコード化できます。たとえば、定期的に見積もりを自動生成してコストダッシュボードに反映させたり、契約期間終了が近づいたらアラートを発火させて更新判断を促すといった運用が可能になります。

また、複数リージョンでの Outposts 展開を管理する際、アカウント・地域の制約チェックが事前に実行されるため、デプロイ失敗のリスクを早期に検出できます。Outposts の廃止プロセスもガイド付きワークフローがリソースのクリーンアップを処理してくれるため、手動での削除漏れや依存関係の確認ミスを防げます。

一方で、セルフサービス化により運用チーム内での権限管理と承認フローの整備が重要になります。特に大規模な組織では、誰がどのタイミングで Outposts を注文・廃止できるのかを明確にし、意図しない構成変更や契約終了を防ぐ必要があります。IAM ポリシーで適切な権限を設定し、AWS CloudTrail でオペレーションをログ監視することが推奨されます。

IAM Identity Center のクォータ独立化と大規模IdP統合

IAM Identity Center のクォータが独立したことで、大規模なマルチアカウント環境でも IdP 統合アプリの拡張がしやすくなります。SRE チームが Terraform で IAM Identity Center を管理している場合、アカウントとアプリケーションのクォータを独立して計画できるため、リソース管理のコード化がシンプルになります。

たとえば、新しい事業部門が立ち上がり AWS アカウントが急増した場合でも、既存の SaaS アプリケーション連携に影響を与えずにアカウントを追加できます。逆に、新しい SaaS ツールを導入する際も、アカウント数の制約を気にせずにアプリケーションを追加できます。

Service Quotas でのクォータ増加リクエストが標準化されたことで、急なスケールアップにも対応しやすくなりました。ただし、クォータ増加リクエストには数営業日かかる場合があるため、計画的な容量管理が依然として重要です。CloudWatch メトリクスやカスタムダッシュボードでアカウント数・アプリケーション数を監視し、クォータの使用率が一定の閾値を超えたら事前にアラートを発火させる仕組みを構築すると、運用の安定性が向上します。

Batch のインスタンス割り当て戦略と HPC ワークロード

AWS Batch に追加された顧客定義のインスタンス割り当て戦略は、バッチワークロードの最適化に新たな選択肢をもたらします。従来の自動選択では、AWS が最適と判断したインスタンスタイプが割り当てられていましたが、ワークロードの特性によっては必ずしも最適ではない場合がありました。

新しい BEST_FIT_PROGRESSIVE_ORDERED 戦略（オンデマンド向け）では、インスタンスタイプの優先順位を手動で指定できます。たとえば、GPU コンピューティングワークロードで特定の GPU 世代を優先したい場合や、メモリ集約型のジョブで特定のメモリサイズを持つインスタンスファミリーを優先したい場合に有効です。SPOT_CAPACITY_OPTIMIZED_PRIORITIZED 戦略は、Amazon EC2 Spot インスタンス向けに設計されており、ワークロード固有の性能特性に基づいてインスタンスタイプの順序を指定しながら優先順位を制御できます。

SRE の観点では、Spot インスタンスの中断リスクを考慮しながらコスト削減を図る際に、SPOT_CAPACITY_OPTIMIZED_PRIORITIZED を活用して安定性の高いインスタンスファミリーを優先リストの上位に配置することで、中断頻度を抑えつつコストメリットを享受できます。AWS Batch API の CreateComputeEnvironment および UpdateComputeEnvironment（または AWS Batch マネジメントコンソール）を通じて設定を行い、Terraform や CloudFormation で管理すれば、環境ごとに異なる戦略を適用し、A/B テストでパフォーマンスとコストを比較することも可能です。

ただし、複雑な優先順位設定を行う場合、ジョブキューの遅延やリソース枯渇のリスクも考慮する必要があります。CloudWatch メトリクスでジョブの待機時間やインスタンスの起動失敗率を監視し、戦略の効果を継続的に評価することが重要です。

Network Firewall のデフォルト設定変更と接続信頼性

AWS Network Firewall のデフォルト設定が「Application drop established (server-directed only)」に変更されたことで、サーバーからクライアントへの正当な TCP パケット（ウィンドウ更新、キープアライブ、リセットなど）が誤ってドロップされる問題が解消されました。これまでのデフォルト設定「Application drop established (bidirectional)」では、こうしたパケットがファイアウォールルールに一致しない場合にドロップされ、間欠的な接続障害が発生していました。

SRE の観点では、長時間接続が必要なアプリケーション（ストリーミング、IoT センサーデータ送信、マイクロサービス間通信など）の信頼性が向上します。特にマイクロサービスアーキテクチャでは、サービス間の通信が頻繁に発生するため、間欠的な接続失敗は障害の原因となりやすく、この変更は大きなメリットです。

既存の Network Firewall ポリシーを運用している場合、設定を見直して新しいデフォルトに合わせることで、接続の安定性を向上させることができます。ただし、PQC（耐量子暗号）対応の TLS ハンドシェイク分割に対応する必要がある場合は、AWS ドキュメントに従って設定を調整する必要があります。

新規に VPC ネットワークを構築する際は、新しいデフォルト設定がベストプラクティスとして適用されるため、追加の設定変更は不要です。CloudWatch Logs や VPC Flow Logs でパケットのドロップ状況を監視し、ファイアウォールルールの調整が必要かどうかを判断することが推奨されます。

全アップデート一覧

まとめ

今回紹介した 4 件のアップデートは、いずれも大規模運用や柔軟なリソース管理、ワークロード最適化、ネットワークセキュリティの信頼性向上に焦点を当てたものです。Outposts のセルフサービス化は、ハイブリッドクラウド戦略を推進する組織にとって調達リードタイムの短縮と運用自動化の可能性を広げます。IAM Identity Center のクォータ独立化は、マルチアカウント環境と SaaS アプリケーション統合を同時に拡張する際のボトルネックを解消します。Batch の新しいインスタンス割り当て戦略は、GPU コンピューティングや HPC ワークロードのパフォーマンスとコストのバランスを細かく制御できるようになりました。Network Firewall のデフォルト設定変更は、長時間接続やマイクロサービス通信の信頼性を高めます。

これらのアップデートを組み合わせることで、エンタープライズ規模のインフラ運用がより柔軟かつ効率的になります。特に SRE チームにとっては、自動化と可視性の向上、コスト最適化、信頼性の改善といった複数の側面でメリットがあるため、積極的に活用を検討する価値があるでしょう。

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

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

• AWS公式ドキュメント