Purpose
AWS Cloud Formationを使ってEC2インスタンスを立ち上げたときに失敗したことのまとめと対策
失敗事例
失敗の内容
UbuntuのEC2インスタンスを構築する際、インスタンスのルートボリュームの指定に誤りがあり、50Gbのディスク(1つ)を作成するつもりが、8Gbと、50Gbの２つのディスクがマウントされたEC2インスタンスができた。
利用したテンプレート（一部）
Parameters:
RootVolumeDeviceName:
Type: String
Default: /dev/sda1
RootVolumeSize:
Type: String
Default: 50
Resources:
EC2:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-023a7615a07affbe5 #Ubuntu Server 18.04 LTS
InstanceType: t2.micro
BlockDeviceMappings:
- DeviceName: !Ref RootVolumeDeviceName
Ebs:
VolumeSize: !Ref RootVolumeSize
パラメータ :
- RootVolumeDeviceName＝/dev/xvda
- RootVolumeSize=50
原因と対応
RootVolumeに、50Gb,/dev/xvdaを指定しているのに、インスタンスができると、ルートボリュームには、/dev/sda1が指定され、サイズは、８Gbになっていた。完全に変数名の”RootVolume”に釣られた。
RootVolumeDeviceNameに、/dev/sda1を指定したら、期待通りのボリュームを持つインスタンスを作成することができた。
反省点
紛らわしい名前
名前につられたのが直接的な問題であった。今回のケースでは、RootVolumeに、/dev/xvdaを利用する場面はなかったため、べた書きでもよかったのかもしれない。
設定されるパラメータの基礎知識の欠如
ルートボリュームは、イメージ側で指定されているため、テンプレート側から設定することはできない。どこでこのパラメータが決定されているか、注意深く確認しておけばよかった。 ボリューム名の確認は、利用するAMIの詳細画面から確認できる。
EC2インスタンスで利用できるデバイス名
利用できるデバイス名で、ルート用に予約済みのものは、/dev/sda1, /dev/xvdaとなっている。
Windowsの場合、/dev/sda1一択なので、迷うことはなさそう。
一方、Linuxの場合、仮想化タイプの違いで場合分けする必要がある。準仮想化(PV)の場合、は/dev/sda1一択。ハードウェア仮想化(HVM)の場合、/dev/sda1と、/dev/xvdaの二択となる。ややこしい。
そうなると、PVと、HVMどちらを選択するのが良いかという話になる。
仮想化タイプの説明の一文で、以下の様に言及されているため、HVMを選択しておけば問題ないと思う。なお、PV AMI と HVM AMI の主な違いは、起動の方法と、パフォーマンス向上のための特別なハードウェア拡張機能 (CPU、ネットワーク、ストレージ) を利用できるかどうかという点とのこと。
最適なパフォーマンスを得るために、インスタンスを起動するときには、現行世代のインスタンスタイプと HVM AMI を使用することをお勧めします。
HVMが推奨されているので、Linuxを利用する際は、/dev/sda1, /dev/xvdaのどちらかがRootVolumeになっている。ということを意識する必要がある。(ぱっとAMIを検索したところ、大半のパブリックイメージは、/dev/sda1を利用していたので、まずは、/dev/sda1でいいのではないかと思う)
Reference
その他注意点
お試しで５０Gbのインスタンスを作成しようとして、気が付いた。お試しで課金が発生しないようにするためには、こういった条件に気を付けたい。
無料利用枠の対象であるお客様は **30 GB **までの EBS 汎用 (SSD) ストレージまたはマグネティックストレージを取得できます。
