一元課金 / サービスクォータ管理難易度 標準無料
ある企業のOrganizationsには20の本番系メンバーアカウントがあり、各アカウントで個別にEC2のvCPUクォータ引き上げ申請を行う運用に手間がかかっている。この運用を効率化したい場合に最も適切なアプローチを選べ。（単一選択）
- AService Quotasのクォータリクエストテンプレートを管理アカウントで設定して新規アカウントへ自動適用させつつ、既存の20アカウントについては
RequestServiceQuotaIncrease等のAPIをスクリプト化して一括申請する - B対象OUに、EC2のvCPU上限を引き上げるSCPをアタッチし、組織レベルで一括してクォータを引き上げる
- C各アカウントのIAM管理者に依頼し、Service Quotasのコンソールから個別にクォータ引き上げをリクエストしてもらう運用を継続する
- DAWS Trusted Advisorでクォータ使用率のアラートを設定し、閾値に達したら自動的にクォータが引き上げられるようにする
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
AWSのService Quotasには、Organizations統合の一環としてクォータリクエストテンプレート（Quota Request Template） という機能がある。
- 管理アカウント（または委任管理者アカウント）から、特定のリージョン・サービスのクォータ引き上げ内容をテンプレートとして登録しておくと、 そのテンプレートに登録されたクォータ引き上げが、組織内の新規作成アカウントに対して自動的に適用される。 ただしこの自動適用の対象はあくまで新規作成アカウントであり、既存アカウントへ後から横断的に一括適用する ネイティブ機能ではない。
- 既にある20の既存アカウントについては、テンプレートの対象外のため、Service QuotasのAPI（
RequestServiceQuotaIncrease等） を使ってスクリプト化し、20アカウント分をまとめて自動申請する運用にすることで、コンソールから1件ずつ手作業で申請する 手間を削減できる。 - SCPやRCPはクォータの引き上げそのものには関与しない（クォータは各アカウントのサービス側の制限値であり、ポリシーで 引き上げられるものではない）点に注意。
- B誤り。SCPは権限（実行可否）の上限を定める仕組みであり、サービスクォータ自体の数値を変更する機能ではない。
- C要件は「運用の効率化」であり、個別申請を継続する現状の非効率な運用を変えていない。
- DTrusted Advisorはクォータ使用率の可視化・警告を行うが、クォータ引き上げ申請やその自動化を代替する機能ではない。
ひっかけ： 「SCPでクォータ引き上げを一括反映できる（誤答の1つ）」という誤解に注意。SCPは権限の上限を定めるものであり、
サービスクォータ（利用可能なリソース数の上限）自体を変更する機能ではない。また「クォータリクエストテンプレートが既存アカウントにも
自動で一括適用される」という誤解にも注意（テンプレートの自動適用対象は新規作成アカウントのみ）。既存アカウント分は
Service QuotasのAPIをスクリプト化して申請する。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）