プログラミングはソースコードとして一つの機能を実現させるための手順書を記述するものです。
しかし、作成した本人でさえ どのような処理をしているかをコメントとして記述しておかなければ、容易に理解できないものです。
もし作成した直後であれば、様々なことが記憶に残っているので、このような問題に至らないのですが、しばらく時間を置いてから処理(ソースコード)を追いかける場合は、コメントがなければ必ず苦労することになります。
ましてや、他の開発者のものであれば、コメントがなければ、実に大変なおもいをすることになるでしょう。
さらに、そのソースコードに修正を加えていくことは、考えただけでも遠慮したくなるに違いありません。
以上のことから、コメントは自分にとっても、開発者にとっても重要で、プログラムの処理の流れを把握/理解するための仕様書といえます。
AWSの監視ツール「CloudWatch」で何？
CloudWatchは、AWSが提供する「フルマネージド運用監視サービス」で、AWSの各種リソースを監視してくれるもの。
・セットアップ不要で使える。
・異常な状態を検知して、自動で復旧までしてくれる。
・メトリクスに応じてアラート通知や、アクションを設定できる。
CloudWatchには3つのサービスがあります。
リソースを監視する「CloudWatch」
CPUやメモリなど複数項目をグラフ化してダッシュボードを作れます。
よく使うものは標準メトリクスとして用意されていて、クレジット（利用料金）も監視できる。
監視するだけじゃなくてリソースの状況に応じて、メールを送ったり、再起動したり、AutoScalingしたりとアクションができるのも特長です。
月額料金が一定額を超えたら通知することもできるようです。
ログを集めて監視する「CloudWatch Logs」
Amazon Linux、RedHat、Windowsなどに対応し、インスタンスにエージェントを入れることで各種ログを取得します。
OSに加えて、アプリケーションのログも対応していて、キーワードでアラート通知させることもできます。
つまり「アプリケーションやOSがエラーログ吐いたら管理者のメールに通知」が実現できるということです。
APIのイベントをトリガーに何らかのアクションを実行させる「CloudWatch Events」
AWSはさまざまな処理をAPIで実行しています。たとえばEC2インスタンスの起動停止もAPIで実行しています。
こういったイベントを監視するのがCloudWatch Events、ということです。
具体的には、インスタンスのterminate（削除）でアラート通知する、コンソールに特定のユーザがサインインしたときにアラート通知する、ということなんかができるようです。
トリガーになるイベントはこれ以外にもEC2ステータスやスケジュールなど数多く用意されていて、LambdaやSQS、SNSなどと連携できます。
プログラムの先頭にはヘッダコメントを設ける
仕様書は、プログラムの保守、機能拡張を行うときに参考にします。しかし、最終的には何を見るかというと、やはりプログラムです。
仕様書などは時としてプログラムの更新と同期していないことがありますが、プログラムは唯一真実を語るものです。
したがいまして、プログラムには仕様が明記されていなければならないのです。
仕様書よりは有効な開発支援となるものですから、必ずコメントを記述しています。（日本語で記述しています）
ヘッダー部は、プログラムが使用されなくなるまでソースプログラムについてまわるものなのです。