#CloudWatch
定期的にAWSリソースの状態（メトリクス）を取得し、問題がある場合はそれを運用者に通知するサービス。
リリース後に安定した運用をすることで利用者の満足度を上げていくことが重要。
・標準メトリクス
ーLambda関数ごとのエラー回数などがあらかじめ定義されている
ーCPU、ディスク利用率、読み込みIOPSなど、一般的な目とリスクの多くが取得可能
ー５分間隔でのメトリスク取得
ー無料
・カスタムメトリクス
ー利用者が定義した値を渡す。独自のメトリクスのこと。標準では取得できないメトリスク。
ー１秒から６０秒でのリアルタイムでのメトリスク取得
ー有料
##CloudWatch Alarms
特定のメトリスクの閾値に応じてアラーム通知や自動アクションを実行可能。
モニタリング値を閾値にアラームを設定して、担当者に周知することが可能。
閾値のアラームで、SNSリソースを使用して、担当者にメール通知で知らせる。
・メトリクス
データポイントは、タイプスタンプと測定単位を保持
・名前空間
メトリスクのコンテナのこと
異なる名前空間のメトリスクを相互に切り離せる
・ディメンション
メトリスクを一意に識別する名前/値もペア
##CloudWatch Logs
AWSサービス及び顧客システムのログの監視・保存・アクセス提供。
ログのデータは、1日から永久保存まで設定可能。
S3へのログのエクスポートが可能。
CloudWach Logsを利用するには、独自のエージェントをインストールする必要があり、このエージェントを介して、各EC2インスタンスのログを取集します。送信元のインスタンスにIAM権限を付与する必要があるので、IAMロールで設定する。
###・CloudWatch Logs Insights
ークエリによってログを可視化・分析することが可能
ー３つのフィールドで生成される
ー時間軸に沿ってトレンドやパターンを可視化することができる
ー可視化されたグラフをダッシュボードに追加できる。
##CloudWatch Events
独自のトリガーと何かしらの後続アクションとの組み合わせを定義するサービス。
独自のトリガーを「イベントソース」。後続アイクションを「ターゲット」と呼ぶ。
CloudWatchはAWSリソースに対するイベントリをトリガーにアクションを実行。オペレーションの変更に応答し、応答メッセージを送信、機能のアクティブ化。変更、状態情報収集に修正アクションを実行。
##AutoScalingの組み合わせ
ステップスケーリングポリシーは、CloudWatchメトリクスから得られる値（CPU使用率やSQSキューサイズなど）の閾値を超えて発せられるアラームに対して、値ベースでスケーリングアクションを個別設定できる機能です。ステップスケーリングポリシーを作成するときは、アラーム超過のサイズに基づいてインスタンス数を動的にスケーリングする 1 つ以上のステップ調整値を指定します。各ステップ調整値は、次のように指定します。
・メトリクス値の下限
・メトリクス値の上限
・スケーリング調整タイプに基づいてスケールする量
CloudWatch は、CloudWatch アラームに関連付けられたメトリクスの統計に基づいて、メトリクスデータポイントを集計します。アラームを超過した場合、適切なスケーリングポリシーがトリガーされます。EC2 Auto Scaling は集計タイプを (raw メトリクスデータではなく) CloudWatch からの最新のメトリクスデータポイントに適用します。ステップ調整によって定義された上限と下限に対して、この集約メトリクス値を比較することにより、実行するステップ調整が決定されます。
スケーリングでは、単純にCPU使用率上がったら沢山インスタンスを追加してしまうといった実際のビジネスにフィットしないケースがあり、そこで、50%なら1台追加、60%なら2台追加、70%なら3台追加といった具合に、閾値を超えてアラームから報告される値によってスケールする台数を指定できるようになりました。
##RDSの拡張モニタリングを有効化
DBインスタンス上のさまざまなプロセスまたはスレッドがCPUをどのように使用しているかを常時モニタリングするためには、RDSの拡張モニタリングを有効化することが必要です。これにより、DBインスタンスのOSのリアルタイムメトリックスが確認できるようになります。 RDSコンソールを使用してDBインスタンスのメトリクスを表示でき、CloudWatch Logsからの拡張モニタリングを利用することができます。**デフォルトでは、拡張モニタリングメトリクスは30日間CloudWatch Logsに保存されます。**料金は、CloudWatch Logsの無料枠を超えた拡張モニタリングに対してのみかかる。
##AWS Cost Explorer
利用しているEC2インスタンスなどのリソースの最適な利用に関する推奨事項を把握することができます。これにより、アカウントやリージョンでアイドル状態のインスタンスや使用されていないインスタンスを特定することができます。推奨事項を作成するために、AWS では過去の EC2 リソースの使用状況、CloudWatch メトリクス、過去の予約履歴を分析してコストを削減できる可能性があるか判断します。
#CloudTrail
AWSリソースの作成や、マネジメントコンソールへのログインなどの操作を記録するサービス。誰が・いつ・どのような操作をしたか、といった監査ログを記録しておくことで重大な障害を起こさないようにする。
取得できるイベントは下記の２種類。管理イベントの取得はデフォルトで有効。データイベントの取得はデフォルトで無効となっている。TrailとLogsを連携することで、ユーザーの不正な操作を早期に発見できる。
・ルートアカウント、IAMユーザーのオペレーションをトラッキング
・Trailログファイルは暗号化されてS3に保存
・KMSによる暗号化もサポート
・過去90日分のログをマネジメントコンソール上で確認できる。90日以上の情報を保持したい場合は、S3に証跡を残す設定が可能。
・管理イベント
マネジメントコンソールのログイン、EC2インスタンスの作成、S3パケットの作成など。過去９０日間のログをマネージメントコンソール上で確認できる。
デフォルトで有効。
・データイベント
S3パケット上のデータ操作、Lambda関数の実行など
デフォルトで無効。
###・WatchとTrailの連携
二つを連携することで、不正操作を早期発見できる。
ユーザーがもし不正操作を行った場合は、自動で検知する。
#Config
AWSリソースのレポジトリ情報からリソース変更履歴や構成変更を管理するサービス。AWSリソースの設定を評価、監査、審査できる。Config では、AWS リソースの設定が継続的にモニタリングおよび記録され、望まれる設定に対する記録された設定の評価を自動的に実行できます。
・定期的に構成情報のスナップショットをS3に保存
・構成情報に基づきシステム構成があるべき状態になっているか評価
・評価基準にはAWSルールまたは独自ルールを適用