【事前知識】

• ETL
  ※Extract（抽出）Transform（変換）Load（格納）のイニシャル
  社内に点在する情報(データ)を必要な情報(データ)のみ1箇所に集約し蓄積し、経営に役立つ洞察を得るために利用する。
  
  ※これまでは情報を蓄積させるにも異なるデータソースであったため、各開発工数と専門知識が求められた
  
  【RPAとの違い】
  RPAツール：既存のアプリケーションの利用を前提とする。
  ETLツール：ツールを利用してデータの収集や加工を行う。

• サブセット
  一部分、部分集合、下位集合などの意味を持つ英単語。ある集団全体を構成する要素の一部を取り出して構成した小集団のこと。
  ITの分野では、仕様や規格、データ集合、ソフトウェアの機能などについてよく用いられる用語。
  本来備えている要素の一部を省略・削除した簡易版、限定版、軽量版という意味で用いられることが多い。

• ヒューリスティック
  必ず正しい答えを導けるわけではないが、ある程度のレベルで正解に近い解答を得ることができる方法。
  答えの精度が保証されない代わりに、回答に至るまでの時間が少ない。

• データパーティショニング
  スキャンされるデータ量が最小限に抑えられ、パフォーマンスが最適かされ、S3での分析クエリのコストが削減される。データへのきめ細かいアクセスも向上。

QuickSight
【ダッシュボード】

クラウド内のデータに接続し、さまざまなソースのデータを結合し、AWSで簡単に分析環境を作ることができるBIサービス。単一のデータダッシュボードに AWS データ、サードパーティーデータ、ビッグデータ、スプレッドシートデータ、SaaS データ、B2B データなどを含めることができる。

[参考]

Open Search Service
【ログ等高速検索】

Elasticsearch から派生したオープンソースの分散検索および分析スイート。リアルタイムのアプリケーションモニタリング、ログ分析、ウェブサイト検索などの幅広いユースケースにご利用できる完全なオープンソースの検索および分析エンジン。統合された視覚化ツールである OpenSearch ダッシュボードを使用して、大量のデータへの高速アクセスと応答を提供するための高度にスケーラブルなシステムを提供する。これにより、ユーザーはデータを簡単に探索できる。Apache Lucene 検索ライブラリを搭載しており、KNN 検索、SQL、異常検出、機械学習コモンズ、トレース分析、フルテキスト検索など、多くの検索および分析機能をサポートしている。ドキュメントやメッセージ、ログ等の様々なデータソースに対してDashboards Query Language（DQL）を使用することでデータの分析や可視化ができるサービス。

※Cloud Frontのログの格納先にOpenSearchドメインを使用することはできない

※本サービスを停止することはできない

[Open Searchについて詳細]

Compute Optimizer【リソース評価・分析】

AWS「リソース設定」と「使用率」のメトリクスを分析。

機械学習を使って過去の使用率メトリクスを分析することでリソースが最適かどうかを報告し、コスト削減し、パフォーマンスを向上させる。
コストを削減しつつパフォーマンスを向上させるための最適化に関する推奨事項を生成する。（EC2、EBS、ECS、Lambdaを対象）

【グラフ機能】

最近の使用率メトリクスの履歴データと、レコメンデーションの予測使用率を示す。最適なコストパフォーマンスのトレードオフとなるレコメンデーションを評価できる。
実行中のリソースを移動またはサイズ変更するタイミングを決定し、パフォーマンスとキャパシティーの要件を満たすのに役立つ。

Kinesis【プラットフォーム】

AWSでデータをストリーミングするためのプラットフォーム。受信するとすぐに処理,分析を行うため、すべてのデータを収集するのを待たずに処理を開始して直ちに応答する。複数のソースから高頻度でストリーミングデータをリアルタイムで収集、処理、分析することが簡単になるため、インサイト(見通し)を適時に取得して新しい情報に低レイテンシーに対応できる。また、特殊なニーズに合わせてカスタムストリーミングデータアプリケーションを構築する。

• ストリーミングデータ
  数千ものデータソースによって継続的に生成されるデータ。

【ユースケース】
動画分析、一括からリアルタイムへの移行、動画分析アプリ、リアルタイムアプリなど

Kinesis Data Streams
【シャードの集合体】

〇仕組み

[情報を展開する]

一連のデータレコードを持つ「シャード」のセット。
各シャードのデータレコードには、Kinesis Data Streams によってシーケンス番号（順序）があるため、メッセージが失われず、重複されず、到着と同じ順序で伝送することが可能。サーバー側での暗号化をサポートする。特定の場所に転送することはできない。

⇒データバッファリングや一括処理には不向き

シャード	Kinesis Datastream内のデータレコードのシーケンス。シャードの増減によってデータの転送速度を変動できる。各シャードには、一連のデータレコードが含まれる。 [参考] 【1つのシャードあたり…】 ・取り込み：1秒あたり最大 2MB のデータ ・書込み：1秒あたり 1,000 レコード ・ストリーム：1秒あたり最大10ギガバイト [引用元公式サイト]
データレコード	Kinesis data stream に保存されたデータの単位。シーケンス番号、パーティションキー、データ BLOB (イミュータブルなバイトシーケンス) で構成される。 各データレコードには、シャード内のパーティションキーごとに一意のシーケンス番号が割り当てられる。 ※BLOB 内のデータが検査、解釈、変更されることは一切ない

〇構成

[情報を展開する]

●プロデューサー（データ送信側）
データレコードを Kinesis Data Streamsに送信する。たとえば、Kinesis data stream にログデータを送信するウェブサーバーはプロデューサー。コンシューマーは、ストリームのデータレコードを処理する。

●コンシューマー（データ処理側）
Kinesis Data Streams からレコードを取得して処理する。これらのコンシューマーは Kinesis Data Streams Application と呼ばれる。S3、Redshift、Splunk などのサービスに直接ストリームレコードを送信する場合は、 Kinesis Data Firehose 配信ストリームを使用できる。
【拡張ファンアウト】
コンシューマーは、シャードあたり 1 秒間に最大 2 MB のデータのスループットで、ストリームからレコードを受け取ることができる。これにより、コンシューマーはスループット性能を向上させることができる。

●Kinesis Client Library(KCL)
Kinesis Data Streamからレコードを取得して、レコードプロセッサ と呼ばれるレコードを処理するためのハンドラをアプリケーション。EC2などの上で常駐させる。アプリケーションの開発者はこの レコードプロセッサ に処理を実装するだけで良く、レコードの取得、どのレコードまで処理したかの状態、Kinesisストリームのシャード増減を自動的に管理してくれる。

●Kinesis Producer Library（KPL）
Kinesis Data Streamsが提供するライブラリ。データストリームへの書き込みプロセスを簡素化する。 バッチ処理、集約、自動再試行などの機能を提供し、データ取り込みの効率性と信頼性を向上させる。

〇連携サービス

[情報を展開する]

【併用：Lambda】
Lambda 関数を使用すると、Kinesis DataStreams のレコードを高速処理できる。
Kinesis データストリームは、シャードのセット。Lambda 関数を共有スループットコンシューマー (標準イテレーター) にマップすることも、拡張ファンアウトを使用する専用スループットコンシューマーにマップすることもできる。

【Application Auto Scaling】
Application Auto Scalingを利用することでKinesis Data Stream に対してシャードを自動的に追加・削除する。スケーリングポリシーを定義を利用することでKinesis Data Stream に対してシャードを自動的に追加・削除するスケーリングポリシーを定義する。

【データ処理によって、複数回のレコードが送信される理由】

Kinsis系のサービスではストリーミング処理を失敗した場合に、プロデューサーが断続的に再起動され複数回送信されてしまう場合がある。重複させないために主キーをレコード内に埋め込み、それぞれのレコードをユニークにする(同じものの存在を1つしか許さない状態)必要。下記2点についてはアプリケーション側で設計時に複数回送信されることを想定される。

●プロデューサーの再試行
●コンシューマーの再試行

Kinesis Data Firehose

完全マネージド型サービス（ゼロ管理）。設定を行うだけで、次々と送られる大量のデータをRedShiftやS3に流し込むサービス。分析用途であり、大量のデータを効率よく格納する圧縮技術やいかにセキュアにデータを保持するかに向いている。アプリケーションの構築なしに設定を行うだけでS3、Redshift,Elastic searchに自動的にデータを収穫・格納できる。
※データのリアルタイム分析を直接実行する機能はない

・Lambda関数と統合されており、Lambda関数によるELT処理を連携することでデータ変換しつつ配信処理を実行できる。

• サブスクライバー
  Marketplaceで提供されているソフトウェアやサービスを契約して利用しているユーザー。

• 動的パーティショニング
  データ内のキーを使用して、Kinesis Data Firehose でストリーミングデータを継続的にパーティショニングし、これらのキーでグループ化されたデータを対応する S3 プレフィックスに配信できる。これにより、Athena , EMR ,Redshift Spectrum などのさまざまなサービスを使用して、S3のストリーミングデータに対して高機能でコスト効率の高い分析を簡単に実行できる。

Kinesis Video Streams【動画処理】

動画を処理する。

Kinesis Data Analytics【分析】

収集したデータを可視化・分析。
リアルタイムのストリーミングデータの分析や処理、保存を行う。

Managed Grafana
【Grafana専用】

複数のソースからの運用メトリクス、ログ、トレースを即座に照会、関連付け、視覚化する。
拡張可能なデータサポートに対して定評があり、広く展開されているデータ視覚化ツールである Grafana を簡単に展開、運用、スケールできる。

ワークスペースと呼ばれる論理的に分離された Grafana サーバーを作成する。
シングルサインオン、データアクセスコントロール、監査レポートなど、コーポレートガバナンス要件に準拠するためのセキュリティ機能が組み込まれている。

※Grafana（グラファナ）とは
分析およびインタラクティブな視覚化を可能にする、マルチプラットフォームで動作するオープンソースのWebアプリケーション

MSK
【Apache Kafka専用】

※MSK：Managed Streaming for Apache Kafka

Apache Kafkaをベースにした完全マネージドのストリーミングサービス。

※Apache Kafka
オープンソースの分散ストリーム処理プラットフォームで、リアルタイムのストリームデータを扱うためのツール

・可用性が高く、クラスターは最新の状態に保たれる。
・拡張性が高く、必要に応じて規模を換えることができる。
・Apache Kafka クラスターを複数のアベイラビリティーゾーン (AZ) に分散して提供する。
・既存アプリケーションで処理しているメッセージング機能をクラウドにすばやく簡単に移したい場合に最適。

Broker （ブローカー）	Kafkaクラスタを構成するサーバーのこと。
Topic （トピック）	メッセージを格納するための論理的な単位。データはTopicに分類される。
Producer （プロデューサ）	Kafkaにメッセージを送信するアプリケーション。
Consumer （コンシューマ）	Kafkaからメッセージを取得するアプリケーション。

[引用元]

★以下を処理実行する
１：サーバーのプロビジョニング
２：Apache Kafka クラスターの設定
３：障害時のサーバーの交換
４：サーバーのパッチとアップグレードのオーケストレート
５：高可用性のためのクラスターの構築
６：データの永続的な保存とセキュリティの確保
７：モニタリングとアラームの設定
８：負荷変動をサポートするためのスケーリングの実行

MSF
【Apache Flink専用】

※Managed Service for Apache Flink

Apache Flink を使用してストリーミングデータをリアルタイムで変換および分析し、アプリケーションを他の AWS サービスと統合できる。管理するサーバーやクラスターはなく、コンピューティングやストレージのインフラストラクチャをセットアップする必要もない。
・複雑なストリーム処理に適している。

分析サポートサービス

Glue
【データ変換】

サーバレス型分析サービス。データ管理と変換する機能。データの加工などを行う、ETL（抽出・変換・格納）サービスであり、主にデータを分析する前に使うサービス。 データソースのデータを探索し、メタデータとして管理する。

【組み込み変換】
データを処理するために使用できる一式の組み込み変換を用意。これらの変換はETLスクリプトから呼び出すことができる。データは変換から変換へとDynamicFrameと呼ばれるデータ構造で渡される。

Data Catalog	メタデータを格納するデータストア(=メタデータストア)。データベースやテーブルといった構造で保管する。S3 などのデータソースに保存されている構造化データ、または半構造化データの集まりをメタデータとして管理する。データカタログには、データベース、テーブル、スキーマといった構成を持ち、コネクション、クローラー、分類子といったメタデータを抽出するための機能がある。
Crawler	データソースへの接続、データスキーマの推測、データカタログでメタデータテーブル定義の作成を行うプログラム
ETL Job	ソースからデータの抽出、Apache Spark スクリプトを使用して変換、ターゲットにロードするビジネスロジック

[公式参考サイト]

キューイングサービス

ストリーム処理をかけるデータはキューイングサービスを通すことが一般的である。

SQS（Simple Queue Service）

キュー内の(複数の)ワーカープロセスでメッセージを処理し、確実な非同期（分散並行）処理を行う。
キューの有効期限が切れるまで繰り返し処理する。

• プロデューサ
  キューにメッセージを入れる、取り出すサービス。

• エンドポイント
  URLを介して送受信する。

〇キュー

メッセージを管理する入れ物のようなもの（256KB限度）デフォルトは4日間保存する。

キューは手動で削除することが可能。

• スタンダードキュー
  順番は保証されない。一回のメッセージ配信をサポートする。
  
  ●シーケンス情報
  追加することで、順序良く受信させることができる。
  (スタンダードキュー可能）
  
  
• 先入れ先出し（FIFOキュー）
  利用料金は高め。受信時にメッセージの並び替え、最低1回のメッセージ配信をサポートする。
  
  ・S3との連携はできない
  ・1秒あたり最大3,000トランザクション
  ・1秒あたり最大300メッセージをサポートする
  
  【キューの切り替え】
  FIFOキューに切り替えるなどする際は、新しくキューを作成する必要がある。
  ※FIFOキューは「コンテンツベース重複排除」を有効化することで、データを一意にできる
  
  【その他機能】
  ●キューイング(待ち行列)
  【一時退避】
  一時的に送信するデータをデータ領域に保持し、滞留させず確実に相手へ届ける。疎結合が可能。
  
  ●デッドレターキュー (DLQ)
  【失敗処理】
  処理できないメッセージを別のキューに移動させる。
  正常に処理 (消費) できないメッセージのターゲットとする。アプリケーションやメッセージングシステムのデバッグに役立つ。
  
  ●遅延キュー
  【受信遅延】
  キューへの新しいメッセージの配信を数秒間遅延させ、そのキューに送信したすべてのメッセージは遅延期間中にコンシューマーに表示されない。
  キューのデフォルト (最小) 遅延は 0 秒。最大値は15分。

〇メッセージ

キューの中に格納される情報。

• メッセージグループ ID
  【メッセージのタグ付け】
  メッセージが特定のメッセージグループに属することを指定するタグ。
  同じメッセージグループに属するメッセージは、そのメッセージグループに関連して厳密な順序で 1つずつ処理される。

• 可視性タイムアウト
  【重複受信防止】
  メッセージの受信中に他クライアントが受信しないように防止する。(30秒～12時間まで延長可能)
  メッセージは受信しただけでは消えず、クライアント側から削除指示を受けた時のみ削除される。
  
  ●ChangeMessageVisibility
  新しいタイムアウト値を指定すると、メッセージの可視性を短縮または拡張できる。
  
  ●VisibilityTimeout
  メッセージが1回受信された後、他のクライアントから同じメッセージを受信不可にするための時間。
  (デフォルトは30秒. 値は0〜43,200(12時間) の間で設定可能)
  
  ●ReceiveMessage
  リクエストによってメッセージを取得。

• SQS Java 拡張クライアントライブラリ
  【メッセージの保存管理】
  メッセージを常に S3 に保存するか、メッセージのサイズが 256 KB を超える場合のみ保存するかを指定する。
  
  ・S3 バケットに保存されている単一のメッセージオブジェクトを参照するメッセージを送信する
  ・S3 バケットからメッセージオブジェクトを取得 / 削除する

〇ポーリング

複数のキューを呼び出して分散してメッセージを処理する。ただし、1つのキューにすべてのメッセージが入っているわけではない。
キューの中の先頭のデータが渡されるため、中の特定のメッセージを指定できない。
[参考]

• ショートポーリング
  メッセージ取得時に特定のキューをランダムに選択し、そのキューからメッセージを取得する。
  リクエストを投げると結果は直ぐに返ってくるため、メッセージ取得時の待機時間0秒。しかし、結果が0件だった場合はリトライされるため、リクエスト回数が増え、料金が増加する。

• ロングポーリング（推奨）
  すべてのキューを確認し、処理可能な(待機時間を超過した)メッセージが存在する場合と接続タイムアウトになった場合のみ結果を返す。
  結果が0件の場合は返答しないため、SQS使用時のコストを削減できるので、ショートポーリングよりも推奨される。
  
  ※ReceiveMessageAPI アクションが 0 より大きい場合ロングポーリングは実行中
  
  ・KMSを使用したサーバー側の暗号化を使用したシームレスな保存データの暗号化をサポート。一元化されたキー管理が可能になる。

〇メトリクス

[参考公式サイト]

• ApproximateNumberOfMessagesVisible
  キューから取得可能なメッセージの数。

MQ
【Apache用】

Apache ActiveMQ および RabbitMQ 用マネージド型のメッセージキューイングサービス。
AWS独自の方法ではなく業界標準APIやメッセージング用プロトコルを使ってるため、今までのアプリから接続先をMQに変えるだけで簡単に移行できる。
リージョン内の複数のAZにメッセージを冗長的に保存するため、耐障害性が高い。

・ソフトウェアをインストールして管理したりする必要はない。
・ソフトウェアのアップグレードやセキュリティの更新、障害の検出と回復などのタスクを自動的に管理する。

• メッセージブローカー
  【中間システム】
  異なるシステム間でメッセージやり取りの時、直接データのやり取りせず、中間システムとしてメッセージ格納領域を管理する機能。

その他関連サービス機能

IAM Access Analyzer
【意図せぬ公開】

外部エンティティ（別のAWSアカウントのエンティティ）と共有されているS3バケットやIAMロールなどが、セキュリティ上のリスクであるリソースとデータへの不適切なアクセスがないかを特定する。
すなわち、AWSリソースに紐付いているポリシーを検査し、他AWSアカウントや外部のインターネット等からのアクセスを可能とするような意図せぬ公開設定がされているか確認する機能。

• S3 Access Analyzer
  IAM Access Analyzeに基づいて現在のS3へのアクセスポリシーを監視できるサービス。
  ※IAM Access AnalyzeのS3用みたいなもの
  バケットアクセスポリシーがS3リソースへの意図したアクセスのみを提供するように意図しないアクセスの可能性があるバケットを検出して迅速に修正できるようにする。
  また、S3バケットに対する外部アカウントからのアクセス情報を分析して、不正なアカウントアクセスがないかを確認することができる。

S３に関する分析機能

S3 Select

単純なSQL式を使用してS3バケット内のオブジェクト内のデータのサブセットを取得し、より迅速かつ安価に分析および処理できる。

【S3インベントリをフィルタリング】

S3インベントリ内のレポートをフィルタリングして、暗号化されていないオブジェクトなどを検索できる。

【データの解析には不向き】
シンプルなSQLステートメントを使用してS3オブジェクトのコンテンツをフィルタリングし、必要なデータのサブセットのみを取得できる。結果として、S3が転送するデータ量を削減でき、データ取得に要するコストを削減し、待ち時間を改善できる。

・アーカイブ容量の最大は250MB未満

※簡単なデータ検索や抽出に利用される機能であるため、本件の高度なビッグデータ分析には利用できない。

Amazon Athena

標準のSQL式を使用して、S3 内のデータを標準 SQL を使用して簡単に(アドホックなSQL)分析できるクエリサービス。サーバーレスなため、インフラストラクチャの管理は不要。S3のデータをポイントし、スキーマを定義し、標準のSQL式を使用してクエリを開始するだけ。S3上にログ等のデータを保管しており、それを分析用途に簡単に利用したい、新しく取得したデータに対してDWHに入れるべきかを検証する場合に利用が適する。

【課金について】
実行したクエリに対してのみ料金が発生する。

S3 分析
【ストレージクラス分析】

ストレージアクセスパターンを分析し、適切なデータをいつ適切なストレージクラスに移行すべきかを判断できる。
アクセス頻度の低い STANDARD ストレージをいつ STANDARD_IA (IA: 小頻度アクセス) ストレージクラスに移行すべきかを判断できるように、データアクセスパターンを確認する。

EMR
【S3を高分析】

※Elastic MapReduce
※スポットインスタンスと相性が良い

Apache HadoopやApache Sparkなどのオープンソースツールを利用し、大量のデータを迅速に処理するために分散アプリケーションを実行する。マネージド型 Hadoop フレームワーク。(高速処理ではない)

・GoogleのフレームワークであるMapReduceをベースに実装されている。

・S3にある大量のログファイルを処理して、分析するのに最適なサービス。

・EMRの処理結果をS3をはじめとしたAWSの他のサービスと連携できる。

伸縮自在	EMRのコンピューティングとストレージは分離されているため、スケーリングができる。
信頼性	クラウド向けの調整。パフォーマンスの低いインスタンスは自動的に置き換わる。
安全性	インスタンスへのアクセスは自動制御、またKMSを使用して暗号化を行うことが可能。
低コスト	最小課金時間が1分、そして1秒毎に課金される。

• Apache Spark
  EMRクラスターを使用した機械学習、ストリーム処理、またはグラフ分析に役立つ分散処理フレームワークおよびプログラミングモデル。 Apache Hadoopと同様に、ビックデータのワークロードを処理するために一般的に使用されているオープンソースの分散処理システム。
  
  ※イメージ比較
  ・Redshiftは標準的な Apache Sparkの3倍以上の速さで、ペタバイト規模の分析を実行できる。
  
• Hadoop
  巨大なデータを処理するため、アプリケーションの実行をハードウェアのクラスター上で行うオープンソースのソフトウェアフレームワーク（プラットフォーム）。
  
  ●HDFS（Hadoop Distributed File System）
  コモディティハードウェア上で実行するように設計された分散ファイルシステム。
  
  ・耐障害性を備えており、低コストのハードウェアに導入できるように設計されている。
  ・アプリケーションデータへの高スループットを提供する。
  ・Apache Hadoop のファイルシステムデータへのストリーミングアクセスを可能にする。

• Kerberos ベースの認証
  EMRクラスターのセキュリティ強化に使用。はじめにIDとパスワードで認証に成功すると、証明のための「チケット」が発行される仕組み。

〇ノード

• マスターノード
  クラスターを制御し、分散アプリケーションのマスターコンポーネントを実行。クラスターにサブミットされたジョブステータスを追跡して、 インスタンスグループの健全性を監視。マスターノードは一つしかなく、インスタンスグループまたはインスタンスフリートは1つの EC2で構成される。
  ※マスターノードが終了するとクラスターも終了するため、マスターノードは突然終了しても問題が発生しないクラスターを実行している場合にのみ、スポットインスタンスとして起動するようにするとよい。

• コアノード
  マスターノードによって管理される。データノードデーモンを実行して、Hadoop Distributed File System(HDFS)の一部を使用して データを格納する。さらにタスクトラッカーデーモンを実行し、インストールされているアプリケーションを要求する。 データ上で、その他の並列計算タスクを実行。マスターノードのように、クラスターあたり最低一つのコアノードが必要。
  ※コアインスタンスを終了すると、データ損失のリスクがある

• タスクノード
  タスクノードはオプション。Hadoop MapReduceタスクやSpark実行プログラムなど、データに対して平行計算タスクを実行するための能力を追加するために使用。
  データノードデーモン上で実行されることも、HDFSでデータを保存することはない。コアノードと同様に既存のユニフォームインスタンスグループにEC2インスタンスを追加することでクラスターにタスクノードを追加、あるいはタスクインスタンスフリートのターゲット容量を変更することができる。オンデマンドインスタンスなど、異なるインスタンスタイプおよび価格設定オプションを組み合わせることができる。

S3 Storage Lens

オブジェクトストレージおよびアクティビティを組織全体で可視化するために使用できるクラウドストレージ分析機能。
メトリクスを分析して、ストレージコストを最適化し、データ保護に関するベストプラクティスを適用するために使用できるコンテキストに応じた推奨事項を提供する。

【（デフォルト）ダッシュボード】
複数のAWSリージョンにわたるS3バケットの監視と、暗号化されたオブジェクトの割合の追跡に適した統合ダッシュボード。
S3コンソールを使用して直接ダッシュボードにアクセスできるため、追加のデータ集約やダッシュボードの作成が不要になる。

Cloud Watch関係

CloudWatch log insight
【Cloud Watchlogの検索】

CloudWatch Logsのログデータに対し、独自の構文を使ってクエリのようにデータを検索したり分析したりすることができる機能。ロググループ内のログデータの分析に特化しており、集計したデータをダッシュボードに表示することができる。

リアルタイムの監視やアラート設定はできない。

CloudWatch Application Insights
【アプリケーションの監視】

他のアプリケーションリソースとともに インスタンスを使用するアプリケーションをモニターリングする。

【アクション実行】
メトリクスとログを継続的にモニターリングし、異常やエラーを検出して相互に関連付ける。エラーや異常が検出されると、Application Insights は CloudWatch Events を生成する。
これを使用して、通知を設定したり、アクションを実行したりできる。

【ダッシュボード】
トラブルシューティングに役立てるために、検出した問題の自動ダッシュボードを作成します。このダッシュボードには、相互に関連付けられた異常とログエラー、さらに根本原因を示唆する追加のインサイトが示されます。

CloudWatch Contributor Insights
【高頻度ボトルネック可視化】

CloudWatch Logsから取得した時系列データから上位（高頻度）の要素をリアルタイム分析を簡素できる機能。
パフォーマンスのボトルネックや、使用されているリソースなどを一目で確認できるダッシュボードで確認することができる。

CloudWatch Logsにエクスポートしたシステムやアプリケーションログなどからエラーが多いURLを特定したり、VPC Flow Logsで意図しないIPアドレスからのアクセスを特定したりすることができる。