目次

AWS Service Quotas 完全ガイド v2.0

AWS サービス使用制限の一元管理・自動スケーリング

AWS Service Quotas は、AWS サービスの使用制限（クォータ・リミット）を一元管理・申請・監視するサービス である。EC2 インスタンス上限・Lambda 同時実行数・VPC 数・RDS インスタンス数などのクォータをコンソール / API から確認し、クォータ引き上げリクエストを申請できる。CloudWatch との統合で使用率 80% 超過時に自動アラーム、Terraform / CloudFormation での IaC 管理、Organizations 全アカウントへのクォータテンプレート一括適用も可能。本ドキュメントは Service Quotas の概念・クォータ管理・自動スケーリング・ベストプラクティスを体系的に解説。

ドキュメントの目的

本ガイドは以下を対象としています。

  • DevOps / インフラエンジニア向け：クォータ管理・キャパシティプランニング
  • SRE 向け：CloudWatch アラーム + Lambda による自動クォータ引き上げ
  • Platform Team 向け：Organizations クォータテンプレート・一元管理
  • コスト最適化 Team 向け：リソース使用率と制限の可視化・効率化
  • 意思決定者向け：Azure Resource Manager・GCP Resource Quotas との比較

2025-2026 年の Service Quotas エコシステム

  • 自動スケーリングクォータ：使用率に基づいて自動的にクォータ引き上げ（オプトイン）
  • ML 駆動の推奨：機械学習で必要なクォータを予測、事前申請の提案
  • Resource Tagging 統合：タグベースのクォータ管理・チャージバック
  • Terraform・CDK での完全管理：IaC による宣言的クォータ定義
  • Real-time Quota API：使用率のリアルタイム取得、キャッシング削減

目次

  1. 概要・課題・特徴
  2. Service Quotas が解決する課題
  3. 主な特徴
  4. アーキテクチャ・概念
  5. クォータ体系・主要クォータ一覧
  6. コアコンポーネント詳細
  7. 主要ユースケース（10+）
  8. 設定・操作の具体例
  9. 類似サービス比較表
  10. ベストプラクティス
  11. トラブルシューティング
  12. 2025-2026 最新動向
  13. 学習リソース・参考文献
  14. 実装チェックリスト・導入ロードマップ
  15. まとめ

概要・課題・特徴

本質

AWS Service Quotas は「AWS サービスの使用上限をコンソール・API から一元管理し、制限に達する前に引き上げ申請できるサービス」。

各 AWS サービスは デフォルトクォータ を設定しており（例：EC2 vCPU 上限 32、Lambda 同時実行数 1,000）、制限を超えるとサービスが停止される。Service Quotas を使用することで、以下を実現する。

  • クォータ枯渇の事前防止：CloudWatch で使用率 80% 検知 → 自動アラーム・引き上げ申請
  • IaC・CI/CD への統合：Terraform でインフラコード化、デプロイ前にクォータ充足確認
  • Organizations 全アカウント管理：クォータテンプレートを一括適用、新規アカウント自動セットアップ
  • API ドリブン運用：Lambda で自動判断・クォータ引き上げリクエスト

Service Quotas が解決する課題

課題 Service Quotas の解決策
スケールアウト時のクォータ枯渇 CloudWatch で事前アラーム → 80% 到達時に引き上げ申請
複数サービスのクォータを分散管理 Service Quotas コンソール 1 つで全サービスのクォータ横断確認
新規 AWS アカウントのセットアップ遅延 クォータテンプレート一括適用 → 自動でクォータ引き上げ申請
CI/CD パイプラインの予期しない失敗 デプロイ前にクォータ充足確認 → キャパシティ不足で失敗するまで待たない
リージョン別・アカウント別のクォータ値の不一致 クォータテンプレートで統一値管理
本番環境でのスケーリング限界 月間・年間予測使用量に基づいて事前にクォータ引き上げ

主な特徴

1. クォータの種類

┌──────────────────────┬──────────────────────┬────────────────────┐
│ クォータ種別         │ 説明                 │ 引き上げ可否       │
├──────────────────────┼──────────────────────┼────────────────────┤
│ Adjustable（調整可） │ AWS が引き上げを許可 │ ✅ 引き上げ可能    │
│ Non-adjustable       │ AWS が変更不可に指定 │ ❌ 引き上げ不可    │
│ Account-level        │ アカウント全体に適用 │ 全リージョン共通   │
│ Region-level         │ リージョンごとに適用 │ リージョン単位申請 │
│ Resource-level       │ リソース個別に適用   │ リソース ARN 指定  │
└──────────────────────┴──────────────────────┴────────────────────┘

2. CloudWatch 統合

フロー:
  Service Quotas メトリクス（使用率）
    ↓ CloudWatch に自動公開
  CloudWatch Alarm（80% threshold）
    ↓ トリガー
  SNS / Lambda
    ├─ Slack 通知
    └─ Lambda で自動クォータ引き上げリクエスト

3. IaC・Terraform サポート

Terraform で宣言的にクォータ管理:

resource "aws_servicequotas_service_quota" "lambda_concurrency" {
  service_code = "lambda"
  quota_code   = "L-B99A9384"
  value        = 3000  # 1,000 → 3,000 に引き上げ
}

4. Organizations テンプレート

管理アカウントでクォータテンプレート定義
  ↓
メンバーアカウント作成時に自動適用
  ↓
全アカウント・全リージョンで統一クォータ値

Service Quotas が解決する課題

ビジネス課題

  1. 本番デプロイの突然のキャパシティ上限エラー

    • ローンチ直前に「EC2 vCPU 上限に達した」で止まる
    • 引き上げ申請に数日 → ビジネス損失
    • Service Quotas で事前計画 → 計画通りローンチ

  2. SaaS のユーザー増加への自動スケール対応

    • 顧客が月 50 人 → 200 人に増加
    • Lambda 同時実行数・RDS ストレージが追いつかない
    • Service Quotas + Lambda で自動スケーリング

  3. 複数 AWS アカウント間のクォータ不一致

    • 本番アカウント = Lambda クォータ 3,000
    • 開発アカウント = Lambda クォータ 1,000（テスト失敗）
    • クォータテンプレート一元管理で統一

技術課題

  1. CI/CD パイプラインの予測不可能な失敗

    デプロイ時に Lambda 関数数 100 個追加
→ クォータ 500 に達してエラー
→ Service Quotas API で事前確認 → キャパシティプランニング

  2. マルチリージョン運用のクォータ管理

    東京リージョン（ap-northeast-1）と大阪リージョン（ap-northeast-2）
で異なるクォータ設定 → Service Quotas で統一管理

  3. キャパシティプランニングの属人化

    SRE の頭の中でのみ「月あたり何リソースが必要か」管理
→ Service Quotas API で可視化 → チームで共有可能

主な特徴

Service Quotas アーキテクチャ

graph TB
    SQ["Service Quotas<br/>コンソール / API"]
    
    QA["Quota Analysis<br/>現在の使用率"]
    AR["Adjustment Request<br/>引き上げ申請"]
    CW["CloudWatch<br/>メトリクス"]
    
    Services["AWS Services<br/>EC2, Lambda, RDS, DynamoDB..."]
    
    Template["Quota Template<br/>Organizations"]
    
    SQ --> QA
    SQ --> AR
    QA --> CW
    AR --> Services
    Template --> Services
    
    CW -.-> Alarm["CloudWatch Alarm"]
    Alarm -.-> Lambda["Lambda<br/>自動引き上げ"]
    Lambda -.-> AR

リージョンレベル vs アカウントレベル

┌────────────────────────────┬─────────────┬──────────────────┐
│ クォータ例                 │ レベル      │ 申請方法         │
├────────────────────────────┼─────────────┼──────────────────┤
│ VPC 数                     │ Region      │ リージョンごと   │
│ Lambda 同時実行数          │ Account     │ 全リージョン共通 │
│ EC2 vCPU（オンデマンド）   │ Region      │ リージョンごと   │
│ RDS インスタンス数         │ Account     │ 全リージョン共通 │
│ DynamoDB テーブル数        │ Account     │ 全リージョン共通 │
│ Elastic IP 数              │ Region      │ リージョンごと   │
│ S3 バケット数              │ Account     │ 全リージョン共通 │
│ ELB 数（ALB/NLB）         │ Region      │ リージョンごと   │
└────────────────────────────┴─────────────┴──────────────────┘

アーキテクチャ・概念

クォータリクエストのライフサイクル

Step 1: リクエスト作成
  aws service-quotas request-service-quota-increase \
    --service-code lambda \
    --quota-code L-B99A9384 \
    --desired-value 3000
  
  Status: PENDING (審査中)

Step 2: AWS 審査
  通常 1-3 営業日
  AWS が以下を確認:
    - アカウント実績
    - クレジット履歴
    - 妥当性判定

Step 3: 承認 / 却下
  Status: APPROVED / DENIED / CASE_OPENED
  
  承認時:
    → クォータが即座に反映
    → 変更は CloudTrail に記録
    → CloudWatch メトリクスが更新

Step 4: リクエスト確認
  aws service-quotas list-requested-service-quota-changes

キャッシュ vs リアルタイム取得

CloudWatch メトリクス（遅延 1-2 分）:
  ✓ 使用率トレンド可視化
  ✓ 履歴データ保持
  ❌ リアルタイム判定には不向き

Service Quotas GetQuota API（リアルタイム）:
  ✓ デプロイ時の即時判定
  ✓ 正確な残容量確認
  ❌ API レート制限（最大 40 req/sec）

クォータ体系・主要クォータ一覧

EC2 クォータ

デフォルト値:

Running On-Demand Standard instances
  → vCPU 単位（リージョン別）
  → デフォルト：32 vCPU
  → 例：t3.medium（1 vCPU）100 個 = 100 vCPU 消費

Elastic IP addresses
  → アカウント全体：5 個（リージョンごと）
  → デフォルト：5

VPC
  → リージョンごと：5 個
  → Elastic Network Interfaces：350 個/リージョン

On-Demand Instance Limit by Instance Type
  → c5.large, t3.medium などインスタンスタイプ別
  → 各タイプのデフォルト異なる

Lambda クォータ

Concurrent executions
  → アカウント・リージョン全体：1,000
  → 個別 Lambda 関数：制限なし

Storage
  → /tmp（一時ファイル）：512 MB
  → 全レイヤー合計：250 MB
  → 環境変数：4 KB

Memory and timeout
  → メモリ：128 MB～ 10,240 MB
  → タイムアウト：900 秒（15 分）

RDS クォータ

DB instances
  → アカウント全体：40 個
  → ストレージ：65,536 GB / DB インスタンス

Read Replicas
  → 1 DB インスタンスあたり：15 個
  → クロスリージョン：制限なし（リージョンクォータ適用）

Backup storage
  → 自動バックアップ：DB サイズ分無料
  → 追加 backup storage：アカウント合計 100 TB

DynamoDB クォータ

Table per Account
  → 2,500 個（Account-level）

Throughput（オンデマンドモード）
  → Write Capacity Units：40,000 WCU/秒/テーブル
  → Read Capacity Units：40,000 RCU/秒/テーブル

Item Size
  → 1 アイテム：最大 400 KB
  → パーティションキー：最大 2,048 bytes

VPC 関連クォータ

VPC
  → リージョンごと：5 個

Subnets per VPC
  → 200 個

Security Groups per VPC
  → 500 個

Route Tables per VPC
  → 200 個

NAT Gateways per AZ
  → リージョンあたり：5 個（リージョン制限）

その他主要クォータ

CloudFormation Stacks
  → アカウント全体：10,000 個

IAM Policies per Role
  → 10 個

Elastic Container Registry（ECR）Images per Repository
  → 1,000 個

SNS Topics
  → アカウント全体：100,000 個

SQS Queue
  → アカウント全体：制限なし

コアコンポーネント詳細

1. Service Quotas コンソール

機能:

Quotas ページ
  → サービス別クォータ一覧
  → 現在値・使用率表示
  → Adjustable / Non-adjustable フラグ

Request Quota Increase
  → 「Request quota increase」ボタン
  → 目標値を指定 → AWS に申請
  → ステータス追跡

AWS Default Service Quotas
  → 各サービスのデフォルト値
  → リージョン別に異なる値表示

Service Quota Alarm
  → 使用率 X% で CloudWatch アラーム設定
  → SNS 通知

2. Service Quotas API

主要オペレーション:

ListServices
  → 対応サービス一覧

ListServiceQuotas
  → 特定サービスのクォータ全件取得
  → フィルター：Adjustable のみなど

GetServiceQuota
  → 特定クォータの詳細（現在値・使用率）

RequestServiceQuotaIncrease
  → クォータ引き上げをリクエスト
  → 非同期実行（結果は別途確認）

ListRequestedServiceQuotaChanges
  → リクエスト履歴・ステータス確認

3. CloudWatch メトリクス

メトリクス:

AWS/ServiceQuotas Namespace
  MetricName: ServiceQuota
  Dimensions:
    - ServiceCode: lambda
    - QuotaCode: L-B99A9384
    - QuotaName: Concurrent executions
  Value: 現在使用数（e.g., 850 / 1,000）

HistoricalData
  → 14 日分のデータ保持
  → CloudWatch Logs Insights で分析可能

4. Organizations クォータテンプレート

ロール:

管理アカウントでテンプレート定義
  {
    "service_code": "lambda",
    "quota_code": "L-B99A9384",
    "desired_value": 3000
  }

全メンバーアカウント（新規含）に自動適用
  → 新規アカウント作成時に 3,000 同時実行
  → 既存アカウント：opt-in で適用

主要ユースケース

1. 本番ローンチ前のキャパシティプランニング

シナリオ:
  SaaS 企業がローンチ前にスケーリング計画

Step 1: 予想最大クライアント数を見積
  → 初期：100 クライアント
  → 1 年後：1,000 クライアント
  → 5 年後：10,000 クライアント

Step 2: Service Quotas で必要クォータ計算
  Lambda 同時実行数：
    100 クライアント × 10 req/秒 × 100ms = 100 並行実行
    1 年後：1,000 並行実行

  EC2 vCPU（web tier）：
    web サーバー 1 台：c5.xlarge（4 vCPU）× 100 台 = 400 vCPU
    1 年後：4,000 vCPU に拡張予定

Step 3: ローンチ前に引き上げ申請
  service-quotas request-service-quota-increase \
    --service-code lambda \
    --quota-code L-B99A9384 \
    --desired-value 5000  # 余裕 5 倍を確保

  service-quotas request-service-quota-increase \
    --service-code ec2 \
    --quota-code L-1216C47A \
    --desired-value 5000  # EC2 vCPU

Step 4: 承認待機（通常 3 営業日）
  → 承認後即座に値反映
  → ローンチ日確定

効果: 予期しないスケーリング失敗を防止

2. CI/CD パイプラインへのクォータ検証ステップ

シナリオ:
  CloudFormation で 100 個の Lambda 関数をデプロイ

従来（クォータ検証なし）:
  cfn create-stack → 50 個目の関数でエラー
  → パイプライン失敗 → 原因調査に数時間

クォータ検証導入:
  Pipeline Step 1: Pre-deployment Quota Check
    
    def check_quotas(template):
        qs = boto3.client('service-quotas')
        
        # Lambda クォータ取得
        quota = qs.get_service_quota(
            ServiceCode='lambda',
            QuotaCode='L-B99A9384'
        )
        current_quota = quota['ServiceQuota']['Value']
        
        # テンプレートで定義される関数数カウント
        functions_in_template = count_lambda_functions(template)
        
        # 既存関数数確認
        existing_functions = count_existing_lambdas()
        
        total_required = existing_functions + functions_in_template
        
        if total_required > current_quota:
            print(f"ERROR: Need {total_required}, only {current_quota} available")
            sys.exit(1)
        else:
            print(f"OK: {total_required} <= {current_quota}")
            return True

  Pipeline Step 2: Deploy（クォータ OK なら実行）
    cfn create-stack ...

効果: デプロイ失敗を事前防止

3. Lambda 同時実行数の自動スケーリング

シナリオ:
  トラフィック増加に伴い Lambda 同時実行が増加中

アーキテクチャ:
  
  CloudWatch Alarm（90% threshold）
    ↓ トリガー時
  SNS Topic
    ↓
  Lambda（auto-scale-quotas）
    │
    ├─ Step 1: 現在クォータ確認
    │  quota = qs.get_service_quota(...)
    │  current = 1000
    │
    ├─ Step 2: 引き上げ必要か判定
    │  if current_usage / current > 0.85:
    │      target = current * 2
    │
    ├─ Step 3: 引き上げリクエスト
    │  qs.request_service_quota_increase(
    │      desired_value = 2000
    │  )
    │
    └─ Step 4: Slack 通知
       "Lambda quota increased 1000 → 2000"

CloudWatch メトリクス:
  QuotaUtilization: 95% → 90% → 75% (安定)

効果: 手動介入なく自動スケーリング

4. Organizations による統一クォータ管理

シナリオ:
  5 つの AWS アカウント（Dev・Test・Staging・Prod-JP・Prod-US）
  を統一したクォータで管理

従来（テンプレートなし）:
  Dev: Lambda 1,000
  Test: Lambda 1,000
  Staging: Lambda 5,000
  Prod-JP: Lambda 10,000
  Prod-US: Lambda 10,000
  → バラバラ、管理困難

クォータテンプレート:

Management Account:
  
  Step 1: テンプレート作成
    aws service-quotas put-service-quota-increase-request-into-template \
      --service-code lambda \
      --quota-code L-B99A9384 \
      --desired-value 5000

  Step 2: 全メンバーアカウントに適用
    aws service-quotas associate-service-quota-template

結果:
  全 5 アカウント → Lambda クォータ 5,000 に自動統一
  新規アカウント作成 → 自動的に 5,000 適用

効果: クォータ値を一元管理、アカウント新設時の自動適用

5. マルチリージョン展開時のキャパシティプランニング

シナリオ:
  東京（ap-northeast-1）と大阪（ap-northeast-2）に
  同じ 150 EC2 インスタンスをデプロイ

クォータ確認:
  
  Tokyo: EC2 vCPU On-Demand Standard
    Default: 32
    Required: 150 * 4 (t3.medium) = 600 vCPU
    → 引き上げ申請：600 → 1000

  Osaka: 同じ
    Default: 32
    Required: 150 * 4 = 600 vCPU
    → 引き上げ申請：600 → 1000

Service Quotas API で両リージョンを並列確認:

  def check_multiregion_quotas():
      regions = ['ap-northeast-1', 'ap-northeast-2']
      results = {}
      
      for region in regions:
          qs = boto3.client('service-quotas', region_name=region)
          quota = qs.get_service_quota(
              ServiceCode='ec2',
              QuotaCode='L-1216C47A'
          )
          results[region] = quota['ServiceQuota']
      
      return results

効果: マルチリージョン展開時の一括キャパシティ確認

6. コスト分析とリソース最適化

シナリオ:
  クォータ使用率と実際のコスト相関分析

CloudWatch メトリクス取得:
  EC2 vCPU 使用率: 25% （クォータ 1000 vCPU）
  → 平均 250 vCPU しか使わない

コスト削減検討:
  1. 不要なインスタンス削除
  2. Reserved Instance 検討（使用率 25% なら不要）
  3. Spot Instance ミックス（アーキテクチャ次第）

Service Quotas で引き下げ申請:
  → デフォルト 32 vCPU に戻す
  → コスト最適化

効果: クォータ値からの逆算でコスト最適化

7. 部門別・プロジェクト別クォータ管理

シナリオ:
  マーケティング部と SaaS 部で AWS リソース共有
  部門ごとの予算・キャパシティ配分

タグベースのクォータ割当:

  Tag: team=marketing
    Lambda Concurrent: 500
    RDS Instances: 5

  Tag: team=saas
    Lambda Concurrent: 2,000
    RDS Instances: 20

Resource Tagging:

  def apply_team_quota_checks(team):
      qs = boto3.client('service-quotas')
      
      quota_config = {
          'marketing': {'lambda_concurrent': 500},
          'saas': {'lambda_concurrent': 2000}
      }
      
      target_quota = quota_config[team]['lambda_concurrent']
      
      return target_quota

効果: 部門別にリソースを割当、チャージバック可能

8. RDS 本番環境のストレージ制限

シナリオ:
  RDS MySQL 本番クラスター
  初期 500 GB → 3 ヶ月後 2 TB に増加

CloudWatch で使用率監視:

  Alarm: RDS Storage Utilization > 80%
    → Lambda でストレージ拡張

Automation:

  def expand_rds_storage():
      rds = boto3.client('rds')
      
      # 現在のストレージサイズ取得
      db = rds.describe_db_instances(
          DBInstanceIdentifier='prod-mysql'
      )
      current_size = db['DBInstances'][0]['AllocatedStorage']
      
      # 新サイズ（2 倍）
      new_size = current_size * 2
      
      # Service Quotas で上限確認
      qs = boto3.client('service-quotas')
      quota = qs.get_service_quota(
          ServiceCode='rds',
          QuotaCode='L-...'  # RDS storage
      )
      
      if new_size <= quota['ServiceQuota']['Value']:
          # ストレージ拡張実行
          rds.modify_db_instance(
              DBInstanceIdentifier='prod-mysql',
              AllocatedStorage=new_size,
              ApplyImmediately=False  # メンテナンスウィンドウで実施
          )

効果: ストレージ枯渇前の自動拡張

9. 多言語・多地域 SaaS のクォータ最適化

シナリオ:
  SaaS が 20 か国で運用
  各国で異なるクォータが必要

要件:
  日本：100 Lambda 同時実行
  米国：500 Lambda 同時実行
  EU：300 Lambda 同時実行
  ...

実装:

  quota_map = {
      'jp': {'lambda_concurrent': 100},
      'us': {'lambda_concurrent': 500},
      'eu': {'lambda_concurrent': 300}
  }

  def apply_regional_quota(region_code):
      target_quota = quota_map[region_code]
      qs = boto3.client('service-quotas', region_name=...)
      
      return target_quota

効果: 地域別にリソース配分最適化

10. デプロイ前のフルバリデーション

シナリオ:
  本番環境への大規模デプロイ前に
  複数リソースのクォータを一括検証

Validation Pipeline:

  def pre_deployment_quota_validation(infra_code):
      results = []
      
      # 解析: CloudFormation テンプレートから必要リソース抽出
      resources_required = parse_cfn_template(infra_code)
      
      # 検証: 各クォータに対して
      for resource_type, quantity in resources_required.items():
          qs = boto3.client('service-quotas')
          
          quota = qs.get_service_quota(
              ServiceCode=resource_type,
              QuotaCode='...'
          )
          
          if quantity > quota['ServiceQuota']['Value']:
              results.append({
                  'status': 'FAIL',
                  'resource': resource_type,
                  'required': quantity,
                  'available': quota['ServiceQuota']['Value']
              })
          else:
              results.append({'status': 'OK', 'resource': resource_type})
      
      # レポート
      if any(r['status'] == 'FAIL' for r in results):
          print("❌ Deploy blocked due to quota limits")
          return False
      else:
          print("✅ All quotas validated, proceed with deployment")
          return True

効果: デプロイ失敗の完全防止

設定・操作の具体例

CLI 例

# サービスコード一覧
aws service-quotas list-services \
  --query 'Services[*].[ServiceCode,ServiceName]' \
  --output table

# Lambda クォータ一覧
aws service-quotas list-service-quotas \
  --service-code lambda \
  --query 'Quotas[*].[QuotaName,Value,Adjustable]' \
  --output table

# 特定クォータの詳細（使用率含む）
aws service-quotas get-service-quota \
  --service-code lambda \
  --quota-code L-B99A9384 \
  --query '{QuotaName: ServiceQuota.QuotaName, Value: ServiceQuota.Value, Usage: Usage}'

# クォータ引き上げリクエスト
aws service-quotas request-service-quota-increase \
  --service-code lambda \
  --quota-code L-B99A9384 \
  --desired-value 3000

# リクエストステータス確認
aws service-quotas list-requested-service-quota-changes \
  --service-code lambda \
  --query 'RequestedQuotaChanges[*].[QuotaCode,Status,DesiredValue,Created]'

# EC2 vCPU クォータ（リージョン指定）
aws service-quotas list-service-quotas \
  --service-code ec2 \
  --region ap-northeast-1 \
  --query "Quotas[?QuotaName=='Running On-Demand Standard instances']"

# CloudWatch アラーム設定（80% 超過時）
aws service-quotas put-service-quota-alarm \
  --service-code lambda \
  --quota-code L-B99A9384 \
  --threshold-percentage 80 \
  --aws-sns-arn arn:aws:sns:ap-northeast-1:123456789012:quota-alerts

SDK 例（Python）

import boto3
from datetime import datetime

def monitor_quotas():
    """全クォータの使用率を監視"""
    qs = boto3.client('service-quotas', region_name='ap-northeast-1')
    cloudwatch = boto3.client('cloudwatch')
    
    # 主要サービスのクォータを確認
    services = ['lambda', 'ec2', 'rds', 'dynamodb']
    
    for service in services:
        response = qs.list_service_quotas(ServiceCode=service)
        
        for quota in response['Quotas']:
            quota_code = quota['QuotaCode']
            quota_name = quota['QuotaName']
            max_value = quota['Value']
            
            # 使用量取得（サービスによって異なる）
            try:
                usage_response = qs.get_service_quota_usage_record(
                    ServiceCode=service,
                    QuotaCode=quota_code
                )
                current_usage = usage_response['ServiceQuotaUsageRecord']['Value']
            except:
                current_usage = None  # 使用量が公開されていない場合
            
            if current_usage:
                utilization = (current_usage / max_value) * 100
                
                # CloudWatch に記録
                cloudwatch.put_metric_data(
                    Namespace='ServiceQuotasMonitoring',
                    MetricData=[{
                        'MetricName': 'QuotaUtilization',
                        'Value': utilization,
                        'Unit': 'Percent',
                        'Timestamp': datetime.utcnow(),
                        'Dimensions': [
                            {'Name': 'ServiceCode', 'Value': service},
                            {'Name': 'QuotaCode', 'Value': quota_code},
                            {'Name': 'QuotaName', 'Value': quota_name}
                        ]
                    }]
                )
                
                # 警告ログ
                if utilization > 80:
                    print(f"⚠️ {service}/{quota_name}: {utilization:.1f}% "
                          f"({current_usage}/{max_value})")

def request_quota_increase_batch(increases):
    """複数のクォータ引き上げをバッチリクエスト"""
    qs = boto3.client('service-quotas')
    
    requests = []
    for increase in increases:
        response = qs.request_service_quota_increase(
            ServiceCode=increase['service_code'],
            QuotaCode=increase['quota_code'],
            DesiredValue=increase['desired_value']
        )
        requests.append(response['RequestedQuotaChange'])
    
    return requests

if __name__ == '__main__':
    monitor_quotas()
    
    # バッチ引き上げ例
    increases = [
        {
            'service_code': 'lambda',
            'quota_code': 'L-B99A9384',
            'desired_value': 5000
        },
        {
            'service_code': 'ec2',
            'quota_code': 'L-1216C47A',
            'desired_value': 1000
        }
    ]
    
    results = request_quota_increase_batch(increases)
    for r in results:
        print(f"Requested: {r['QuotaCode']} → {r['DesiredValue']}")

Terraform 例

# Service Quotas Provider
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

# Lambda 同時実行クォータを 3,000 に引き上げ
resource "aws_servicequotas_service_quota" "lambda_concurrent_executions" {
  service_code = "lambda"
  quota_code   = "L-B99A9384"
  value        = 3000
}

# EC2 vCPU クォータを 1,000 に引き上げ
resource "aws_servicequotas_service_quota" "ec2_vcpu_quota" {
  service_code = "ec2"
  quota_code   = "L-1216C47A"
  value        = 1000
}

# RDS DB インスタンス数を 100 に拡張
resource "aws_servicequotas_service_quota" "rds_instances" {
  service_code = "rds"
  quota_code   = "L-7B6409FD"
  value        = 100
}

# CloudWatch アラーム設定
resource "aws_cloudwatch_metric_alarm" "lambda_quota_80pct" {
  alarm_name          = "lambda-quota-80-percent"
  comparison_operator = "GreaterThanOrEqualToThreshold"
  evaluation_periods  = "1"
  metric_name         = "ServiceQuotaUtilization"
  namespace           = "AWS/ServiceQuotas"
  period              = "60"
  statistic           = "Average"
  threshold           = "80"
  alarm_description   = "Alert when Lambda quota utilization exceeds 80%"
  alarm_actions       = [aws_sns_topic.quota_alerts.arn]
  
  dimensions = {
    ServiceCode = "lambda"
    QuotaCode   = "L-B99A9384"
  }
}

resource "aws_sns_topic" "quota_alerts" {
  name = "service-quotas-alerts"
}

# Output
output "lambda_quota_requested" {
  value       = aws_servicequotas_service_quota.lambda_concurrent_executions.value
  description = "Lambda concurrent executions quota requested"
}

類似サービス比較表

┌──────────────────────┬──────────────────┬──────────────────┬──────────────────┐
│ 観点                 │ AWS Service      │ Azure Resource   │ GCP Resource     │
│                      │ Quotas           │ Manager Quotas   │ Quotas           │
├──────────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ コンソール管理       │ ✅ Service       │ ✅ Portal        │ ✅ Console       │
│                      │ Quotas 専用UI    │                  │                  │
│ API 提供             │ ✅ 豊富          │ ✅ REST API      │ ✅ REST / gRPC   │
│ CloudWatch 連携     │ ✅ ネイティブ     │ ⚠️ Azure Monitor │ ❌ 別途実装      │
│ IaC (Terraform)     │ ✅ 完全対応       │ ✅ Azure ARM     │ ✅ Terraform     │
│ Organizations管理   │ ✅ テンプレート  │ ✅ Tenant        │ ⚠️ 限定的        │
│ 自動スケーリング    │ ✅ Lambda 可能    │ ⚠️ ルール基      │ ❌ 手動          │
│ 料金                │ 無料             │ 無料             │ 無料             │
└──────────────────────┴──────────────────┴──────────────────┴──────────────────┘

ベストプラクティス

キャパシティプランニング

✅ DO

  1. 6 ～ 12 ヶ月の成長予測に基づいてクォータ決定

    現在：Lambda 500 req/sec
1 年後（予測）：Lambda 5,000 req/sec
→ 引き上げ：クォータ 5,000 を申請

  2. クォータの 2-3 倍の余裕を確保

    実際の使用：Lambda 1,000 req/sec
クォータ：5,000（5 倍の余裕）
→ スパイクトラフィック・一時的な不具合に対応

  3. 定期的なクォータ使用率レビュー

    月 1 回、CloudWatch メトリクスを確認
実使用率が 20% なら引き下げ検討（コスト最適化）

❌ DON’T

  • クォータ = 現在の使用量に設定 → スケーリング時に即座に上限に達する
  • 全てのサービスで最大クォータ申請 → 不要なコスト増加
  • クォータ申請後、放置 → デフォルト値のままのリソースが溜まる

自動化・運用

✅ DO

  1. CloudWatch アラーム + Lambda で自動クォータ引き上げ

    使用率 85% → Lambda トリガー → 自動引き上げリクエスト

  2. CI/CD パイプラインに事前クォータチェック

    デプロイ前に必要クォータを計算・確認
不足なら自動で申請してデプロイ待機

  3. Terraform / CloudFormation でクォータ管理

    インフラコードと一緒にクォータ値を version 管理

❌ DON’T

  • 手動でのみクォータ申請 → 承認待機期間にデプロイ失敗
  • CloudWatch アラーム設定なし → 使用率が高いまま放置
  • デプロイ時にクォータ確認なし → 予期しない失敗

セキュリティ

✅ DO

  1. Service Quotas API への IAM 権限制限

    開発者：list / get 権限のみ
SRE：request 権限も付与
管理者：full access

  2. CloudTrail で Service Quotas API アクセスを記録

    誰がいつクォータを変更したか完全監査

❌ DON’T

  • 全ユーザーに Service Quotas 管理権限 → 意図しない申請が増える

トラブルシューティング

症状 原因 解決策
クォータ引き上げが却下される アカウント実績不足 / 妥当性欠如 AWS Support に申し立て。過去 3 ヶ月の使用実績を示す
CloudWatch メトリクスに値がない 使用量が記録されていない 24h 以上の利用実績が必要。新規リソースは翌日から
リージョン別に異なるクォータ デフォルト値が地域依存 Service Quotas で各リージョンを個別確認・申請
API レート制限エラー 40 req/sec 超過 バッチ処理 / 指数バックオフで再試行
Terraform で resource not found クォータコードが誤記 AWS CLI で正確なコード確認後、修正

2025-2026 最新動向

自動スケーリングクォータ（Auto-scaling Quota）

AWS は「使用率に基づいて自動的にクォータを引き上げる」機能をロードマップに記載。2026 年中旬に一部サービスで利用可能予定。

  • 現在（2025）: 手動申請 → AWS 審査 → 承認（1-3 日）
  • 将来（2026）: 使用率 85% → 自動引き上げ → 即座に有効

ML 駆動の推奨

機械学習で「このアカウントには将来どのクォータが必要か」を予測。AWS がプロアクティブに引き上げを提案。

Real-time Quota API

キャッシング削減のため、使用率のリアルタイム取得 API をリリース予定。CloudWatch の 1-2 分遅延ではなく、0 秒遅延で状態把握。

学習リソース・参考文献

公式リソース

  1. AWS 公式ドキュメント

  2. チュートリアル・ハンズオン

    • Getting started with AWS Service Quotas
    • Setting up quota alarms with CloudWatch
    • Automation with Lambda and EventBridge

比較・ベンチマーク

実装チェックリスト・導入ロードマップ

導入前チェック

  • [ ] 現在のクォータ値と使用率を確認（Service Quotas コンソール）
  • [ ] 主要リソース（EC2・Lambda・RDS）のクォータを把握
  • [ ] 予想成長率を見積（1 年・3 年・5 年）
  • [ ] CloudWatch ダッシュボードの整備
  • [ ] SNS Topic の作成（アラート通知先）

Phase 1: 監視（1 週間）

  1. Service Quotas コンソール・API の基本操作確認
  2. CloudWatch アラーム設定（80% threshold）
  3. 現在のクォータ使用率の定期確認習慣

Phase 2: 自動化（2 週間）

  1. CI/CD パイプラインにクォータチェックステップ追加
  2. Lambda で自動クォータ引き上げロジック実装
  3. Terraform / CloudFormation でクォータ管理開始

Phase 3: 最適化（継続）

  1. 月 1 回のクォータレビュー（使用率 + 成長トレンド）
  2. Organizations テンプレート化
  3. Cost Analysis とのクロスリファレンス

まとめ

AWS Service Quotas は「AWS サービス使用制限を一元管理し、キャパシティプランニング・自動スケーリングを実現するサービス」。

強み

  • 無料（Service Quotas コンソール・基本 API）
  • AWS 全サービス対応
  • CloudWatch・EventBridge・Lambda との自動化が容易
  • Organizations でマルチアカウント管理可能

弱み

  • 使用量データが全サービスで公開されていない（リージョン・リソースレベル）
  • リクエスト承認に 1-3 日かかる（自動承認ではない）

採用判断

Service Quotas は本番環境運用の 必須 サービス。

✅ EC2・Lambda・RDS・DynamoDB などの本番環境 ✅ スケーリング予定がある SaaS / アプリケーション ✅ マルチアカウント・マルチリージョン運用 ✅ キャパシティプランニング・コスト最適化

最終更新：2026-04-26 バージョン：v2.0