結論
Elastic Beanstalk の構成設定(インスタンス設定)で、他の用途で使っている inbound SSH all 許可を設定したセキュリティグループを割り当ててはいけない.
問題
EC2 オンプレのアプリケーション環境と、Elastic Beanstalk アプリケーション環境を並行して運用している状態において、EC2 インスタンスに設定してあるセキュリティグループの SSH inbound 設定がいつの間にか外れてしまうという事象にたびたび遭遇していた.
調査
CloudTrail でアクティビティ履歴を追ってみる
アクティビティ履歴には RevokeSecurityGroupIngress として、セキュリティグループの設定が変更されたような記録が残っているが、 ConsoleLogin 前に実行されており、また、API 経由でのセキュリティグループ設定変更についても心当たりがない.
eb ssh してみる
CloudTrail には Elastic Beanstalk を使っているプロジェクトの担当者名が残っていた ＆ ConsoleLogin 前にやりそうなこととすると eb ssh か？と思い、やってみたら、気になるメッセージが.
$ eb ssh
INFO: Attempting to open port 22.
INFO: SSH port 22 open.
:
INFO: Closed port 22 on ec2 instance security group.
マニュアル読む
しっかりマニュアルに書いてあった.
eb ssh で -o オプションを指定していないと、 セッションの終了時にセキュリティグループ設定を自動変更してくれている らしい.
環境のセキュリティグループでポート 22 に関するルールが指定されていない場合、このコマンドは、0.0.0.0/0（すべての IP アドレス）からの受信トラフィックについてポート 22 を自動的に開きます。
(中略)
-o または --keep_open
SSH セッションの終了後に、EB CLI はポート 22 を閉じません。
まとめ
Elastic Beanstalk でインスタンス設定するときは、わざわざ SSH open のセキュリティグループを割り当ててやる必要はない. むしろ、そのセキュリティグループが他の用途でも使われていると eb ssh のたびに変更されることになってハマることになる. (というか、マニュアル読みましょう、という話.)