こんにちは！イーゴリです。
EC2を運用している場合、OSのEOL（End of Life）への対応は避けて通れません。 EOL対応では単にOSを入れ替えるだけではなく、インフラ構成や運用方法の見直しが必要になることもあります。
本記事では、EC2のLinux EOL対応を行う際に検討しておきたいポイントと移行方法について紹介します。
EOL対応の事前準備
マネージドサービスへの移行検討
いきなりですが少し別の視点になります。EOL対応を機に、可能であればマネージドサービスへの移行も検討してみてください。
例えばAmazon ECS on AWS FargateやRDSなどのサービスを利用することで、EC2のEOL対応やインスタンスの入れ替え作業を減らすことができます。もちろん、マネージドサービスであっても運用作業が完全になくなるわけではありませんが、数年ごとに一気に数百台のEC2を入れ替えるような作業を削減できる可能性があります。
もしこの方法が要件に合わない場合は、以下の項目に進んでください。
新しいOSで何が変わるのかを理解する
まず最初に、新しいOSで何が変わるのかを理解することが重要です。
例えばAmazon Linuxの場合、Amazon Linux 1とAmazon Linux 2は同じ系統のディストリビューションですが、 Amazon Linux 2023はこれまでとは異なる設計思想を持つ新しいディストリビューションとなっています。
そのため、従来の設定やツールがそのまま動作しない可能性があります。
詳細については以下の記事も参考になります。
IPアドレス変更の影響を確認する
移行時に重要になるポイントの一つが IPアドレスの変更が許容できるかどうかです。
IP変更が問題ない場合は、新しいEC2を作成して移行する方法がシンプルです。
一方でIPアドレスの変更が許容されない場合は、以下のような手順になることがあります。
事前に新しいEC2を作成
必要な設定を完了
メンテナンス時間にENIを切り替える
このような場合には、以下の記事で紹介しているツールが役立つことがあります。
このツールを使うことで既存EC2の設定をもとにCloudFormationテンプレートを生成できるため、 複数のEC2を移行する場合でも オペミスを防ぐことができます。
なお、EOLのタイミングは、IPアドレスへの依存をなくす良い機会ではないでしょうか。
既存ソフトウェアの動作確認
新しいOSで既存のソフトウェアが動作するかどうかも事前に確認する必要があります。
アプリケーションだけではなく、CloudWatch Agentなどのミドルウェアや運用ツールも確認対象になります。
例えばCloudWatch Agentの場合、Amazon Linux 2では特別な設定なしで動作していましたが、Amazon Linux 2023では rsyslogのインストールが前提条件となる場合があります。
詳しくはこちらの記事を参照してください。
コスト最適化の検討
OS移行は、コスト最適化を見直す良い機会でもあります。
例えば以下のようなポイントを検討できます。
x86からArm（Graviton）への移行
インスタンス世代の更新
EBS gp2 → gp3への変更
Instance Sizeの見直し
EBS容量の削減
特にArmインスタンスはコストパフォーマンスが高いですが、一部のソフトウェアが対応していない場合もあるため、十分な検証が必要です。 なお、RDSはマネージドサービスのため、x86からArm（Graviton）への移行は比較的スムーズに行えますが、パフォーマンスについては十分に検証した上でご判断ください。
セキュリティの見直し
移行のタイミングでセキュリティ設定も見直しましょう。
例えば以下のような項目です。
EBS暗号化
IMDSv1 → IMDSv2移行
EBSに個人情報や機密データが保存されている場合は、EBS暗号化を必ず検討するべきだと思います。
IMDSv2への移行も推奨されていますが、一部ソフトウェアが対応していない場合があるため、テスト環境での確認が必要です。
例えば、Datadogの監視設定では、IMDSv1を使用している場合、特別な設定を必要としませんが、IMDSv2を使用する場合は、「ec2_prefer_imdsv2」オプションを「false」から「true」に変更しないと、インスタンスIDを取得できず、ホスト名の識別が正しく行われないことがあります。また、Datadog AgentがインストールされているEC2をクローンすると、オプションが「false」のままの場合、ホスト名がクローン元のEC2と同じまま残ってしまうことがあります。 blog.serverworks.co.jp
自動化の検討
EOL対応では多くの作業が発生するため、可能な限り自動化を検討しましょう。
例えば以下のサービスが活用できます。
CloudFormation（EC2の構築等）
UserData（CloudFormationから指定し、パッケージのインストールやOS内の初期設定を実行）
Systems Manager Run Command（設定変更や適用等）
設計やスクリプト作成には時間がかかることもありますが、EOL対応は数年ごとに発生するため、長期的には自動化及び標準化のメリットが大きくなります。
手順の標準化
すべての作業を自動化できない場合でも、手順を標準化することが重要です。 パラメータを変数化しておくことで、誰が作業しても同じ結果になるようにでき、運用ミスを減らすことができます。
命名規則の整理
EC2の命名規則も見直す良いタイミングです。
例えばCloudWatch Agentのlog_stream_name設定では、 固定値（インスタンス名やIP等）ではなく
{instance_id}
のような変数を使うことで、EC2クローン時の作業を簡略化できます。
具体例については、以下のAWSドキュメントをご参照ください。
また、新しいEC2の名前も事前に決めておくと運用がスムーズになります。例えば以下のような命名も考えられます。
既存インスタンス名 + _AmazonLinux2023
移行完了後は、「Resource Groups & Tag Editor」を利用して一括リネームすることも可能です。
スナップショット管理
EC2移行ではEBSスナップショットが増えることがあります。
そのため、以下のようなルールを決めておくことが重要です。
スナップショット保持期間
削除タイミング
自動削除の仕組み
不要なスナップショットを放置すると、EC2が多い環境では大きなコストにつながる可能性があります。EOLに関連することが分かるスナップショット名を付けておくと、スナップショットの管理がさらに楽になります。
また、新旧EC2の移行に伴うEBSスナップショットの削除の仕組みやルールが用意されていない場合は、各スナップショットをどのくらいの期間保持するのかを必ず確認する運用をルール化しておくことをおすすめします。
事前に保持期間を決めておかないと、後から不要なEBSスナップショットを整理するための対応や新たな案件が発生する可能性があります。
新旧リソースの差分確認方法
設計ミスやオペミスによって差分が発生することは0ではないため、新旧リソースの差分を確認する仕組みを事前に考えておく必要があります。
一番手頃で導入コストがかからない方法としては、describe-instances / describe-instance / describe-volumes などの情報を取得し、diffコマンドやVS Codeなどで差分を確認する方法があります。 この方法であれば、どの項目に差分があるのかを比較的簡単に把握できます。 一方で、取得したJSONには、タイムスタンプなど案件上あまり意味を持たない項目が含まれており、それらも差分として検出されることがあります。 そのため、不要な項目を除外し、本当に確認したい差分だけを出力するスクリプトを用意しておくと、確認作業を効率化できます。
EC2のEOL対応における移行方法
ブルーグリーンデプロイ（旧EC2と新EC2の並行稼働）
EC2の再構築
インプレースアップグレード
それぞれメリット・デメリットがあるため、環境や要件に応じて適切な方法を選択する必要があります。
ブルーグリーンデプロイ（旧EC2と新EC2の並行稼働）
IPアドレスへの依存がない場合、この方法が個人的には一番良いと思います。
この方法では、新しいOSでEC2を構築し、旧EC2と新EC2を一定期間並行稼働させます。 下記の方法を利用すると、既存EC2と同じパラメータ、または少し変更したパラメータでEC2をすぐに作成できますので、参考にしてください。
その後、ロードバランサーやDNSなどでトラフィックを新しいEC2へ切り替えます。
この方法のメリットは以下です。
- 切り替え/切り戻しが容易で、短時間で対応できる
- 本番環境に近い状態で十分なテストができる
- ダウンタイムを最小化できる
IPアドレスへの依存がない環境では、この方法が最も安全な移行方法になることが多いです。
また、EOL対応のタイミングは、IPアドレスに依存しない構成へ改善する良い機会でもあります。 可能であれば、ロードバランサーやRoute 53などを活用し、IPアドレスに依存しない構成を検討することをおすすめします。
EC2の再構築
この方法では、既存のEC2を削除してから新しいEC2を作成します。 事前に新規EC2で実施できる作業を完了させておき、メンテナンス時間に既存EC2のENIを保護した上でEC2を削除します。その後、新しいEC2を作成し、既存のENIをアタッチすることで環境を復元します。
このパターンの場合、作業が増えるため、切り替えに必要な時間も増えます。 なお、以下の点にも注意が必要です。
- 切り替え/切り戻しに比較的時間がかかる
- 作業が増える分メンテナンス時間を増やす必要がある
- 比較的に大きなダウンタイムが発生する
IPアドレスの変更が許容できない場合は、事前に新しいEC2を作成し、メンテナンス時間にENIを切り替える方法も検討できます。
また、複数のEC2を移行する場合は、既存EC2の設定をもとにCloudFormationテンプレートを自動生成するツールを利用することで、作業の効率化やオペミスの防止につながります。
インプレースアップグレード
インプレースアップグレードでは、既存のEC2上でOSを直接アップグレードします。
一見するとシンプルに見える方法ですが、以下のようなリスクがあります。
- OSアップグレードに失敗した場合、追加の調査や別の移行方法等を検討する必要があり、対応に時間がかかる可能性がある
- 環境の再現性が低い
- 構成が複雑化する可能性がある
- 長期間運用されたサーバーでは設定のドリフトが発生している可能性がある
- 環境をコード化（Infrastructure as Code）しにくい
そのため、インプレースアップグレードよりも、新しいEC2を作成して移行する方法（ブルーグリーンデプロイや再構築）が推奨されることが多いです。
また、失敗時には事前に取得したAMIからEC2を復元する必要があるため、既存EC2の設定をもとにCloudFormationテンプレートを自動生成するツールを利用することで、作業の効率化やオペミスの防止につながります。
作業の流れとしては、AMIの取得およびCloudFormationテンプレートの作成 → OSアップグレード → 失敗した場合はENIを保護 → EC2を削除 → 取得したAMIから復元、といった流れになると思います。
EOL対応の事後作業
あくまで大まかなチェック項目としてここに記載していますが、案件によって事後作業の内容は異なると思います。
- 旧EC2と新EC2の差分を比較し、問題がないか？
- 下記のような不要なリソースが削除されているか？
- 不要なスナップショット（EOLに関連することが分かるスナップショット名があると、残っているスナップショットをすぐに確認できます）
- Availableステータスの不要なENI
- CFnにより作成されたLaunchTemplate
- 旧EC2や関連リソース
- インスタンス名が合っているか？
- 対象インスタンスが正常に監視されているか？
まとめ
EC2のLinux EOL対応では、単純なOS更新だけでなく、以下の点などを総合的に検討することが重要です。
- OS変更による仕様差分の確認
- IPアドレス変更の影響
- ソフトウェア互換性
- コスト最適化
- セキュリティ強化
- 自動化
EC2のEOL対応は、上記のような環境改善を進める良いタイミングだと思います。
以上、御一読ありがとうございました。
本田 イーゴリ (記事一覧)
カスタマーサクセス部
・2024 Japan AWS Top Engineers (Security)
・AWS SAP, DOP, SCS, DBS, SAA, DVA, COA, CLF, ANS, AIF, MLS, MLA, DEA
・Azure AZ-900
・EC-Council CCSE
趣味：日本国内旅行(47都道府県制覇)・ドライブ・音楽
