シェルバッチは書き換えなくていい — EC2で正しく動かす4つの作法

「クラウドに行くならシェルはLambdaに書き換え」という思い込みが、移行を何年も遅らせることがあります。実行環境がEC2になっても、シェルはそのまま動きます。書き換えないと決めたときに、代わりに何をすべきか——4つの作法に絞って説明します。

01作法①：起動をcron直書きからSSM／EventBridgeへ

サーバ内のcrontabに起動定義を書くのは、オンプレの悪習をそのまま持ち込む形です。EventBridge SchedulerからSSM Run Command経由でスクリプトを起動する形にすると、「いつ・誰が・何を実行して・結果がどうだったか」がAWS側に証跡として残ります。起動定義がサーバの外に出るので、サーバを作り直しても定義が消えません。時刻指定はタイムゾーン対応のSchedulerで（cron変換ツール）。

02作法②：ログをCloudWatch Logsへ

ログをローカルの/var/logに吐いて終わり、ではサーバ障害と一緒にログも失います。CloudWatch Agentでログを集約し、終了コードと「ERROR」等のパターンにメトリクスフィルタ＋アラームを設定します。これだけで「異常終了に朝まで気づかない」が消えます（詳しくは監視10選）。

03作法③：パスワードの直書きをやめる

スクリプト内のDBパスワード直書きは、オンプレでは「まあ社内だから」で見逃されてきましたが、クラウドでは即座に重大リスクです。Secrets Manager／Parameter Storeに移し、実行時に取得する形へ。この置き換えだけは「書き換えない」の例外として必ずやってください。数行の修正で済みます。

04作法④：サーバが落ちたときの割り切りを決めておく

バッチ用EC2を1台で運用するなら、「落ちたらどうするか」を先に決めます。最低限はEC2自動復旧（ハード障害での自動再起動）＋ジョブのべき等性（二重実行・途中再実行しても壊れない作り）の確保。べき等性だけは、既存スクリプトに手を入れる価値がある改修です。処理前のファイル退避と処理済みマーカーだけでも大きく変わります。

05この構成の寿命

「EC2でシェル続投」は恥ずかしい構成ではなく、証跡・監視・秘匿情報・復旧の4点を押さえれば監査にも耐える立派な本番構成です。その上で、改修の機会が来たジョブからコンテナやサーバーレスへ移していけばいい。全部を今すぐ書き換える必要は、どこにもありません。