• インスタンス数やvCPUの上限が増える
  例えば「オンデマンドインスタンスのvCPU数上限」を引き上げれば、より多くのインスタンスを同時に起動可能になる。
• スケーリングの柔軟性が向上
  オートスケーリングや大規模な負荷試験を行う際に、制限に引っかからずにリソースを増やせる。
• 業務継続性の確保
  制限を超えるとリクエストが失敗するが、事前にクォータを上げておけばサービス停止リスクを減らせる。

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

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

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

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

・ログを出力する際、宛名テーブルを使用するとS3Athenaと連携できる。
・ログが改変されていないか、検証・確認できる
※デフォルトではデータのイベントロギングは無効になっているため、設定が必要

【SQL ベースのクエリ】
イベントに対して SQL ベースのクエリを実行することができる。イベントはイベントデータストアに集約される。コンプライアンススタックを補完し、ほぼリアルタイムのトラブルシューティングを支援する監査ソリューション。

・ORC は、データをすばやく取得できるように最適化された列指向ストレージ形式。

●管理イベント

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

●データイベント

【リソースに対して】
AWS アカウントのリソースで、またはリソース内で実行されたリソースオペレーションを示す。データイベントログ記録を有効にするには、サポートされているリソースまたはリソースタイプを証跡に明示的に追加する必要がある。

下記、S3 のバケットおよびオブジェクトレベルのリクエストに関する情報を取得できる。
・呼び出し元のAWSアカウント
・呼び出し元のIAMユーザーロール
・API呼び出しの時間
・APIのIPアドレスの追跡…etc

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

●基本モニタリング

データは自動的に 5 分間隔で取得される。料金は発生しない。

●詳細モニタリング

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

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

●メトリクスフィルター

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

●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へのメトリクス送信を許可する。

●メトリクスエクスプローラー

タグおよびリソースプロパティ別にメトリクスをフィルタリング、集計、および可視化できるタグベースのツール。

●AWS/Usage メトリクス名前空間

AWSリソースの使用状況とサービスクォータを追跡する。

●aws:autoscaling:groupName タグ

Auto Scaling グループに属するすべてのEC2のCPUメトリクスを一元的に管理できる。

[メトリクス詳細]

[メトリクスの保存期間について]

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

●CloudWatch エージェント（統合型）

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

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

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

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

●Cloud Watchアラーム

【単体】監視項目が一定の値になった際にアラームとアクションを起動。
EC2を自動的に停止、終了、再起動、または復旧するアラームを作成できる。

●予算請求額アラート

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

メトリクスには以下が含まれる：
・AWS全体の予想請求額
・サービスごとの予想請求額
・指定した金額のしきい値を超えると、アラームがトリガーされる。
（これはすでに超えた時点の実際の請求額によって判断され、予測値は使われない）
・しきい値を超えている状態でアラームを作成すると、すぐに ALARM 状態になる。

●クロスアカウントアラーム【統合】

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

[グラフについて]

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

[ダッシュボードについて]

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

●サブスクリプションフィルター

指定された送信先にリアルタイムでログデータをストリーミングする。

●(CloudWatchlogs)メトリクスフィルター

※機能を有効にしてからのログしか読み込めない
ログから定期的にメトリクスを抽出し、CloudWatch メトリクスとして保存。ログデータを CloudWatch メトリクスに変換し、CloudWatchに出力する。フィルターを通してログデータから直接パターンを抽出し、それに基づいてメトリクスを生成、記録。CloudWatch ログに入るログデータを検索及びフィルタリングできる。
ログデータをグラフ化またはアラームを設定できる数値、CloudWatch メトリクスに変換する。

・ログデータの送信時にログデータで探す用語とパターンを定義する
・ユーザー名とクライアント名をディメンションとしてメトリクスに追加することで、日次、週次、月次のユニークユーザー数を効率的に追跡できる。

[参考サイト]

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

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

●ロググループ

保持、モニタリング、アクセス制御について同じ設定を共有するログストリームのグループ。ロググループを定義して、各グループに入れるストリームを指定。1 つのロググループに属することができるログストリーミングの数に制限はない。

• ログストリーム
  【ルールセット？】同じソースを共有する一連のログイベント。
  CloudWatch Logs のログの各ソースは、個別のログストリームを構成。

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

[ログイベントのバッチ条件]
下記の条件が満たされた場合、バッチがフルになると発行される。

・最初のイベントが追加されてから[buffer_duration]の時間が経過した
・累積されたログイベントの[batch_size]未満だが、新しいログイベントを追加すると[batch_size]を超過する
・ログイベント数は[batch_count]に達した
・バッチのログイベントは24時間以上にならないが、新しいログイベントを追加し２４時間の制約を超過する

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

●セグメント

Lambdaなどの各AWSサービスの動作に関するデータ。リソース名、リクエストの詳細、行った作業の詳細などの情報。

●トレース

このリクエストに何秒かかってるのか、またステータスコードなどリクエスト毎に一覧で確認できる。1 つのリクエストで生成されたセグメントをすべて収集する。IDが割り振られていて、詳細はIDをクリックすると確認することができる。トレース ID はアプリケーションを経由するリクエストのパスを追跡する。

●スクリプト・ツール

AWS SDK、AWS CLIを利用することでX-Ray SDKを使わずに直接X-Ray APIとデータのやり取りが可能。

●Config アグリゲータ

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

●カスタムルール

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

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

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

[作成・デプロイ方法]

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

●設定レコーダー

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

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

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

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