AWS Service Quotas
AWS サービスの利用上限値を一元管理し、上限引き上げリクエストの送信やアラート設定を行えるサービス
概要
AWS Service Quotas は、AWS の各サービスに設定されたクォータ (利用上限値) を一元的に確認・管理するサービスです。EC2 インスタンス数、Lambda 同時実行数、S3 バケット数など、数百のサービスにわたるクォータ値を単一のコンソールから参照でき、上限引き上げリクエストもワンクリックで送信できます。CloudWatch と統合してクォータ使用率のアラームを設定でき、上限に近づいた際に事前通知を受け取れます。Organizations と連携すれば、組織内の全アカウントのクォータをテンプレートで一括管理し、新規アカウント作成時に自動的に必要なクォータ引き上げを適用できます。Trusted Advisor のクォータチェックよりも詳細な管理が可能です。
クォータの種類と引き上げリクエストの実務
AWS のクォータには、調整可能 (Adjustable) なものと固定 (Non-adjustable) なものの 2 種類があります。調整可能なクォータは Service Quotas コンソールから引き上げリクエストを送信でき、多くの場合 24 - 48 時間以内に承認されます。固定クォータはアーキテクチャ上の制約に基づくもので、引き上げはできません (例: 1 リージョンあたりの VPC 数の絶対上限)。引き上げリクエストの承認は自動化されているものと、AWS サポートチームの手動レビューが必要なものがあります。大幅な引き上げ (例: Lambda 同時実行数を 1000 から 10000 に) は手動レビューとなり、ユースケースの説明が求められる場合があります。実務では、本番環境のローンチ前に必要なクォータを洗い出し、余裕を持って引き上げリクエストを送信する計画が重要です。特にイベント時のトラフィック急増に備え、Auto Scaling の最大値に対応するクォータが確保されているか事前に確認する運用が推奨されます。
CloudWatch アラームによるクォータ監視の設計
Service Quotas は CloudWatch メトリクスとしてクォータの使用率を公開しており、使用率が閾値を超えた際にアラームを発報する設定が可能です。例えば、EC2 の Running On-Demand Instances クォータの使用率が 80% を超えたら SNS で通知し、90% を超えたら PagerDuty にエスカレーションする多段アラームを構築できます。ただし、すべてのサービスが CloudWatch メトリクスに対応しているわけではなく、対応状況は Service Quotas コンソールの「モニタリング」列で確認できます。未対応のサービスについては、Lambda を定期実行して GetServiceQuota API と使用量を比較し、独自のメトリクスを CloudWatch にパブリッシュする補完設計が有効です。Trusted Advisor もクォータチェックを提供しますが、チェック間隔が長く (最短でも数時間)、リアルタイム性に欠けるため、Service Quotas の CloudWatch 統合の方が即時性に優れます。ダッシュボードに主要サービスのクォータ使用率を集約し、運用チームが日常的に確認する体制を整えることが推奨されます。
Organizations テンプレートによるマルチアカウント管理
Service Quotas の Organizations 統合では、クォータリクエストテンプレートを作成し、組織内の新規アカウントに自動的にクォータ引き上げを適用できます。これにより、新しいワークロードアカウントを作成するたびに手動でクォータ引き上げを申請する手間が省けます。テンプレートには、組織の標準的なワークロードに必要なクォータ値を定義します。例えば、Lambda 同時実行数 3000、EC2 On-Demand vCPU 数 200、S3 バケット数 200 などを標準テンプレートとして設定し、全アカウントに一律適用する運用が一般的です。ただし、テンプレートで設定できるのは引き上げリクエストの自動送信であり、承認が保証されるわけではない点に注意が必要です。大幅な引き上げは手動レビューとなる場合があります。実務では、アカウントの用途 (開発用、本番用、データ分析用) に応じて異なるテンプレートを用意し、OU (組織単位) ごとに適用するテンプレートを変える設計が効果的です。コスト管理の観点では、不必要に高いクォータを設定すると意図しないリソース作成を許容してしまうため、適切な上限設定がガバナンスとして機能します。