Amazon マシンイメージ – AMI –

• Amazon マシンイメージ (AMI) は、クラウド内の仮想サーバーであるインスタンスを起動するために必要な情報を提供します。
• AMI は基本的にテンプレートであり、必要に応じて多くのインスタンスを起動するために使用できます。
• VPC 内では、インスタンスはさまざまな AMI から起動できます。
• AMI には次のものが含まれます。
  • たとえば、オペレーティングシステム、アプリケーションサーバー、アプリケーションなどのインスタンスのルートボリュームのテンプレート
  • どの AWS アカウントが AMI を使用してインスタンスを起動できるかを制御する起動権限。 AMI が共有されている AWS アカウント ID
  • インスタンスが起動されたときにアタッチするボリュームを指定するブロックデバイスマッピング
• AMI は以下のいずれかです。
  • AWS 管理、提供、公開された AMI
  • サードパーティまたはコミュニティによるパブリックカスタム AMI の提供
  • 他の AWS アカウントによって作成され、あなたと共有するプライベート AMI
  • あなたによって作成されたプライベートおよびカスタム AMI
• AMI ライフサイクル
  • AMI を作成して登録した後
  • 新しいインスタンスを起動するために使用できます。AMI の所有者が起動権限を付与している場合は、AMI からインスタンスを起動することもできます。
  • AMI は、同じリージョンまたは異なるリージョンにコピーできます。
  • AMI からインスタンスの起動が完了したら、AMI の登録を解除することができます。

AMI のタイプ

• リージョンとアベイラビリティーゾーン
  • AMI はリージョンに固有のものであり、必要に応じて他のリージョンにコピーする必要があります。
• オペレーティング システム
  • AMI は、例えば Linux、Windows、Ubuntu などのための様々な OS フレーバーで利用可能です。
• アーキテクチャ (32 ビットまたは 64 ビット)
• 起動許可
  • 起動許可は、AMI にアクセスできる人を定義します。
    • パブリック – すべての AWS アカウントからアクセス可能
    • 明示的 – 特定の AWS アカウントと共有
    • プライベート – AMI 作成者の AWS アカウントでのみ使用可能
• ルートデバイスストレージ
  • AMI は、ルートデバイスストレージとして EBS またはインスタンスストアを持つことができます
  • EBS バックアップ
    • EBS ボリュームは EC2 インスタンスライフサイクルに依存せず、独立して永続化できます。
    • EBS のバックアップされたインスタンスは、ボリュームを失うことなく停止することができます
    • また、終了フラグの削除が無効になっている場合、インスタンスの終了のボリュームを失わずに EBS インスタンスを永続化することもできます。
    • インスタンスを起動するために必要な部分だけがインスタンスが使用可能になる前にスナップショットから取得する必要があるため、EBS バックアップインスタンスは Instance ストアバックアップインスタンスよりも速く起動します。
    • AMI の作成は、Amazon EBS によってバックアップされる AMI の方がはるかに簡単です。CreateImage API アクションは、Amazon EBS バックアップ AMI を作成し、それを登録します。
  • インスタンスストアのバックアップ
    • インスタンスストアは一時的なストレージであり、インスタンスのライフサイクルに依存します。
    • インスタンスが終了した場合、またはインスタンスストアボリュームがアタッチされた EBS バックアップインスタンスが停止した場合、インスタンスストアは削除されます。
    • インスタンスストアボリュームを停止できません
    • インスタンスストアボリュームには、S3 に AMI があり、インスタンスが使用可能になる前に Amazon S3 からすべてのパーツを取得する必要があるため、EBS バックアップインスタンスに比べて起動時間が高くなります
    • インスタンスストアに基づいた Linux AMI を作成するには、Amazon EC2 AMI ツールを使用してインスタンス自体のインスタンスから AMI を作成する必要があります。
  • より詳細な @ EBS と インスタンスストアの比較

Amazon Linux AMI

Amazon Linux AMIは、以下の機能を備えた、AWSによって提供される、サポートされ維持されたLinuxイメージです。

• Amazon EC2 上で実行されているアプリケーションのための、安定した、安全で高性能な実行環境。
  • Amazon Linux では、デフォルトでリモートルート SSH は許可されません。
  • パスワード認証は、ブルートフォースパスワード攻撃を防ぐために無効になっています。
  • Amazon Linux AMI を使用して起動されたインスタンスは、SSH ログインを有効にするために起動時にキーペアを提供する必要があります
  • 受信セキュリティグループは SSH アクセスを許可する必要があります
  • デフォルトでは、SSH を使用してリモートでログインできる唯一のアカウントは、EC2 ユーザーです。このアカウントには sudo 権限もあります。
  • Amazon Linux AMI は、起動時にセキュリティ更新プログラムをダウンロードしてインストールするように構成されています。
• Amazon EC2 ユーザーに追加料金なしで提供されます。
• 複数のバージョンの MySQL、PostgreSQL、Python、Ruby、Tomcat、およびより多くの一般的なパッケージへのリポジトリアクセス。
• 最新のコンポーネントを含むように定期的に更新され、これらの更新は、実行中のインスタンスにインストールするための yum リポジトリでも利用できるようになります。
• AWS CLI、Amazon EC2 API、AMI ツール、Python 用 Boto ライブラリ、および Elastic な負荷分散ツールなど、AWS サービスと簡単に統合できるように、プレインストールされたパッケージが含まれています。

Linux 仮想化のタイプ

• Linux のアマゾンマシンのイメージは、仮想化の2種類のいずれかを使用します: 仮想 (PV) またはハードウェア仮想マシン (HVM)
• PV と HVM AMI の主な違いは、彼らが起動する方法であり、彼らはより良いパフォーマンスのための特別なハードウェア拡張機能 (CPU、ネットワーク、およびストレージ) を活用できるかどうか。
• 最適なパフォーマンスを得るには、インスタンスを起動するときに、現在の生成インスタンスタイプと HVM AMI を使用することをお勧めします。
• HVM AMI
  • HVM AMI には、イメージのルートブロックデバイスのマスターブートレコードを実行することによって、完全に仮想化されたハードウェアとブートのセットが示されます。
  • HVM の仮想化タイプは、それがベアメタルハードウェア上で実行されたかのように、変更せずに仮想マシンの上に直接オペレーティングシステムを実行する機能を提供します。
  • Amazon EC2 ホストシステムは、ゲストに提示される基盤となるハードウェアの一部またはすべてをエミュレートします。
  • HVM ゲストは、PV ゲスト とは異なり、ホストシステム上の基盤となるハードウェアへの高速アクセスを提供するハードウェア拡張機能を利用できます。
  • HVM AMI は、強化されたネットワーキングと GPU 処理を利用するために必要です。専用のネットワークおよび GPU デバイスに指示を通すためには、OS はネイティブハードウェアプラットフォームにアクセスできる必要があります。HVM 仮想化は、このアクセスを提供します。
  • 現在生成されているすべてのインスタンスタイプは、HVM AMI をサポートします。 CC2、CR1、HI1、および HS1 前世代のインスタンスタイプは、HVM AMI をサポートします。
• PV AMI
  • PV AMI ブートは、ブートサイクルを開始し、チェーンがあなたのイメージ上の menu.lst ファイルで指定されたカーネルをロードする PV-GRUB と呼ばれる特別なブートローダで起動します。
  • 仮想ゲストは、仮想化を明示的にサポートしていないホストハードウェア上で実行できますが、拡張ネットワーキングや GPU 処理などの特殊なハードウェア拡張機能を利用することはできません。
  • C3 および M3 電流生成インスタンスタイプは PV AMI をサポートします。C1、HI1、HS1、M1、M2、および T1 以前の世代のインスタンスタイプは、PV AMI をサポートしています。

共有 AMI

• 共有 AMI は、使用するために他のユーザーと作成および共有できる AMI です。
• 必要なコンポーネントをすべて使用して共有 AMI を開始し、必要に応じてカスタムコンポーネントを追加することができます。
• 共有 AMI は、Amazon が詳細なチェックを実行せず、これらの AMI の完全性とセキュリティを保証するため、リスクを伴う可能性があります。
• 共有 AMI を使用する前に、サードパーティによるインスタンスへの不要なアクセスを許可するプレインストールされた資格情報を確認し、機密データを第三者に送信する可能性がある事前に構成されたリモートログを作成しない
• Amazon では、起動アクセス許可を定義して、すべての (パブリックにする) か、特定の AWS アカウントのみに AMI を共有できます。
• 起動アクセス許可は、AWS アカウントレベルでのみ機能します。AWS アカウント内の特定のユーザーを制限するために使用することはできません。
• 共有 Linux AMI のガイドライン
  • ブート時に AMI ツールを更新する
    • 起動中に AMI ツールまたは任意のソフトウェアを更新します。
    • ソフトウェアの更新がすべてのソフトウェアを壊さないように考慮し、ダウンロードが AMI ユーザーに課金されるので WAN トラフィックを考慮してください。
  • Root 用のパスワードベースのリモートログインを無効にする
    • 固定ルートパスワードはセキュリティリスクであり、無効にする必要があります
  • ローカルルートアクセスを無効にする
    • 共有 AMI を使用する場合は、直接ルートログインを無効にすることをお勧めします。
  • SSH ホストキーのペアを削除する
    • 誰かがあなたの AMI を使用してインスタンスを起動するときに SSH が新しいユニークな SSH キーのペアを生成するために強制的に /etc/ssh にある既存の ssh ホストキーのペアを削除し、セキュリティを改善し、”マンインミドル” 攻撃の可能性を減らす
  • 公開キー資格情報をインストールする
    • Amazon EC2 では、インスタンスの起動時に、ユーザーが公開秘密キーのペア名を指定できます。
    • インスタンスを起動するときに有効なキーペア名を指定する必要があります、公開キー、Amazon Ec2 がサーバー上で保持するキーペアの部分、インスタンスメタデータに対して HTTP クエリを通じてインスタンスが利用できるようにし、承認されたキー
    • ユーザーは、キーペアを使用して AMI のインスタンスを起動し、root パスワードを必要とせずにログインできます。
  • sshd DNS チェックを無効にする (オプション)
    • sshd の DNS チェックを無効にすると、わずかにあなたの sshd のセキュリティが弱くなります。ただし、DNS の解決に失敗した場合、SSH ログインはまだ機能します。sshd チェックを無効にしないと、DNS 解決の失敗によってすべてのログインが禁止されます。
  • 自分自身を識別する
    • AMI は、それ以上の情報がないアカウント ID によってのみ表されるため、AMI の説明に役立つ情報を提供することをお勧めします。
  • 自分自身を保護する
    • AMI に機密データやソフトウェアを保存しない
    • 機密データまたは秘密情報を保持するディレクトリを除外 & スキップし、AMI を作成する前にシェルの履歴を削除する

AMI の作成

EBS-Backed Linux AMI

• EBS-Backed Linux AMI は、インスタンスから直接または EBS スナップショットから作成できます。
• EBS-Backed Linux AMI の作成プロセス:
  1. 新しい AMI #2 を作成するのに似た AMI #1 を選択します
  2. AMI #1 からインスタンスを起動し、それに応じてインスタンスを構成する
  3. インスタンスを停止してデータの整合性を確保し、AMI #2 を作成します
  4. EBS スナップショットを作成し、スナップショットから AMI #2 を作成します
  5. Amazon は自動的に EBS バックアップ AMI を登録します
  6. AMI #2 新しいインスタンスを起動するために使用する
• デフォルトでは、EC2 はインスタンスをシャットダウンし、アタッチされたボリュームのスナップショットを取得し、AMI を作成して登録してから、インスタンスを再起動します。
• インスタンスのシャットダウンと再起動は、[再起動なし] オプションを使用して防ぐことができますが、作成されたイメージのファイルシステムの整合性は保証できません
• EC2 は、インスタンスのルートボリュームと、インスタンスにアタッチされている他の EBS ボリュームのスナップショットを作成します。インスタンスに関連付けられているボリュームが暗号化されている場合、新しい AMI は Amazon EBS 暗号化をサポートするインスタンスでのみ正常に起動します。
• 追加のインスタンスストアボリュームまたは EBS ボリュームの場合、新しい AMI のブロックデバイスマッピングにはこれらのボリュームの情報が含まれ、新しい AMI から起動したインスタンスのブロックデバイスマッピングには、これらの情報が自動的に含まれます。ボリューム。
• EBS ボリューム上のデータは存続しますが、新しいインスタンスのブロックデバイスマッピングで指定されたインスタンスストアボリュームは新規であり、AMI の作成に使用したインスタンスのインスタンスストアボリュームのデータは含まれません。
• AMI 作成時に作成されたスナップショットとして既に取得された EBS スナップショットを持つ EBS バックアップ AMI を作成する方が効率的です。
• AMI とスナップショットの両方のストレージに対して課金されます。

Instance Store-Backed Linux AMI

• Instance Store-Backed Linux AMI の作成プロセス
  1. 新しい AMI #2 を作成するのに似た AMI #1 を選択します
  2. AMI #1 からインスタンスを起動し、それに応じてインスタンスを構成する
  3. インスタンスをバンドルします。バンドル処理が完了するまでに数分かかります。
  4. プロセスが完了したら、イメージマニフェスト (image.manifest.xml) と、ルートボリュームのテンプレートを含むファイル (iamge.part.xx) で構成されるバンドルがあります。
  5. Amazon S3 バケットにバンドルをアップロードする
  6. インスタンスストアにバックアップされた AMI を登録します。
  7. 新しい AMI #2 を使用してインスタンスを起動すると、Amazon S3 にアップロードしたバンドルを使用してインスタンスのルートボリュームが作成されます。
• 削除されるまで Amazon S3 でバンドルによって使用されているストレージ領域の料金が発生します。
• 追加のインスタンスストアがルートボリュームでない場合、新しい AMI のブロックデバイスマッピングにはこれらのボリュームの情報が含まれ、新しい AMI から起動するインスタンスのブロックデバイスマッピングには、これらのボリュームの情報が自動的に含まれます。

AMI の登録解除

• チャージは作成された AMI に発生し、必要でない場合は登録することができます。
• 登録 AMI は、EBS スナップショットまたは S3 バケット内のバンドルを削除せず、個別に削除する必要があります。
• 登録が解除されると、新しいインスタンスは AMI から起動できません。ただし、AMI からすでに作成されたインスタンスには影響しません
• EBS バックアップ AMI のクリーンアップ
  
  • EBS-Backed AMI の登録抹消
  • AMIの登録を解除してもスナップショットに影響を与えないので、EBSスナップショットを削除してください
• インスタンスストアでバックアップされた AMI をクリーンアップする
  
  • Instance Store-backed AMI の登録抹消
  • AMI の登録を解除しても S3 バケットに格納されているバンドルには影響しないので、S3 バケットからバンドルを削除してください

暗号化されたスナップショットを持つ AMI

• EBS バックアップスナップショットを使用した AMI は、暗号化されたルートとデータボリュームの両方で接続できます。
• AMI のコピーイメージを使用して、暗号化されていないスナップショットを持つ AMI からのスナップショットを作成することができます。既定では、コピーイメージはスナップショットの暗号化状態を保持します。
• スナップショットは、デフォルトの AWS キーマネージメントサービスの顧客マスタキー (CMK)、または指定したカスタムキーで暗号化できます。

AMI のコピー

• Amazon EBS バックアップ AMI およびインスタンスストアバックアップ AMI をコピーできます。
• AMI のコピー
  • 同一のターゲット AMI が作成されますが、独自の一意識別子
  • EBS バックアップ AMI では、同一の別個のルートおよびデータスナップショットが作成されます。
  • スナップショットの暗号化ステータスが保持される
  • ただし、起動アクセス許可、ユーザー定義タグ、または Amazon S3 バケットのアクセス許可は、ソース AMI から新しい AMI にコピーされません。コピー操作が完了すると、新しい AMI に対する起動権限、ユーザー定義タグ、および Amazon S3 バケットのアクセス許可が異なります。
• ソース AMI はターゲット AMI に影響を与えることなく登録できます。
• 所有している AMI、適切なアクセス許可で共有されている AMI をコピーできます。
• AMI はリージョン固有に作成され、リージョン内またはリージョン間でコピーできるため、一貫性のあるグローバル展開を支援し、拡張性と可用性の高いアプリケーションを構築できます。
• AMI のコピーイメージを使用して、暗号化されていない AMI から AMI を暗号化できます。
• AMI コピーイメージを使用して、暗号化された AMI から暗号化しない AMI を作成することはできません

---

AWS認定試験の練習問題

• 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます（これはあなたと異なる場合があります）。
• AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
• AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
• さらなるフィードバック、ディスカッション、修正を可能にします。

1. インスタンスストアされた AMI からユーザーが EC2 インスタンスを起動しました。インフラストラクチャチームは、実行中のインスタンスから AMI を作成する必要があります。 AMI を作成する際には、以下に挙げる資格情報のどれも必要ではありませんか？
   1. AWS アカウント ID
   2. 509証明書と秘密キー
   3. コンソールにログインするための AWS ログイン ID
   4. アクセスキーとシークレットアクセスキー
2. インスタンスストアされた AMI からユーザーが EC2 Windows インスタンスを起動しました。ユーザーは AMI を EBS でバックアップされた AMI に変換する必要があります。ユーザーはどのように変換できますか？
   1. EBS ボリュームをインスタンスにアタッチし、EBS 内のすべての AMI バンドルデータをバンドル
   2. Windows ベースのインスタンスストアのバックアップ AMI を EBS バックアップ AMI に変換することはできません。
   3. インスタンスストアのバックアップされた AMI を EBS バックアップ AMI に変換することはできません。
   4. EBS ボリュームをアタッチし、copy コマンドを使用して、すべての一時的なコンテンツを EBS ボリュームにコピーします。
3. ユーザーは、US-East-1a リージョンに2つの EBS バックアップ EC2 インスタンスを開始しました。ユーザーは、インスタンスの1つのゾーンを変更する必要があります。ユーザーはどのように変更できますか？
   1. インスタンスのいずれかを停止し、アベイラビリティーゾーンを変更する
   2. このゾーンは、AWS CLI を使用してのみ変更できます。
   3. AWS EC2 コンソールで、[アクション] → [ゾーンの変更]、[新しいゾーンの指定] の順に選択します。
   4. 実行中のインスタンスの AMI を作成し、別の AZ でインスタンスを起動します。
4. ユーザーは、US-East-1a リージョンで大きな EBS バックアップ EC2 インスタンスを開始しました。ユーザーは、ヨーロッパで別の小さなインスタンスを作成して、そのインスタンスの DR （災害復旧）を達成したいと考えています。ユーザーはどのように DR を達成できますか？
   1. “インスタンスコピー” コマンドを使用して、実行中のインスタンスを EU リージョンにコピーします。
   2. インスタンスの AMI を作成し、AMI を EU リージョンにコピーします。次に、EU AMI からインスタンスを起動します。
   3. 米国東部リージョンから EU リージョンへのインスタンスのコピー
   4. [次のように起動する] オプションを使用して、インスタンスをあるリージョンから別のリージョンにコピーします。
5. ユーザーは、US-East-1a ゾーンに EC2 インスタンスストアバックインスタンスを起動しました。 ユーザーは AMI＃1 を作成し、ヨーロッパリージョンにコピーしました。 その後、ユーザーは US-East-1a ゾーンで実行されているアプリケーションを少し更新しました。 ユーザは、変更後に AMI＃2 を作成する。 ユーザーが AMI＃1 のコピーからヨーロッパの新しいインスタンスを起動した場合、以下のステートメントのどちらが当てはまりますか？
   1. 新しいインスタンスは、コピー中に元の AMI の参照をコピーするだけで、AMI コピーの後に変更が加えられます。したがって、コピーされた AMI は、すべての更新データを持つことになります
   2. 新しいインスタンスは、AMI の更新を保持しているため、AMI のコピー後に変更が加えられます。
   3. インスタンスストアのバックアップされた AMI をあるリージョンから別のリージョンにコピーすることはできません。
   4. EU リージョン内の新しいインスタンスには、AMI コピーの後に行われた変更はありません。
6. Georgeは、米国East地区で作成されたEC2 AMIをAWSアカウントからStefanoに共有しました。ジョージは同じAMIを米国西部地域にコピーします。 Stefanoは、米国西部からジョージのアカウントのコピーされたAMIにアクセスできますか？
   1. いいえ、コピー AMI はアクセス許可をコピーしません
   2. 特定のアカウントで AMI を共有することはできません。
   3. はい、コピー AMI はすべてのプライベートアカウントの共有アクセス許可をコピーするため
   4. はい、AMI に添付されているすべてのアクセス許可をコピー AMI がコピーするため
7. EC2インスタンスは、Amazon Machine Image（AMI）から起動されます。与えられた公開 AMIは：
   1. 任意の AWS リージョンで EC2 インスタンスを起動するために使用します。
   2. AMI が格納されているのと同じ国で EC2 インスタンスを起動するためにのみ使用されます。
   3. AMI が格納されているのと同じ AWS リージョンで EC2 インスタンスを起動する場合にのみ使用します。(AMI は、そのファイルが Amazon S3 内にある領域に関連付けられています)
   4. AMI が格納されているのと同じ AWS アベイラビリティーゾーンで EC2 インスタンスを起動する場合にのみ使用します。

リファレンス

• Amazon マシーンイメージ(AMI)のユーザーガイド

---

Jayendra’s Blog

この記事は自己学習用に「AWS EC2 Amazon Machine Image – AMI – Certification（Jayendra’s Blogより）」を日本語に訳した記事です。