発端
私はインフラ（AWS）周りのテックリードとして、社内のプロジェクトで発生した困りごとの対応をしています。
今日あるプロジェクトにて、「EC2のCPU使用率が急上昇したので原因を調査したい。一緒に見てくれないか」と依頼を受けたので一緒に調査した。
まずは該当のEC2のCPU使用率を確認
そのプロジェクトのインフラ構成はシンプルなALB+EC2インスタンス2台。
通常時の平均CPU使用率は10%だが、2台とも同じタイミング（深夜1:40~2:00頃）に60%まで上昇し、その後10%に戻っていることをCloudWatchメトリクスから確認できた。
2台同時ということは各EC2インスタンスがそれぞれ固有で使用しているリソースが原因ではなさそう（EBSとか)。
データベースのメトリクスを確認
このプロジェクトではデータベースとしてAurora for PostgreSQLを使用していた。
当時間帯に絞ってメトリクスを見たが、こちらは問題なし。
キャッシュサーバーのメトリクスを確認
キャッシュサーバーとしてElastiCacheを使用していたので同じくメトリクスを見たが、こちらも問題なし。
ALBのアクセスログを確認
ALBはデフォルトでアクセスログを取れないのだが、このプロジェクトのALBは有効になっていた。
ログを確認すると見慣れないパス（/.credential、/storage的な）へのアクセスログが大量に出てきた。・・・怪しい。
まあセキュリティの会社が脆弱性診断のために意図的に意図的に攻撃的なパスでリクエストを送るパターンもあるが、深夜&事前連絡なしであることを考慮するとあり得ない。
ログに残っている送信元IPアドレスも海外のものだった。
悪意のある第3者が大量リクエストを送った結果、CPU使用率が上がった。
今回の問題点
AWSコンソールを画面共有して色々見せてもらうと、外部からこのALBへのアクセス許可がされていた。
普通はALBに紐づくセキュリティグループで送信元IPアドレスを絞れるが、プロジェクトの要件上いろんなユーザーからアクセスできるようにする必要があるため全開放していた。
あと問題なのがEC2にオートスケーリング設定が入っていなかったこと。
これでは万が一大量アクセス継続して実行されるとEC2インスタンスが処理しきれず通常リクエストも捌けなくなる。
（今回のアクセスは瞬間的だから良かった。）
対策案
今回私からプロジェクト担当者に提案したのは以下２つ
AWS WAFの導入
WAFならレートリミットをかけられるし、IP/地域で絞ることもできる。
ALBなら直接WAFをアタッチできる。よりセキュアになるし、WAFはそこまでコストもかからない。
（特別なAWSマネージドルールを付与するなら別料金がかかるが、今回は取り急ぎ不要と考えた）
ただしWAFをいきなり導入すると通常リクエストも弾く可能性があるので、まずはカウントモードで試すよう伝えた。
EC2オートスケーリングの設定
WAF導入は（上記フローを考慮すると）やや手間と時間がかかるので、まずはサクッと設定できるこちらを実施するよう伝えた。
アクセスログをCloudWatch Logsに出力する
今回はALBのログから調査できてよかったが、このプロジェクトではインスタンスで稼働しているアプリログが確認できなかったのでCloudWatch Logsに出力するよう伝えた。