負荷低すぎはもはや障害じゃないのかという記事の話。
そうすると、 『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』 みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか？
とのこと。
なんだけど、これはつまり経費削減で、持つリソース（営業経費）を有効に扱おうという話題であり、パフォーマンスチューニングの範疇ですよね。「ビジネス的な損失」っていう定義がわかんないけど、たとえば「サーバが落ちて機会損失で売上が減った」みたいなケースとは区別したほうがいいと思うんですが、どうでしょうか。
専門用語でいうパフォーマンスチューニングは、アプリケーションなりミドルウェアなりを調整して、リソースはCPUとかメモリとかネットワーク帯域なりの限られたリソースで収まるように使いましょうっていう問題領域だったと思います。ここで、ありがたいフォースにより強いリソースを使っても許されるという状況を考えるとする。誰がチューニングするでしょうか？
私はしません。
1-2日で対応できるとしても、後回しにします。これで仕事が減った！「余地があることを知っている」という状態が、混沌とした現状に心の安定を作り出します。
同様に、負荷低すぎ問題は経費削減圧力がどの程度存在するかによって、今対応すべきかが変わってくるはずです。「現状として低負荷だからリソースを削減していい」というのも難しい感じがあります。将来を見通さないと…。どこまで考えればいいのか。つらい。
まーよーするに、パフォーマンスチューニングは状況を見つつ対応するか考えようっていう、普通の話に落ち着くことができます。改善の余地があるのが、いわゆるクラウドの利点ですね。
対応優先度の検討には、対応の手間がどんだけかかるんだっけ？みたいな話も当然入ってくるので、ツール（aws_setuyaku）による解決はよさそうなので使うかもしれない。
そのうち。
今はまだいいかなとは思うけど。