概要
AWS を使い始めてしばらくすると、「サーバーが重いのは自分の設定のせいか、AWS 側の障害か」「インスタンスを増やそうとしたらエラーになった」「このインスタンスは大きすぎないか」といった疑問に出会います。どれも EC2 や RDS の本体ではなく、運用を支える小さなサービスが答えてくれる問いです。
この記事では、次の 5 つのサービスを「困ったとき・コストを下げたいとき・上限に当たったとき、どこを見るか」という観点で整理します。
- AWS Compute Optimizer: リソースの使用状況から、適正なサイズを推奨する
- AWS Health Dashboard: AWS 側の障害や予定されたメンテナンスを知らせる
- Service Quotas: アカウントの上限（クォータ）を確認し、引き上げを申請する
- AWS License Manager: Microsoft や Oracle などのソフトウェアライセンスの使用量を管理する
- Amazon Managed Service for Prometheus: コンテナのメトリクスを Prometheus 互換で収集・保存する
あわせて、似た役割を持つ Trusted Advisor・Cost Explorer・CloudWatch・Amazon Managed Grafana との違いも比較表で押さえます。AWS Certified Cloud Practitioner（CLF）の第 3 分野「クラウドテクノロジーとサービス」の管理・ガバナンス、第 4 分野「請求、料金、およびサポート」のコスト最適化に当たる内容で、AWS Certified Solutions Architect – Associate（SAA）の運用設計の土台にもなります。
クラウドおさる猿山でも、バナナ倉庫が狭いのか、配達の道が崩れたのか、倉庫の数に上限があるのかで、相談に行く先が違うのでござる。困りごとごとに「どこを見るか」を整理する回でござるな。
—
この記事のメリット
- 「コスト」「障害」「上限」「ライセンス」「メトリクス」の困りごとごとに、見るべきサービスを選べるようになります
- Compute Optimizer と Trusted Advisor・Cost Explorer の推奨の違いを説明できます
- Health Dashboard（AWS 側の出来事）と CloudWatch（自分のリソースの状態）の違いを区別できます
- Service Quotas で見る「適用されたクォータ」「デフォルトクォータ」「調整可能性」の意味が分かります
- Managed Service for Prometheus と Managed Grafana が「集めて貯める」と「見せる」で分担していることを理解できます
—
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
困りごとで見るサービスを分ける
クラウドおさるとひさん、運用のサービスは名前が似ていて、どれを開けばよいか分からなくなるでござる。どう整理すればよいのでござるか？
土肥「いま何に困っているか」で分けるのがいちばん分かりやすいよ。コストを下げたいのか、AWS 側で何か起きていないか知りたいのか、上限に当たったのか。困りごとが決まれば、開く画面もほぼ決まるんだ。
クラウドおさる困りごとが先、サービス名はあと、でござるか。
土肥そうそう！ まとめるとこんな感じだよ。
| 困りごと | 見るサービス | 何が分かるか |
|---|---|---|
| インスタンスが大きすぎる・小さすぎる気がする | AWS Compute Optimizer | 使用状況のメトリクスから、適正なサイズの推奨 |
| アカウント全体で節約できる点・危ない設定を一覧したい | AWS Trusted Advisor | コスト最適化・セキュリティ・耐障害性などのチェック結果 |
| 何にいくら使ったかを知りたい | AWS Cost Explorer | 過去のコストの内訳と予測 |
| 自分のサーバーの CPU やエラーを見たい | Amazon CloudWatch | 自分のリソースとアプリケーションのメトリクス・ログ・アラーム |
| AWS 側で障害やメンテナンスが起きていないか知りたい | AWS Health Dashboard | AWS のサービスの状態と、自分のアカウントに影響するイベント |
| インスタンスを増やそうとしたら上限エラーになった | Service Quotas | 上限の現在値と、引き上げの申請 |
| 商用ソフトのライセンス数を守りたい | AWS License Manager | ライセンスの使用量と、超過を防ぐルール |
| コンテナのメトリクスを Prometheus の形で集めたい | Amazon Managed Service for Prometheus | Prometheus 互換のメトリクスの保存とクエリ |
| 集めたメトリクスをダッシュボードで見たい | Amazon Managed Grafana | 複数のデータソースをまとめた可視化 |
クラウドおさる倉庫が狭いなら倉庫番、道が崩れたなら村の掲示板、倉庫の数が足りないなら長老会への申請、と行き先を決めておくのと同じでござるな！
土肥いいたとえだね。試験でも「〜したい」という要件から、この表の左の列を読み取ってサービスを選ばせる形が多いよ。
Compute Optimizer：適正なサイズを推奨する
クラウドおさるCompute Optimizer は何を最適化してくれるのでござるか？
土肥リソースの「サイズ」だよ。CloudWatch のメトリクスで過去の CPU 使用率やネットワークの使われ方を分析して、「このインスタンスは大きすぎる」「小さすぎる」を判定し、ちょうどよいインスタンスタイプを最大 3 つ推奨してくれるんだ。分析期間は既定で 14 日間だよ。
クラウドおさる判定はどんな言葉で出てくるのでござる？
土肥EC2 インスタンスの場合は 3 つに分類されるよ。
| 分類 | 意味 | 起きうること |
|---|---|---|
| 過剰なプロビジョニング | CPU・メモリ・ネットワークなどをサイズダウンしても、ワークロードの要件を満たせる | 使っていない分のコストを払っている |
| プロビジョニング不足 | CPU・メモリ・ネットワークなどがワークロードの要件を満たしていない | アプリケーションの性能が落ちる |
| 最適化 | すべての要素が要件を満たし、過剰でもない | 新しい世代のインスタンスタイプが推奨される場合もある |
土肥対象は EC2 だけじゃなくて、EC2 Auto Scaling グループ、EBS ボリューム、Lambda 関数、Fargate 上の ECS サービス、RDS や Aurora なども含まれるよ。ただし、使い始めるにはオプトインが必要で、推奨が出るまでに少なくとも 24 時間かかるんだ。EC2 なら過去 14 日間に 30 時間以上のメトリクスがあることも条件だよ。
クラウドおさるオプトインしたら勝手に料金がかかる、ということはないのでござるか？
土肥気になるところだよね。ドキュメントで「有料機能」と明記されているのは、分析期間を 14 日から 93 日に延ばす拡張インフラストラクチャメトリクスだよ。これは推奨の設定であとから有効にする機能なので、使うときは料金を確認してからにしよう。
Trusted Advisor・Cost Explorer の推奨との違い
クラウドおさる「大きすぎるインスタンス」は、Trusted Advisor や Cost Explorer でも教えてくれると聞いたでござる。何が違うのでござるか？
土肥いいところに気づいたね！ 3 つとも「節約のヒント」を出すけど、見る範囲が違うんだ。
| サービス | 見る範囲 | 推奨の中身 |
|---|---|---|
| AWS Compute Optimizer | リソース 1 つひとつのサイズ | 使用状況のメトリクスから、適正なインスタンスタイプ・ボリューム・メモリ設定を推奨。性能が足りない「プロビジョニング不足」も指摘する |
| AWS Trusted Advisor | アカウント全体のベストプラクティス | コスト最適化・パフォーマンス・セキュリティ・耐障害性・サービス制限・運用上の優秀性の 6 カテゴリでチェックする |
| AWS Cost Explorer | 請求・コストの実績 | コストの内訳を可視化する。適正化の推奨（EC2 の縮小・終了）や、リザーブドインスタンス・Savings Plans の購入の推奨も出す |
土肥ちなみに Trusted Advisor のコスト最適化には、昔からある「使用率の低い EC2 インスタンス」のチェック（過去 14 日間のうち 4 日以上、1 日の平均 CPU 使用率が 10% 以下でネットワーク I/O が 5 MB 以下）と、Compute Optimizer のデータを使う新しいチェックがあるんだ。最近は Cost Explorer の適正化の推奨も、Compute Optimizer の推奨を集める Cost Optimization Hub を使うようにドキュメントで案内されているよ。
クラウドおさる中身を一番細かく見ているのは Compute Optimizer で、ほかのサービスはその結果も使って見せてくれる、という関係でござるな。
土肥そのイメージで大丈夫！ 試験では「サイズの最適化」「性能不足も含めて推奨」なら Compute Optimizer、「ベストプラクティスのチェック全般」なら Trusted Advisor、「コストの実績分析」なら Cost Explorer、と選ぶといいよ。
Health Dashboard と CloudWatch の違い
クラウドおさるサーバーが急に遅くなったとき、AWS が悪いのか弊猿の設定が悪いのか、どう見分けるのでござるか？
土肥そこで役立つのが AWS Health Dashboard だよ。AWS のサービス側で起きている障害や、予定されているメンテナンスを知らせてくれるんだ。2 つの画面があるよ。
| 画面 | サインイン | 表示されるもの |
|---|---|---|
| サービスの状態（Service health） | 不要（誰でも見られる） | 特定のアカウントに限らない公開イベント。過去 12 か月のサービス中断の履歴も見られる |
| アカウントの状態（Your account health） | 必要 | 公開イベントに加えて、自分のアカウントのリソースに影響するイベント。過去 90 日のイベントを見られる |
クラウドおさる自分のリソースの様子なら、CloudWatch でも見られるのではござらんか？
土肥そこが試験でよく狙われる違いなんだ。CloudWatch は自分のリソースとアプリケーションの CPU 使用率やログを見て、しきい値でアラームを出すサービス。Health Dashboard はAWS 側の出来事、たとえば「このリージョンの EC2 で障害が起きている」「このインスタンスが載っているホストのメンテナンスが予定されている」を知らせるサービスなんだ。
| 観点 | AWS Health Dashboard | Amazon CloudWatch |
|---|---|---|
| 何の状態か | AWS のサービスと、AWS 側のイベントがアカウントに与える影響 | 自分のリソースとアプリケーション |
| 情報の出どころ | AWS が発信するイベント（障害・予定されている変更・通知） | 自分のリソースから集めたメトリクス・ログ |
| 代表的な使い方 | 障害の切り分け、メンテナンスの予定確認 | CPU 使用率のアラーム、ログの検索 |
土肥AWS Health のイベントは、追加料金なしで Amazon EventBridge に流して通知や自動処理につなげられるよ。一方で、AWS Health の API を使うにはビジネスサポート以上のサポートプランが必要なんだ。
クラウドおさる自分の猿の体温を測るのが CloudWatch、村の掲示板で「北の道が崩れた」と知るのが Health Dashboard でござるな。
Service Quotas：上限を確認して引き上げを申請する
クラウドおさるインスタンスを増やそうとしたら上限のエラーになったという話を聞いたでござる。AWS にも上限があるのでござるか？
土肥あるんだ。AWS のサービスには、アカウントごとに作れる数や使える量の上限が決まっていて、これをサービスクォータと呼ぶよ。Service Quotas は、その上限をひとつの画面で確認して、引き上げを申請できるサービスなんだ。
| 用語 | 意味 |
|---|---|
| デフォルトクォータ | AWS が最初に決めている値 |
| 適用されたクォータ | 引き上げ後などで、実際にそのアカウントに適用されている値 |
| 調整可能性 | 引き上げを申請できるかどうか。すべてのクォータが引き上げられるわけではない |
| リージョンのクォータ / グローバルクォータ | リージョンごとに数えるもの（VPC の数など）と、アカウント全体で数えるもの |
クラウドおさるEC2 の台数にも上限があるのでござるか？
土肥EC2 のオンデマンドインスタンスは、台数ではなく vCPU の数で上限が決まっているんだ。たとえば「Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances」というクォータが、汎用的なインスタンスファミリーで使える vCPU の合計の上限だよ。オンデマンドインスタンスのクォータは、使用量に応じて EC2 が自動で引き上げることもあるんだ。
土肥調整可能なクォータは、コンソールから「クォータ引き上げのリクエスト」で申請できるよ。小さな引き上げは自動で承認されて、大きなものは AWS サポートが承認・拒否・一部承認を判断するんだ。対応しているクォータなら、使用率が上限に近づいたときに CloudWatch アラームで知らせる設定もできるよ。
クラウドおさる上限は長老会への申請と同じで、すぐ通るとは限らないのでござるな。本番の前に余裕をもって確認しておくでござる。
土肥その通り！ ちなみに Trusted Advisor にも「サービス制限」のカテゴリがあって、上限に近づいているクォータを教えてくれるよ。上限の確認と申請をする場所は Service Quotas、と覚えておこう。
License Manager：ライセンスの使いすぎを防ぐ
クラウドおさるLicense Manager は、何のライセンスを管理するのでござるか？
土肥Microsoft、Oracle、SAP、IBM などのベンダーのソフトウェアライセンスだよ。複数のアカウントやリージョンにまたがって、どれだけライセンスを使っているかを一元的に管理できるんだ。
| 機能 | 内容 |
|---|---|
| ライセンスの数え方 | vCPU・物理コア・ソケット・マシン数などの単位で、ライセンス契約の条件を表す |
| ハードな制限 / ソフトな制限 | 上限を超える起動を止める（ハード）か、超えたことを知らせる（ソフト）かを選べる |
| BYOL（Bring Your Own License） | 手持ちのライセンスをクラウドで使い、コストを抑える |
クラウドおさる契約で決まった数を超えて使うと、あとでベンダーから違反を指摘されるのでござるな。
土肥そうなんだ。超過やそれに伴うペナルティのリスクを下げるのが License Manager の役割だよ。試験では「ソフトウェアライセンスの使用状況を管理・追跡したい」と言われたら License Manager だね。
Managed Service for Prometheus と Managed Grafana
クラウドおさる最後の Managed Service for Prometheus は、CloudWatch とは別の監視サービスでござるか？
土肥Prometheus は、コンテナや Kubernetes の監視でよく使われるオープンソースのモニタリングツールなんだ。Amazon Managed Service for Prometheus は、それと互換性のあるサーバーレスのサービスで、Amazon EKS やセルフマネージドの Kubernetes などのメトリクスを、インフラの管理なしに取り込んで保存できるよ。クエリには Prometheus と同じ PromQL を使うんだ。
クラウドおさるでは、集めたメトリクスはどこで見るのでござる？
土肥そこで出てくるのが Amazon Managed Grafana だよ。Grafana はダッシュボードを作るためのツールで、Managed Grafana は Managed Service for Prometheus のワークスペースをデータソースとして追加できるんだ。CloudWatch や AWS X-Ray なども同じダッシュボードにまとめられるよ。
| サービス | 役割 | 料金の考え方 |
|---|---|---|
| Amazon Managed Service for Prometheus | メトリクスを集めて貯め、PromQL で問い合わせる | メトリクスの取り込みと保存の量に応じて |
| Amazon Managed Grafana | 複数のデータソースをダッシュボードで可視化する | ワークスペースのアクティブユーザーごと |
クラウドおさる帳面にバナナの出入りを書きためるのが Prometheus、その帳面をグラフにして長老会に見せるのが Grafana、という分担でござるな。
土肥ばっちり！ 「Prometheus 互換」「コンテナのメトリクス」と来たら Managed Service for Prometheus、「ダッシュボードで可視化」と来たら Managed Grafana だよ。
—
実践
課金が発生しない範囲で、Health Dashboard・Service Quotas・Compute Optimizer のコンソールを開き、技術解説で整理した情報がどこに表示されるかを確認します。この実践ではリソースを作成せず、クォータの引き上げ申請や Compute Optimizer のオプトインも行いません。
前提条件
- AWS マネジメントコンソールにログイン済みであること（AWS Health、Service Quotas、Compute Optimizer を閲覧できる権限）
- リージョンは
ap-northeast-1（東京）を使用します - 作成するリソースはありません。「アカウントレベルでの引き上げをリクエスト」「ご利用開始」などのボタンは押さないでください
手順 1: Health Dashboard でアカウントの状態を確認する
AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。
上部の検索バーに Health と入力し、表示された「AWS Health Dashboard」を選択します。
左側ナビゲーションの「アカウントの状態」を選択します。
アカウントに影響するイベントが、「未解決の問題と最近の問題」「スケジュールされた変更」「その他の通知」「イベントログ」のタブに分かれて並びます（タブ名の後ろに件数が表示されます）。イベントが無い場合は、空の一覧が表示されます。いずれかのタブにイベントがあれば、イベント名を選択して、影響を受けるリージョンやサービス、影響を受けるリソースが表示されることを確認します。
続けて、左側ナビゲーションの「サービスの状態」の下にある「未解決の問題と最近の問題」を選択します。こちらはアカウントに限らない公開イベントの一覧で、サインインしなくても見られる画面と同じ内容です。
手順 2: Service Quotas で EC2 のクォータを確認する
上部の検索バーに Service Quotas と入力し、表示された「Service Quotas」を選択します。
左側ナビゲーションの「AWS のサービス」を選択し、検索ボックスに EC2 と入力して、表示された「Amazon Elastic Compute Cloud (Amazon EC2)」を選択します。
クォータの一覧の検索ボックスに Running On-Demand Standard と入力します。一覧に「Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances」が表示され、以下の列を確認できます。
- 適用されたアカウントレベルのクォータ値: このアカウントで実際に使える vCPU の上限
- AWS のデフォルトのクォータ値: AWS が最初に決めている値
- 使用率: いま使っている量
- 調整可能性: 引き上げを申請できるかどうか
クォータ名を選択すると詳細画面が開きます。クォータの説明や ARN に加えて、「モニタリング」「リクエスト履歴」「アラーム」「タグ」のタブがあり、「モニタリング」タブでは使用率のグラフ、「アラーム」タブでは使用率に応じた CloudWatch アラームを確認できます。クォータ名の下にある「アカウントレベルでの引き上げをリクエスト」は押さずに画面を閉じます。
手順 3: Compute Optimizer のオプトイン状況を確認する
上部の検索バーに Compute Optimizer と入力し、表示された「Compute Optimizer」を選択します。
オプトインしていないアカウントでは、サービスの説明と「ご利用開始」ボタンが並ぶ画面が表示されます。「ご利用開始」の先でオプトインの対象（「このアカウントのみ」か「組織内のすべてのアカウント」か）を選ぶ流れになっていますが、この実践では押しません。
すでにオプトイン済みのアカウントでは、ダッシュボードにリソースの種類ごとの検出結果（過剰なプロビジョニング・プロビジョニング不足・最適化）の件数が表示されます。
クラウドおさる障害は Health Dashboard、上限は Service Quotas、サイズは Compute Optimizer と、3 つの画面で見えるものがはっきり分かれていたでござる。困ったときに開く場所を覚えておくと、猿山の当番でも慌てずに済むでござるな。
クラウドおさる試験では「AWS 側の障害か自分のリソースの問題か」「上限の確認か節約の推奨か」を取り違えさせる観点が多いでござる。Health Dashboard と CloudWatch、Compute Optimizer と Trusted Advisor の違いを押さえておくでござる。
—
まとめ
| こうしたいとき | 使うサービス |
|---|---|
| リソースのサイズが適正か知りたい（過剰・不足の両方） | AWS Compute Optimizer |
| アカウント全体のベストプラクティスをチェックしたい | AWS Trusted Advisor |
| コストの実績を分析したい | AWS Cost Explorer |
| AWS 側の障害・予定されたメンテナンスを知りたい | AWS Health Dashboard |
| 自分のリソースのメトリクス・ログを監視したい | Amazon CloudWatch |
| サービスの上限を確認し、引き上げを申請したい | Service Quotas |
| ソフトウェアライセンスの使用量を管理したい | AWS License Manager |
| コンテナのメトリクスを Prometheus 互換で集めたい | Amazon Managed Service for Prometheus |
| 集めたメトリクスをダッシュボードで可視化したい | Amazon Managed Grafana |
- Compute Optimizer は CloudWatch のメトリクスから、過剰なプロビジョニング・プロビジョニング不足・最適化を判定する。使うにはオプトインが必要
- Health Dashboard は AWS 側の出来事、CloudWatch は自分のリソースの状態を見る
- Service Quotas では「適用されたクォータ」「デフォルトクォータ」「調整可能性」を確認し、調整可能なものだけ引き上げを申請できる。EC2 のオンデマンドインスタンスは vCPU の数で上限が決まる
- License Manager はライセンスの使用量を数え、ハードまたはソフトな制限で超過を防ぐ
- Managed Service for Prometheus が集めて貯め、Managed Grafana が見せる
関連記事として、アカウント全体のチェックは AWS Trusted Advisor でアカウントのベストプラクティスを確認する、自分のリソースの監視は Amazon CloudWatch でメトリクスとアラームを設定する、コストの実績分析は AWS Budgets と Cost Explorer ── 使いすぎを見つけて予算アラートで止める で解説しています。
—
参照先
- とはAWS Compute Optimizer – AWS Compute Optimizer
- へのオプトイン AWS Compute Optimizer – AWS Compute Optimizer
- リソースの要件 – AWS Compute Optimizer
- EC2 インスタンスのレコメンデーションを表示する – AWS Compute Optimizer
- 拡張インフラストラクチャメトリクス – AWS Compute Optimizer
- AWS Trusted Advisor チェックリファレンス – AWS サポート
- コスト最適化 – AWS サポート
- 適切なサイズ設定に関する推奨事項によるコストの最適化 – AWS コスト管理
- Cost Optimization Hub による機会の特定 – AWS コスト管理
- とは AWS Health – AWS Health
- AWS Health ダッシュボード – AWS Health
- AWS Health ダッシュボードの開始方法 – AWS Health
- Amazon CloudWatch とは – Amazon CloudWatch
- Service Quotas とは何ですか。 – Service Quotas
- サービスクォータの表示 – Service Quotas
- クォータ引き上げのリクエスト – Service Quotas
- Service Quotas と Amazon CloudWatch アラーム – Service Quotas
- Amazon EC2 インスタンスタイプクォータ – Amazon EC2
- とは AWS License Manager – AWS License Manager
- Amazon Managed Service for Prometheus とは – Amazon Managed Service for Prometheus
- Amazon Managed Service for Prometheus で使用するための Amazon Managed Grafana のセットアップ – Amazon Managed Service for Prometheus
- Amazon Managed Grafana とは – Amazon Managed Grafana
