はじめに
SAA試験勉強のうちセキュリティ、モニタリング、コスト管理に関して、個人的に何度も忘れてしまうものや分かりにくいものをまとめていきます！
試験範囲を網羅しているわけでは全くありませんのでご注意を！
その他の範囲まとめはこちら↓
セキュリティ関連
Shield Advanced
DDoS攻撃防止のためのサービス。
保護対象はELB（ALB,NLB,CLB）
不特定のIPアドレスからのDDoS攻撃を予防するには、Shield Advancedを利用してShield Response Team（SRT)に協力を仰ぎ、攻撃の影響を軽減するコントロールを組み込むことが必要。
SRT：Shield Advancedユーザーに追加のサポートを提供する専門家チーム。
Security Lake
AWS環境、SaaS(Office365など)、オンプレからセキュリティログやイベントデータなどのセキュリティデータを一元的に集め、分析するためのフルマネージド型のセキュリティデータレイク。
セキュリティデータを自動的に収集し、S3に格納する。
Firewall Manager
複数のAWSアカウントやサービスを対象として、firewallのルールを一元的に設定・管理するサービス。
GWLB (Gateway Load Balancer)
AWS環境でファイアウォールや侵入検知／防御システムなどの仮想ネットワークアプライアンス（NVA）を効率的に導入・運用するためのサービス。
混同しやすいサービス↓
- Organizations：複数アカウントの管理やSCPによるアクセス権限制御。
- Config：AWSリソースの設定を管理する。
- Security Hub：AWS リソースのセキュリティベストプラクティスへの準拠やGuardDuty、Inspector、Macieなどのアラートを確認・判定する。確認・判定するのみで、直接的にセキュリティ設定や管理はできない。
GuardDuty
AWS環境における脅威検出を自動的に行うサービス。
異常なアクティビティや不審な挙動をリアルタイムで検出し、EventBridgeを使えばイベントとして処理することもできる。
WAFのルール更新をするLambda関数を実装すればWAFのルールを自動的に調整することも可能。
Inspector
脆弱性スキャンツール。
主にEC2インスタンスのセキュリティ評価に使われる。
GuardDutyはリアルタイムな脅威検出ができる。
Inspectorは（主に）EC2に使う脆弱性スキャンツール。
セキュリティグループとNetwork ACL
| 項目 | セキュリティグループ | Network ACL |
|---|---|---|
| 適用範囲 | インスタンス単位 | サブネット単位 |
| ルールタイプ | ステートフル（インバウンドを許可するだけでアウトバウンドも許可される） | ステートレス |
| デフォルトルール | 同じセキュリティグループ内通信のみ許可 | すべて拒否 |
| 設定方法 | 許可のみを指定 | 許可と拒否を指定 |
| 優先度 | ー | ルール番号が小さいほうが優先 |
| 柔軟性 | 高い（インスタンスごとに細かく設定できる） | 低い（サブネット全体に一律に適用） |
| 主な用途 | インスタンスレベルのセキュリティ、特定のアプリケーションへのアクセス制御 | サブネット全体のトラフィック制御、より広範囲なセキュリティポリシーの適用 |
トラフィックは、①ACLのルールに合致するかチェック → ②セキュリティグループのルールに合致するかチェック。両方のルールに合致した場合のみ通信が許可される。
Network ACLにおける記述内容について
Egress: trueはアウトバウンドの設定
Egress: falseはインバウンドの設定
Network Firewall
VPC向けのファイアウォール機能を提供するマネージドサービス。
ドメイン名によるトラフィックのフィルタリングなど、セキュリティグループやネットワークACLよりもさらに高度な機能を備えている。
モニタリング関連
(Systems Manager) Inventory
AWS環境内およびオンプレミス環境のマネージドインスタンスに関する情報を収集し、集中的に管理するためのサービス。
- AWSインスタンスのID、AMI ID、インスタンスタイプ、IPアドレス
- OS名、バージョン、パッチレベルなど
- インストールされているアプリケーション、バージョンなど
- ネットワークインターフェース、IP構成、DNSなどの情報
CloudTrail
CloudTrailログで取得できる内容は大きく分けて以下3つ
-
管理イベント
AWSアカウントのリソースに対して行われた管理操作に関する情報。
デフォルトで記録され、過去90日間分は無料でCloudTrailコンソールから取得できる。- EC2インスタンスの起動・停止・終了
- IAMユーザー、グループ、ロールの作成・変更・削除
- S3バケットの作成・削除・ポリシーの変更
- セキュリティグループのルール変更
- CloudTrail自体の設定変更
など
-
データイベント
リソース内のデータに対して行われた操作に関する情報。
デフォルトでは記録されない。リソースごとに記録を有効化する必要があり、有料。- S3バケット内のオブジェクトのアップロード、ダウンロード、削除など
- Lambda関数の実行
- DynamoDBテーブルの読み取り・書き込み・削除など
-
インサイトイベント
AWSリソースの使用状況における異常なアクティビティを自動的に検出する機能。
デフォルトでは記録されず、追加料金が発生する。- 特定のAPIコールの異常な増加
- 特定のユーザーによる通常とは異なる時間帯のAPIコール
CloudWatch
CloudWatchアラーム
CloudWatchアラームでは、アラーム発報時のアクションも設定できる。
例えば、EC2インスタンスのステータスチェックをしていた場合、異常を示すアラームを発報した際に、EC2自動復旧のアクションを取ることができる。
Cloud Watch Logs
サブスクリプションフィルターでデータの転送先を設定できる。
例えば、OpenSearch ServiceやKinesis、Lambdaに直接ストリーミング可能。
CloudWatch Container Insights
ECS、EKSにCloudWatch Container Insightsを設定することで、コンテナ化されたアプリケーションとマイクロサービスのメトリクスとログを収集して可視化できる。
CPUやメモリの使用率、タスク数、サービス数などを確認できる。
クロスアカウントオブザーバビリティ
複数のAWSアカウントに分散しているCloudWatchのデータを、単一のモニタリングアカウントで集約して可視化・分析するための機能。
設定方法
-
モニタリングアカウントの設定
モニタリングアカウントでオブザーバビリティ設定を作成する -
ソースアカウントの設定
各ソースアカウントで、モニタリングアカウントへのアクセスを許可する設定をするこのアクセス許可の設定はCloudFormationテンプレートを使うことで自動化できる。
CloudFormationテンプレートを各ソースアカウントにデプロイすることで、必要なIAMロールとポリシーが自動的に作成される。
3.オブザーバビリティリンクの確立
ソースアカウントとモニタリングアカウント間でオブザーバビリティリンクを確立する
AWS/Events名前空間
EventBridge関連のメトリクスを確認できる。
EventBridgeルール、ターゲットのパフォーマンスや動作を監視するためのメトリクスが含まれている。
Eventルールがトリガーされているか、エラーが発生していないかを確認したり、パフォーマンスを確認したりできる。
VPCフローログ
ネットワークトラフィックを取得し、CloudWatchでモニタリングできるようにする。
- ネットワークインターフェースを送信元／送信先とするトラフィックが対象
- セキュリティグループとネットワークACLのルールでaccepted/rejectされたトラフィックログを取得する
- キャプチャウィンドウと言われる時間枠(約10分)で収集
- RDS、Redshift、ElastiCashe、WorkSpacesのネットワークインターフェーストラフィックも取得可
- 追加料金なし
例えば、EC2インスタンスのネットワークインターフェースに対するVPCフローログを有効化することで、EC2インスタンスのネットワークインターフェースを行き来するIPトラフィック情報をキャプチャできる。
→ このデータをCloudWatchLogsに集約することで、EC2インスタンスへのトラフィックログを中央管理できる。
OpenSearchServiceとの連携
さらに、OpenSearchServiceとも連携すると、より詳細は検索や分析、可視化が可能になる。
OpenSearchServiceと連携する場合には、VPCフローログ取得に関する基本設定をCloudWatchLogsで行い、
FirehoseでVPCフローログをOpenSearchServiceに配信する設定を行う。
Firehoseを使うことで、VPCフローログのデータを効率的にOpenSearchServiceに配信することができる。
X-Ray
マイクロサービスアーキテクチャのアプリケーションなど、分散アプリケーションを分析およびデバッグできるようにするサービス。
- リクエストの流れを追跡できる（サービスマッピングにより地図のように可視化される）
- ボトルネックを見つける
- エラー原因を特定する
Compute Optimizer
コンピューティングリソースの設定と使用状況を分析し、コスト最適化とパフォーマンス向上のための推奨事項を提案する。
EC2、AutoScalingグループ、EBSボリューム、Lambda関数、ECS（Fargate使用）
Workload Discovery on AWS
ワークロードを可視化するためのツール。
自動的に詳細なアーキテクチャ図を生成することができる。
アーキテクチャの可視化による理解やトラブルシューティング、監査とコンプライアンス要件に準しているかどうかの確認などに活用できる。
Budgets
AWSの各サービスの使用状況を監視し、設定した金額や使用状況のしきい値に近づいたり、超えた場合にアラートやアクションを実行するサービス。
メールやSNSのほか、Slack等でもアラートを受け取れる。
アクションとしては、特定のインスタンスの停止設定や、IAMポリシーやSCPの付与によるリソースの制御が可能。
例えば、Organizationsで新たなリソースのプロビジョニングを制限するSCPを設定し、Budgetsによって予算の閾値を超えたときに、そのSCPを自動的に付与できる。
コスト管理
Cost Anomaly Detection
機械学習を用いてAWSの利用料金における異常な支出を自動的に検出し通知するサービス。
通常とは異なる支出パターンを異常とみなすため、予期せぬコスト増加に早く気付くことができる。
Budgetsと連携することで、Budgetsの基本機能である予算超過だけでなく、予算内での異常な支出も検出できる。
Budgetsはあくまでも予算に基づいてアラートを送信するが、
Cost Anomaly Detectionは過去の実績に基づいて異常を検出する。
コスト配分タグ
- AWS定義のコスト配分タグ
- AWSが自動的に生成するタグ
-
aws:というプレフィックスが付く（ex.aws:createdBy)
- ユーザー定義のコスト配分タグ
- ユーザーが自由に作成できるタグ
- タグキーとタグ値のペアで構成される（ex:
Project:ProjectA,Department:Sales) - 部門ごと、プロジェクトごとにコストを把握したい場合に使う
Savings Plans
対象となるサービス：EC2、Lambda、Fargate
1年または3年の期間で一貫したコンピューティング使用量を契約する代わりに低額の料金で使用できる料金モデル。
Savings Plansには以下2つのタイプがある。
- Compute Savings Plans
最も優れた柔軟性を提供し、コストを最大66%削減できる。
リージョン、インスタンスファミリー、インスタンスサイズやOSなどに関わらず、約束したコンピューティング使用量に対して割引が適用される。 - EC2 Instance Saving Plans
料金が最も低く、リージョン内の個々のインスタンスファミリーの契約と引き換えに、最大72%の節約を提供。
プラン購入時にリージョンとインスタンスファミリーを指定する必要がある。
SageMakerにはSageMaker用の「SageMaker Savings Plans」がある
Cost and Usage Reports と Cost Explorer
どちらもコストの可視化と分析に使用するもの。違いは以下の通り。
| - | Cost and Usage Reports | Cost Explorer |
|---|---|---|
| データ詳細度 | 非常に詳細 (時間, 日単位) | 概要レベル |
| データ形式 | CSVファイル（S3に保存） | 視覚的なインターフェース（AWSコンソール） |
| カスタマイズ性 | 高い | 低い |
| 使いやすさ | 分かりやすく分析・可視化するには、CSVファイルをAthenaやQuickSightを使う必要がある | 視覚的で分かりやすい |
| 適した用途 | 詳細なコスト分析、カスタムレポート作成、コスト最適化のための詳細データ | コストの概要把握、慶応分析、コスト予測 |
リザーブド購入オプションによる割引ができるもの
- EC2リザーブドインスタンス
- RDSリザーブドインスタンス
- ElastiCacheリザーブドキャッシュノード
- DynamoDBリザーブドキャパシティ
- Redshiftリザーブドノード