# Amazon EC2 インスタンスタイプの変更
ニーズが変わるにつれて、インスタンスの利用率が高すぎたり (インスタンスタイプが小さすぎる)、低すぎたりする (インスタンスタイプが大きすぎる) ことに気付く場合があります。この場合は、インスタンスタイプを変更することでインスタンスのサイズを変更できます。例えば、ワークロードに対して `t2.micro` インスタンスが小さすぎる場合は、`t2.large` などのより大きな T2 インスタンスタイプに変更することで、サイズを大きくすることができます。また、`m5.large` などの別のインスタンスタイプに変更することもできます。また、IPv6 への対応など、いくつかの機能を利用するために、旧世代のインスタンスタイプから現世代のインスタンスタイプに変更することもできます。
既存のワークロードを処理するのに最適なインスタンスタイプにレコメンデーションが必要な場合は、AWS Compute Optimizer を使用することができます。詳細については、「[Compute Optimizer から EC2 インスタンスの推奨事項を取得する](ec2-instance-recommendations.md)」を参照してください。
インスタンスタイプを変更する場合、新しいインスタンスタイプのレートの課金が開始されます。すべてのインスタンスタイプのオンデマンド料金については、「[Amazon EC2 オンデマンド料金](https://aws.amazon.com/ec2/pricing/on-demand/)」を参照してください。
インスタンスタイプを変更せずにインスタンスにストレージを追加するには、EBS ボリュームをインスタンスに追加します。詳細については、「Amazon EBS ユーザーガイド」の「[インスタンスへの Amazon EBS ボリュームのアタッチ](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-attaching-volume.html)」を参照してください。
## どの手順に従うべきですか？
インスタンスタイプを変更するには、さまざまな手順があります。使用する手順は、インスタンスのルートボリューム、およびインスタントタイプがインスタンスの現在の設定と互換性があるかどうかによって異なります。互換性が決定される方法については、「[インスタンスタイプ変更の互換性](resize-limitations.md)」を参照してください。
次の表を使用して、従う手順を決定します。
| ルートボリューム | 互換性 | 以下の手順に従います |
| --- | --- | --- |
| EBS | 互換性あり | [インスタンスタイプを変更する](change-instance-type-of-ebs-backed-instance.md) |
| EBS | 互換性なし | [新しいインスタンスタイプに移行する](migrate-instance-configuration.md) |
| インスタンスストア | 該当しない | [新しいインスタンスタイプに移行する](migrate-instance-configuration.md) |
# インスタンスタイプ変更の互換性
インスタンスの現在の設定が目的のインスタンスタイプと互換性がある場合にのみ、インスタンスタイプを変更できます。使用するインスタンスタイプに既存のインスタンス設定との互換性がない場合、インスタンスタイプに対応した設定を持つ新しいインスタンスを起動して、アプリケーションを新しいインスタンスに移行する必要があります。
互換性は、次のように決定されます。
**仮想化タイプ**
Linux AMI では、2 つの仮想化タイプ (準仮想化 (PV) およびハードウェア仮想マシン (HVM) ) のどちらかを使用します。PV AMI から起動したインスタンスの場合、HVM のみのインスタンスタイプに変更することはできません。詳細については、[仮想化タイプ](ComponentsAMIs.md#virtualization_types)を参照してください。インスタンスの仮想化タイプを確認するには、Amazon EC2 コンソールで **[Instances]** (インスタンス) 画面の詳細ペインの **[Virtualization]** (仮想化) の値を参照します。
**アーキテクチャ**
AMI はプロセッサのアーキテクチャに固有であるため、プロセッサアーキテクチャーが現在のインスタンスタイプと同じインスタンスタイプを選択する必要があります。例:
+ 現在のインスタンスタイプが、Arm アーキテクチャに基づくプロセッサである場合、対象となるインスタンスタイプは、Arm アーキテクチャベースのプロセッサ (C6g や M6g など) をサポートするものに制限されます。
+ 32 ビット AMI をサポートするのは以下のインスタンスタイプのみです。`t2.nano`、`t2.micro`、`t2.small`、`t2.medium`、`c3.large`、`t1.micro`、`m1.small`、`m1.medium`、および `c1.medium`。32 ビットインスタンスのインスタンスタイプを変更する場合は、これらのインスタンスタイプに制限されます。
**ネットワークアダプター**
ドライバーのネットワークアダプターを別のネットワークアダプターに切り替えると、オペレーティングシステムが新しいアダプターを作成したときに、ネットワークアダプターの設定がリセットされます。設定を再構成するには、管理者権限を持つローカルアカウントへのアクセスが必要な場合があります。ネットワークアダプターを別のネットワークアダプターに切り替える例を次に示します。
+ AWS PV (T2 インスタンス) からインテル 82599 VF (M4 インスタンス)
+ インテル 82599 VF (ほとんどの M4 インスタンス) から ENA (M5 インスタンス)
+ ENA (M5インスタンス) から高帯域幅の ENA (M5nインスタンス)
**拡張ネットワーク**
[拡張ネットワーク](enhanced-networking.md)をサポートするインスタンスタイプでは、必要なドライバーがインストールされていなければなりません。例えば、[Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)には Elastic Network Adapter (ENA) ドライバーがインストールされた EBS-backed AMI が必要です。拡張ネットワーキングをサポートしていないインスタンスタイプから、拡張ネットワークをサポートするインスタンスタイプに変更するには、インスタンスに [ENA ドライバー](enhanced-networking-ena.md)または [ixgbevf ドライバー](sriov-networking.md)を適切にインストールする必要があります。
ENA Express を有効にしてインスタンスのサイズを変更する場合、新しいインスタンスタイプも ENA Express をサポートしている必要があります。ENA Express をサポートしているインスタンスタイプのリストは、「[ENA Express でサポートされるインスタンスタイプ](ena-express.md#ena-express-supported-instance-types)」を参照してください。
ENA Express をサポートするインスタンスタイプから ENA Express をサポートしないインスタンスタイプに変更するには、インスタンスをサイズ変更する前に、ENA Express が現在有効になっていないことを確認します。
**NVMe**
[Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)では、EBS ボリュームは NVMe ブロックデバイスとして公開されます。NVMe をサポートしないインスタンスタイプから NVMe をサポートするインスタンスタイプに変更するには、まずインスタンスに NVMe ドライバーをインストールする必要があります。また、ブロックデバイスマッピングで指定したデバイスのデバイス名は、NVMe デバイス名 (`/dev/nvme[0-26]n1`) を使用して変更されます。
[Linux インスタンス] したがって、`/etc/fstab` を使用してブート時にファイルシステムをマウントするには、デバイス名の代わりに UUID/Label を使用する必要があります。
**ボリュームの制限**
インスタンスにアタッチできる Amazon EBS ボリュームの最大数はインスタンスのタイプとサイズによって異なります。詳細については、「[Amazon EC2 インスタンスの Amazon EBS ボリューム制限](volume_limits.md)」を参照してください。
インスタンスタイプまたはインスタンスサイズに変更できるのは、現在インスタンスにアタッチされているボリュームと同じ数またはそれ以上のボリュームをサポートするものに限られます。現在アタッチされているボリュームの数をサポートしていないインスタンスタイプまたはインスタンスサイズに変更すると、リクエストは失敗します。例えば、32 個のボリュームが接続されている `m7i.4xlarge` インスタンスから、最大 27 個のボリュームをサポートする `m6i.4xlarge` インスタンスに変更すると、リクエストは失敗します。
**NitroTPM**
[NitroTPM](nitrotpm.md) が有効な AMI と NitroTPM をサポートするインスタンスタイプを使用してインスタンスを起動した場合、インスタンスは NitroTPM が有効な状態で起動します。同じく NitroTPM をサポートするインスタンスタイプにのみ変更できます。
# Amazon EC2 インスタンスのインスタンスタイプを変更する
必要なインスタンスタイプがインスタンスの現在の設定と互換性がある場合は、次の手順を使用して Amazon EBS-backed インスタンスのインスタンスタイプを変更します。詳細については、「[インスタンスタイプ変更の互換性](resize-limitations.md)」を参照してください。
**考慮事項**
+ インスタンスタイプを変更するには、そのインスタンスを停止する必要があります。インスタンスが停止している間のダウンタイムを予定しておいてください。インスタンスを停止し、インスタンスタイプの変更を行うと、数分かかります。インスタンスを再起動すると、アプリケーションの起動スクリプトによってかかる時間が変動する場合があります。詳細については、[Amazon EC2 インスタンスの停止と開始](Stop_Start.md) を参照してください。
+ インスタンスを停止して起動すると、インスタンスは新しいハードウェアに移動されます。インスタンスに Elastic IP ではないパブリック IPv4 アドレスがある場合には、このアドレスはリリースされて、インスタンスは新しいパブリック IPv4 アドレスになります。インスタンスのライフサイクル全体における IP アドレスの動作の詳細については、「[インスタンスの状態の違い](ec2-instance-lifecycle.md#lifecycle-differences)」を参照してください。
+ [[Spot Instance]](using-spot-instances-request.md#stopping-a-spot-instance) (スポットインスタンス) のインスタンスタイプを変更することはできません。
+ [Windows インスタンス インスタンスタイプを変更する前に、AWS PV ドライバーパッケージを更新することをお勧めします。詳細については、「[EC2 Windows インスタンスでの PV ドライバーのアップグレード](Upgrading_PV_drivers.md)」を参照してください。
+ インスタンスが Auto Scaling グループにある場合、Amazon EC2 Auto Scaling サービスはインスタンスを異常と判断して停止し、場合によってはそれを終了して代替インスタンスを起動します。インスタンスタイプを変更するときに、そのグループのスケーリングプロセスを中断することで、これを防ぐことができます。詳細については、「Amazon EC2 Auto Scaling ユーザーガイド**」の「[スケーリングプロセスの中断と再開](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-suspend-resume-processes.html)」を参照してください。
+ NVMe インスタンスストアボリュームを使用してインスタンスのインスタンスタイプを変更すると、AMI またはインスタンスブロックデバイスマッピングで指定されていない場合でもすべての NVMe インスタンスストアボリュームが利用可能であるため、追加のインスタンスストアボリュームが更新されたインスタンスに存在するようになる可能性があります。それ以外の場合、更新したインスタンスには、元のインスタンスの起動時に指定したのと同じ数のインスタンスストアボリュームが設定されます。
+ インスタンスにアタッチできる Amazon EBS ボリュームの最大数は、インスタンスのタイプとサイズによって異なります。インスタンスにすでにアタッチされているボリュームの数をサポートしていないインスタンスタイプまたはインスタンスサイズに変更することはできません。詳細については、「[Amazon EC2 インスタンスの Amazon EBS ボリューム制限](volume_limits.md)」を参照してください。
+ [Linux インスタンス] `AWSSupport-MigrateXenToNitroLinux` ランブックを使用して、互換性のあるインスタンスを Xen インスタンスタイプから Nitro インスタンスタイプに移行できます。詳細については「*AWS Systems Manager 自動 ランブックリファレンス*」の [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-migrate-xen-to-nitro.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-migrate-xen-to-nitro.html) を参照してください。
+ [Windows インスタンス] 互換性のある Windows インスタンスを Xen インスタンスタイプから Nitro インスタンスタイプに移行する方法に関するその他のガイダンスについては、「[最新世代のインスタンスタイプへの移行](migrating-latest-types.md)」を参照してください。
**Amazon EBS-backed インスタンスのインスタンスタイプを変更するには**
1. (オプション) 新しいインスタンスのタイプに既存のインスタンスにインストールされていないドライバーが必要な場合は、インスタンスに接続してドライバーをインストールする必要があります。詳細については、「[インスタンスタイプ変更の互換性](resize-limitations.md)」を参照してください。
1. [Windows インスタンス] [静的 IP アドレス指定](config-windows-multiple-ip.md#step1)を使用するように Windows インスタンスを設定し、拡張ネットワーキングをサポートしないインスタンスタイプから拡張ネットワーキングをサポートするインスタンスタイプに変更する場合、静的 IP アドレス指定を再設定すると IP アドレスが競合する可能性について警告が表示される場合があります。これを防ぐには、インスタンスタイプを変更する前に、インスタンスのネットワークインターフェイスで DHCP を有効にします。インスタンスから、**[Network and Sharing Center]** (ネットワークと共有センター) を開き、ネットワークインターフェイスの **[Internet Protocol Version 4 (TCP/IPv4) Properties]** (インターネットプロトコルバージョン 4 (TCP/IPv4) のプロパティ) を開いて、**[Obtain an IP address automatically]** (IP アドレスを自動的に取得する) を選択します。インスタンスタイプを変更し、ネットワークインターフェイス上で静的 IP アドレッシングを設定します。
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. インスタンスを選択し、[**Instance state (インスタンスの状態)**]、[**Stop instance (インスタンスの停止)**] の順に選択してください。確認を求められたら、[**Stop**] を選択してください。インスタンスが停止するまで、数分かかる場合があります。
1. インスタンスが選択された状態で、[**Actions (アクション)**]、[**Instance settings (インスタンス設定)**]、[**Change instance type (インスタンスタイプの変更)**] の順に選択します。状態が `stopped` ではないインスタンスの場合、このオプションはグレー表示されています。
1. **[Change Instance Type]** (インスタンスタイプの変更) で、次のいずれかの操作を行います。
1. **[Instance type]** (インスタンスタイプ) で、使用するインスタンスタイプを選択します。
インスタンスタイプがリストにない場合、インスタンスタイプはインスタンスの設定と互換性がありません。代わりに、[新しい EC2 インスタンスを起動して新しいインスタンスタイプに移行する](migrate-instance-configuration.md) の手順をすべて行います。
1. (オプション) 選択したインスタンスタイプが EBS 最適化をサポートしている場合は、**[EBS-optimized]** (EBS 最適化) を選択して EBS 最適化を有効にするか、**[EBS-optimized]** (EBS 最適化) を選択解除して EBS 最適化を無効にします。
選択したインスタンスタイプがデフォルトで EBS に最適化されている場合、**[EBS-Optimized]** (EBS 最適化) は選択状態になっており、これを選択解除することはできません。
1. （オプション) 新しいインスタンスタイプで vCPU オプションを設定します。
既存のインスタンスのインスタンスタイプを変更すると、Amazon EC2 は、可能であれば既存のインスタンスから新しいインスタンスに CPU オプション設定を適用します。新しいインスタンスタイプがこれらの設定をサポートしていない場合、CPU オプションは **なし** にリセットされます。このオプションでは、新しいインスタンスタイプのデフォルトの vCPU 数が使用されます。
選択したインスタンスタイプが vCPU 設定をサポートしている場合は、**[詳細]** パネルで **[CPU オプションを指定]** を選択して、新しいインスタンスタイプの vCPU を設定します。
1. **[変更]** を選択して、新しい設定を受け入れます。
1. インスタンスをスタートするには、インスタンスを選択後、**[Instance state]** (インスタンスの状態)、**[Start instance]** (インスタンスの開始) の順にクリックします。インスタンスが `running` 状態になるまで、数分かかる場合があります。インスタンスが起動しない場合は、「[インスタンスタイプ変更のトラブルシューティング](troubleshoot-change-instance-type.md)」を参照してください。
1. [Windows インスタンス] インスタンスが EC2Launch v1 を使用した Windows Server 2016 または Windows Server 2019 を実行する場合は、Windows インスタンスに接続し、インスタンスタイプが変更された後に次の EC2Launch PowerShell スクリプトを実行してインスタンスを設定します。
**重要**
管理者パスワードはインスタンス初期化 EC2 Launch スクリプトを有効にするとリセットされます。初期化タスクの設定で指定することで、管理者パスワードのリセットを無効にするように設定ファイルを変更できます。パスワードリセットを無効にするステップについては、「[初期化タスクの設定](ec2launch-config.md#ec2launch-inittasks)」(EC2Launch) または「[設定の変更](ec2launch-v2-settings.md#ec2launch-v2-ui)」(EC2Launch v2) を参照してください。
```
PS C:\> C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 -Schedule
```
# 新しい EC2 インスタンスを起動して新しいインスタンスタイプに移行する
EC2 インスタンスのインスタンスタイプを変更できるのは、そのインスタンスが、目的の新しいインスタンスタイプとの互換性がある設定を持つ EBS-backed インスタンスである場合のみです。それ以外の場合、設定またはインスタンスが新しいインスタンスタイプと互換性がない場合、またはインスタンスストアベースのインスタンスである場合は、必要なインスタンスタイプと互換性のある代替インスタンスを起動する必要があります。互換性が決定される方法の詳細については、「[インスタンスタイプ変更の互換性](resize-limitations.md)」を参照してください。
**データ移行プロセスの概要**
+ 元のインスタンスのデータをバックアップします。
+ 使用する新しいインスタンスタイプと互換性がある設定で新しいインスタンスを起動して、元のインスタンスにアタッチされた EBS ボリュームをアタッチします。
+ アプリケーションを新しいインスタンスにインストールします。
+ データを復元します。
+ 元のインスタンスに Elastic IP アドレスがある場合は、ユーザーが中断することなくアプリケーションを使用し続けることができるように、Elastic IP アドレスを新しいインスタンスに関連付ける必要があります。
**インスタンスを新しいインスタンスに移行するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. 次のように、まだ必要なデータをバックアップします。
+ インスタンスに接続し、インスタンスストアボリュームのデータを永続ストレージにコピーします。
+ EBS ボリュームの[スナップショットを作成](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html)して、同じデータを持つ新しいボリュームを作成したり、ボリュームを元のインスタンスからデタッチして新しいインスタンスにアタッチしたりできます。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. **[Launch Instances]** (インスタンスの起動) を選択します。インスタンスを設定する場合は、次の操作を行います。
1. 使用するインスタンスタイプをサポートする AMI を選択します。例えば、新しいインスタンスタイプのプロセッサタイプをサポートする AMI を選択する必要があります。また、現行世代のインスタンスタイプには HVM AMI が必要です。
1. 起動する新しいインスタンスタイプを選択します。使用するインスタンスタイプが使用できない場合は、選択した AMI の構成と互換性がありません。
1. 同じトラフィックが新しいインスタンスに到達できるようにする場合は、元のインスタンスで使用されているものと同じ VPC とセキュリティグループを選択します。
1. 新しいインスタンスの設定が完了したら、手順を実行してキーペアを選択し、インスタンスを起動します。インスタンスが `running` 状態になるまで、数分かかる場合があります。
1. EBS スナップショットにデータをバックアップした場合は、[スナップショットからボリュームを作成](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-volume.html#ebs-create-volume-from-snapshot)し、新しいインスタンスにその[ボリュームをアタッチ](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-attaching-volume.html)します。
EBS ボリュームを元のインスタンスから新しいインスタンスに移動するには、元のインスタンスから[ボリュームをデタッチ](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-detaching-volume.html)し、新しいインスタンスにその[ボリュームをアタッチ](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-attaching-volume.html)します。
1. アプリケーションと必要なソフトウェアを新しいインスタンスにインストールします。
1. 元のインスタンスのインスタンスストアボリュームからバックアップしたデータを復元します。
1. 元のインスタンスに Elastic IP アドレスがある場合は、次のようにそれを新しいインスタンスに割り当てます。
1. ナビゲーションペインで [**Elastic IP**] を選択します。
1. 元のインスタンスに関連付ける Elastic IP アドレスを選択して、[**Actions (アクション)**]、[**Disassociate Elastic IP address (Elastic IP アドレスの関連付けの解除)**] の順に選択します。確認を求めるメッセージが表示されたら、[**Disassociate (関連付け解除)**] を選択します。
1. Elastic IP アドレスがまだ選択された状態で、[**Actions (アクション)**]、[**Associate Elastic IP address (Elastic IP アドレスの関連付け)**] の順に選択します。
1. [**リソースタイプ**] で、[**Instance (インスタンス)**] を選択します。
1. **[インスタンス]** で、新しいインスタンスを選択します。
1. (オプション) [**プライベート IP アドレス**] で、Elastic IP アドレスを関連付けるプライベート IP アドレスを指定します。
1. [**Associate**] を選択します。
1. (オプション) 不要になった場合は、元のインスタンスを終了できます。インスタンスを選択し、新しいインスタンスではなく元のインスタンスを終了させようとしていることを確認し (名前や起動時間の確認など)、**[Instance state]** (インスタンスの状態)、**[Terminate instance]** (インスタンスを終了) を選択します。
# インスタンスタイプ変更のトラブルシューティング
以下の情報は、インスタンスタイプの変更時に発生する可能性のある問題の診断と修復に役立ちます。
## インスタンスタイプを変更してもインスタンスが起動しない
**考えられる原因: 新しいインスタンスタイプの要件が満たされていない**
インスタンスが起動しない場合、新しいインスタンスタイプの要件の 1 つが満たされていない可能性があります。詳細については、[タイプを変更した後、Linuxインスタンスが起動しなくなったのはなぜですか?](https://repost.aws/knowledge-center/boot-error-linux-nitro-instance)を参照してください。
**考えられる原因: AMI がインスタンスタイプをサポートしていない**
EC2 コンソールを使用してインスタンスタイプを変更する場合、選択した AMI でサポートされているインスタンスタイプのみを使用できます。しかし、AWS CLI を使ってインスタンスを起動すると、互換性のない AMI とインスタンスタイプを指定してしまうことがあります。AMI とインスタンスタイプに互換性がない場合、インスタンスは起動できません。詳細については、[インスタンスタイプ変更の互換性](resize-limitations.md)を参照してください。
**考えられる原因: インスタンスがクラスタープレイスメントグループに属している**
インスタンスが[クラスタープレイスメントグループ](placement-strategies.md#placement-groups-cluster)に属しており、インスタンスタイプを変更した後にインスタンスの起動に失敗した場合、以下を試してください。
1. クラスタープレイスメントグループ内のすべてのインスタンスを停止します。
1. 影響を受けるインスタンスのインスタンスタイプを変更します。
1. クラスタープレイスメントグループ内のすべてのインスタンスを起動します。
## インスタンスタイプを変更した後、アプリケーションからアプリケーションまたは Web サイトにアクセスできない
**考えられる原因: パブリック IPv4 アドレスが解放されている**
インスタンスタイプを変更する場合は、まずインスタンスを停止する必要があります。ユーザーがインスタンスを停止すると、パブリック IPv4 アドレスを解放し、お客様のインスタンスに新しいパブリック IPv4 アドレスを付与します。
インスタンスの停止と開始の間にパブリック IPv4 アドレスを保持するには、インスタンスが実行されていれば、追加コストなしで Elastic IP アドレスを使用することをお勧めします。詳細については、「[Elastic IP アドレス](elastic-ip-addresses-eip.md)」を参照してください。