AWSからEC2インスタンスのメンテのお知らせがきました。
今回はサーバーの移行をする必要があり、Elastic Beanstalkで作成した環境がが対象になりました。

Elastic Beanstalkで作成した場合、EC2インスタンスコンソールで「同様のものを作成」をしてはいけないと思っていました（Elastic Beanstalk環境で作成されているものをEC2インスタンスで勝手に停止・起動などすると依存関係が壊れるとかで..）が、

Elastic Beanstalk は配下のインスタンスに異常を検知する場合、Auto Scaling 機能が働いて
問題のあるインスタンスを取り除き、新たにインスタンスを補充する動きをします。

その際にはあらかじめ設定されたアプリケーションがデプロイされるので、以前と同じ機能を持った
インスタンスが補充され元の状態へ復旧される、と考えることができます。

なので、今回は

EC2 管理コンソールより意図的にインスタンスを停止させ、その停止を検知して新規インスタンスでの置き換え処理が実行されることで、サーバの移行を行います。
EC2インスタンスの画面から対象になったElastic Beanstalkで作成した環境のインスタンスを右クリックで「インスタンスの状態→停止」の方法で移行ができるので簡単！

無事にサーバ移行できました。

他にも方法があるのでメモします。今回は3の手順を利用しました。

「環境のクーロン設定」により別の環境を作成する
Worker に対して「環境のクローン作製」を実行すると、同じ設定の Elastic Beanstalk 環境が作成されますが、SQS のキューは Elastic Beanstalk が作成したキューを利用している為、、既存のキューとは別の新しいキューが作成されます。
この為、「環境のクローン作製」で作成したElastic Beanstalk 環境へ移行を行う場合、メッセージを送信される SQS のキュー名をご変更する必要があるので注意。
つまり、環境の切り替えはメッセージを送信されるアプリケーション側の SQS のキュー名を切り替える事で実現されます。
新しい環境の切り替えを行って頂いた後、既存の環境を削除してください。
対象のインスタンスを任意の時刻に Stop する
インスタンスを Stop する事で自動的に新しいインスタンスが起動します。手元の環境で確認した所、 Elastic Beanstalk が提供しているサンプルアプリケーションで稼働している Worker の場合、およそ 5分で新しいインスタンスが稼働しました。
この方法では、新しいインスタンスが正常に稼働するまでの期間、サービスの停止が伴います。その為、サービスを停止しても問題無い時間帯にて実施する必要があります。

また、Stop したインスタンスは AutoScaling により自動的に Terminate される為、既存のインスタンスにデータ等を保管している場合は、事前に別のリソースへ退避する必要があります。

３. 環境タイプ負荷分散、Autoscaling を利用する
Worker を複数台同時稼働しても問題無いようであれば、「環境タイプ負荷分散、Autoscaling を利用する」方法もある。

負荷分散、Autoscaling を利用した入れ替え手順
　a. ElasticBeanstalk 環境の設定からスケーリング->環境タイプを「負荷分散、AutoScaling」へ変更。
　b. 「適用」をクリックし、設定が反映したら、 ElasticBeanstalk 環境の設定からスケーリング->Auto Scaling -> 最小インスタンス数を「2」へ変更
　c. ElasticBeanstalk 環境のヘルスカラ、2台インスタンスが正常に稼働している事を確認
　d. 稼働確認後、メンテナンス対象のインスタンスを削除
　e. d の操作でインスタンスが1台削除されるが、その後自動的に新しいインスタンスが起動してきます。
　f. 新しく起動したインスタンスの正常稼働を確認した後、ElasticBeanstalk 環境の設定からスケーリング->Auto Scaling -> 最小インスタンス数を「1」へ変更
　g. 以降 Worker 1台で稼働されたい場合は、ElasticBeanstalk 環境の設定からスケーリング->Auto Scaling -> 最大インスタンス数も「1」へ変更してください。

3 の手順では、サービスの停止が伴わないよう、複数の Worker を同時稼働させ、メンテナンス対象のインスタンスを停止させる方法になります。
こちらの手順においても、もし既存のインスタンスにデータ等を保管している場合は、事前に別のリソースへ退避してください。

2および3の手順では、既存の SQS キューをそのまま継続して利用致しますので、メッセージを送信されるアプリケーション側の設定の変更は必要ありません。