【事前知識】

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

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

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

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

通知サービス

SES

※SES(Simple Email Service)

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

SNS

※SNS(Simple Notification Service)

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

• トピック（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分に設定されており、その期間内に集約される。

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

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と連携できる。

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

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

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

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

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

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

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

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

• Metric Math
  複数のメトリクスを組み合わせて新しく情報を生成するためのツール。

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

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

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

〇アラームの状態

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

〇メトリクス

• メトリクスエクスプローラー
  タグおよびリソースプロパティ別にメトリクスをフィルタリング、集計、および可視化できるタグベースのツール。
  
  ●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 Agent
  CloudWatch Logsでそれらを一元化するために、EC2インスタンスにインストールすることができる。ログデータはデフォルトで5秒の頻度で送信される。

• 統合 CloudWatch エージェント
  オペレーティングシステム全体でEC2 インスタンスから、ローカルログのイベントやサーバー内部のメトリクスを収集、またカスタムメトリクスをCloudWatch Logs に送信。
  CloudWatch Logs エージェントではEC2インスタンス単位でパラメータを管理していたが、統合 CloudWatch エージェントではパラメータストアで管理することも可能。

〇アラーム

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

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

〇GUI画面

【グラフについて】

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

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

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

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

Cloud Watch Logs
【ログ監視】

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

・使用時、対象のサーバーにエージェントのインストールが必要。

・送信元のインスタンスにはCloud WatchのIAM権限として、IAMロールの付与が必要。

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

• CloudWatch Logs メトリクスフィルター
  フィルターを使用して、ログデータから直接パターンを抽出し、それに基づいてメトリクスを生成、記録する。1つ以上のメトリクスフィルターを作成することで、CloudWatch ログに入るログデータを検索及びフィルタリングできる。
  ログデータをグラフ化またはアラームを設定できる数値、CloudWatch メトリクスに変換する。
  
  ・ログデータの送信時にログデータで探す用語とパターンを定義する
  ・ユーザー名とクライアント名をディメンションとしてメトリクスに追加することで、日次、週次、月次のユニークユーザー数を効率的に追跡できる。

〇ログについて

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

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

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

※Cloudwatch Logsのサブスクリプション機能を利用するとLambdaへログを連携できる。

●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 Synthetics
【外形監視】

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

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

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

EventBridge
【イベントルーティングサービス】

（※旧：Cloud Watch Events）

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

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

※SNSへの直接連携はできない

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

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

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

X-Ray
【サービス監視】

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

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

• 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 サービスのログの管理メトリクス監視を通じて、アプリの動きを個々の単位で監視できる。

IAMアクセスアドバイザー

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

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

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

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

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

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

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

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

DynamoDBストリーム
【DynamoDB】

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

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

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

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