【AWSユーザーガイド非公式解説】［EC2］2.Amazon マシンイメージ
この記事はAWSユーザーガイドの以下リンクの解説記事です。
公式ではEC2の説明として、まずAMIが出てきます。
AMIとはOS（とその他ソフトウェアを含む）マシンイメージです。AWSではEC2にOSをインストールすることはできません。EC2は必ずAMIから作成します。
AMIにはAMI IDというリージョン単位でAMIを識別するIDがあります。
下のイメージのAMIはLinuxで、ルートデバイスタイプがEBSのAMIです。
AMIにはディスクボリュームの情報が含まれます。イメージ下の方の「ルートデバイスの詳細」にストレージの情報があり、このAMIからインスタンスを起動すると、100GBのEBSが作成され、OSボリュームとして使用されます。
AMIはインスタンスタイプとの互換性が必要です。例えばmacOS用のAMIを使用する場合、
macOS用のAMIをサポートするインスタンスタイプを選択する必要があります。
AMIはAWSが提供するAMIの他に、デベロッパーが提供するAMIがあります。自分が作成したAMIは他のユーザーと共有することが可能です。あまり使用する機会はないかもしれませんが、共有範囲をパブリックとし、全てのユーザーに公開することもできます。
AMIカタログでは、クイックスタートAMIの他に、自分のAMI、AWS Marketplace AMI、コミュニティAMIに分類されています。
AWS Marketplaceは登録事業者が自社製品を組み込んだAMIを提供しています。例えばCisco Systemsはセキュリティ製品を組み込んだAMIを提供しており、それらのAMIを使用するとセキュリティアプライアンスの構築が容易になります。EC2の料金とは別に（ソフトウェアライセンス料等の）料金が発生する可能性があります。
コミュニティAMIはパブリックに公開されている無料のAMIです。AWSでは誰でもAMIをパブリックに公開することができ、個人が公開したAMIもコミュニティAMIに含まれるため利用には注意が必要です。
公式ではAMIはOS、プロセッサアーキテクチャ、ルートデバイスタイプ、仮想化タイプを選択し、決定するという説明がありますが、通常であれば、OSとインスタンスタイプからAMIを決定する流れだと思います。
Amazon EC2 の AMI タイプと特性
ルートデバイスタイプ
AMIのルートボリュームのタイプとして、Amazon EBS-Backed と Instance Store-Backedがあります。
-
Amazon EBS-backed AMI
ルートデバイスにamazon Elastic Block Store (Amazon EBS) を使用します。実際のディスクはネットワーク経由で接続されています。 -
Amazon instance store-backed AMI
AMI から起動したインスタンスのルートデバイスは、インスタンスストアとなります。インスタンスストアは揮発性で、 インスタンスが終了するとデータは消失します。EBSとは違い、ホストコンピューターに直接接続されているため、高スループットを要する処理に適しています。
（Windows AMI はルートデバイスのインスタンスストアをサポートしていないため、Windows OSを使用したい場合はAmazon EBS-backed AMIしか選択肢がありません。）
次の表では、それぞれの重要な相違点をまとめています。
| 特徴 | Amazon EBS-backed AMI | Amazon instance store-backed AMI |
|---|---|---|
| ルートデバイスボリューム | EBS ボリューム | インスタンスストアボリューム |
| インスタンスの起動時間 | 通常 1 分以内 | 通常 5 分以内 |
| インスタンス終了時のデータの永続性 | デフォルト（※）では、インスタンスを終了するとルートボリュームは削除されます。 ルートボリューム以外のEBS ボリュームのデータはデフォルトで保持されます。 |
インスタンスを終了するとデータは消失します。 |
| インスタンスの停止 | 停止状態にすることができます。ルートボリュームは 保持されます。 | 停止状態にすることはできません。 |
| インスタンス属性の変更 | インスタンスの停止中に、インスタンスタイプ、カーネル、RAM ディスク、およびユーザーデータが変更可能です。 | 変更はできません。 |
| 料金 | インスタンスタイプごとの利用料金の他に、EBS ボリュームの料金が発生します。 EC2からAMIを作成した場合はEBSスナップショットとして保存されるため、AMIのEBSスナップショットにも料金が発生します。 |
インスタンスタイプごとの利用料金が発生します。 EC2からAMIを作成した場合はS3に保存するため、S3の料金が発生します。 |
| AMI の作成 | コンソール、CLI等から作成可能です。 | AMI ツールをインストールする必要があります。 |
※インスタンスの作成時にストレージの「終了時に削除」設定を「いいえ」にして作成することにより終了時のルートボリュームのデータを保持することができます。
インスタンスの停止項目に記載があるとおり、Amazon EBS-backed AMIでは、起動状態のインスタンスの停止が可能です。EBSがデータを保持することができるため、停止したインスタンスから再度同じインスタンスを起動することができます。Amazon EBS-backed AMIはデータを保持することができないため、停止ができません。必ず終了を行う形となり、再度起動したい場合はインスタンスを再作成することになります（終了前にAMIを作成しておき、そのAMIからインスタンスを作成することにって復元することは可能です）。
仮想化タイプ
AMIの仮想化方式として、HVM（Hardware-assited VM）及びPV（paravirtual）の２種類があります。HVMの場合、ハードウェア拡張機能が利用可能です。
| 特徴 | HVM | PV |
|---|---|---|
| 説明 | HMV AMIは、仮想化されたハードウェアを含む形のイメージとなっており、一般的なOSと同じようにイメージのルートブロックデバイスのマスターブートレコードを実行することで起動します。 OSに対してカスタマイズを行う必要がありません。 |
PV AMI は、PV-GRUB と呼ばれる特別なブートローダーを使用して起動します。ハードウェアの操作はハイパーバイザに対するAPIをOS側で実行することにより行われます。 AMIのOSではカスタマイズ済みのためOSに対するカスタマイズ作業は不要です。 （推測ですがOSに対するカスタマイズが困難なため）WindowsOSはサポート外です。 |
| サポートされるインスタンスタイプ | 全ての現行世代のインスタンスでサポートされます。 | 現行世代のインスタンスタイプではサポートされず、旧世代（C1、C3、M1、M3、M2、および T1）のみです。 |
| ハードウェア拡張のサポート | OSが直接ハードウェアを操作する形での、ネットワークやGPU処理の高速化機能（ハードウェア拡張）が使用できます。 | ハードウェア拡張は使用できません。 |
PV on HVM
従来、PVの方がHVMよりもパフォーマンスが優れていました。PV用の特別なドライバの処理効率が高かったためです。現在では、PV用のドライバーをHVMで利用できるようになり、パフォーマンスが向上しています。
公式では特に推奨等の説明はありませんが、PVが現行世代のインスタンスタイプでサポートされていないことからも、あまりPVを選択する機会はないと思われます。
AMIの仮想化タイプはAMIの概要で確認できます。
AMI ライフサイクル
インスタンスを作成する際は必ずAMIを指定する必要があります。
提供されているAMIから作成することも、カスタマイズしたインスタンスからAMIを作成し、自己所有のAMIから別のインスタンスを作成することもできます。
AMIはIDを持ち、リージョン内でユニークになります。作成したAMIを他のリージョンで使用したい場合は、そのリージョンにAMIをコピーすることで別のIDが割り当てられます。
登録解除と無効化
自己所有のAMIは無効化、登録解除が可能です。
一時的にAMIを使用不可の状態にしたい場合にはAMIの無効化を行います。AMIを無効にすると、そのAMIを使用して新たにインスタンスを起動することはできません。起動済みのインスタンスには影響しません。無効にしたAMIはいつでも有効化可能です。
AMIを削除したい場合はAMIの登録解除を行います。こちらも新たにインスタンスを起動することはできなくなりますが、起動済みのインスタンスには影響しません。
AMIはカタログデータのようなもので、EBS-backed AMIの場合、実体はEBSスナップショットとして保存されています。AMIの登録解除を行わずに紐づけられているEBSスナップショットを削除しようとすると失敗します（下のイメージ参照）。AMIの登録解除を行なってもEBSスナップショットは削除されません。AMIを削除してもEBSスナップショットが残っている場合、料金が発生するため注意が必要です。
Amazon Data Lifecycle Manager を使用すると、AMIの登録解除、スナップショットの削除までを自動化することができます。
Amazon EBS-backed AMI を作成する
自己所有のEBS-backed AMIを作成する場合は、ルートデバイスタイプがEBSとなっているAMIを使用します。
インスタンスからの AMI 作成の概要
ルートデバイスタイプがEBSのAMIからインスタンスを作成し、インスタンスにソフトウェアインストール、設定等をおこなった後に、独自のAMIを作成します。
AMI作成時のデフォルトでは、インスタンスを停止し、AMIの作成が完了したら再起動を行います。ディスクI/Oがない状態とする（静止点を作成する）ためです。
XFS等のファイルシステムの場合、起動したままディスクI/Oがない状態を作ることが可能なため、その場合は再起動を行う設定を解除し、AMIを作成します。
インスタンスのルートボリュームの他にアタッチされているEBSボリュームがある場合、AMI作成時にそのEBSボリュームもスナップショットが作成されます。追加で１つのEBSボリュームをアタッチしている場合は作成されるEBSスナップショットは2つになります。
AMI作成にかかる時間はEBSボリュームのサイズに依存します。あらかじめEBSスナップショットを作成しておくことにより、AMI作成にかかる時間は短縮可能です。
AMIにはインスタンスにアタッチされていたEBSボリューム（※）の情報がブロックデバイスマッピングとして記録されています。
作成されたAMIからインスタンスを作成すると、元のインスタンスのものとは別にEBSボリュームが作成されます。元のインスタンスが複数のEBSボリュームをアタッチしていた場合、EBSボリュームも複数作成されます。EBSスナップショットから復元される形となるため、新しいインスタンスでもデータは保持された状態です。
※公式ではここでインスタンスストアボリュームの説明があります。Amazon EBS-backed AMIであってもインスタンスタイプがサポートしている場合は、追加のボリュームとしてインスタンスストアを使用することが可能です。その場合はインスタンスストアのマッピングも記録されます。但し、インスタンスストアは揮発性のため、そのAMIから起動されたインスタンスではデータが初期化されたボリュームとなります。
instance store-backed AMI を作成する
ルートデバイスタイプがINSTANCE-STOREのAMIから作成したインスタンスでAMIを作成する場合はInstance Store-Backed AMIになります。
AMI 作成の概要
instance store-backed AMIを作成するためにはインスタンス（Linux）にAMIツールをインストールする必要があります。
AMIツールでec2-bundle-volコマンドを使用すると、イメージマニフェスト (image.manifest.xml) とルートボリューム用のテンプレートを含むファイル (image.part.xx) で構成されるバンドルが作成されます。AMIツールでec2-upload-bundleコマンドを使用することによりバンドルファイルをS3にアップロードします。
作成したAMIを使用して、インスタンスを作成する場合、S3にアップロードされたバンドルを使用して、ルートボリュームが作成されます。
元のインスタンスで追加のインスタンスストアボリュームをアタッチしていた場合は、そのAMIを使用して作成したインスタンスでも追加のインスタンスストアボリュームが作成されます。
前提条件
- AMI ツール、AWS CLIのインストールが必要です。
- バンドルを保存するためのS3バケットと、アクセス権が必要です。
- instance store-backed AMIは暗号化には対応していません。
- X.509 証明書および対応するプライベートキーが必要です。
Windows Sysprep を使用して Amazon EC2 AMI を作成する
Windows OS の場合、インスタンス固有システム設定（Security ID、OS のライセンス認証状態等）が付与されているため、インスタンスを複製する用途でAMIを作成する場合は、Microsoft Sysprep(システム準備)ツールを使用し、インスタンス固有のシステム設定を削除した状態を作ります。バックアップ用途でAMIを作成する場合はSysprepは不要です。
WindowsOSの場合、Windows 起動エージェント(EC2Config または EC2Launch v1 または v2)を使用して、Windows Sysprep を行なったAMI を作成することもできます。
Amazon EC2 AMI のコピー
Amazon マシンイメージ (AMI) のコピーは、同じリージョン内または同じパーティション内のリージョン間で作成できます。AMI を別のパーティションにコピーする場合は、「AMI を保存および復元する」を参照してください。
公式ではここでいきなり、リージョンのパーティションというものが出てきます。AWSのリージョンを分類するパーティションという考えがあり、パーティションを跨ぐ、AMIのコピーはS3を利用する必要があります。通常、AWSを使っていてもパーティションを意識することはないと思います。
パーティションは執筆時点で、以下のものに分かれています。
- AWS Standard partition
「ap-northeast-x」「ap-southeast-ｘ」等の通常使用するリージョンは全てこの中にあります。 - AWS China partition
中国リージョンです。中国リージョンは政治的な理由（？）により通常のAWSとは制限が違うようです（詳細未調査）。 - AWS GovCloud(US) partition
米国政府専用のAWSサービスです。 - AWS ISO (US) partition
機密リージョンのようです。ネット検索すると推測情報はでてきますが、公式の情報はありません。
考慮事項
-
AMI をコピーするためのアクセス許可
AMIをコピーするためにはアクセス権限が必要です。作成したAMIに対してIAMポリシーを使用したアクセス権設定が可能です。 -
起動許可と Amazon S3 バケット許可
AMIの「許可を設定」アクションで設定できる起動許可項目（共有設定等）はコピーされたAMIには引き継がれません。S3バケットに対する許可も引き継がれません。 -
タグ
自己所有のAMIの場合、ユーザー定義のタグはコピー時に引き継がれます。システムタグ（aws:プレフィックス）や他のユーザーが付与したタグは引き継がれません。
AMI のコピー
AMIの検索画面からコピー元となるAMIを選択し、AMIのコピーアクションを実行します。
コピーの際に、AMIの名称、説明の変更、送信先リージョンの選択、タグコピーの有無、EBSスナップショットの暗号化有無を選択できます。
Amazon EC2 AMI をコピーするための権限を付与する
Amazon EC2 AMI コピーの仕組み
コピーしたAMI（ターゲットAMI）はコピー元のAMI（ソースAMI）とは別のAMI（別のID）となります。ソースAMIとターゲットAMIの間に依存関係はなくなり、それぞれのAMIに対して別の変更を行うことができます。
EBS-backed AMI におけるEBSスナップショットは、コピー先のAMIで別のEBSスナップショットが作成され、マッピングされます（データは保持）。
増分スナップショットを作成していた場合のコピー時の動きは以下になります。
- 同一リージョンの場合、同じ数のEBSスナップショットのコピーが作成されます。但し、コピー時に暗号化を行う場合（暗号化されていないスナップショットを暗号化する場合、または暗号化キーを変更する場合）は増分スナップショットを纏めた１つのスナップショットになります。
- 別リージョンの場合、増分スナップショットを纏めた１つのスナップショットが作成されます。
リージョン間のコピー
リージョン間コピーにより、同一の内容（ソフトウェアバージョン等含め）のインスタンスを別のリージョンで起動することができます。リージョン間のコピーはグローバルアプリケーションの構築、可用性の向上などの用途で使用されます。
【例】
・世界各地のユーザーからアクセスされるアプリケーションで、各リージョンにインスタンスを分散して起動する。
・災害対策用リージョンにAMIをコピーしておき、災害時に起動することでBCP対応を行う。
EBS-backed AMIの場合、コピー先リージョンにEBSスナップショットが作成されます。
instance store-backed AMI の場合、最初のコピーの際に、宛先リージョンAmazon S3 バケットを作成します。その後のコピーには作成されたバケットが使用されます。
- 前提条件
複数リージョンでの起動を前提とする場合、インスタンスがリージョンに依存しないように設計するか、コピー後のAMIからインスタンスを起動し、修正する必要があります。 - 制約事項
- ターゲットとなるリージョンでの同時実行コピーは100個までとなります。
- 仮想化タイプがPVのAMIは、PVがサポートされていないリージョンにはコピーできません。（おそらく比較的新しいリージョンである）アジアパシフィック (香港) – ap-east-1等は旧世代のインスタンスタイプがサポートされておらず、PVタイプをインスタンスを起動することができません。
アカウント間のコピー
AMIの「許可を設定」アクションで共有が許可されているアカウントはAMIをコピーできます。アカウント間のコピーはクロスアカウントコピーと呼びます。
- AMIのクロスアカウントコピーを行う場合は、コピー元のAMIの実体が保存されているEBSスナップショット(Amazon EBS-backed AMI の場合)またはS3バケット (instance store-backed AMI の場合)に対するアクセス許可が必要です。
- EBSスナップショットが暗号化されている場合は、コピー先アカウントに暗号化キーを共有する必要があります。
コピーしたAMIの所有者はコピーしたアカウントになり、EBS料金またはS3料金もコピーしたアカウントで発生します。
暗号化とコピー
AMIのコピーは暗号化をサポートしますが、暗号化されたスナップショットをコピーする際に非暗号化スナップショットにすることはできません。
- 元のAMI（スナップショット）が暗号化されていない場合、コピー先には暗号化されていないAMI（スナップショット）が作成されます。コピー時に暗号化を行うことも可能です。
- 元のAMI（スナップショット）が暗号化されている場合、コピー先には同じキーで暗号化されたAMI（スナップショット）が作成されます。元のAMI（スナップショット）とは別のキーを指定してコピーを作成することも可能です。
S3 を使用して AMI を保存および復元する
AMIはS3バケットに保存して、別のリージョンにコピーしてS3バケットからAMIを復元することができます。
（前述のパーテーション間でAMIのコピーを行う場合はS3への保存が必要です。公式ではAWS パーティション間でAMIをコピーする方法の記載がありますが割愛します。）
AMI のアーカイブコピーを作成する
AMIはS3に保存する際にひとつのオブジェクトとして保存され、AMIのメタデータ（AMI id等）も、共有に関する情報を除き、オブジェクト内に保持されます。
オブジェクト化を行う段階で圧縮が行われるため、実体のEBSスナップショットよりもサイズが小さくなります。S3のストレージクラスを変更することにより、より安価にアーカイブを保存することが可能なため、コスト削減につながります。
S3に保存するためには、AMIが自己所有、またはAMI及びスナップショットが共有されている必要があります。公開されているだけのAMIをS3に保存することはできません。
EBS-backed AMI での暗号化の利用
EBSスナップショットを使用したAMIでは、EBSの暗号化機能を利用できます。
公式ではAMIから起動する際の暗号化と、AMIをコピーする場合の暗号化が分けて説明されていますが、どちらも同じ動作となります。
デフォルトでは、元となるAMIのEBSスナップショットの暗号化状態を保持します。
- 元となるAMIのスナップショットが暗号化されていない場合は、暗号化されません。
- 元となるAMIのスナップショットが暗号化されている場合は、暗号化されます。
但し、AWSにはリージョンごとに暗号化をデフォルトとする設定があり、デフォルト暗号化が有効の場合は元となるAMIのスナップショットの暗号化状態にかかわらず、暗号化されます。
デフォルト暗号化はEC2の設定画面から有効化することができます。
AMIからインスタンスを起動する際、またはAMIをコピーする際に暗号化を指定することもできます。
- 自己所有のスナップショットの場合は、特に指定しなければ同じKMSキーとなります。
- 自己所有でない（共有されたAMIの）スナップショットの場合は、特に指定しなければAWSアカウントのデフォルトKMSキーで暗号化されます。
- 自己所有かどうかに関わらず、暗号化キーを指定した場合は指定した暗号化キーで暗号化されます。
共有AMI
AMIは共有することができます。共有の方法としてだれでも使用できるパブリック公開と特定のアカウントまたは組織内にのみ共有するプライベート公開があります。
AWSが提供するAMIも共有機能を利用しています。AWSの他にもさまざまなデベロッパーがソフトウェアコンポーネントインストール済みのAMIを提供しています。それらのAMIを使用することによりソフトウェアインストール等の初期設定を簡略化できます。
誰でも簡単にAMIを共有することができるため、AMIの信頼性が重要となり、検証済みプロバイダー提供のAMIを使用することが推奨されています。
- 検証済みプロバイダ
AMIカタログの検索画面から検証済みプロバイダーのAMIを絞り込むことができます。
検証済みプロバイダとはAWS Marketplaceで販売者として登録されているデベロッパのことです。登録には審査があり、明確なカスタマーサポートプロセスおよびサポート組織があることことなどが登録要件となっていますが、AWSがAMIの信頼性を保証するわけではありません。
AMIの共有は共有の設定画面より行います。（下のイメージではセキュリティ観点によりパブリック公開をブロックしています。）
特定のアカウントや組織内のOUで共有することもできます。
AMI のパブリックアクセスのブロックについて
不要なAMIのパブリック公開を防止するため、EC2の設定画面でAMIのパブリックアクセスを禁止することができます。この設定はリージョンごとに行う必要があります。
この設定は公開済みのAMIには影響しません。そのため、通常時はブロックしておき、公開する必要があるタイミングで一時的にブロックを解除することが推奨されています。
組織および組織単位での共有 AMI の使用
AWS Organizationsを使用して、組織内での共有を行うことができます。
AWS OrganizationsのOU（アカウントをグルーピングする機能）は階層構造となっており、上位のOUに対してAMIの共有を行うと、下位のOUに所属するアカウントもAMIを使用可能になります。
- AMI共有の設定が可能なのはAMIを所有するアカウントのみです。
- AMIのユーザータグは共有できません。
- スナップショットが暗号化されたAMIの共有を行いたい場合は、カスタマーマネージド型キーを使用してください。AWS管理キーで暗号化されたスナップショットのAMIは共有できません。また、カスタマーマネージド型キーの使用を組織またはOUに許可する必要があります。
- AMIはリージョンごとにユニークIDとなるため、共有されたAMIは同一リージョンでのみ使用可能です。AMIを他リージョンで使用する場合はAMIのコピーを行なってください。
- 共有AMI使用してインスタンスを起動することはできますが、共有AMIを変更、削除することはできません。起動したインスタンスからAMIを新たに作成することはできます。
特定の AWS アカウントとの AMI の共有
AWSアカウントIDを指定して、特定のアカウントとAMIを共有することができます。
- AMI共有の設定が可能なのはAMIを所有するアカウントのみです。
- AMIのユーザータグは共有できません。
- スナップショットが暗号化されたAMIの共有を行いたい場合は、カスタマーマネージド型キーを使用してください。AWS管理キーで暗号化されたスナップショットのAMIは共有できません。また、カスタマーマネージド型キーの使用を共有するアカウントに許可する必要があります。
- AMIはリージョンごとにユニークIDとなるため、共有されたAMIは同一リージョンでのみ使用可能です。AMIを他リージョンで使用する場合はAMIのコピーを行なってください。
- 共有AMI使用してインスタンスを起動することはできますが、共有AMIを変更、削除することはできません。起動したインスタンスからAMIを新たに作成することはできます。
- 共有されたAMIをコピーする場合はAMIのストレージ（EBSスナップショット）に対する読み取り権限が必要です。
Discussion