SSDインスタンスタイプのルートデバイス。 SSDとEBSの混乱
私はもともとt1.micro linuxから作成されたAMIを持っています。このAMIの「ルートデバイスタイプ」はEBS（8 GB）であり、私のWebアプリケーションソフトウェアはこのルートボリュームに「ベイク」されています。
このAMIからm3.mediumインスタンスを起動したいのですが、4GB SSDの「インスタンスストレージ」があります。
新しく起動したm3.mediumインスタンスはSSDストレージを利用しますか？または、「インスタンスストア」をルート「ルートデバイスタイプ」として新しいAMIを作成する必要がありますか？
同様に...「Amazon Linux AMI 2013.09.2」を使用して最初からm3.mediumを起動しようとすると、起動ウィザードを使用して削除できないデフォルトで8GBのルートEBSボリュームが追加されます。
ここで何が欠けていますか？
インスタンスストレージとしての機能に関係なく、EBSドライブから起動します。 SSDを追加ドライブとしてマウントできます。これは、スワップスペース、一時ファイル、キャッシュなどに便利です。
将来の読者のために注目に値するAmazonは、「汎用」SSDをEBS全体で利用できるようにしました。その後、コンソールまたはAPIを介して「gp2」として選択できます。標準の磁気ドライブよりも月に数セント高い。
http://aws.Amazon.com/blogs/aws/new-ssd-backed-elastic-block-storage/http://aws.Amazon.com/ebs/details /
SSDインスタンスストレージ（および磁気インスタンスストレージ）は一時的なものであり、インスタンスをシャットダウンして、後で再度起動するなどの操作を行った場合、永続的になるとは限りません（ホスト間で移行された場合、たとえば、一時的なボリュームはそれにとどまりません）。
これは本当にスクラッチスペース（キャッシュ、一時など）にのみ役立ちます。これは非常に便利で無料であり、帯域幅を消費しません。 EBSはインスタンスのネットワーク帯域幅を使用します（専用のSANインターフェースを使用するEBS最適化インスタンスを除く）。