LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Amazon Linux 2023とは——AL2の後継として登場したディストリビューション

Amazon Linux 2023(AL2023)とは、AWSが2023年3月に公開したLinuxディストリビューションで、Amazon Linux 2(AL2)の後継にあたる版を指します^*6。AWSはAL2023を、高いセキュリティ水準・予測できるライフサイクル・一貫した更新体験という3つの原則で設計したと説明しています^*6。

AL2023はFedora Linuxなど複数のアップストリームを組み合わせて構築されており、RPMベースのパッケージ体系を採用しています^*4。カーネルはkernel.orgの長期サポート版から、他のディストリビューションとは独立して選定される点も特徴のひとつです^*4。

AL2023のサポートポリシー——標準サポートとメンテナンスを合わせた5年間

AL2023の各メジャーバージョンには、5年間の長期サポートが提供されます^*3*4。この5年間は2段階に分かれており、標準サポート期間中は四半期ごとにマイナーバージョンの更新が配布される仕組みです^*3。AL2023の標準サポートは2027年6月30日に終了する予定になっています^*3。

標準サポートの後はメンテナンス期間に移り、セキュリティ更新と重要な不具合修正のみが提供されるようになります^*3。この更新は準備が整った時点で随時公開される形をとります^*3。AL2023のメンテナンス期間は2029年6月30日に終わる予定です^*3。

新しいメジャーバージョンは2年おきに登場する計画ですが、AWSは2025年と2026年については新しいAmazon Linuxのメジャーバージョンを投入しないと表明しました^*1。新しいOSバージョンを出す際は1年前までに案内するとも述べられており、利用者側が移行計画を立てる時間を確保する狙いがうかがえます^*1。

glibc・OpenSSL・OpenSSH・DNFといったコアパッケージは、そのメジャーバージョンが存在する期間を通じて支援対象になります^*3。コア以外のパッケージは、それぞれの上流プロジェクトが定める支援方針に従う仕組みです^*3。個別パッケージの支援状況は、dnf supportinfoコマンドで確認できます^*3。

後継版であるAL2023を選ぶ動機のひとつが、前身のAL2のサポート終了です。AL2は2026年6月30日にサポートを終了しました^*2。AWSはこの期日より前にAL2023へ移行するよう案内していました^*2。すでに期日を過ぎているため、AL2をそのまま使い続けている環境では、更新の提供が止まった状態にあります。

AL2との違い——パッケージ管理・SELinux・カーネル・決定的アップデート

AL2023はAL2に対して、いくつかの点で設計思想が変わっています。第一に、標準のパッケージ管理ツールがYUMからDNFに切り替わりました^*4。DNFはYUMの後継として位置づけられているツールです^*4。

第二に、SELinuxの既定モードです。AL2023はSELinuxをpermissive(許可)モードで有効にした状態で提供されています^*7。強制(enforcing)モードへの切替は、起動時のcloud-initやコマンドラインから設定できます^*4。

第三に、インスタンスメタデータサービスの既定値です。AL2023はIMDSv2を既定で要求する設定になっています^*7。AL2の環境でIMDSv1に依存した処理が残っている場合、この既定値の違いが移行時の確認点になります^*7。

第四に、カーネルのバージョンです。AL2はLinuxカーネル4.14系と5.10系を基盤としていますが、AL2023はカーネル6.1系と6.12系を採用しています^*7。ネットワーク管理の仕組みも変わり、AL2のISC dhclientに代わって、AL2023ではsystemd-networkdがネットワークインターフェースを管理します^*4。

第五に、更新の考え方そのものです。AL2023は「決定的アップデート(deterministic updates)」と呼ばれる仕組みを採用し、AMIとパッケージリポジトリのバージョンを既定で固定します^*4*6。dnf updateを実行しても、そのままではインストール済みのパッケージは更新されません^*6。AWSはこの仕組みにより、同じAMI IDから起動したマシン同士でパッケージ構成をそろえやすくなる点を利点として挙げています^*6。AL2では単一の共通リポジトリを継続的に更新する方式だったため、起動時期が異なるインスタンス間でパッケージのバージョンにばらつきが生じやすい面がありました。

ほかにも、AL2023ではcgroup v2が既定になった点、cronが標準では導入されずsystemdタイマーへの移行が案内されている点、FIPS対応がFIPS 140-2からFIPS 140-3の証明に変わった点などが挙げられます^*7*4。amazon-linux-extrasの仕組みも廃止され、パッケージは名前空間化された形でひとつのコアリポジトリにまとまりました^*5。

両者の主な違いを整理すると次の通りです。

AL2からAL2023への移行の考え方——インプレース非対応と新規インスタンス作成

AL2023への移行を検討する際に押さえておきたいのが、既存のAL2インスタンスをそのままAL2023へ切り替える経路が用意されていない点です。AWSが公開している移行手順では、AL2023のAMIから新しいインスタンスを作成し、段階的に入れ替えていく進め方が示されています^*7。

具体的には、既存の起動テンプレートを複製してAMIだけをAL2023版に差し替え、新しいAuto Scalingグループやキャパシティプロバイダーを既存のクラスタに追加する形が紹介されています^*7。動作確認が取れた段階でAL2023側の比率を少しずつ高め、最終的にAL2側のインスタンスを停止していく流れです^*7。一度に切り替えるのではなく、比率を調整しながら検証する点がこの手順の要点だといえるでしょう。

移行前の準備としては、AL2とAL2023のパッケージ差分を確認する作業が案内されています^*5。あわせて、cronジョブをsystemdタイマーに書き換える準備を進めておくことも推奨されています^*5。cronはAL2023では既定で導入されないため、事前の棚卸しをしておくと切替後の対応にゆとりが生まれます^*5。

移行作業の実務——パッケージ差分の確認とcloud-init・cgroupの検証

実際の移行作業では、複数の観点からの確認が求められます。ひとつはアプリケーションが依存しているパッケージの有無です。AL2023では一部のパッケージが提供対象から外れており、32bitのユーザースペースパッケージも含まれていません^*4。EPEL(Extra Packages for Enterprise Linux)もAL2023では対象外になっています^*4。自社のアプリケーションがこれらに依存していないか、事前の洗い出しが欠かせません。

もうひとつはcloud-initの挙動の違いです。AL2023のcloud-initはパッケージリポジトリの管理を担うようになりました^*4。以前のAmazon Linuxではセキュリティアップデートをcloud-initが既定で導入していましたが、AL2023ではこの動作が既定から外れています^*4。加えて、リモートのユーザーデータ取得先に到達できない場合、以前は警告のみでしたが、AL2023では処理そのものが失敗する仕様に変わりました^*4。設定ミスによる意図しない起動を防ぎやすくなった一方、cloud-initの構成は移行時に見直す必要があります。

コンテナを運用している場合は、cgroupの版数にも注意が必要です。AL2023はcgroup v2が既定になっており、メモリ使用量の集計方法がAL2のcgroup v1と異なります^*7。同じワークロードでもページキャッシュの扱いが変わるため、AL2023上では見かけ上のメモリ使用率が上がって見える場合があります^*7。移行前にコンテナ基盤側でメモリ使用量を計測し、必要に応じてリソース制限を見直す作業が推奨されています^*7。

これらの確認を終えたうえで、検証環境でAL2023のAMIからインスタンスを起動し、アプリケーションやミドルウェアが問題なく動作するかをテストする流れになります。IMDSv2が既定で必須化されている点や、SELinuxがpermissiveモードで有効になっている点も、検証環境で挙動を確かめておきたい項目です^*7。

移行を進める体制——内製と外注の分かれ目

AL2023への移行は、AWSが手順を公開しているとはいえ、確認すべき観点が多岐にわたります。パッケージ差分の洗い出し、cloud-initやcgroupといった基盤部分の挙動確認、Auto Scalingやコンテナオーケストレーションとの連携まで、複数領域の知識が求められる作業です^*4*7。

対象インスタンスが少数で、依存パッケージの構成が単純な環境であれば、自社の運用担当者が手順を確認しながら対応できる場合もあります。判断が分かれるのは、対象台数が多い環境や、Auto Scaling・コンテナ基盤が複雑に組み合わさった構成での検証工数です。通常業務と並行して洗い出しから検証まで進めるには、まとまった時間の確保が課題になりやすいところです。

外部のパートナーに委託する場合は、依頼できる範囲の広さが選定の分かれ目になります。パッケージ差分の調査からcloud-init設定の見直し、段階的なインスタンス入れ替え、動作検証までを一括して任せられるかどうかを確認しておきたいところです。元請（プライムベンダー）として保守・運用を受託している事業者であれば、移行後の運用まで見据えた体制づくりを相談しやすくなります。

。移行対象のインスタンス数や、コンテナ基盤の有無によって必要な工数は変わってきます。現状の構成を診断したうえで、内製・外注の切り分けを検討する進め方が実務的だといえます。

まとめ：AL2023移行で押さえる3つの判断軸

本稿ではAmazon Linux 2023への移行とサポートの要点を、AWS公式情報をもとに整理しました。要点は3つに集約できます。第一に、AL2023は2023年3月に登場した後継ディストリビューションで、標準サポートとメンテナンスを合わせた5年間のライフサイクルが公式に示されています^*3*6。第二に、AL2はすでに2026年6月30日にサポートを終えており、後継となるAL2023への移行が実務上の焦点になっています^*2。第三に、AL2からAL2023への切替はインプレースのアップグレード経路がなく、新しいAMIでインスタンスを作り直しながら段階的に入れ替える進め方が基本になります^*7。パッケージ差分やcloud-init・cgroupの挙動確認まで含めると、対象規模に応じて内製と外注の判断が必要になってくるはずです。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS「Amazon Linux 2023 FAQs」（https://aws.amazon.com/linux/amazon-linux-2023/faqs/）
2. *2　出典：AWS「Amazon Linux 2 FAQs」（https://aws.amazon.com/amazon-linux-2/faqs/）
3. *3　出典：AWS「Release cadence」（Amazon Linux 2023 User Guide）（https://docs.aws.amazon.com/linux/al2023/ug/release-cadence.html）
4. *4　出典：AWS「Comparing AL2 and AL2023」（Amazon Linux 2023 User Guide）（https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html）
5. *5　出典：AWS「Prepare your migration to AL2023」（Amazon Linux 2 User Guide）（https://docs.aws.amazon.com/linux/al2/ug/prepare-for-al2023.html）
6. *6　出典：AWS News Blog「Amazon Linux 2023, a Cloud-Optimized Linux Distribution with Long-Term Support」（https://aws.amazon.com/blogs/aws/amazon-linux-2023-a-cloud-optimized-linux-distribution-with-long-term-support/）
7. *7　出典：AWS「Migrating from an Amazon Linux 2 to an Amazon Linux 2023 Amazon ECS-optimized AMI」（Amazon Elastic Container Service Developer Guide）（https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html）

Tweet