はじめに

次世代インスタンスタイプが発表され、少なくともt2シリーズに関しては無料枠を利用したい場合以外t3を利用しない手はないと思いますので、会社のt2系インスタンスたちをt3に変更しようとしたところ、ちょっとしたハマりポイントに遭遇しましたので備忘録として残しておきます。

Nitro Systemについては公式ドキュメントを。

概要

旧世代のAMIで作成したEC2インスタンスはENAを有効化する必要がある
ルートデバイス以外にEBSをアタッチしているEC2インスタンスはfstabのデバイス名を修正する必要がある

変更手順

変更手順についてはこちらの記事に付け加える点はないです。感謝！

現在のEC2インスタンスがENAに対応しているか確認

$ aws ec2 describe-instances \
  --instance-ids YOUR_INSTANCE_ID \
  --query 'Reservations[].Instances[].EnaSupport'

結果の出力が空であれば未対応です。

このままインスタンスタイプを変更しようとすると（NITRO世代インスタンスタイプを選択することは可能）、下記エラーが出て起動できません。

error

Enhanced networking with the Elastic Network Adapter (ENA) is required for the 't3.medium' instance type. Ensure that your instance 'YOUR_INSTANCE_ID' is enabled for ENA.

NITRO世代のインスタンスタイプはENA対応が必須なので、有効化しましょう。

ENA有効化

$ aws ec2 modify-instance-attribute \
  --instance-id YOUR_INSTANCE_ID \
  --ena-support

EC2インスタンス起動

あとは普通に起動すればOKです。

ルートデバイス以外にEBSをアタッチしている場合は注意が必要

ここからが本題です。

EC2インスタンスにおいて、ルートデバイスは/dev/xvda1となり、それ以外のEBSをアタッチすると、xvdb,xvdc...というデバイス名で認識されます。

ここで、ルートデバイスのみのNITRO世代EC2インスタンスのdfの結果とfstabを確認してみます。

ルートデバイスのみ

dfの結果

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
udev             1988132      12   1988120   1% /dev
tmpfs             398668     328    398340   1% /run
/dev/nvme0n1p1  51466360 9004128  40265740  19% /
none                   4       0         4   0% /sys/fs/cgroup
none                5120       0      5120   0% /run/lock
none             1993332       0   1993332   0% /run/shm
none              102400       0    102400   0% /run/user

ルートデバイス名が/dev/xvda1から/dev/nvme0n1p1になっています。

/etc/fstab

LABEL=cloudimg-rootfs	/       ext4	defaults,discard     0 0

/etc/fstabについては、LABELによる指定のため、変更されていません。

ルートデバイス以外にEBSをアタッチしている場合

fstabが下記のように書かれている状態で、NITRO世代インスタンスタイプに変更してみます。

/etc/fstab

LABEL=cloudimg-rootfs	/       ext4	defaults,discard     0 0
/dev/xvdb               /data   ext4    defaults,nofail      0 0

インスタンスタイプ変更後

dfの結果

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
udev             1984692       0   1984692   0% /dev
tmpfs             398540    5740    392800   2% /run
/dev/nvme0n1p1  20263528 7514240  12732904  38% /
tmpfs            1992680       0   1992680   0% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs            1992680       0   1992680   0% /sys/fs/cgroup
tmpfs             398540       0    398540   0% /run/user/1000

OSは起動しましたが、/dev/xvdbがマウントされていません。
デバイスを確認してみます。

# ll /dev | grep nvme
crw-------  1 root root    248,   0 10月 16 23:04 nvme0
brw-rw----  1 root disk    259,   1 10月 16 23:04 nvme0n1
brw-rw----  1 root disk    259,   2 10月 16 23:04 nvme0n1p1
crw-------  1 root root    248,   1 10月 16 23:04 nvme1
brw-rw----  1 root disk    259,   0 10月 16 23:04 nvme1n1

/dev/xvdbが/dev/nvme1n1になっています。

※デバイス名はアタッチしているディスク数、パーティションの切り方で変わるので環境に合わせて読み替えてください。

そこで、fstabを下記のように修正します。

/etc/fstab(修正後)

LABEL=cloudimg-rootfs  /       ext4  defaults,discard 0 0
/dev/nvme1n1           /data   ext4  defaults,nofail  0 0

OSを再起動します。

dfの結果

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
udev             1984692       0   1984692   0% /dev
tmpfs             398540    5856    392684   2% /run
/dev/nvme0n1p1  20263528 7514548  12732596  38% /
tmpfs            1992680       4   1992676   1% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs            1992680       0   1992680   0% /sys/fs/cgroup
/dev/nvme1n1    51475068  736676  48100568   2% /data
tmpfs             398540       0    398540   0% /run/user/1000

うまくマウントされました。

デバイス名については公式ドキュメントに記載があります。

注意

今回のケースでは、fstabのマウントオプションnofailをつけていたためデバイス名が変わってもマウントされずにOS自体は起動できましたが、オプションなしだと起動時のマウントに失敗し、OSが起動せず焦る羽目になるので、前もってfstabにはnofailをつけておきましょう。