どーも！shihopowerです！
今回はAWSの「分析・最適化」系サービス・機能の差分についてまとめます。
AWS SAAやSAP対策をしていると、S3 InventoryやS3 ストレージクラス分析、S3 Storage Lensのような名前も目的も似ているサービスが選択肢に並んでいて、どう見分ければいいのか迷った経験はありませんか？
こういった問題を解くカギは2つあると思っています。
- 各サービス・機能の「得意なこと／苦手なこと」を押さえておくこと
- 選択肢を絞るときの判断軸を持っておくこと
本記事では実際に試験で混同しやすいグループを7つのカテゴリに分けて整理します。同じくSAAやSAP対策をしている方の参考になれば幸いです！
1. まず持っておきたい4つの判断軸
試験で似たサービスが並んだときに迷わないよう、問い方のフレームを先に持っておきます。
| 軸 | 問い |
|---|---|
| ① 何を分析したいか | コスト？ストレージ？セキュリティ？パフォーマンス？ |
| ② どの粒度で見たいか | 組織全体？アカウント？バケット単体？オブジェクト単体？ |
| ③ いつの情報か | リアルタイム？履歴・トレンド？将来予測？ |
| ④ 誰がどう使うか | 画面でインタラクティブに？生データを自分で加工？他ツールに連携？ |
この4軸を頭に置いた上で、カテゴリ別の差分を見ていきましょう。
2. カテゴリ別サービス差分まとめ
2-1. ストレージ最適化系（S3）
S3の管理・分析機能はそれぞれ役割が明確に分かれています。
| サービス・機能 | 一言で言うと | 詳細 |
|---|---|---|
| S3 Inventory | 棚卸し・一覧リスト | オブジェクトのメタデータ（暗号化状態・レプリケーション状態など）をCSV/ORC/Parquet形式で日次・週次に出力。監査・コンプライアンス用途向け |
| S3 ストレージクラス分析 | 単体バケットのアクセスパターン分析 | Standard→Standard-IAへの移行判断を支援。バケット単位またはプレフィックス・タグ単位で設定が必要。結果が出るまで30日以上かかる |
| S3 Storage Lens | 組織全体のストレージトレンド分析 | マルチアカウント・マルチバケットを横断した統合ビューを提供。無料メトリクスは14日間、高度なメトリクス（有料）にアップグレードすると15か月分のデータを分析可能 |
⚠️ 混同しやすいポイント：S3 ストレージクラス分析 vs S3 Storage Lens
どちらも「ストレージコストの最適化」に使えるサービスですが、分析できる範囲に決定的な違いがあります。
- S3 ストレージクラス分析：バケットごとに個別設定が必要で、組織全体を横断した分析はできない。また移行推奨はStandard→Standard-IAのみ
- S3 Storage Lens：最初からマルチアカウント・マルチバケットの統合ビューを持ち、高度なメトリクスで移行すべきバケットや、ライフサイクルルールが未設定のバケットまで特定できる
「複数のS3バケット」「組織全体のトレンド」を分析したい場合は、S3 Storage Lensが適切です。
2-2. コスト最適化系
「コスト系」のサービスは用途が重なって見えますが、それぞれ役割が異なります。
| サービス | 一言で言うと | 詳細 |
|---|---|---|
| AWS Cost Explorer | コストの可視化・予測 | コンソール上でインタラクティブに操作。過去13か月のデータ表示と今後18か月の予測が可能。Reserved Instancesの購入推奨も提供 |
| AWS Cost and Usage Reports（CUR） | 生データの出力 | AWSコストと使用量に関する最も包括的なデータセット。S3バケットに定期エクスポートし、Athena・QuickSight・Redshiftなどで自分で加工・分析する |
| AWS Trusted Advisor | ベストプラクティス全般チェック | コスト最適化・セキュリティ・信頼性・パフォーマンス・サービス制限の5分野を広くチェック。深いストレージトレンド分析はできない |
| AWS Compute Optimizer | コンピューティングのサイジング推奨 | EC2・Auto Scaling・Lambda・EBS・ECS on Fargateを対象に、機械学習で過去の使用状況を分析し、最適なリソース構成を推奨 |
引っかけポイント
Trusted Advisorは「コスト削減の推奨もする」サービスですが、S3 Storage Lensのような詳細なストレージアクセスパターン分析は行いません。コスト系の問題でTrusted Advisorが選択肢に出てきたら、それが求められている「分析の深さ」に対応できるかを必ず確認しましょう。
2-3. セキュリティ分析系
セキュリティ系のサービスは「何を見ているか」で明確に区別できます。
| サービス | 一言で言うと | 詳細 |
|---|---|---|
| Amazon Macie | S3内の機密データ検出（データの中身） | 機械学習とパターンマッチングで、S3オブジェクト内のPII（個人情報）や財務情報などの機密データを自動検出。データプライバシー・コンプライアンス用途 |
| IAM Access Analyzer for S3 | バケットのアクセス権限分析（設定を見る） | バケットポリシーを分析し、外部エンティティからアクセス可能なリソースを特定。意図しない外部公開や不適切な権限設定を検出する |
| Amazon GuardDuty | 脅威検出（異常な行動・不審な通信） | 機械学習・異常検出・脅威インテリジェンスを使い、AWSアカウント・ワークロード・データへの悪意あるアクティビティを継続的に監視 |
| Amazon Inspector | 脆弱性診断（ソフトウェアの弱点） | EC2・Lambda・ECRコンテナイメージに対してソフトウェアの脆弱性と意図しないネットワーク露出を継続的にスキャン |
| Amazon Detective | セキュリティインシデントの根本原因調査 | GuardDutyなどが検出したアラートについて、データの可視化・グラフ分析を通じて根本原因を調査する。「検出する」のではなく「調査する」ツール |
| AWS Security Hub | セキュリティサービスの統合管理 | GuardDuty・Inspector・Macie・IAM Access Analyzerなど複数のサービスのファインディングを一元集約・管理 |
混同しやすいペア
- Macie vs Access Analyzer：どちらもS3に関係するが、Macieは「データの中身（機密情報）」、Access Analyzerは「アクセス権限の設定（外部公開）」を見る
- GuardDuty vs Detective：GuardDutyが「脅威を検出する」のに対し、Detectiveは「検出された脅威を調査する」補完関係にある
- Inspector vs GuardDuty：Inspectorは「既知の脆弱性（ソフトウェアの弱点）」、GuardDutyは「実際の脅威・異常行動」を対象にする
2-4. 監視・モニタリング系
「ログ・監視系」は特に混同しやすいグループです。「何を記録しているか」で区別します。
| サービス | 一言で言うと | 詳細 |
|---|---|---|
| Amazon CloudWatch | パフォーマンスの監視・アラート | メトリクス・ログ・アラームによるシステムの運用健全性の監視。「今何が起きているか」をリアルタイムで把握する |
| AWS CloudTrail | APIコール履歴の記録・監査 | ユーザー・ロール・AWSサービスが行ったアクションをイベントとして記録。「誰が何をしたか」の証跡を残す |
| AWS Config | リソース設定の変更履歴とコンプライアンス評価 | リソースの構成とリソース間の関係を詳細に記録し、時系列での変化を追跡。設定ルールへの準拠状況を評価する |
| Amazon EventBridge | イベント駆動のルーティング・自動化 | AWSサービスやアプリケーションからのイベントを受け取り、ルールに基づいてターゲットへルーティングする |
3サービスの整理
CloudWatch ：「今の状態」を監視する（メトリクス・ログ・アラート）
CloudTrail ：「誰が何をしたか」を記録する（APIコール・操作履歴）
Config ：「設定がどう変わったか」を追跡する（構成変更・コンプライアンス）
2-5. データ分析・BI系
データ分析系は「処理のどのステップを担うか」で整理すると分かりやすくなります。
| サービス | 一言で言うと | 詳細 |
|---|---|---|
| Amazon Athena | S3上のデータをSQLで直接クエリ | サーバーレスのインタラクティブクエリサービス。S3にあるデータをそのままSQLで分析できる。スキャンしたデータ量に応じた従量課金 |
| Amazon Redshift | データウェアハウス | 大規模な構造化データの分析に特化。あらかじめデータを投入して低レイテンシのクエリを実行。ダッシュボード用途などに向く |
| AWS Glue | ETL（データの抽出・変換・ロード） | フルマネージドのETLサービス。データのクローリング・変換・カタログ管理を担い、分析の前段階でデータを整形する |
| Amazon EMR | Hadoop/Sparkによる大規模バッチ処理 | 大量データを分散処理するためのマネージドクラスターサービス。ETLや機械学習など複雑な処理に利用 |
| Amazon QuickSight | BIダッシュボード・可視化 | データを可視化してダッシュボードやグラフを作成するBIツール。他のデータソースに接続して使う |
| Amazon Kinesis | リアルタイムストリームデータの収集・処理 | ストリーミングデータをリアルタイムで収集・処理・分析する |
混同しやすいペア
- Athena vs Redshift：Athenaは「S3にあるデータをそのままクエリ（サーバーレス・従量課金）」、Redshiftは「データを投入してウェアハウスとして運用（低レイテンシ・常時稼働）」
- Glue vs Athena：Glueは「データを加工・整形する（ETL）」前処理、Athenaは「整形済みデータをクエリする（分析）」という流れで使われることが多い
- Kinesis vs EMR：Kinesisは「リアルタイムのストリーム処理」、EMRは「バッチ処理」
2-6. コンピューティング最適化系
コスト系と混同しやすい「コンピューティング最適化」系を整理します。
| サービス | 一言で言うと | 詳細 |
|---|---|---|
| AWS Compute Optimizer | EC2等のサイジング推奨 | 機械学習を使って過去の使用状況メトリクスを分析し、EC2・Auto Scaling・Lambda・EBS・ECS on Fargateの最適なリソース構成を推奨 |
| Amazon EC2 Auto Scaling | 負荷に応じた自動スケール | 最適化ではなく、需要に応じてリソースを自動的に増減させる自動化の仕組み |
Compute Optimizerが「今のリソースが適切か推奨する」ツールであるのに対し、Auto Scalingは「自動でスケールさせる仕組み」であり、用途が異なります。
2-7. ネットワーク分析系
| サービス | 一言で言うと | 詳細 |
|---|---|---|
| VPC Flow Logs | VPC内のIPトラフィックの記録 | VPCのネットワークインターフェースを通過するIPトラフィックの情報をキャプチャしてログに記録する |
| VPC Reachability Analyzer | 特定の通信経路が到達可能か検証 | ネットワーク構成を分析し、送信元から送信先への通信が到達可能かどうかを確認する。実際にパケットを送らずに検証できる |
| AWS Network Manager | WAN・拠点間ネットワークの監視 | グローバルネットワーク（Transit Gateway・Site-to-Site VPN・Direct Connect等）を一元的に監視・管理する |
3. 実際の試験問題で判断軸を使ってみる
ここで、実際に私が試験対策をしていて出会った問題をもとに、判断軸をどう使うかを確認してみます。
問題のシチュエーション（ぼかして要約）
複数のS3バケットを運用する企業で、コストが増加傾向にある。過去1年間のデータトレンドを分析し、各オブジェクトに適したストレージクラスを特定したい。
選択肢には以下のようなサービスが並んでいました。
- A：Cost and Usage Reports + Trusted Advisor
- B：S3 ストレージクラス分析 + QuickSight
- C：S3 Storage Lens（高度なメトリクスにアップグレード）
- D：IAM Access Analyzer for S3
判断軸で絞ってみる
① 何を分析したいか？
→ ストレージコストの最適化、具体的にはストレージクラスの見直し
→ DのAccess Analyzerはセキュリティ（アクセス権限）のツールなので即除外
② どの粒度で見たいか？
→ 「複数のS3バケット」とあるので、単一バケットではなく横断的なビューが必要
→ Bのストレージクラス分析はバケット単位で個別設定が必要で、組織全体の横断ビューがないため不向き
③ いつの情報か？
→ 「過去1年間のトレンド」が必要
→ AのCost and Usage Reportsは請求データは取れるが、ストレージクラスのアクセスパターン分析には不向き。Trusted AdvisorもStorage Lensほどの詳細なストレージトレンド分析は行わない
→ CのS3 Storage Lensは高度なメトリクスにアップグレードすることで15か月分のデータを分析でき、過去1年のトレンドを十分カバーできる
④ 誰がどう使うか？
→ ダッシュボードで分析したい
→ S3 Storage Lensはコンソール上のインタラクティブなダッシュボードを標準で持っている
→ 正解はC
このように4つの判断軸を順番に当てはめると、根拠を持って選択肢を絞り込めます。
4. まとめ
カテゴリをまたいで使える判断軸は以下の通りです。
「何を」分析したいか
└ ストレージ → S3系（Inventory / ストレージクラス分析 / Storage Lens）
└ コスト全体 → Cost Explorer / CUR / Trusted Advisor / Compute Optimizer
└ セキュリティ → Macie / Access Analyzer / GuardDuty / Inspector / Detective
└ 運用監視 → CloudWatch / CloudTrail / Config
「どの粒度」か
└ 組織全体・横断 → Storage Lens / Cost Explorer / GuardDuty / Security Hub
└ 個別リソース・単体 → ストレージクラス分析 / Inspector / VPC Reachability Analyzer
「いつの情報」か
└ リアルタイム → CloudWatch / GuardDuty / Kinesis
└ 履歴・トレンド → Storage Lens（15か月）/ CloudTrail / Config / Cost Explorer（13か月）
└ 将来予測 → Cost Explorer（18か月予測）/ Compute Optimizer
「誰がどう使うか」
└ 画面で確認 → Cost Explorer / Storage Lens / QuickSight
└ 生データを加工 → CUR / S3 Inventory / Athena
└ 他サービスに統合 → Security Hub / EventBridge
似たサービスが選択肢に並んでいても「何のために・どの粒度で・いつの情報を・どう使いたいか」を一つずつ当てはめることで、正解に近づけると思います。
SAAやSAP対策の参考になれば幸いです！
参考URL
ストレージ最適化系
- Cataloging and analyzing your data with S3 Inventory - Amazon S3
- Amazon S3 analytics – Storage Class Analysis - Amazon S3
- Monitoring your storage activity and usage with Amazon S3 Storage Lens - Amazon S3
- Viewing metrics with Amazon S3 Storage Lens - Amazon S3
- Using Amazon S3 Storage Lens to optimize your storage costs - Amazon S3
コスト最適化系
- Analyzing your costs and usage with AWS Cost Explorer - AWS Cost Management
- AWS Cost and Usage Report - Amazon EC2 Reserved Instances and Other AWS Reservation Models
- AWS Compute Optimizer Documentation
セキュリティ分析系
- Monitoring data security with managed AWS security services - Amazon S3
- How Detective is used for investigation - Amazon Detective
- Choosing AWS security, identity, and governance services - AWS
監視・モニタリング系
- AWS CloudTrail or Amazon CloudWatch? - AWS Decision Guide
- Choosing an AWS monitoring and observability service - AWS Decision Guide
データ分析・BI系