Service Quotasの自動管理機能でクォータ管理工数の削減が可能に
はじめに
この記事は KINTOテクノロジーズ Advent Calendar 2025 の12日目の記事です🎅🎄
こんにちは。クラウドインフラ所属の松尾です。
AWS re:Inventで発表された新機能ではないですが、
個人的に熱いと感じたアップデートがあったので紹介します。
Service Quotasの自動管理機能です。
2025年10月に「自動管理設定」機能がGAとなり、
Service Quotasの上限値が近づくと通知が飛ぶようになりました。
そして先日、GAのタイミングで予告されていた「自動調整」モードが追加。
これまでクォータ監視を実装しようとすると、複雑な構成を自前で用意する必要がありましたが、
この機能を使えばコンソールからポチポチするだけでクォータの監視から自動調整までやってくれます。
しかも無料です。
ただ、先に言っておくと自動調整について、「全部のクォータに対応しているわけではない」という制約があります。
この記事では、実際に検証してわかった仕様や制約を書いていきます!
アップデートの経緯
| 日付 | 内容 |
|---|---|
| 2025年10月 | 自動管理機能の追加。追加時は「通知のみ」モードがGA。自動調整モードの予告あり |
| 2025年11月 | 「通知と自動調整」モードが追加 |
公式アナウンス:
- AWS Service Quotas の自動クォータ管理の一般提供を開始 - AWS
- AWS Service Quotas now supports automatic quota adjustment
何が嬉しいのか
Before(従来の方法)
クォータ監視を実装するには、こんな構成が必要でした:

出典: AWS Solutions Library
- CloudWatch Alarmsでメトリクスを監視
- Lambda関数でService Quotas APIを叩いて上限緩和リクエストを送信
- EventBridgeでトリガー設定
- SNSで通知
- Amazon DynamoDB 監視対象のクォータの管理
これだとかなり複雑な構成になるので構築、運用が大変でした。
After(自動管理機能)
- コンソールで数クリックで設定完了
- 80%/95%で自動通知
- 「自動調整」モードなら自動で上限緩和リクエストまで送ってくれる
- 今までクォータ監視で必要だったリソースの料金の発生はなし
従来までの方法と比べ、複雑な設定は無し。かなり導入がしやすそうです。
| Before | After | |
|---|---|---|
| 設定の手間 | Lambda/EventBridge/SNS/DynamoDB等の構築が必要 | コンソールで数クリック |
| 通知タイミング | 自分で閾値を設定 | 80%/95%で自動通知(固定) |
| クォータ調整 | Lambda等で自前実装 | 自動調整モードで対応 |
| 料金 | 各リソースの料金が発生 | 無料 |
機能の仕様
通知タイミング
公式ドキュメントによると、以下のタイミングで通知が送信されます:
- 80% 使用率に達した時
- 95% 使用率に達した時
重要:この閾値は固定です。
コンソールで設定するとき「あれ、閾値設定するところないな?」って思ったんですが、そもそも変更できない仕様でした。
「70%で通知が欲しい」みたいなカスタマイズはできないので、その場合は従来通りCloudWatch Alarmsを使う必要があります。
自動管理モード
| モード | 説明 |
|---|---|
| 通知のみ(NotifyOnly) | 80% / 95%で通知を送信 |
| 通知と自動調整(NotifyAndAdjust) | 通知に加えて、自動でクォータ増加リクエストを送信 |
通知先
AWS User Notificationsと統合されていて、以下の通知先を設定できます:
- Eメール(SES経由、サポートされていないリージョンからのイベントはバージニア経由で送信)
- AWS コンソールモバイルアプリケーション(事前にアプリのインストールとプッシュ通知の有効化が必要)
- チャットチャネル(Amazon Q Developer経由でSlack/Teamsに配信、事前にチャットクライアントの設定が必要)
料金
無料で使用できます。
自動管理機能自体には追加料金はかかりません。
通知に使われるAWS User Notificationsも無料ですが、
裏で呼び出しているSES・モバイルプッシュ・Amazon Q Developerの使用や、
自動管理機能とは別にCloudWatch Alarmsで独自の監視を設定する場合は、別途料金がかかる場合があります。
設定方法
📝 補足: 2025年11月時点では本機能は現在Terraformでは対応しておりません
コンソールでの設定
- Service Quotasコンソールを開く
- 左メニューから「自動管理」を選択
- 「自動管理を開始」をクリック
- 自動管理モードを選択(「通知のみ」または「通知と自動調整」)
- 通知設定を構成(オプション)
- 例外設定を構成(オプション)
- 確認して送信
めちゃくちゃ簡単。
CLIでの設定
以下はus-west-2(オレゴン)リージョンでの設定例です。
# User Notificationsの通知先と自動調整を指定する場合
aws service-quotas start-auto-management \
--opt-in-level ACCOUNT \
--opt-in-type NotifyAndAdjust \
--notification-arn arn:aws:notifications::xxxxxxxxxxxx:configuration/xxxxx \
--region us-west-2
⚠️ 注意: リージョンごとに設定が必要です。オレゴンリージョンで設定しても、東京リージョンには適用されません。
CLIで全リージョン設定する場合はスクリプトを組むなどの対応が必要です。
内部の仕組み(イベントパターン)
自動管理を設定すると、内部的にはAWS User Notificationsの詳細フィルターとして以下のようなイベントパターンが設定されます:
{
"source": ["aws.health"],
"detail-type": ["AWS Health Event"],
"detail": {
"service": ["SERVICEQUOTAS"],
"eventTypeCode": [
"AWS_SERVICEQUOTAS_THRESHOLD_BREACH",
"AWS_SERVICEQUOTAS_INCREASE_REQUEST_FAILED",
"AWS_SERVICEQUOTAS_APPROACHING_THRESHOLD"
],
"eventTypeCategory": ["accountNotification"]
}
}
各イベントタイプの意味(公式ドキュメント):
| eventTypeCode | 意味 |
|---|---|
AWS_SERVICEQUOTAS_APPROACHING_THRESHOLD |
調整可能なクォータが閾値に近づいた。自動調整モードならここでクォータの引き上げリクエストが送信される |
AWS_SERVICEQUOTAS_THRESHOLD_BREACH |
調整できないクォータが閾値を超過。クォータの引き上げできないので使用率を最適化する必要あり |
AWS_SERVICEQUOTAS_INCREASE_REQUEST_FAILED |
クォータの引き上げリクエストが失敗した |
実際に検証してみた
検証環境
- リージョン:us-west-2(オレゴン)
- 自動管理モード:通知と自動調整
必要な権限
自動管理機能を使用するために必要な権限、および閲覧権限は以下の通りです。
-
使用するために必要な権限
- ServiceQuotasFullAccess
- AWSHealthFullAccess
-
閲覧するために必要な権限
- AWSHealthFullAccess
対応クォータの確認
コンソールの「サポートされているクォータを表示」から確認してみたんですが、リリース直後だからか思ったより対応範囲が限定的でした。
今後、対応するリソースが増えることを期待したいです。
対応していたサービスの例:
- AWS Systems Manager
- Amazon EC2
- WAF(Regionalのみ)
- ELB
- Lambda
- Route53
- IAM
対応していなかったサービスの例:
- VPC
- API Gateway
- EventBridge
- Amazon Simple Email Service(SES)
Route53やIAMなどのグローバルサービスの場合、通知のみできるようで自動調整には対応していない印象でした
自動調整の動作確認
AWS WAFの「Maximum regex pattern sets per account in WAF for regional」で検証してみました。
このクォータはデフォルト値が10なので、8個作成すれば80%に到達します。
検証手順
1. 事前準備
まずはService Quotasで自動管理の設定を行います。
- Service Quotasの自動管理を「通知と自動調整」モードで有効化

(オレゴンリージョンで設定した際、キャプチャしてなかったのでバージニアリージョンでの設定画面になりますmm) - 通知設定に移ります。ここではAWS User Notificationsの設定を行います。
今回はAmazon Q Developerを用意し、Slackチャンネルに通知するようにしました。
⚠️ 注意: イベントソースのリージョンを選択できますが、自動管理を有効にしているリージョンのイベントしか受け取れないため、
監視したいリージョンごとに自動管理の設定が必要です(自動管理とAWS User Notificationsは別設定だからちょっとややこしい)

- 自動管理の例外とするサービスを選択できますが、今回は何も設定しないまま作成

2. 正規表現パターンセットを作成
次に正規表現パターンセットを作成し、閾値に引っかかるようにします。
- WAFコンソール → 正規表現パターンセット → 「Create regex pattern set」
- リージョン:us-west-2(オレゴン)※Regionalを選択
- 適当な名前で8個作成

3. 使用率の確認
- Service Quotas → AWS WAF → 「Maximum regex pattern sets per account in WAF for regional」
- 使用率が80%になっていることを確認しました
4. 通知/自動調整の発動を待つ
- 数分待機...
検証結果
-
通知/自動調整反映までの時間:正確には確認できていませんが、数分程度で完了
-
クォータ値:10→11に。自動調整後のクォータ値の指定はできませんが、80%を切るようなクォータに更新してくれそう?


-
通知に関して、Slack通知は見づらい
改行コード(\n)がそのまま表示されてしまい、長文が一塊になっています。
また、通知本文には「どのクォータが閾値に近づいたか」の具体的な情報が含まれておらず、
通知文に添付のリンクからAWS Health Dashboardの「Affected resources」タブを確認する必要があります。

通知としては「何か閾値に近づいた」ことはわかるが、詳細確認には一手間かかる印象です。
注意点・制約
1. 対応クォータが限定的
正直、今のところこれが一番大きな制約だなと感じました。
VPCやSESといった基本的なサービスのクォータが対応していないのは残念です。
現時点ではService Quotaの自動管理だけでは「クォータ周りの調整がすべて解決」とはならない。
対応クォータの拡大を今後待つしかないです。
2. 閾値のカスタマイズ不可
80%/95%の閾値は固定。「50%で早めに通知が欲しい」「100%になるまでは通知不要」みたいな要件には対応できません。
3. AWS Organizations対応は未実装
2025年11月時点では、Organizations単位での一括設定には対応していないため、
各アカウントで個別に設定する必要があります。
CLIコマンドには--opt-in-levelというオプションがCLIであるのでいつか対応されることを期待したいです。
4. 自動調整の承認は保証されない
自動調整はあくまで「上限緩和リクエストを自動送信する」機能です。
リクエストがAWSに承認されるかどうかは別の話で、拒否される可能性もあります。
5. 通知・自動緩和までに時間がかかる場合がある
クォータが11に上がった直後、正規表現パターンを3つ追加して合計11個にして使用率を100%にしてみました。
が、今度は通知もされず、自動調整もありませんでした。
しかし数時間後、自動調整されていることが確認できたことから、
場合によっては通知や自動調整までに時間がかかることがあるようです。
まとめ
Service Quotasの自動管理機能は、クォータ監視のハードルを大きく下げてくれる個人的にはかなり良いアップデートです。
無料で始められて、コンソールから数クリックで設定できます。
対応クォータがまだ限定的だったり、IaC(Terraform)未対応だったりとまだまだ制約はありますが、
サポートされているクォータに関しては実際にクォータ拡張作業の工数を削減できることがわかりました。
弊社では独自実装のクォータ管理ツールも運用しており、
自動管理機能でサポートされていないクォータについては引き続きそちらで対応していく予定です。
以上、この記事が誰かの参考になれば幸いです。
関連記事 | Related Posts
We are hiring!
【クラウドプラットフォームエンジニア】プラットフォームG/東京・大阪・福岡
プラットフォームグループについてAWS を中心とするインフラ上で稼働するアプリケーション運用改善のサポートを担当しています。
【クラウドエンジニア】Cloud Infrastructure G/東京・大阪・福岡
KINTO Tech BlogWantedlyストーリーCloud InfrastructureグループについてAWSを主としたクラウドインフラの設計、構築、運用を主に担当しています。



