【ITニュース解説】Amazon EKS to Deprecate AL2 AMIs: How to Migrate with eksctl

Amazon Elastic Kubernetes Service（EKS）は、サービスを利用するユーザーにとって重要な変更を発表した。これは、仮想マシンを動かすための基本的なソフトウェアである「Amazon Linux 2（AL2）」のイメージ（AMI）の提供を将来的に終了する、という内容だ。具体的には、2025年11月26日以降、EKSで最適化されたAL2 AMIは新しく公開されなくなる。

この変更に深く関わるのが、コンテナ化されたアプリケーションを管理するシステムであるKubernetesのバージョンだ。Kubernetes 1.32が、AL2 AMIをサポートする最後のバージョンとなる予定である。そのため、Kubernetes 1.33以降のバージョンでは、EKSは「Amazon Linux 2023（AL2023）」または「Bottlerocket」という新しい種類のAMIのみを提供することになる。現在AL2のワーカーノード（実際にアプリケーションが動作するサーバー）を使ってEKSクラスターを運用している場合、Kubernetesのバージョンを1.32より新しいものにアップグレードする前に、必ず新しい種類のOSイメージに移行しなければならないことを意味する。

なぜこのような変更が行われるのかというと、AWSがより現代的なオペレーティングシステムへの移行を推進しているためだ。AL2は長年AWSの標準として利用されてきたが、その後継となるAL2023や、コンテナの実行に特化したBottlerocketには、AL2にはない多くの利点がある。

AL2023はAL2の直接の後継であり、長期的なサポート、将来の更新スケジュールを予測しやすいリリースサイクル、そしてより迅速で効率的なセキュリティパッチの提供といったメリットがある。一方、Bottlerocketはコンテナに特化したOSで、システムの中核となる部分が変更できないように保護されている（イミュータブルなルートファイルシステムを持つ）。これにより、攻撃を受ける可能性のある範囲が狭まり、セキュリティが強化されるという特徴がある。

これらの新しいOSはどちらも、予測可能なアップデートや、最初からセキュリティを考慮した設定などによって、システムのセキュリティを大きく向上させる。また、クラウド環境で動かすことを前提としたアプリケーションのパフォーマンスを最適化し、Kubernetes 1.32以降の将来のバージョンにもスムーズに対応できる土台を提供する。

この変更がEKSユーザーに具体的に何を意味するかというと、もし現在のクラスターがAL2ノードグループで動いている場合、Kubernetes 1.32まではそのまま使い続けることができる。しかし、Kubernetes 1.33以降にアップグレードを計画しているならば、その前に必ずノードをAL2023またはBottlerocketに移行する必要がある。さらに重要な点として、2025年11月26日以降は、たとえ古いKubernetesバージョンにとどまったとしても、AL2 AMIの新規公開やセキュリティパッチは提供されなくなる。これは、古いAL2ノードを使い続けると、セキュリティリスクにさらされる可能性が高まるため、計画的な移行が非常に重要となる。

幸いなことに、この移行のために既存のクラスター全体を最初から作り直す必要はない。EKSクラスターを管理するためのコマンドラインツールである「eksctl」を使えば、現在動いているクラスターのコントロールプレーン（クラスター全体を管理する部分）や、そこで動いているアプリケーションをそのままにした状態で、ノードグループを新しいものに置き換えたり、既存のノードグループをその場でアップグレードしたりできる。

具体的な移行戦略はいくつかある。

一つの方法は、既存のAL2ノードグループを動かしながら、新しくAL2023ノードグループを追加する方法だ。これは、既存のアプリケーションに影響を与えずに、新しい環境を準備できる点で安全な方法だ。eksctl create nodegroupコマンドを使って、新しいAL2023ベースのノードグループをクラスターに追加する。例えば、--ami-family AmazonLinux2023というオプションを指定するだけで、AL2023のOSイメージを使ったノードグループが作成される。新しいノードグループが正常に動作し始めたら、次に古いAL2ノードから実行中のアプリケーションを安全に退避させる。これはkubectl drainコマンドで行い、ノード上のアプリケーションを新しいAL2023ノードに移動させる。すべてのワークロードが退避され、古いAL2ノードが空になったら、eksctl delete nodegroupコマンドで古いAL2ノードグループを削除すればよい。

もう一つの方法は、既存のノードグループをAL2023に直接アップグレードする方法だ。これは、設定を記述したcluster.yamlというファイルの中で、ノードグループのOSイメージの種類をamiFamily: AmazonLinux2023に変更し、eksctl upgrade nodegroupコマンドを実行する。このコマンドは、古いノードに新しいワークロードが割り当てられないようにし（コーディング）、実行中のアプリケーションを安全に退避させ（ドレイン）た上で、自動的にAL2023ベースの新しいノードに置き換えてくれる。この方法は、手作業が少なく、効率的にアップグレードを進められる利点がある。

最後に、もしセキュリティを特に重視する、またはコンテナ化されたワークロードのみを実行しているような場合には、Bottlerocketへの移行も有力な選択肢となる。eksctl create nodegroupコマンドで--ami-family Bottlerocketを指定することで、Bottlerocketベースのノードグループを簡単に作成できる。

移行が完了したら、新しいノードが意図したOSで動いていることを確認することが重要だ。kubectl get nodes -o wideコマンドを実行すると、クラスター内のすべてのノードの情報が表示され、その中にOSの種類も含まれる。また、kubectl describe node <ノード名> | grep "OS Image"コマンドを使うことで、特定のノードがどのOSイメージを使っているかを詳細に確認できる。AL2023に移行したノードであれば「Amazon Linux 2023」、Bottlerocketに移行したノードであれば「Bottlerocket OS」といった表示が期待される。

移行を安全かつスムーズに進めるためのベストプラクティスがいくつかある。まず、本番環境に適用する前に、必ずステージング環境や開発環境といったテスト環境で十分に検証を行うべきだ。また、一度にすべてのノードを更新するのではなく、順次ノードを置き換えていく「ローリングアップグレード」の手法を用いることで、サービスへの影響を最小限に抑えることができる。eksctlの設定ファイルであるcluster.yamlは、バージョン管理システム（Gitなど）で管理し、変更履歴を残しておくことで、将来のアップグレードや問題発生時のロールバックを容易にする必要がある。最後に、移行後にはAWS CloudWatchやKubernetesのメトリクス（性能指標）を監視し、アプリケーションが期待通りに動作しているか、パフォーマンスに問題がないかを確認することが非常に重要となる。

Amazon EKSがAL2 AMIのサポートを終了するという発表は、EKSユーザーにとって大きな変更だが、同時に既存のシステムを最新化し、より安全で高性能な環境へ移行する良い機会だ。短期的には、Kubernetes 1.32まではAL2を使い続けることが可能だが、長期的にはAL2023（AL2の最も近い後継）またはBottlerocket（セキュリティに特化したOS）への移行が必須となる。2025年11月の期限に間に合うように、早期に移行計画を開始し、eksctlを活用してノードグループのアップグレードを進めることで、スムーズな移行を実現できるだろう。