メモ: EBSタイプ、インスタンスストアタイプ

AWSのAMIには、rootデバイスがEBSタイプのものと、インスタンスストアタイプのものの2種類があります。

このことはAWSを使う上で知っておくべき常識ですが、自分はよくわかっていなかったため、無頓着でした。

で、今日やった失敗。

AWS上でサーバ/エージェント型のツールを動かしたいな。
サーバにはlargeインスタンス、エージェントには microインスタンスを使おう。
エージェントを1つセットアップしたら、AMIを作って量産すればエエのよね。AWSベンリだわー。
（インスタンスストアタイプのAMIをウッカリ作成）
アレ? こまいインスタンスが作れなす・・・。何かlargeインスタンスごろごろ・・・。?
ぐはぁ、明らかにオーバースペック。それに、お金がっっ
（3に戻ってAMIを作り直し）

情けないですね。こういうマヌケなことをして時間を無駄にしてはいけませんね。

というわけで、理解している範囲で備忘メモを書きます。

EBSタイプとインスタンスストアタイプ

ストレージの性質

EBSタイプのインスタンスは、そのライフサイクルの中にStopというステータスがあります。ストレージがEBSにあるために、インスタンスがStopしている間も、内部のデータが保持されます。

一方、インスタンスストアタイプのインスタンスには、Stopのステータスがありません。動いている（Running）か、止まっている（Terminated）かです。インスタンスが止まると、内部のデータは消えてしまいます。

AMIの違い

インスタンスのrootデバイスの種類は、それぞれの元となるAMIによって決まります*1。AMIは、EC2インスタンスを作成する際に使用するテンプレートです。

rootデバイスがEBSタイプのインスタンスは、EBS-backed AMIと呼ばれるAMIから作成されます。EBS-backed AMIは、EBSスナップショットを作成し、スナップショットをAMIとして登録することで作成できます。

rootデバイスがインスタンスストアタイプのインスタンスは、S3-backed AMIと呼ばれるAMIから作成されます。S3-backed AMIは、分割されたマシンイメージとmanifestファイルをS3に一旦アップロードし、manifestファイルをAMIとして登録することで作成できます。

インスタンスタイプの制限

rootデバイスがインスタンスストアタイプの場合、microインスタンスを使うことができません。small以上のグレードのインスタンスを利用します。# 今日の失敗はコレです。

インスタンスストアタイプのAMIを指定して、microインスタンスを起動しようとすると、次のエラーメッセージを受け取ります。

（コマンドツールから実行した場合）

Client.UnsupportedOperation: AMI 'ami-9999xxxx' with an instance-store root device is not supported for the instance type 't1.micro'.

（マネジメントコンソールから実行した場合）

Note, launching a t1.micro instance requires that you select an AMI with an EBS-backed root device.

それぞれをどう使うか

インスタンスの種類は、何をしたいのか、そのために他のどのAWSサービスを組み合わせるかなどを考慮して決めます。たとえば、S3経由でAMIを定期的にバックアップする構成のシステムにすれば、インスタンスストアタイプのAMIを保持することになるでしょう。そのため、rootデバイスの種類のみに着目して、どちらが良い/悪いとはいえません。

中の人の意見

AWSの中の人によって書かれた本には、次の記述があります。

AMIはAmazon S3またはEBSスナップショットに格納できる。新しいスナップショットベースのモデルの方が高速で、柔軟性にも優れている。必要であれば、EBSスナップショットから起動したインスタンスを終了し、同じインスタンスタイプで、あるいは異なる仕様のインスタンスタイプで再起動することもできる。
Jeff Bar：『Amazon Web Servicesガイドブック』，インプレスジャパン，p.88，2011.2.

また、中の人ではありませんが、『Amazon Cloudテクニカルガイド』の著者の方も、特に理由がなければEBSタイプのAMIをすすめるスタンスのようです。