SW BBANG J

月曜の朝、本番EC2インスタンスが消えていた。Slackに通知が飛んで、誰もやっていないと言う。こういう状況で最初に開くべきツールが CloudTrail Event History だ。 TerminateInstances アクションは必ずCloudTrailに記録されており、どのIAMユーザーまたはロールが実行したかを数分で特定できる。 TL;DR — CloudTrailでEC2削除者を特定する ステップ 操作 確認ポイント 1 Event Historyを開く リージョンが正しいか確認 2 イベント名で TerminateInstances をフィルタ 削除時刻の前後30分を絞り込む 3 イベント詳細を展開 userIdentity フィールドを確認 4 CLIで同じクエリを実行 インスタンスIDで絞り込み精度を上げる 5 再発防止策を実施 Termination ProtectionまたはSCP適用 CloudTrail Event Historyの仕組みを理解する CloudTrailはAWSアカウント内のAPI呼び出しを記録するサービスだ。EC2の TerminateInstances も例外ではなく、マネジメントコンソール、CLI、SDK、Auto Scalingなど、どの経路で実行されても同じイベントとして記録される。 Event Historyは追加設定なしで有効になっており、過去90日間のマネジメントイベントを保持する。S3バケットへの長期保存にはTrailの設定が必要だが、90日以内の調査であればEvent Historyだけで完結する。 graph LR A["コンソール操作"] --> CT["CloudTrail"] B["AWS CLI"] --> CT C["SDK / アプリ"] --> CT D["Auto Scaling"] --> CT CT --> EH[...

EC2インスタンスのCPU使用率はCloudWatchコンソールで即座に確認できるのに、メモリ使用率を見ようとすると何も表示されない——この状況に直面したエンジニアは多い。アラームを設定しようとして初めて「なぜRAMのメトリクスが存在しないのか」に気づく。これはAWSの設計上の理由があり、CloudWatch Agentをインストールすることで解決できる。 TL;DR：EC2メモリ監視の要点 項目 内容 デフォルトで取得できるメトリクス CPUUtilization、ネットワーク、ディスクI/O（ハイパーバイザーレベル） デフォルトで取得できないメトリクス メモリ使用率、ディスク空き容量、スワップ使用率 解決策 CloudWatch Agentをインスタンスにインストールし、OSレベルのメトリクスを送信 必要なIAM権限 CloudWatchAgentServerPolicyをインスタンスプロファイルにアタッチ メトリクス名前空間 CWAgent（デフォルト） なぜEC2メモリ使用率はCloudWatchに表示されないのか CloudWatchがデフォルトで収集するEC2メトリクスは、AWSのハイパーバイザー（基盤となる仮想化レイヤー）が観測できる情報に限定される。CPUの使用サイクル数やネットワークパケット数はハイパーバイザーから見えるが、ゲストOS内部のメモリ割り当て状況はハイパーバイザーには見えない。 ハイパーバイザーとゲストOSの関係は、ビルのオーナーと入居テナントに似ている。オーナーは電力消費量（CPU）や出入りする荷物の量（ネットワーク）は把握できるが、部屋の中で何がどこに置かれているか（メモリの中身）は見えない。 これはAWSの制限ではなく、クラウド仮想化の構造的な特性だ。ゲストOS内部の状態を取得するには、OS内部で動作するエージェントプロセスが必要になる。それがCloudWatch Agentの役割だ。 graph TD HV["AWSハイパーバイザー 仮想化レイヤー"] EC2["EC2インスタンス ゲ...