AWS SAA(Solutions Architect - Associate)対策
適正サイズ化
このレッスンでできるようになること。「過剰なリソースに払い続けている」という要件文に対して、勘ではなくデータに基づいた是正策を選べるようになります。
要件の文から入る
ある会社が、数年かけて増えた数百台の EC2 とアタッチされた EBS を抱えています。請求は増え続けているのに、担当者は「どのインスタンスが余っているのか分からない」と言っています。まず何をしますか。運用の手間はできるだけ増やしたくありません。
答えは AWS Compute Optimizer を有効にして、その推奨を根拠にダウンサイジングするです。ここで効いている要件語は「どれが余っているか分からない」です。この文が出たら、答えは削減の実行ではなく、まず可視化と推奨の取得になります。いきなり「全インスタンスを 1 段小さくする」という選択肢は、根拠が無いので落ちます。
3 つの道具の役割分担
コスト最適化の文脈で並びやすいサービスは、見ているものが違います。
| 何を見るか | どんな答えを返すか | 典型的な出題 | |
|---|---|---|---|
| Compute Optimizer | CloudWatch のメトリクス履歴 | EC2 や Auto Scaling グループ、EBS、Lambda に対する具体的な推奨サイズ | 「過剰なリソースを特定したい」 |
| Trusted Advisor | アカウント全体の設定と利用状況 | 使われていないリソースやセキュリティ、上限などの横断チェック | 「アイドルなリソースを洗い出したい」 |
| Cost Explorer | 請求データの履歴 | どのサービス、どのタグに費用が寄っているかの内訳と予測 | 「どこに費用がかかっているか知りたい」 |
順番で言うと、Cost Explorer が「どの分野が高いのか」を示し、Compute Optimizer が「そのうちどのリソースをどう変えるか」を示し、Trusted Advisor が「そもそも使われていないものはないか」を拾います。試験では推奨サイズを出すのは Compute Optimizer という結びつきが最も問われます。
メモリを根拠にできるかという分岐
適正サイズ化でつまずくのは、EC2 の標準メトリクスにメモリ使用率が含まれていない点です。CPU、ネットワーク、ディスクの入出力はハイパーバイザー側から見えますが、メモリの使用量はゲスト OS の中の話なので、標準では取れません。
メモリを根拠に判断したいなら、CloudWatch エージェントを入れてカスタムメトリクスとして送る必要があります。Compute Optimizer もエージェントが入っていればメモリを加味した推奨を出せます。「メモリが余っているのに大きなインスタンスを使い続けている」という要件文が出たら、まずエージェントの導入が前提条件になります。この点は次の監視のレッスンでもう一度出てきます。
適正サイズ化の打ち手
是正の方向は 1 つではありません。要件文がどれを求めているかで答えが変わります。
- インスタンスを 1 段小さくする。負荷が常に低いときの基本形です
- 新しい世代のファミリーへ載せ替える。同じ性能をより低い費用で得られることが多い方向です
- 台数を減らして Auto Scaling に任せる。負荷に波があるときはこちらです
- 夜間や休日に止める。開発環境やテスト環境という語が出たらこれです
- EBS を gp2 から gp3 へ、または不要なスナップショットとアタッチされていないボリュームを削除する
要件語から構成への対応表
| 要件文の言い回し | 選ぶもの |
|---|---|
| どのリソースが過剰か特定したい | Compute Optimizer の推奨 |
| 使われていないリソースを洗い出したい | Trusted Advisor のチェック |
| どのサービスに費用が寄っているか知りたい | Cost Explorer |
| メモリ使用率を根拠にしたい | CloudWatch エージェントを導入してから判断する |
| 開発環境の夜間と休日の費用を減らしたい | スケジュールによる停止、または Auto Scaling のスケジュールアクション |
| 負荷に波があり平均は低い | インスタンスを小さくするより Auto Scaling で台数を追従させる |
| 予算を超えたら気づきたい | AWS Budgets のアラート |
よくある引っ掛け
1 つめは、負荷に波があるワークロードに対して「一律にダウンサイジングする」を選んでしまうものです。平均が低くてもピークで足りなくなれば要件を満たしません。波があると書かれていたら、答えはサイズではなく台数です。
2 つめは、メモリ不足やメモリ過剰の判断を CloudWatch の標準メトリクスだけで行おうとするものです。標準では取れないので、エージェントの導入が抜けた選択肢は成立しません。
まとめ
- 「どれが過剰か分からない」と書かれたら、削減の実行ではなく Compute Optimizer での可視化が先です
- Compute Optimizer は推奨サイズ、Trusted Advisor は未使用の洗い出し、Cost Explorer は費用の内訳です
- EC2 の標準メトリクスにメモリは含まれません。CloudWatch エージェントが前提になります
- 負荷に波があるなら、サイズを下げるのではなく Auto Scaling で台数を追従させます
- 開発環境という語が出たら、停止スケジュールが有力な答えになります
復習ミニクイズ
ある企業が数百台の EC2 を運用しており、請求が増え続けています。ワークロードの負荷は日中と夜間で大きく変動し、担当者は「どのインスタンスが過剰なのか分からない」と述べています。メモリ使用率も判断材料にしたいという要望があります。最初に取るべき対応として最も適切なのはどれですか。