CloudWatchを勉強している際に、メモリ使用率がなぜ標準で取得できないのか技術的な理由が気になったので、色々調べてみました。備忘録の意味も兼ねて、載せておきたいと思います。
疑問点
CloudWatchで取得できるEC2インスタンスの標準メトリクスについて、CloudWatchのBlack Beltでは以下のように書かれています。
この記載の通り、CloudWatchでは標準で取得できるメトリクスとしてCPU使用率やディスク読み込みバイト数、ネットワーク利用状況などが用意されておりますが、メモリ使用率などは標準では用意されておりません。 標準で用意されていない項目はカスタムメトリクスに分類されており、取得できるようにするためには、EC2にCloudWatchエージェントのインストールなどが必要になります。（参考記事：CloudWatchエージェントでEC2インスタンスのカスタムメトリクスを取得する）
一般的なリソース監視において、メモリ使用率は重要な項目であるにも関わらず、なぜ標準で用意がされていないのでしょうか？
結論
結論を言うと、メモリ使用率はOSからしか取得できないためです。
・EC2の構成
まず下記の図の通り、EC2インスタンスはハイパーバイザ型の仮想化技術が用いられており、ホストサーバの上に仮想マシンを立ち上げてOS（LinuxやWindows）を実行しています。
・EC2の責任分界点
そしてEC2はIaaSサービスであるため、責任分界点モデルより、OS以上のレイヤーは全てユーザーの管理領域となります。（NRIセキュア ブログより画像引用）
・標準メトリクスで取得できない理由
つまりどういうことかというと、CloudWatch（AWS管理側）は管理領域外であるOSレイヤーのメトリクスを取得することが出来ないのです。そのため標準で取得できるメトリクスは、仮想化レイヤー以下に関係するCPU使用率やディスク読み込みバイト数、ネットワーク利用状況などに限られます。
一方、メモリの管理はOSの役割なので、CloudWatchエージェントなどでOSからメモリ使用率を抽出して、CloudWatchに送信する必要があります。またメモリに限らず、空きディスク領域やログインユーザー数など、OS内部でしか取得できないメトリクスも同様となります。
最後に
CloudWatchのメトリクスについて調べてみましたが、多くのAWS書籍やネット情報では標準メトリクスとカスタムメトリクスの分類ぐらいまでしか記載されておらず、その先まで触れられているものは殆どありませんでした。CloudWatchとはそういうものなんだ、と言ってしまえばそれまでかもしれませんが、今回色々調べていくうちに、自分の中で多くの気づきを得たり、各領域の繋がりを整理することが出来ましたので、今後も疑問に思ったことは調べて発信していきたいと思います。
参考