【事前知識】

【リソース＝サービス】
AWSが所有する資産（リソース）を指している（？）
AWS自体、AWS社の資産をレンタルすることで、ユーザーがサービスを展開することができる、クラウドサービス。

【インシデント理念】
AWSにおけるインシデント対応では、以下2つの考え方がある。
●予防的統制
想定されるリスクが発現することを事前に予防。

●発見的統制
想定外のリスクの発現を検知して即座に対応する

• アクセスログ
  リクエストを受け取った時刻、クライアントのIP、レイテンシー、リクエストのパスなどの情報を提供。

通知サービス

SES

※SES(Simple Email Service)

Eメールサービス※SMS配信はできない

SNS

※SNS(Simple Notification Service)

メッセージ通知サービス。
Lamda , SQS , HTTP/S , Email , SMS、を対象とする。

※GuardDutyの検出結果を直接受け取ることはできない。

• トピック（Pub/Subシステム）
  メッセージを送信し、受信するためのアクセスポイント。
  情報を管理する単位。

• メッセージの配信(パブリッシュ)
  SNSをサブスクライバへ配信する。

• 購読者(サブスクライバ)
  メッセージの購読者。

〇処理方法

メッセージキューイング	バッチのような非同期かつ並列な分散処理が可能になる。
パイプライン	DBからデータを取り出し、順次処理する。
ストリーミング	リアルタイムに流れてくるものを処理する。

PinPoint
【カスタマー向け通知】

顧客とのエンゲージメントを管理するサービスであり、テキストメッセージによりアンケートの送信に適している。
Eメール、音声、プッシュ通知、SMSといった様々な媒体が使用できる。

Service Quotas
【クォータ使用率管理】

多くの AWS のサービスクォータの使用率などを 1 か所から確認、管理できるようにする。
クォータ値を確認できるだけでなく、Service Quotas コンソールからクォータの引き上げをリクエストすることもできる。

●クォータ
適用できるサービスリソースまたはオペレーションの最大数。
リージョンごとに作れるサブネットの数だったり、VPCごとのサブネットに制限がある。
[クォータの緩和リクエスト]

※今までサポートセンターに連絡し、緩和申請をしていたが、ダッシュボードから現在の適応状況や申請履歴などを確認できる。

【リソースの現在の使用率を表示 】
アカウントが一定期間アクティブになったら、リソース使用率のグラフを表示できる。

Service Health Dashboard
【災害規模】

AWSサービス全般のステータス（リージョン規模の障害など）を表示するサービス。

Personal Health Dashboard
【メンテナンス・イベント】

AWSによって予定されたメンテナンスを確認することができる。また、それによるユーザーへの影響を確認できる。

・Cloud Watch Eventsと統合が可能

• AWS Health API
  【基盤サービス】
  Healthデータや通知を既存の運用ダッシュボードと統合できる。
  すべてのユーザーは AWS Health API による Personal Health Dashboard を使用できる。

EC2関係

モニタリング
【ステータス】

• 基本モニタリング
  メトリクスはすべて 5 分間隔で利用できる。料金は発生しない。
  ただし、ステータスチェックメトリクスに限り 1 分間隔で利用。

• 詳細モニタリング
  ステータスチェックメトリクスを含むすべてのメトリクスは、1 分間隔で利用できる。
  ※このレベルのデータを取得するには、インスタンスのデータ取得を明確に有効にすること。
  
  ・単一のリージョン内のすべてのEC2の統計を集計することもできる。
  ・料金は、CloudWatch に送信されるメトリクスごとに発生。
  ※データストレージに対しては料金が発生しない

インスタンスコンソール出力
【トラブルシューティング】

カーネルの問題やサービス設定の問題のトラブルシューティングを行うなど問題を診断する。

※問題が発生すると、SSH デーモンの開始前にインスタンスが停止したり、インスタンスに到達不能になる可能性がある。

インスタンスを選択してから、
[アクション]→[モニタリングとトラブルシューティング]→[システムログを取得] を選択。

VPCフローログ
【トラフィック】

VPC のネットワークインターフェイスとの間で行き来する IP トラフィックログ情報を取得する。
(※送信元・送信先アドレスとポート、プロトコル番号など)

・VPCフローログレコードはデフォルトでは最大の集約間隔が10分に設定されており、その期間内に集約される。

※AutoScalling で増減したインスタンスの情報取に対応はできない

※既存のフローログは修正できない

●Apache Parquet形式
列指向のストレージ形式により、高い圧縮率と高速なクエリ性能を実現。Amazon Athenaなどで使用することで、I/Oコスト削減やクエリ時間の短縮に寄与。

・データパーティショニング
データにパーティションを設定することで、クエリ実行時のスキャン範囲を限定。必要なデータだけを読み込むため、クエリ応答時間を短縮。
→ クエリ実行時に不要なデータを読み込まずに済むため、パフォーマンス向上 & コスト削減。

【VPCネットワークトラフィックのログはファイルサイズが大きくなりがち】
Parquetを使用することで：
・クエリ実行の高速化とスキャンデータ量の最小化を実現
・S3ストレージコストを最大25％削減
・Athenaなどの分析で、不要なデータをスキップ

◇収集できる情報

[情報を展開する]

version	フローログのバージョン（例：2）
account-td	AWSアカウントID
Interface-id	ネットワークインターフェイスID（eni-で始まる）
srcaddr / dstaddr	送信元 / 宛先 IP アドレス
srcport / dstport	送信元 / 宛先 ポート番号
protocol	使用されたプロトコル（TCP: 6, UDP: 17など）
packets / bytes	パケット数 / バイト数
start / end	通信の開始 / 終了時間（UNIXエポック形式）
action	通信の許可/拒否（ACCEPT / REJECT）
log-status	ログ記録のステータス（OK / NODATA / SKIPDATA）

Cloud Trail
【APIの履歴】

AWSインフラストラクチャ全体のアカウントアクティビティが出力される。
AWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うサービス。
（※いつ、どのユーザーが、何に、何をしたか）

・AWS APIで実行されたアクション(使用履歴)を「管理イベント/操作イベント」に記録する。

・Cloud Watch Eventsと統合されており、分析用途には使えない。

・IPアドレスはログに出力されない。

【ファイル整合性機能】

CroudTrailファイルが改変されていないか、「ダイジェストファイル」を作成して、整合性をチェックできる。

• CloudTrail Lake
  【SQL ベースのクエリ】
  イベントに対して SQL ベースのクエリを実行することができる。イベントはイベントデータストアに集約される。
  コンプライアンススタックを補完し、ほぼリアルタイムのトラブルシューティングを支援する監査ソリューション。
  
  ・ORC は、データをすばやく取得できるように最適化された列指向ストレージ形式。
  
  ●イベントデータストア
  高度なイベントセレクターを適用することによって選択する条件に基いたイベントのイミュータブルなコレクション。
  
  ●イベントデータ
  イベントデータストアに以下の通り保持できる。
  最大 3,653 日 (約 10 年)：[1 年間の延長可能な保存料金] オプションを選択した場合
  最大 2,557 日 (約 7 年間)：[7 年間の保存料金] オプションを選択した場合

【管理イベント/データ（操作）イベント】

• 管理イベント
  デフォルトの設定。
  証跡は AWS のサービス全体で管理イベントをログに記録し、無料で利用できる。

• データイベント
  【リソースに対して】
  AWS アカウントのリソースで、またはリソース内で実行されたリソースオペレーションを示す。
  データイベントログ記録を有効にするには、サポートされているリソースまたはリソースタイプを証跡に明示的に追加する必要がある。
  
  下記、S3 のバケットおよびオブジェクトレベルのリクエストに関する情報を取得できる。
  ・呼び出し元のAWSアカウント
  ・呼び出し元のIAMユーザーロール
  ・API呼び出しの時間
  ・APIのIPアドレスの追跡…etc

〇ログの保存

APIの呼び出し記録を証跡として作成（ログの保存）する。
証跡を管理アカウントに設定することで他アカウントの証跡を一元的に管理できる。

【保存先】
自動的に「S3バケット」、「Cloud Watch logs」に配信する。デフォルトで過去90日分の情報を残す(集中管理することが可能)。

・ログを出力する際、宛名テーブルを使用するとS3Athenaと連携できる。

・ログが改変されていないか、検証・確認できる

※デフォルトではデータのイベントロギングは無効になっているため、設定が必要

【CloudTrailログファイルの保護ポイント】

• S3 Server Side Encryption（SSE）: CloudTrailログはデフォルトでS3内で暗号化される。
• IAM/S3ポリシー: アクセス権限を細かく制御可能。
• MFA Delete（多要素認証削除）: 削除操作に追加の認証ステップを導入し、誤操作や悪意ある削除を防止。

CloudWatch
【リソース状況の監視】

AWS上で稼働するシステム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について収集・監視・可視化。
Billingの設定から、CloudWatchでアラームを設定することで、Cloud Watchのアラートを受け取れるようになる。

• 基本モニターリング
  データは自動的に 5 分間隔で取得される。料金は発生しない。

• 詳細モニターリング
  データは 1 分間隔で取得される。このレベルのデータを取得するには、インスタンスのデータ取得を明確に有効にする必要がある。詳細モニタリングを有効にしたインスタンスでは、同様のインスタンスグループの集約データを取得もできる。料金はCloudWatch に送信されるメトリックスごとに発生します。データストレージに対しては料金が発生しない。

・詳細度が1分のデータを含む、標準の解像度

・詳細度が1秒のデータを含む、高解像度

• Metric Math
  複数のメトリクスを組み合わせて新しく情報を生成するためのツール。
  CloudWatch メトリクスに対して数式を使って新しい時系列データを作成・分析できる機能です。複数のメトリクスを組み合わせて、より意味のある指標を導き出すのに役立つ。
  CloudWatch メトリクスに対して 四則演算や統計関数を適用可能
  結果は グラフ表示やアラーム条件に利用できる
  複数メトリクスの合成や、カスタム指標の作成が可能

• procstat プラグイン
  個別のプロセスからメトリクスを収集できる。
  Linux サーバーと、Windows Server 2012 以降を実行するサーバーでサポートされる。

●クロスアカウントオブザーバビリティ（Cross-Account Observability）
複数の AWS アカウントにまたがる監視データ（メトリクス・ログ・トレースなど）を一元的に可視化・分析できる CloudWatch の機能。

• 複数アカウントの CloudWatch データを1つのアカウントで集中管理できる。
• 監視用の「モニタリングアカウント」と、データを提供する「ソースアカウント」をリンクする。
• AWS Organizations を使えば自動連携も可能。

【共有できるデータの種類】
・CloudWatch Internet Monitor のデータ
・CloudWatch メトリクス
・CloudWatch Logs（ロググループ）
・AWS X-Ray のトレース
・Application Insights のアプリケーション情報

●Cloud Watch Agent Server Policy
EC2のIAMインスタンスプロファイルにアタッチすることで、CloudWatchへのメトリクス送信を許可する。

【メトリクスの保存期間について】

期間	使用時間
６０秒未満のデータポイント	３時間使用できる（カスタムメトリクス）
６０秒（１分）のデータポイント	１５日間使用できる
３００秒（５分）のデータポイント	６３日間使用できる
３６００秒（１時間）のデータポイント	４５５日（１５か月）間使用できる

〇メトリクス

【ログデータの検索およびフィルタリング】
1つまたは複数のメトリクスフィルターを作成することで、CloudWatch Logsで受信するログデータを検索およびフィルタリングできる。メトリクスフィルタはCloudWatch Logsに送信されたログデータを検索するための語句とパターンを定義する。
CloudWatch Logsは、これらのメトリクスフィルタを使用して、ログデータを数値のCloudWatchメトリクスに変換し、グラフを作成したり、アラームを設定したりできる。

• メトリクスエクスプローラー
  タグおよびリソースプロパティ別にメトリクスをフィルタリング、集計、および可視化できるタグベースのツール。
  
  ・AWS/Usage メトリクス名前空間
  AWSリソースの使用状況とサービスクォータを追跡する
  
  ●aws:autoscaling:groupName タグ
  AutoScaling グループに属するすべてのEC2のCPUメトリクスを一元的に管理できる。

標準メトリクス	EC2を立ち上げた時に標準的に設定してくれるメトリクス。CPU使用率、インスタンスのステータスチェックなど。
NetworkInおよびNetworkOut	これらのメトリックは、インスタンスによってすべてのネットワークインターフェースで転送されたバイトの量を追跡する。 ・請求アラームはバージニア北部でなら確実に作れる ・アラームを実行するデータポイント：何回通知するか
PutMetricData	メトリクスデータポイントをCloudWatchに発行する。CloudWatchはデータポイントを指定されたメトリクスに関連付ける。指定されたメトリクスが存在しない場合、CloudWatchはメトリクスを作成する。（ListMetricsの呼び出しに表示されるまで最大15分かかる）
埋め込みメトリクスフォーマット	CloudWatch Logs に書き込まれるログの形式と同様の、カスタムメトリクスを非同期的に生成できる。 JSON 形式。 抽出されたメトリクス値のアラームをグラフ化および作成できる。 また、CloudWatch Logs Insights（分析） を使用すると、抽出されたメトリクスに関連付けられた詳細なログイベントを照会できる。
収集されるメトリクスにカスタムディメンションを追加する	メトリクスを収集するため、Cloudwatchエージェント構成ファイル内にappend_dimensionsフィールドを作成する。

【メトリクス詳細】

Namespaces	CloudWatch メトリクスのコンテナ。異なる名前空間のメトリクスは相互に切り離されて、異なるアプリケーションのメトリクスが誤って同じ統計に集約されないようにする。
Metrics	CloudWatch に発行された時系列のデータポイントのセットを表す。
Dimensions	メトリクスのアイデンティティの一部である名前と値のペア （統計に使用するメトリクスを絞ることが出来る）
Resolution	・詳細度が 1 分のデータを含む、標準の解像度 ・詳細度が 1 秒のデータを含む高解像度
Statistics	指定した期間のメトリクスデータの集計（統計）
Units	Bytes、Seconds、Count、Percent などの単位
Periods	集計期間は1秒単位の算出となる(デフォルト：1分)（6分＝360秒）（MAX：1日）
Aggregation	統計の取得時に指定した期間の長さに従って、Amazon CloudWatch は統計を集約
Percentiles	データセットにおける値の相対的な位置を示す。たとえば、95 パーセンタイルは、95 パーセントのデータがこの値を下回っており、5 パーセントのデータがこの値を上回っていることを意味します。

• Alarms
  指定した期間の単一のメトリクスを監視。一定期間におけるしきい値とメトリクスの値の関係性に基づいて、1 つ以上の指定されたアクションを実行。

OK	メトリクスや式は、定義されているしきい値の範囲内です。
ALARM	メトリクスまたは式が、定義されているしきい値を超えています。
INSUFFICIENT_DATA	アラームが開始直後であるか、メトリクスが利用できないか、メトリクス用のデータが不足しているため、アラームの状態を判定できません。
作成方法	（アラーム名には ASCII 文字のみを使用） ・CloudWatch コンソール：PutMetricAlarm API アクション から ・AWS CLI の put-metric-alarm コマンド から
一覧表示	・CloudWatch コンソール：DescribeAlarms API アクション から ・AWS CLI の describe-alarms コマンド から
有効・無効	・CloudWatch コンソール、DisableAlarmActions および EnableAlarmActions API アクション ・WS CLI の disable-alarm-actions および enable-alarm-actions コマンド
動作テスト	・SetAlarmState API アクション ・AWS CLI の set-alarm-state コマンドを使用

◇エージェント

[情報を展開する]

●CloudWatch エージェント（統合型）
CloudWatch Logsで収集データを一元化するために、EC2インスタンスにインストールすることができる。ローカルログのイベントやサーバー内部のメトリクスを収集、またカスタムメトリクスをCloudWatch Logs に送信。

・ログデータはデフォルトで5秒の頻度で送信される。
・オンプレミスにもインストール可能。

※CloudWatch Logs エージェントではEC2インスタンス単位でパラメータを管理していたが、統合 CloudWatch エージェントではパラメータストアで管理することも可能。

項目	CloudWatch Logs Agent	CloudWatch Agent（統合型）
主な用途	ログファイルを CloudWatch Logs に送信	メトリクスとログの両方を CloudWatch に送信
収集対象	ローカルログファイル	メモリ使用率、ディスク使用率、カスタムメトリクス、ログなど
対応サービス	EC2（旧方式）	EC2、オンプレミス、Systems Manager 経由で管理可能
設定方法	awslogs.conf ファイル	JSON形式の設定ファイル（SSM Parameter Storeでも管理可能）
現在の推奨	廃止予定（古い方式）	推奨（統合型エージェント）

〇アラーム

• OK：正常
• ALARM：警告
• INSUFFICIENT_DATA：データが足りていない

• Cloud Watchアラーム
  【単体】
  監視項目が一定の値になった際にアラームとアクションを起動。
  EC2を自動的に停止、終了、再起動、または復旧するアラームを作成できる。
  
  ●請求アラーム
  請求額を監視し、一定額（しきい値）を超えた場合に、SNS（メッセージ通知サービス）を使用して、通知。
  全体のコストを監視するだけであり、特定の項目にスポットを当てることはできない。
  
  ●異常検知
  過去のメトリクスデータが分析され、予想される値のモデルを作成。予想される値は、メトリクスの一般的な時間単位、日単位、週単位のパターンを考慮。
  
  ●複合アラーム
  複数のメトリクスがしきい値が超えた場合、アラームの状態を監視してそれらの状態を判別する。
  複数のメトリクスを組み合わせて評価する。
  
  ●静的しきい値
  指定した評価期間数の中で、監視するメトリクスがしきい値を超えると、アラーム状態になる。
  
  ●Auto Recovery
  【インスタンスの復旧】
  AWSシステム側で問題が生じ、EC2インスタンスが起動できなくなった時、自動復旧するサービス。
  復旧されたインスタンスは、インスタンス ID、プライベート IP アドレス、Elastic IP アドレス、すべてのインスタンスメタデータを含め、元のインスタンスと同じになる。

【予算請求額アラート】
CloudWatchを使って、AWSの予想請求額（Estimated Charges）をモニタリングできる。
・請求に関するメトリクスは「米国東部（バージニア北部）」リージョンに格納されます。

メトリクスには以下が含まれます：

• AWS全体の予想請求額
• サービスごとの予想請求額

• 指定した金額のしきい値を超えると、アラームがトリガーされます。
  • これはすでに超えた時点の実際の請求額によって判断され、予測値は使われません。
• しきい値を超えている状態でアラームを作成すると、すぐに ALARM 状態になります。

• クロスアカウントアラーム【統合】
  さまざまなAWSアカウント横断でメトリックに基づいたアラートを提供する。
  既存のクロスアカウントダッシュボードと組み合わせて使うことで、運用を一元的に可視化できる。さらに、メトリック計算を使用して異なるアカウントのメトリックを組み合わせることができる。

〇GUI画面

【グラフについて】

• [Absolute]タブ
  グラフ確認で日時および開始・終了時間を指定できる。
  [何年何月何日の何時何分]という形式。

【ダッシュボードについて】

• クロスアカウントクロスリージョンダッシュボード
  複数の AWS アカウントおよび複数のリージョンの CloudWatch データを 1 つのダッシュボードにまとめることができる。
  ・この全体的なダッシュボードから、アプリケーション全体のビューを取得することができる。
  
  ・アカウントのサインインやログアウトをしなくてもより具体的なダッシュボードにドリルダウンすることもできる。

• メトリクスフィルター
  CloudWatch Logsに送信されるログデータからパターンを検出し、それらをCloud Watchメトリクスとしてカウントできる。

Cloud Watch Logs
【ログ監視】

使用中の「すべてのシステム・アプリケーション」、「AWS サービスからの各種ログファイルをモニタリング・保存・アクセス」を一元管理する。

・使用時、対象のサーバーにエージェントのインストールが必要。
・送信元のインスタンスにはCloud WatchのIAM権限として、IAMロールの付与が必要。

〇フィルタ

(CloudWatchlogs)メトリクスフィルター	サブスクリプションフィルター
※機能を有効にしてからのログしか読み込めない ログから定期的にメトリクスを抽出し、CloudWatch メトリクスとして保存。 ログデータを CloudWatch メトリクスに変換し、CloudWatchに出力する。 フィルターを通してログデータから直接パターンを抽出し、それに基づいてメトリクスを生成、記録。CloudWatch ログに入るログデータを検索及びフィルタリングできる。 ログデータをグラフ化またはアラームを設定できる数値、CloudWatch メトリクスに変換する。 ・ログデータの送信時にログデータで探す用語とパターンを定義する ・ユーザー名とクライアント名をディメンションとしてメトリクスに追加することで、日次、週次、月次のユニークユーザー数を効率的に追跡できる。	指定された送信先にリアルタイムでログデータをストリーミングする。

[参考サイト]

• ロググループ
  保持、モニタリング、アクセス制御について同じ設定を共有するログストリームのグループ。
  ロググループを定義して、各グループに入れるストリームを指定。1 つのロググループに属することができるログストリーミングの数に制限はない。
  
  ●ログストリーム
  【ルールセット？】
  同じソースを共有する一連のログイベント。
  CloudWatch Logs のログの各ソースは、個別のログストリームを構成。

〇ログについて

エージェントから監視ログが送られてくる頻度はデフォルトで5秒。データベースのログは加えられた変更を順番に記録している（詳細ではない）

以下の内容を表示できる。

・簡単な表示
・特定のエラーコードまたはパターンの検索
・特定のフィールドに基づくフィルター処理
・将来の分析のための安全なアーカイブ

●RDSから取得できるログはエンジンごとに異なる

DBエンジン	取得できるログの種類
Amazon Aurora MySQL MariaDB	監査ログ エラーログ 一般ログ スロークエリログ メモリ使用量
PostgreSQL	Postgresql log Upgrade log
Oracle Microsoft SQL Server	アラートログ 監査ログ リスナーログ トレースログ

【ログイベントのバッチ条件】

下記の条件が満たされた場合、バッチがフルになると発行される。

最初のイベントが追加されてから[buffer_duration]の時間が経過した

累積されたログイベントの[batch_size]未満だが、新しいログイベントを追加すると[batch_size]を超過する

ログイベント数は[batch_count]に達した

バッチのログイベントは24時間以上にならないが、新しいログイベントを追加し２４時間の制約を超過する

◇連携サービス

[情報を展開する]

※Cloudwatch Logsのサブスクリプション機能を利用するとKinesis Stream、 Data Firehose StreamやLambdaへログを直接連携できる。

CloudWatch Synthetics
【外形監視】

エンドポイントやAPIを監視するためのCanary（スケジュールで実行される設定可能なスクリプト）を作成するのに有効。

・外形監視（ユーザー目線）、生死監視（システム目線）ができる。
・利用ユーザーと同じアクション（APIなど）を実行して、パフォーマンスや可用性をモニタリング。

⇒問題が発生した場合、アラートを出せる。

• Canary
  スケジュールにそってウェブサイトやAPIを監視し、実行するスクリプト。
  ・監視したい対象のURLを指定。
  ・IAMロールを割り当てる。結果の格納先はS3。

EventBridge
【イベントリアルトラッキング】

（※旧：Cloud Watch Events）

AWSのリソース状態をリアルタイムに監視し、イベントをトリガーにアクションを実行する。

(サービスのトリガーとして利用される)ルールに一致したイベントを 1 つ以上のターゲット関数またはストリームを実行して、「応答メッセージを環境に送り」、「機能をアクティブ化」し、変更を行い、「状態情報を収集する」ことによって、是正措置を実行する。

※SNSへの直接連携はできない　※EFSのイベントをトリガーにできない
※直接、Event Bridge からStep Function を起動できる

●入力トランスフォーマー
EventBridgeの機能の一つで、イベントデータをターゲットに送信する前に、必要な情報だけを抽出・整形するためのツール。

• イベントソース
  【独自のトリガー】
  種類：スケジュール/イベント。
  トリガーであって、アラーム機能はない。

• ターゲット
  後続のアクション。

• Event Bridge DLQ
  ターゲットに正常に配信できなかったイベントを保存するために、EventBridgeが使用する標準的な SQS キュー。
  ・DLQを使用するかどうかは、ルールを作成してターゲットを追加するときに選択できる。
  ・DLQを設定すると、正常に配信されなかったイベントを保持でき、イベント配信の原因となった問題を解決、イベント処理できる。

【Trusted Advisorとの連携】
EventBridge を使用して、Trusted Advisor のチェックがステータスを変更するときに検出できる。
その後、ルールに指定した値のステータスが変更されたときに、EventBridge は、1 つ以上のターゲットアクションを呼び出せる。

• EventBridgeイベントバス
  イベントを受信するパイプライン。特定のイベントバスに関連付けられたルールによって条件の一致をチェックし、受信したイベントを評価する。

X-Ray
【サービス監視】

マイクロサービスで構築されたAWSサービスの実行状況を可視化する。レスポンスタイムやレスポンスステータス、アプリやアプリ基盤を分析し、アプリケーションに対するリクエストに関するデータを収集し、サービスの実行状況を把握、パフォーマンスの問題やエラーの根本原因を特定して、トラブルシューティングを行える。分散トレース。

コンソール上で表示したり分析することで問題を特定することができる。

• X-Ray SDK
  【アプリケーション】
  モニタリングを実行するために、X-Rayデーモンを必要とする。
  セグメントデータを作成をX-Rayデーモンに送信する。

• X-Ray エージェント
  データがログファイルから収集され、X-Ray サービスに送信される。
  その後、データは X-Ray サービスで集計、分析、保存される。このエージェントにより、API を使って直接送信するよりも簡単にデータを X-Rayサービスに送信することができる。
  ※要はログファイルからX-Rayにデータを送るもの

• X-Rayデーモン
  アプリケーションから受け取ったセグメントデータをバッファリングしX-Ray APIに定期的に転送。

• X-Rayコンソール
  トレースをコンソールで可視化分析・デバッグを行う。

• X-Ray サービスマップ
  サービスやリソースの関係性をリアルタイムで表示できるので高いレイテンシーが発生している場所を簡単に検出できる。
  AWSの他のサービス「EC2、ECS、Lambda,Elastic Beanstalkと連携することが出来る。Lambda は、X-Ray デーモンおよびは、関数の呼び出しと実行に関する詳細でセグメントを記録する。
  
  ●セグメント
  Lambdaなどの各AWSサービスの動作に関するデータ。リソース名、リクエストの詳細、行った作業の詳細などの情報。
  
  ●トレース
  このリクエストに何秒かかってるのか、またステータスコードなどリクエスト毎に一覧で確認できる。
  1 つのリクエストで生成されたセグメントをすべて収集する。IDが割り振られていて、詳細はIDをクリックすると確認することができる。トレース ID はアプリケーションを経由するリクエストのパスを追跡する。

• スクリプト・ツール
  AWS SDK、AWS CLIを利用することでX-Ray SDKを使わずに直接X-Ray APIとデータのやり取りが可能。

【CloudWatchとの違い】
●X-Ray
【サービス監視】
サービスマップと呼ばれるグラフから全体のパフォーマンスを確認することができ、リソースのレイテンシーの検出や障害の発生率特定などを診断することが出来る。

●CloudWatch
【サーバー監視】
AWS サービスのログの管理メトリクス監視を通じて、アプリの動きを個々の単位で監視できる。

リソースの評価

Config
【リソースの履歴・評価・構成変更管理】

AWSリソースの設定を「いつ」、「だれが」、「どのように」変更したのか、リソースの設定を評価、監査、審査できるサービス。

●設定レコーダー
リソースの構成変更・設定変更を追跡するための中心的なコンポーネント。

項目	説明
役割	AWSリソースの設定変更を検出・記録する
対象	EC2, S3, IAM, VPCなど多くのAWSサービス
出力先	記録はS3バケットに保存され、CloudWatch Logsにも送信可能
トリガー	定期的（スナップショット）またはイベントベース（変更時）

1. 設定レコーダーを有効化
   → どのリソースタイプを記録するか指定できます（すべて or 一部）
2. 記録開始
   → AWS Configが対象リソースの設定を定期的にスキャンし、変更を検出
3. 履歴保存
   → 構成履歴や変更イベントをS3に保存。CloudTrailと連携すると、誰が変更したかも追跡可能
4. コンプライアンス評価
   → AWS Configルールと組み合わせることで、設定がポリシーに準拠しているかを自動評価できます

【変更履歴の記録】

AWSリソースの設定変更を継続的にモニタリングおよび記録・追跡する。望まれる設定として記録された設定の評価を自動的に実行。

6時間ごとにチェックし、更新された設定の詳細を指定したＳ３バケットに変更履歴を送信する。
システム変更など、リソースが変更された場合などのタイミングで、Amazon SNSと連携、通知する。問題がある場合はメール通知や修正対応を随時できる。

【スナップショット】
※ダウンロード不可能

AWSリソースの設定から、AWSリソースの構成情報のスナップショットを取得し、管理できる。
この構成情報を元に、現状のAWSリソースの設定が利用者によって定義された正しい状態になっているか評価。

• Config アグリゲータ
  AWS Configで収集しているリソースや、Configルールのチェック結果を収集することができる。
  組織に所属していないAWSアカウントや、組織に所属していたとしても、特定のAWSアカウント（複数）に対して、一括管理ができる。
  
  以下の3パターンを対象とする。
  ①複数のアカウントと複数のリージョン。
  ②単一のアカウントと複数のリージョン。
  ③AWS Organizations 内の組織と、AWS Config が有効になっている組織内のすべてのアカウント。

〇リソース管理

ルールを使用して、AWSリソースへの設定を評価できる。ルールの条件に違反しているリソースが検出されると、そのリソースに非準拠のフラグが付けられ、通知が送信される。

〇修正機能

リソースの設定を記憶し、ルール非準拠の場合は修復アクションを利用して権限等、自動削除できる。ただし、コンプライアンス基準までは対応できないため、注意なお、修正は Systems Manager Automation と連携して実行されている。

〇マネージドルール

• approved-amis-by-id
  実行中のインスタンスで指定された AMI が使用されているかどうかを確認する。承認済み AMI ID のリストを指定する。
  実行中のインスタンスで使用されている AMI が、このリストにない場合は NON_COMPLIANT と返ってくる。

• required-tags
  指定したタグがリソースにあるかどうか確認し、評価できる。これにより、準拠していないリソースを簡単に特定できる。

◇カスタムルール

[情報を展開する]

AWSリソースへの変更を定期的に監査し、コンプライアンスを監視する。

作成方法	Lambda 関数（AWS Lambda デベロッパーガイドを使用） Guard（AWS Config のポリシー言語。GitHub リポジトリで提供）
用語の整理	・Lambda で作成したルール → AWS Config カスタムルール ・Guard で作成したルール → AWS Config カスタムポリシールール

◇コンフォーマンスパック

[情報を展開する]

Config のルールと修復アクションをまとめた構成管理テンプレート。アカウント単位、リージョン単位、または Organizations 全体に一括デプロイ可能。この仕組みにより、セキュリティやコンプライアンスの自動化・標準化が容易になる。

【作成・デプロイ方法】

• YAML テンプレートで構成（マネージドルール／カスタムルール＋修復アクション）
• Systems Manager ドキュメント（SSM ドキュメント）に保存し、SSM 経由でデプロイ可能
• AWS Config コンソールまたは AWS CLIを使用して展開
• サンプルテンプレートを使えばすぐに評価を開始できる
• ゼロからカスタムテンプレート作成も可能

Trusted Advisor
【アドバイス・トリガー】

※Trusted Advisor は Configに統合（2023）

AWSで利用している EC2 や RDS などのサービスを「コスト」「セキュリティ」「パフォーマンス」「耐障害性」「サービスの制限」について、ベストプラクティスに基づいた、リアルタイムのアドバイスを検査結果レポートとして提供。

※Amazon SNS に直接連携する機能はない

例えとして、セキュリティグループの設定をスキャンして、特定のポートのアクセス許可状態を識別することができる。
または、サービスの使用料が制限に達しないか監視してくれる。
※使用率の高い全てのEC2インスタンスを検出することができる

【注意点】
特定のリソース使用パターンを基にした具体的な推奨事項提案は非対応。
リソース使用の詳細なモニタリングデータが含まれないため、正確な最適化として不十分である。

[参考公式サイト]

【自動修正機能】

[参考公式サイト]

【CloudWatchがTrusted Advisorを参照する】

※Trusted Adviserは監視ではない。CloudWatchが参照しに来る。

[参考公式サイト]

その他関連サービス機能

ALB アクセスログ

ELB はロードバランサーに送信されるリクエストについて詳細情報をキャプチャしたアクセスログを提供。
各ログには、
・リクエストを受け取った時刻
・クライアントのIPアドレス
・接続タイプ
・レイテンシー
・リクエストのパス
・サーバーレスポンス
・ユーザーエージェントに関する情報

取得後、ログをキャプチャし、圧縮ファイルとして指定したS3バケット内に保存する。

IAMアクセスアドバイザー

IAMアイデンティティ（ユーザー、グループ、ロール）にアクセスを許可されているサービスと過去のアクセス履歴を表示。

S3アクセスロギング
【S3】

アクセス元のIPアドレスを含んだ各種ログ情報を取得できる。
ログの保存先は、ログ取得元バケットと同リージョン、かつ同AWSアカウントに存在するS3バケット。

●S3サーバーアクセスログ

• 記録内容: バケットに対する各リクエストの情報（日時、IPアドレス、操作内容、レスポンスコードなど）
• 用途:

• セキュリティ監査（誰がいつ何をしたか）
• アクセスパターンの分析
• 請求の最適化（不要なアクセスの特定など）

S3 イベント通知
【S3発報】

「新しいオブジェクトの作成イベント」,「オブジェクト削除イベント」,「オブジェクト復元イベント」,「低冗長化ストレージ (RRS)。 オブジェクト消失イベント」,「レプリケーションイベント」発生時、イベントを通知発行する。

【S3のイベント発行トリガー】
①Amazon SNSトピック：S3をトリガーとしてメールなどを通知できる。
②Amazon SQSキュー：S3をトリガーとしてStandardキューを配信できる。
③AWS Lambda
Lambda関数を作成時、カスタムコードをパッケージ化してLambdaにアップロード。S3をトリガーにLambda関数を実行できる。

【トリガーになる操作】

操作内容	説明
新しいオブジェクトの作成	PutObject や CopyObject などでファイルがアップロードされたとき
オブジェクトの削除	DeleteObject や DeleteObjects による削除
オブジェクトの復元	Glacier などからの復元操作
RRS（低冗長化ストレージ）オブジェクトの紛失	RRS 利用時にオブジェクトが失われた場合
レプリケーションイベント	バケット間でオブジェクトがレプリケートされたとき
ライフサイクルによる有効期限切れ	ライフサイクルポリシーでオブジェクトが期限切れになったとき
ライフサイクルによるストレージ移行	例：Standard → Glacier への移行
Intelligent-Tiering による自動アーカイブ	使用頻度に応じたストレージ階層の変更
オブジェクトのタグ付け	PutObjectTagging などによるタグの追加・変更
オブジェクト ACL の変更	PutObjectAcl によるアクセス制御の変更

これらのイベントは、バケットの設定で通知先（SNS/SQS/Lambda/EventBridge）を指定することで、リアルタイムに処理や通知を行うことが可能。

RDS イベント通知
【RDSの機能】

RDS のイベントが発生したときに、Amazon SNS を使用して通知を送信できる。
AWS リージョンの Amazon SNS でサポートされているすべての通知の形式が使用可能。
(E メール、テキストメッセージ、HTTP エンドポイントの呼び出しなど)

DynamoDB Streams
【DynamoDB】

直近24時間の追加・更新削除の変更履歴を保持する機能。アプリケーションの利用履歴を把握でき、データの更新タイミング検知、変更内容に応じた処理をリアルタイムにストリームを提供。
DynamoDB テーブルに保存された項目の変更をキャプチャすることができる。

※DynamoDB は AWS Lambda と統合されているため、DYNEストリームをトリガーとした連携機能を作成できる

※複数のLamda関数とは相性が悪い

拡張VPCルーティングの有効
【RedShift】

VPCに出入りするRedshiftクラスターのすべてのCOPYおよびUNLOADトラフィックを監視。
Redshift はクラスターとデータリポジトリ間のすべての COPY と UNLOAD トラフィックが VPC を通るよう強制する。

・インターネットを介さず、VPCを介してAWSサービスにアクセスすることができる。