AWSサービスクォータの設計と管理入門｜上限エラーを本番前に防ぐリミット監視・引き上げ申請・マルチアカウント設計の実践ガイド

オンプレ環境で長年サーバーを管理してきたエンジニアにとって、「リソースが足りない」は物理的な制約の話だった。CPUが詰まればサーバーを増設し、ストレージが溢れれば増量すればいい。しかしAWSに移行すると、まったく別の種類の「壁」にぶつかることがある。それがサービスクォータ（利用上限）だ。

EC2を大量に起動しようとしたら「vCPU数の上限に達しました」と弾かれた。Lambda関数が同時実行数の上限を超えてリクエストが絞られた。VPCを6つ作ろうとしたら「5つまで」とはじかれた——こういったトラブルは、本番稼働後のスケールアウト時や、大型リリース当日に突如現れることが多い。

この記事では、AWSサービスクォータの基本的な仕組みから、現場で詰まりやすい主要クォータの洗い出し方、CloudWatchを使った使用率監視の設定手順、引き上げ申請の実践的なコツ、そしてマルチアカウント設計による制約突破まで体系的に解説する。

なぜクォータ管理がオンプレ経験者の盲点になるのか

オンプレでは、物理サーバーに搭載されたCPUコア数やメモリ容量が「絶対的な上限」だった。上限は目に見えており、データセンターの棚を見れば何台のサーバーが動いているか一目でわかる。

AWSでは話が変わる。クラウドには無限のリソースが存在するように見えるが、実際にはアカウント単位・リージョン単位でソフトウェア的な上限が設定されている。この上限には2つの理由がある。

一つはセキュリティだ。新規アカウントが誤って数千台のEC2を起動してしまったり、不正アクセスによってリソースが際限なく起動されるリスクを防ぐために、意図的に低い初期値が設定されている。

もう一つはインフラの公平分配だ。AWSの物理インフラは世界中のユーザーで共有されており、特定のアカウントが無制限にリソースを独占しないよう、クォータという仕組みで調整している。

オンプレ経験者がAWSに移行する際、この「ソフト上限」の存在を見落としがちだ。本番稼働前のピーク試験や大規模スケールアウト時に初めて気づくケースが後を絶たない。

AWSサービスクォータの仕組みと種類

調整可能クォータと調整不可クォータ

AWSのクォータは大きく2種類に分かれる。

調整可能クォータは、AWSに申請することで上限を引き上げられるものだ。EC2のvCPU数、Lambdaの同時実行数、VPCの数などが該当する。ほとんどの主要サービスのクォータはこのカテゴリに入っており、ビジネス上の理由を添えて申請すれば、多くの場合は数日以内に対応してもらえる。

調整不可クォータは、AWSのシステム設計上の制約として固定されているものだ。例として、IAMポリシー1つあたりのサイズ上限（6,144文字）や、S3オブジェクト1つあたりの最大サイズ（5 TB）などがある。これらは申請しても変更できないため、設計段階で回避策を組み込む必要がある。

Service Quotasの各クォータ詳細画面では、「調整可能: はい/いいえ」がラベル表示されており、申請できるかどうかをひと目で確認できる。

アカウントレベルとリージョンレベルの違い

クォータの適用範囲にも注意が必要だ。

リージョンレベルのクォータは最も一般的で、東京リージョン（ap-northeast-1）と大阪リージョン（ap-northeast-3）は独立して別々の上限を持つ。東京リージョンでvCPU数の引き上げを申請しても、大阪リージョンには反映されない。マルチリージョン構成を取る場合は、使用するすべてのリージョンで個別に引き上げ申請が必要だ。

アカウントレベルのクォータは、リージョンをまたいで適用される。IAMロールの総数（1,000個）などがその例だ。全リージョンの合計でカウントされるため、グローバル展開時は特に意識したい。

本番で詰まりやすい主要クォータ一覧（2026年7月時点）

現場でトラブルになりやすいクォータを整理した。

特に注意したいのがEC2のvCPU上限だ。新規アカウントでは32 vCPUという非常に低い上限になっている。m5.largeは2 vCPUなので、16台起動した時点で上限に達する計算だ。本番移行前に必ず引き上げておく必要がある。

Lambdaの同時実行数（1,000）も見落としやすい。1,000という数字は一見多く見えるが、リージョン全体の合計だ。ひとつのアカウントで複数のLambda関数を運用していると、想定より早く上限に近づく。

クォータの確認と使用率監視の実践手順

1. Service Quotasダッシュボードで現在値を確認する

AWS Management Consoleで「Service Quotas」と検索してサービスを開く。左メニューの「AWSのサービス」から対象サービス（例: Amazon EC2）を選ぶと、そのサービスが持つクォータ一覧が表示される。

各クォータの「使用率」列を確認すると、現在の利用量とデフォルト上限が並んで表示される。ここで「80%以上」のクォータを見つけたら、早急に引き上げ申請を検討すべきだ。

AWS CLIでも確認できる。

# EC2のクォータ一覧を取得
aws service-quotas list-service-quotas \
  --service-code ec2 \
  --region ap-northeast-1

# 特定クォータの詳細を確認（L-1216C47Aは Running On-Demand Standard Instances vCPU数のコード）
aws service-quotas get-service-quota \
  --service-code ec2 \
  --quota-code L-1216C47A \
  --region ap-northeast-1

2. CloudWatchアラームでクォータ使用率を監視する

クォータ使用率はAmazon CloudWatchと統合されており、使用率がしきい値を超えた際にアラームを発報できる。

設定手順は次のとおりだ。

Service Quotasの対象クォータ画面を開き、「CloudWatchアラームの作成」ボタンをクリックする。するとCloudWatchのコンソールに遷移し、メトリクスとして「AWS/Usage」名前空間が自動的に設定される。しきい値に「80」（80%）を入力し、SNSトピックで通知先を設定すれば完成だ。

CLIを使って設定する場合は次のようになる（例: EC2 vCPU使用率が80%を超えたらアラーム）。

# EC2 On-Demand vCPU 使用率アラームの作成（AWS CLIの例）
aws cloudwatch put-metric-alarm \
  --alarm-name "EC2-vCPU-Quota-Usage-80pct" \
  --alarm-description "EC2 On-Demand vCPU使用率が80%超" \
  --metric-name ResourceCount \
  --namespace AWS/Usage \
  --dimensions Name=Service,Value=EC2 \
               Name=Type,Value=Resource \
               Name=Resource,Value=vCPU \
               Name=Class,Value=Standard/OnDemand \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:quota-alert \
  --region ap-northeast-1

上記ではしきい値に「80」（使用可能上限の80%）を指定しているが、実際の「80%に相当するvCPU数」はクォータ値に応じて計算する必要がある。コンソールから設定する場合は比率で指定できるため、コンソール操作の方が直感的だ。

3. AWS Trusted Advisorで高使用率クォータを洗い出す

AWS Trusted Advisorには「サービスの制限」チェック項目があり、アカウント全体で使用率が高いクォータを自動的に洗い出してくれる。緑（80%未満）・黄色（80%以上）・赤（使用率100%）の3色で状態を示してくれるため、どのクォータをすぐ対応すべきかが一目でわかる。

ただし、Trusted Advisorのサービス制限チェックが詳細に機能するのはBusinessサポートプラン以上だ。Developerプランや無償プランでは表示項目が限定される点に注意が必要だ。

クォータ引き上げ申請の実践ガイド

1. 申請の基本フロー

Service Quotasコンソールから直接申請できるものと、サポートチケット経由になるものの2ルートがある。

Service Quotas経由（推奨）

コンソールの対象クォータ画面で「クォータの増加のリクエスト」ボタンをクリックし、希望する新しい上限値を入力して送信するだけだ。申請のステータスはコンソール上でリアルタイムに確認できる。CLIでは次のように実行する。

# EC2 vCPUクォータの引き上げリクエスト（例: 32→256 vCPU）
aws service-quotas request-service-quota-increase \
  --service-code ec2 \
  --quota-code L-1216C47A \
  --desired-value 256 \
  --region ap-northeast-1

# 申請状況の確認
aws service-quotas list-requested-service-quota-changes-by-service \
  --service-code ec2 \
  --region ap-northeast-1

サポートチケット経由（古いクォータの場合）

一部の古いクォータはService Quotasに移行されておらず、AWSサポートセンターからチケットを起票する必要がある。Support Center → サポートケース作成 → 「サービス制限の引き上げ」カテゴリを選ぶ。

2. 通りやすい申請書き方のコツ

クォータ引き上げ申請に「審査」は基本的にないため、調整可能なクォータであれば大抵は承認される。ただし一部の大幅増加（例: vCPU 32→10,000）や特殊なクォータは確認が入ることがある。その際に備えて、次の情報を申請コメントに添えておくと対応が早まる。

・利用用途: 「ECサイトの本番環境でピーク時に300台のEC2インスタンスを起動するため」など具体的に
・希望値の根拠: 「現在の使用量が28 vCPU（上限の87%）であり、3か月以内に150 vCPUが必要な見込み」
・希望日時: 「2026年8月15日のサービスリリース前に必要」

大きな数値を一度にリクエストするより、段階的に引き上げる方がスムーズに通ることも多い。32→256→1,024という段階的申請も有効だ。

3. 引き上げに時間がかかるケースとその対処

Lambdaの同時実行数やEC2のvCPU数など主要クォータは、申請後数時間～数日で反映されることが多い。ただし次のケースでは時間がかかることがある。

・大幅増加の申請: AWSの担当者が内部確認を行うため数営業日かかることがある
・本番リリース前の一斉申請: 混雑期は処理が遅れやすい
・サポートプランが低い場合: 対応優先度に影響することがある

本番移行日の最低でも2週間前には申請を済ませておくのが実務的な安全マージンだ。申請状況を毎日確認し、通らない場合はチケットをフォローアップすることを忘れずに。

マルチアカウント設計でクォータ制約を乗り越える

AWSのクォータはアカウント単位で設定される。これは逆に言うと、アカウントを分けることでクォータ枠を増やせるということだ。

AWS Organizationsを使ったマルチアカウント構成では、開発・検証・本番のワークロードを別アカウントに分けるだけで、それぞれが独立したクォータ枠を持つ。

例えば、Lambdaの同時実行数がリージョンあたり1,000の制限がある場合、開発・本番を同一アカウントで運用していると互いにクォータを食い合う。これを別アカウントに分離することで、本番アカウントのLambdaに1,000の枠を丸ごと確保できる。

さらに、AWS IAM Identity Centerを活用してシングルサインオン（SSO）を設定すれば、複数アカウントの管理コストを抑えながらアカウント分散のメリットを享受できる。

また、Amazon EC2 Auto Scalingを組み合わせる際は、スケールアウト先のvCPU上限をAutoScalingの最大容量より大きく設定しておかないと、スケールアウトが途中で止まる事態になる。AutoScalingの設計時には必ずEC2クォータとの整合性確認が必要だ。

クォータ設計のベストプラクティス

現場での経験から整理したベストプラクティスを示す。

1. プロジェクト開始時に「クォータ確認チェックリスト」を実施する
本番移行の計画フェーズで、使用予定のAWSサービスのデフォルトクォータを一通り確認し、想定ピーク使用量と照らし合わせる。80%を超える見込みのクォータは申請リストに追加する。

2. 引き上げ済みクォータはIaC（Terraform/CloudFormation）でドキュメント化する
どのクォータをいつ何故引き上げたかを記録しておく。アカウントを移行した際や新しいチームメンバーが参加した際、背景がわかっていると設計判断の根拠が引き継げる。

3. CloudWatchアラームを「75%でWARN、90%でCRIT」の2段階で設定する
75%でWarningアラームが発報されれば、引き上げ申請の準備を始める余裕が生まれる。90%のCriticalになってから慌てても、申請が通る前に上限に達する可能性がある。

4. 定期的なクォータ棚卸し（四半期ごと推奨）を習慣化する
ワークロードは時間とともに成長する。3か月前に余裕があったクォータが、新機能追加後に逼迫していることも珍しくない。Trusted Advisorのチェックを定期スケジュールで実行し、アラームの閾値も見直す。

5. 新規サービス導入時は必ずそのサービスのクォータを確認する
新しいAWSサービスを採用する際、そのサービス固有のクォータを把握しておく。例えばAmazon API Gatewayを採用するなら「REST APIの数（600）」や「ステージ数（10 per API）」を把握した上でアーキテクチャを設計する。

6. 調整不可クォータは設計で回避する
IAMポリシーの文字数上限（6,144文字）やS3オブジェクトのマルチパートアップロード最大パーツ数（10,000）など、変更できないクォータは設計段階で工夫が必要だ。IAMポリシーが肥大化しそうな場合はポリシーを複数に分割し、ロールにアタッチするか、インラインポリシーを組み合わせる設計にする。

本記事のまとめ

AWSサービスクォータは、クラウド移行プロジェクトで見落とされがちながら、本番稼働後に深刻なインシデントを引き起こすことがある地雷だ。

重要なポイントをまとめると次のとおりだ。

・クォータは「調整可能」と「調整不可」の2種類があり、ほとんどの主要クォータは申請で引き上げられる
・リージョン単位で独立しているため、マルチリージョン構成では各リージョンで個別に申請が必要
・EC2 vCPU（32）、Lambda同時実行数（1,000）、VPC数（5）が特に詰まりやすい初期上限
・CloudWatchアラームで使用率を常時監視し、75%を超えたら引き上げ申請を準備する
・マルチアカウント設計でアカウントを分けることで、クォータ枠を実質的に増やせる
・本番移行日の2週間前には申請を完了させておくのが安全マージン

「クォータを意識しない設計」は、建物の重量計算をせずに高層ビルを建てるようなものだ。事前の確認と監視の仕組みを整えておくことで、本番稼働後の「なぜスケールアウトできないんだ」という夜中の緊急対応を避けられる。