EC2 Linux インスタンスのインスタンスタイプを変更する前に、どのような手順を実行する必要がありますか?

所要時間2分

私のシステムは、現在の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで利用可能となっているものよりも多くの CPU またはメモリを必要としています。インスタンスのサイズを変更する前にどのようなステップを実行して、移行が成功したことを確認するのですか ?

簡単な説明

EC2 Linuxインスタンスのインスタンスタイプを変更すると、以下を変更できます。

CPU コア数
RAM 容量
割り当てられたインスタンスストア領域の量
Amazon Elastic Block Store (Amazon EBS) 最適化
拡張ネットワーキング
GPU コア
FPGA
機械学習アクセラレーター

注: インスタンスとデータのバックアップを維持することがベストプラクティスです。インフラストラクチャを変更する前に、AMI を作成することまたは EBS ボリュームのスナップショットを作成することを検討してください。

解決方法

インスタンスタイプまたはインスタンスファミリーを変更する前に、現在のインスタンスタイプと新しいインスタンスタイプに互換性があるかどうかを確認します。次の一般的な問題は、インスタンスタイプを変更するときに互換性の問題を引き起こします。互換性の問題の詳細なリストについては、Compatibility for changing the instance type を参照してください。

互換性を確認したら、Amazon EBS-backed インスタンスのインスタンスタイプを変更できます。

インスタンスを停止する

インスタンスタイプを変更する前に、インスタンスを停止する必要があります。インスタンスを停止して起動する前に、必ず以下の点に留意してください。

インスタンスがインスタンスストアでバックアップされているか、データを含むインスタンスストアボリュームがある場合、インスタンスが停止するとデータが失われます。ある Instance store-Backed インスタンスから別の instance store-backed インスタンスに移動する場合は、自身の instance store-backed インスタンスを移行する必要があります。詳細については、Migrate an instance store-backed instance を参照してください。
インスタンスが Amazon EC2 Auto Scaling グループの一部である場合、インスタンスを停止するとインスタンスが終了することがあります。Amazon EMR、AWS CloudFormation、または AWS Elastic Beanstalk を使用してインスタンスを起動した場合、インスタンスは AWS Auto Scaling グループの一部である可能性があります。このシナリオでインスタンスが削除されるかどうかは、Auto Scaling グループのインスタンススケールイン保護の設定によって異なります。インスタンスが Auto Scaling グループの一部である場合は、解決手順を開始する前に、一時的に Auto Scaling グループからインスタンスを削除してください。
Elastic IP アドレスを使用していない場合、インスタンスを停止して起動すると、インスタンスのパブリック IP アドレスが変更されます。インスタンスに外部トラフィックをルーティングする際は、パブリック IP アドレスではなく Elastic IP アドレスを使用することをお勧めします。Route 53 を使用している場合は、パブリック IP が変更されたときに Route 53 DNS レコードを更新する必要がある場合があります。

拡張ネットワーキング

拡張ネットワーキングをサポートするインスタンスに変換する場合は、必要なドライバをインストールし、現在のインスタンスで拡張ネットワーキングを有効にしてください。詳細については、「Linux での拡張ネットワーキング」を参照してください。

Nitro ベースのインスタンスタイプ

インスタンスを Nitro ベースのインスタンスタイプに変更することを計画している場合は、次の手順を実行します。

NVMe モジュールと ENA モジュールがインスタンスにインストールされていることを確認します。
/etc/fstab にリストされているブロックデバイスが NVMe ブロックデバイス名 (/dev/nvme1、/dev/nvme2 など) と互換性があることを確認します。
Amazon Elastic Block Store (Amazon EBS) ボリュームは、NVMe デバイスとしてこれらのインスタンスタイプに公開されますが、デバイス名は停止/起動イベントで変更されます。ボリュームの不一致を避けるため、ファイルシステムの UUID またはラベルを使用してファイルシステムをマウントします。

これらのチェックを自動化するには、NitroInstanceChecks スクリプトを実行します。詳細については、タイプを Nitro ベースのインスタンスタイプに変更した後、Linux インスタンスが起動しないのはなぜですか? を参照してください。Run the NitroInstanceChecks script のセクションの指示に従います。

スクリプトが実行され、必要な更新がすべて行われたら、/etc/udev/rules.d/70-persistent-net.rules の DRIVERS エントリが ? または ENA に設定されていることを確認します。

テキストエディタを使いファイルを開きます。次の例では、vi エディタを使用します。

vi /etc/udev/rules.d/70-persistent-net.rules

正しいエントリは次のように表示されます。

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="01:23:45:67:89:ab", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0

Networking on current generation instances

現行世代のインスタンスは、Virtual Private Cloud (VPC) でのみ起動されます。現在のインスタンスが EC2-Classic インスタンスである場合は、インスタンスを VPC 内の Linux インスタンスに移行します。

混合 EC2 アーキテクチャ

インスタンスのソース AMI が特定のアーキテクチャ用に構築されている場合、作成できるのは同じアーキテクチャのインスタンスタイプに制限されます。特定のアーキテクチャ向けに構築された AMI の例としては、32 ビット (i386)、64 ビット (x86_64)、64 ビット ARM (arm64) などがあります。これは、インスタンスが mac1 インスタンスタイプ用に作成された AMI を実行している場合にも当てはまります。これらのイメージをインスタンスタイプ間で移動することはできません。