はじめに

AWSのサービスクォータ、意識していますか？

小規模なシステムであれば、意識していなくても問題になることはないかもしれません。
しかし、大規模なシステムではアーキテクチャ設計からサービスクォータを意識していないと痛い目に遭うことがあります。

本記事では、サービスクォータを意識する必要性を解説します。
合わせて、全サービスクォータを一覧化するCLIスクリプトも紹介します。

2022/02/28 追記

続編書きました。↓

サービスクォータとは？

一言で言えば**「AWSのサービス毎に定められた制限」**です。

以下はVPCのクォータです。

「リージョンあたりの VPC の数」はデフォルトで「5」となっています。
「デフォルトで」というのは調整できる＝引き上げ可能ということです。

「VPC 当たりの IPv6 CIDR ブロック」のように引き上げ不可のクォータもあります。
引き上げ不可のクォータは特に注意が必要です。

なぜ、サービスクォータを意識しないといけないのか？

結論から言うと、サービスクォータを意識していないと、システムの信頼性・可用性が低下してしまう可能性があるためです。

例えば、Aさんが API Gateway - Lambda - DynamoDB を用いてサーバーレスなAPIサービスを作ったとしましょう。
Aさんは「Lambdaは自動でスケーリングしてくれるから利用者が増えても大丈夫」と考えています。
このAPIサービスは好評を博し、順調に利用者が増えていきました。
すると、ある日突然、このAPIでエラーが頻発するようになりました。

なぜでしょう？

原因は、利用者増加に伴い、Lambdaの同時実行数が増え、同時実行数が「1,000」を超えた＝Lambdaのサービスクォータに引っ掛かってしまったためでした。

つまり、Aさんはサービスクォータを意識していなかったため、このAPIサービスの信頼性・可用性の低下を招いてしまったわけです。
こういった事態を引き起こさないよう、アーキテクチャ設計からサービスクォータを意識しておきましょう。

ここでは Lambdaの同時実行数のクォータを例にしましたが、場合によっては API Gateway や DynamoDB のクォータが問題になっていた可能性もあります。
つまり、サービスクォータはシステムを構成するすべてのサービスについて意識する必要があります。

AWS Well-Architected Framework にも書かれている

サービスクォータを意識しよう、という話は AWS Well-Architected Framework にも書かれています。
AWS Well-Architected Framework は簡単に言うと**「AWS アーキテクチャ設計のベストプラクティスを体系化したもの」**です。

AWS Well-Architected Framework は、以下の6つの柱で構成されています。

オペレーショナルエクセレンス（運用上の優秀性）
セキュリティ
信頼性
パフォーマンス効率
コスト最適化
サステナビリティ（持続可能性） ¹

サービスクォータは信頼性に影響するので**「信頼性の柱」**として定義されています。

サービスクォータと制約を認識する
アカウントおよびリージョンをまたいでクォータを管理する
アーキテクチャを通じて、固定サービスクォータと制約に対応する
クォータをモニタリングおよび管理する
クォータ管理を自動化する
フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する

クォータのモニタリングと管理の自動化については、また別の機会に書こうと思います。
↓
続編「続・AWSのサービスクォータをなめてると痛い目に遭うぞ！（自動化CloudFormation付き）」書きました。（2022/02/28 追記）

サービスクォータはどうやって確認すればよいのか？

「サービスクォータを意識しないといけないことはわかった」
「じゃあ、どうやって確認すればいいんだ？」
「引き上げはどうやるんだ？」

答えは「Service Quotas コンソールで確認・リクエストする」です。
詳細は以下の記事を読んでみてください。

でも、ひとつひとつ確認するのは面倒じゃないですか？

私は面倒ですw

前述のとおり、サービスクォータはシステムを構成するすべてのサービスについて意識する必要があります。
例として挙げたサーバーレスAPIでも、実際には API Gateway, Lambda, DynamoDB だけではなく、セキュリティやモニタリングのために WAF, KMS, CloudWatch Logs, Alarm, SNS, S3, ... と多くのサービスを使う必要があります。

私はアーキテクチャ設計を担当することが多いので、毎回、それらすべてのクォータを確認するのは面倒なんです！

なので、すべてのサービスクォータを一括出力するCLIスクリプトを作ってみました。

AWS CLI スクリプト

all_quotas.sh

#!/bin/sh

# 引数から対象リージョンを取得（未指定の場合、$AWS_REGIONを対象リージョンとする）
region=${1:-$AWS_REGION}
echo "Target region: $region"

# すべてのデフォルトクォータ
all_default_quotas='[]'

# サービスコード一覧を取得
services=`aws service-quotas list-services --region $region --query Services[*].ServiceCode --output text`
for service in $services
do
  # デフォルトクォータを取得
  echo "Getting default service quotas: $service"
  quotas=`aws service-quotas list-aws-default-service-quotas --region $region --service-code $service`

  # すべてのデフォルトクォータに追加
  all_default_quotas=`echo $all_default_quotas $quotas | jq -s '.[0] + .[1].Quotas'`
done

# JSONファイル出力
echo $all_default_quotas > all_default_quotas_$region.json

コピペして、CloudShellなどで実行してみてください。
やっていることはシンプルで、これだけです↓

list-services コマンドでサービスコード一覧を取得
サービス毎にループ
2-1. list-aws-default-service-quotas コマンドでサービスクォータを取得
2-2. 取得したクォータを結合
JSONファイルとして出力

なお、list-aws-default-service-quotas コマンドは名前のとおり、デフォルトのクォータを取得するコマンドです。
これを list-service-quotas コマンドに置き換えると、現在のクォータ（引き上げた場合、引き上げ後のクォータ）を取得することができるので、目的に応じて使い分けてください。

IAM や CloudFront などグローバルサービスのクォータを取得するには、バージニア北部リージョン（us-east-1）を指定する必要があります。

一覧化

JSONのままでは確認しづらいので適当なツールを使って、CSV化しましょう。
私は Visual Studio Code の以下のプラグインを使わせていただきました。便利ですね。感謝。

あとは Excel なり Spreadsheets なりで取り込めば、全サービスクォータ一覧のできあがり！
こんな感じになります↓

これでサービスクォータをさくっと確認することができるようになりました。

まとめ

AWSのサービスクォータを意識しよう
サービスクォータを意識しないと信頼性が低下してしまう可能性がある
サービスクォータはシステムを構成するすべてのサービスについて意識しよう

最後まで読んでいただき、ありがとうございます。
この記事が少しでも役に立てば幸いです。

サステナビリティ（持続可能性）の柱は、2021年12月に AWS re:Invent 2021 で発表・追加されました。https://aws.amazon.com/jp/blogs/news/sustainability-pillar-well-architected-framework/ ↩

AWSのサービスクォータをなめてると痛い目に遭うぞ！（全サービスクォータ一覧化スクリプト付き）