AWS のサービスクォータはなぜ存在するのか - 共有インフラを守るマルチテナント設計
AWS のサービスクォータ (旧サービス制限) が単なる制約ではなく、マルチテナント環境で他の顧客を守るための設計であることを、ノイジーネイバー問題、ソフトリミットとハードリミットの違い、引き上げ申請の裏側から解説します。
サービスクォータの本質 - 他の顧客を守る仕組み
AWS のサービスクォータ (旧称: サービス制限) は、各アカウントが使用できるリソースの上限です。EC2 インスタンスの起動数、Lambda の同時実行数、S3 バケットの数、VPC の数など、ほぼすべてのリソースにクォータが設定されています。これらのクォータは、ユーザーを不便にするために存在するのではありません。AWS のインフラはマルチテナントです。物理的なサーバー、ネットワーク、ストレージを複数の顧客が共有しています。1 つのアカウントが無制限にリソースを消費すると、同じ物理インフラを共有する他の顧客のパフォーマンスが劣化します。これが「ノイジーネイバー問題」です。サービスクォータは、各テナントのリソース消費に上限を設けることで、ノイジーネイバー問題を防止します。コントロールプレーン (API) にもクォータがあります。EC2 の DescribeInstances API は 1 秒あたり 100 リクエストが上限です。1 つのアカウントが API を大量に呼び出すと、コントロールプレーンの処理能力が圧迫され、他のアカウントの API 呼び出しが遅延します。
ソフトリミットとハードリミット
クォータには 2 種類あります。ソフトリミット (調整可能なクォータ) は、Service Quotas コンソールまたは AWS サポートへの申請で引き上げ可能です。EC2 のオンデマンドインスタンスの vCPU 数 (デフォルト: リージョンあたり各インスタンスファミリーで異なる)、Lambda の同時実行数 (デフォルト: 1,000)、S3 バケット数 (デフォルト: 100) などがソフトリミットです。ハードリミット (調整不可能なクォータ) は、サービスの設計上の制約であり、引き上げできません。IAM ポリシーのサイズ上限 (6,144 文字)、CloudFormation のスタックあたりのリソース数 (500)、S3 オブジェクトの最大サイズ (5TB) などがハードリミットです。ハードリミットは、サービスの内部アーキテクチャに起因する制約です。IAM ポリシーのサイズ上限は、ポリシーの評価パフォーマンスを保証するために設定されています。ポリシーが大きすぎると、API 呼び出しのたびに行われるポリシー評価のレイテンシが増加し、すべての API 呼び出しに影響します。
クォータ引き上げ申請の裏側
Service Quotas コンソールから引き上げ申請を送信すると、何が起きるのでしょうか。一部のクォータは自動承認されます。S3 バケット数の引き上げ (100→1,000) などは、申請後数分で自動的に承認されます。これらのクォータは、引き上げても他の顧客への影響が小さいため、自動化されています。一方、EC2 の vCPU クォータの大幅な引き上げ (例: 1,000→10,000) は、AWS のキャパシティチームによる手動レビューが必要です。レビューでは、申請されたリージョンの物理的なキャパシティに余裕があるか、申請者のアカウントの利用実績が申請量に見合っているか、が確認されます。新規アカウントでいきなり大量のリソースを申請すると、不正利用 (暗号通貨マイニングなど) の疑いで却下されることがあります。利用実績を積み上げてから段階的に引き上げるのが確実です。クォータ引き上げの処理時間は、自動承認なら数分、手動レビューなら数時間から数日です。本番環境のローンチ前に余裕を持って申請してください。
デフォルトクォータが低い理由
新規アカウントのデフォルトクォータは意図的に低く設定されています。EC2 のオンデマンド vCPU は、新規アカウントではインスタンスファミリーごとに 5〜32 vCPU 程度です。この低いデフォルト値には 3 つの理由があります。第 1 に、不正利用の防止です。盗まれたクレジットカードで作成されたアカウントが大量の EC2 インスタンスを起動して暗号通貨をマイニングする、という不正利用は AWS にとって深刻な問題です。デフォルトクォータを低くすることで、不正利用の被害を最小限に抑えます。第 2 に、意図しない高額請求の防止です。設定ミスで Auto Scaling が暴走し、数千台のインスタンスが起動してしまうケースがあります。クォータがなければ、数時間で数万ドルの請求が発生します。第 3 に、キャパシティプランニングです。AWS は各リージョンの物理的なキャパシティを管理しています。すべてのアカウントが同時に最大クォータまでリソースを使用しても対応できるよう、キャパシティを計画しています。デフォルトクォータが低ければ、必要なキャパシティの見積もりが容易になります。
クォータの監視と自動化
Service Quotas は CloudWatch と統合されており、クォータの使用率をメトリクスとして取得できます。たとえば、EC2 の vCPU クォータの使用率が 80% を超えたら CloudWatch アラームを発火させ、SNS で通知する設定が可能です。クォータに達してからでは遅いため、事前に監視して余裕を持って引き上げ申請を行うことが重要です。Trusted Advisor もクォータの使用率を監視しています。Business サポート以上のプランでは、Trusted Advisor がクォータの使用率が 80% を超えたサービスを自動的に検出し、ダッシュボードに表示します。AWS Organizations を使用している場合、Service Quotas のクォータリクエストテンプレートを使用して、新規アカウント作成時に自動的にクォータ引き上げを申請できます。組織内のすべてのアカウントに統一されたクォータを適用することで、アカウントごとに手動で申請する手間を省けます。クォータ管理を体系的に学ぶには、専門書籍 (Amazon)が参考になります。