【初心者向け】Amazon EC2の高度な詳細（Advanced details）についてまとめてみた

こんにちは！エンタープライズクラウド部技術2課の日高です。
Amazon EC2（今後はEC2と表記）をマネジメントコンソールから作成する際に、「この設定なんだっけ？」と高度な詳細の項目について忘れてしまうことがよくあるので備忘録がてらまとめていきたいと思います。

今回、「購入オプション」「ドメイン結合ディレクトリ」「IAM instance profile」「ユーザーデータ」は載せるとボリュームが多くなりすぎて読み手の方が大変だと思うので、別のブログにて書いていきたいと思います。

高度な詳細（Advanced details）の項目
まとめ

高度な詳細（Advanced details）の項目

インスタンスの自動復旧（Instance auto-recovery）

システムのステータスチェックが失敗したとき（AWS基盤側で障害があった際）に、自動的にインスタンスの復旧を行う設定です。また、自動復旧されると、AWS Health Dashboard のイベントで通知されます。
自動復旧に失敗すると、AWS Health Dashboard のイベントと E メールで通知されます。
こちらの機能は、「デフォルト」か「無効」を選択することができ、指定しない状態で作成すると「デフォルト」の状態でEC2が作成されます。

基本的に有効で問題ないと思いますが、(1)の場合は利用できないので注意が必要です。
また、(2)の場合はAmazon EventBridge ルールを使用するのがよいと思います。

(1)インスタンスストアボリュームや、メタルインスタンスタイプのインスタンスを利用している場合(公式ドキュメントにて制限事項の記載があります)
(2)システムのステータスチェックが失敗したときにカスタマイズした設定をしたい場合

制限事項
インスタンスストアボリュームとメタルインスタンスタイプのインスタンスは、簡易自動復旧ではサポートされていません。

Auto Scaling グループ内のインスタンスでは、簡易自動リカバリは開始されません。インスタンスが、ヘルスチェックが有効になっている Auto Scaling グループの一部である場合、インスタンスは、障害が発生したときに置き換えられます。

簡素化された自動回復は、予定外のイベントにのみ適用されます。予定されているイベントには適用されません。

終了または停止したインスタンスは回復できません。
インスタンスを回復する抜粋

シャットダウン動作（ Shutdown behavior）

OSレベルで行われたシャットダウンの際に、EC2インスタンスを停止/終了するか指定する設定です。
デフォルトでは「停止」になっています。
基本的には「停止」のままでいいと考えています。

また、後ほど紹介する「終了保護」を有効にしていても、「シャットダウン動作」を終了にしているとEC2インスタンスは削除されるので注意が必要です。

停止 - 休止動作（Stop - Hibernate behavior）

EC2を一時停止しハイバーネーションできる機能です。
EC2上で起動に時間のかかるアプリケーションなどを使っている場合に休止状態を使うことで、起動時間を短縮することができます。
また、デフォルトでは「無効」になっていて、「無効」になっている既存のインスタンスを「有効」にすることはできません。

具体的には、一時停止する前の状態(アプリケーションが起動しているなど)を保持して停止し、再開時には一時停止前と同じ状態で起動します。
WindowsやMacのスリープ状態をイメージすると分かりやすいと思います。
動作としてはメモリ上に保管されているデータをルートEBSボリュームに格納されたファイルに保存して、一時停止前の状態を保持しています。

休止状態を使用するにあたり、いくつか制限事項があるため、主要な制限事項を以下に記載します。

サポートされるインスタンスファミリー

汎用: M3、M4、M5、M5a、M5ad、M5d、M6i、M6id、T2、T3、T3a
コンピューティング最適化: C3、C4、C5、C5d、C6i、C6id
メモリ最適化: R3、R4、R5、R5a、R5ad、R5d
ストレージの最適化: I3、I3en

サポートされるAMI

サポートされているLinux AMIはこちらをご覧ください：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/hibernating-prerequisites.html#hibernation-prereqs-supported-amis
サポートされる Windows AMIはこちらをご覧ください：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/hibernating-prerequisites.html#hibernation-prereqs-supported-amis

EBSボリューム

ルートEBSボリュームにメモリ分の空き容量があることと暗号化が必須です。
また、汎用 SSD （gp2 および gp3）、プロビジョンド IOPS SSD （io1 および io2）である必要があります。

※その他の制限事項については以下をご覧ください。

docs.aws.amazon.com

終了保護(Termination protection)

AWS CLI、マネジメントコンソール、APIによるインスタンスの削除を防ぐ設定です。
デフォルトでは「無効」となっていますが、誤削除を防ぐために「有効」をおすすめします。

削除保護が有効なインスタンスをマネジメントコンソールから削除しようとすると以下のようなエラーが表示されます。

しかし、インスタンスの削除を完全に回避できるわけではなく「シャットダウン動作」による削除や、「Amazon EC2 Auto Scaling」による削除は防げないため注意が必要です。

停止保護(Stop protection)

AWS CLI、マネジメントコンソール、APIによるインスタンスの停止を防ぐ設定です。
デフォルトでは「無効」となっていますが、起動状態を常に維持する必要がある場合は「有効」にすることをおすすめします。

また停止を防ぐだけではなく、休止と削除も防ぐことができます。
しかし、再起動、スケジュールされた停止、 OS からのシャットダウン、AWS EC2 Auto Scalingによる終了などは、防ぐことはできませんのでご注意ください。

※実際に検証したブログが以下になります

Amazon EC2 で Stop Protection（停止保護）機能が発表されました - サーバーワークスエンジニアブログblog.serverworks.co.jp

CloudWatch モニタリングの詳細 (Detailed CloudWatch monitoring)

詳細モニタリングの有効/無効を指定できる設定です。
デフォルトで、EC2インスタンスは、CloudWatchにより CPU使用率、ディスクI/O量などのデータを自動的に 5 分間隔で取得し監視することができます。
詳細モニタリングを有効にすることで、データを 1 分間隔で取得することができます。

ただし、詳細モニタリングは料金がかかるため１分間隔でデータを取得する必要がない場合はデフォルトで問題ないと考えています、

※詳細モニタリングの料金がこちらになります aws.amazon.com

Elastic GPU

Windows インスタンスに対して既存のインスタンスタイプにGPUを追加することができる設定です。
Windowsインスタンスを利用していて、かつGPUを使用したいけどG2、P2などのインスタンスではCPUやメモリの量に過不足がある場合などに利用できます。
選択できるElastic Graphics アクセラレーターは「eg1.medium」、「eg1.large」、「eg1.xlarge」、「eg1.2xlarge」があります。

ただ利用する場合は以下の制約があるので注意が必要です。

アクセラレーターをアタッチできるのは、Windows インスタンスと Microsoft Windows Server 2012 R2 以降のみです。Linux インスタンスは現在サポートされません。

一度に 1 つのアクセラレーターをインスタンスにアタッチできます。

アクセラレーターは、インスタンスの起動時にのみアタッチできます。アクセラレーターを既存のインスタンスにアタッチすることはできません。

アクセラレーターがアタッチされたインスタンスを休止状態にすることはできません。

インスタンス間でアクセラレーターを共有することはできません。

1 つのインスタンスからアクセラレーターをデタッチしたり、別のインスタンスに移動することはできません。アクセラレーターが必要でなくなった場合には、インスタンスを終了します。アクセラレータータイプを変更する場合には、インスタンスで AMI を作成し、インスタンスを終了してから、別のアクセラレーター仕様で新しいインスタンスを起動します。

OpenGL API でサポートされているバージョンは、4.3 以前のみです。DirectX、CUDA および OpenCL はサポートされていません。

Elastic Graphics アクセラレーターは、インスタンスのデバイスマネージャーでの表示またアクセスができません。

アクセラレーターのキャパシティーを予約したり、スケジュールすることはできません。

アクセラレーターは EC2-Classic のインスタンスにはアタッチできません。
Elastic Graphics の制限事項抜粋

クレジット仕様(Credit specification)

T系インスタンスを選択している場合、バースト可能パフォーマンスのモードをスタンダード/無制限で指定できる設定です。
デフォルトでは以下のようになります。

T4g、T3a、および T3 インスタンスを無制限として起動
専有ホストでスタンダードとして T3 インスタンスを起動のみ行えます。
T2 インスタンスをスタンダードとして起動

※詳しくは以下をご覧ください

プレイスメントグループ (Placement group)

既に作成しているプレイスメントグループを選択するかしないか指定する設定です。
プレイスメントグループとは、複数インスタンスを論理的にグループ化することでパフォーマンス向上/耐障害性を高める機能の事です。

プレイスメントグループは、主にパフォーマンスを向上させるための「クラスタープレイスメントグループ」、耐障害性を高めるための「パーティションプレイスメントグループ」「スプレッドプレイスメントグループ」の３種類が存在します。

クラスタープレイスメントグループ

単一AZ内のインスタンスを論理的にグループ化し、EC2インスタンスを密な場所に配置することでネットワークパフォーマンスを最適化します。
同じリージョン内で、VPC Peeringで接続されている場合、 VPCをまたがることができます

低いネットワークレイテンシー、高いネットワークスループットが求められる場合や、ネットワークトラフィックの大部分がグループ内のインスタンス間で発生している場合などにおすすめします。

パーティションプレイスメントグループ

インスタンスをパーティションと呼ばれる論理的なセグメントに分割します。
このパーティションで分割されたインスタンスが同一のラックを共有しないことによりハードウェアによる障害を軽減することができます。

ユースケースとしては、耐障害性を高めたい場合や、HDFS、HBase、Cassandra などの大規模な分散および複製ワークロードを異なるラック間でデプロイするなどが挙げられます。
ただし、パーティションはAZごとに7 つまでのため注意が必要です。

スプレッドプレイスメントグループ

スプレッドプレイスメントグループは、グループ内のインスタンスをそれぞれ異なるハードウェアに配置することで、インスタンスが同じラックを共有するときに発生する可能性のある同時障害のリスクを減らすことができます。
これより互いに分離してインスタンスを保持することができるので、それぞれのインスタンスを独自に構成したいときに使用します。

キャパシティーの予約(Capacity reservation)

キャパシティー予約（正しくはオンデマンドキャパシティー予約）とは、該当するインスタンスタイプの EC2 インスタンスを任意の時間に「起動可能」であるというキャパシティーを予約する権利のことです。
設定値は以下の４つがあります。

None：なし
Open：開く ※デフォルト値
Target by ID（Specify Capacity Reservation）：キャパシティーの予約の指定
Target by group（Specify Capacity Reservation resource group）：キャパシティー予約リソースグループの指定

デフォルトでは「開く（Open）」が指定されているため、インスタンス起動時にオンデマンドキャパシティーの設定を参照し、条件に一致するキャパシティー予約があれば、その設定を資料してインスタンスを起動します。

※詳しくは以下のブログをご覧ください

blog.serverworks.co.jp

テナンシー(Tenancy)

テナント属性とも呼ばれ、EC2インスタンスのAWS基盤側のハードウェアをどのような形態で利用するかを指定する設定です、
共有/専有/専有ホストの中から選択でき、デフォルトでは「共有」が指定されています。

セキュリティ要件などによりハードウェアを指定する必要がある場合は、専有/専有ホストの選択していただき、特に要件がない場合は「共有」をおすすめします。（共有の方が、専有/専有ホストに比べて料金が低いため）

共有（Default）

AWS 基盤側となるハードウェアを他の利用者と共有する状態で使用する形態です。

専有（Dedicated Instance）

AWS 基盤側となるハードウェアを専用で利用する形態です。
具体的には、利用している AWS アカウントが起動した別のインスタンスが動作することはあっても、他の AWS アカウントの起動したインスタンスが動作することはありません。

専有ホスト（Dedicated Hosts）

AWS 基盤側となるハードウェアを専用で利用する形態です。
具体的には、利用時にインスタンスファミリーを指定すると、他の AWS アカウントのインスタンスはもちろん、利用者の AWS アカウントの別のインスタンスが起動されることもありません。

RAM ディスク ID(RAM disk ID)

準仮想化 (PV) AMI に対してのみ有効な設定で、インスタンスの RAM ディスクを選択します。
カーネルを選択した場合は、サポートするドライバーと共に特定の RAM ディスクを選択しなければならない可能性があるため注意が必要です。
基本的に最新のAMIはHVM AMIなので、そこまでRAM ディスクIDは意識しなくても問題ないと考えています。

準仮想化（PV）

仮想化方式の1種で、仮想化を明示的にサポートしていないホストハードウェアで実行できます。
起動方法としてPV-GRUB や、AKI, ARI を使う方式があります。

完全仮想化（HVM）

仮想化方式の1種で、完全に仮想化された一連のハードウェアを備えています。
ルートデバイスにあるブートローダから、デバイス内に含まれる kernel を起動していきます。
最新のMAIはほとんどが、HVM AMIです。

仮想化方式の確認方法

仮想化方式は、マネジメントコンソール上ではAMIの欄から確認することができます。

カーネル ID(Kernel ID)

準仮想化 (PV) AMI に対してのみ有効な設定で、インスタンスのカーネルを選択します。
基本的に最新のAMIはHVM AMIなので、そこまでカーネルIDは意識しなくても問題ないと考えています。

Nitro Enclave

有効にすることで、機密性の高いデータをより安全に処理できる機能になります。
デフォルトでは無効になっています。

具体的には、EC2インスタンス内にEnclaveと呼ばれるメモリとCPUの分離を行った環境が作られます。
Enclaveでは、永続なストレージを持たず、管理者もアクセス出来ず、外部ネットワークとは接続出来ず、親EC2インスタンスとの通信のみが許可されます。

ただ利用できるEC2インスタンスは下記要件を満たしいてる必要があります。

Nitroベースのインスタンスであること
インスタンスのvCPUが4以上であること
Linux OSであること

ライセンス設定(License configurations)

任意で既存のLicense Managerルールを選択することができます。
License Managerルールにより、EC2インスタンス起動時にライセンス違反を制限することができます。

※詳しくは以下をご覧ください

docs.aws.amazon.com

CPUオプションを指定

CPUのコア数やスレッド数などの数を指定できます。
設定画面は以下の通りです。

アクセス可能なメタデータ(Metadata accessible)

インスタンスメタデータへのアクセスを有効/無効から指定できる設定です。
デフォルトでは「有効」になっていて、無効にするとインスタンスの起動時にユーザーデータを使用することができなくなります。

メタデータのバージョン(Metadata version)

インスタンスメタデータのバージョンを V1およびV2/V2のみから指定できる設定です。
デフォルトでは「V1およびV2」が選択されます。

V2を使用することでメタデータへのアクセスに、事前に取得したTokenが必須になるためセキュリティが向上します。
しかし、「V2のみ」を選択すると、すべてのインスタンスメタデータリクエストにセッショントークンを含める必要があります。
これにより、インスタンスメタデータアクセスに V1 を使用するアプリケーションまたはエージェントは動作しなくなるため注意が必要です。

メタデータレスポンスのホップ制限 (Metadata response hop limit)

メタデータトークンが移動できるネットワークホップの数を1~64で指定できる設定です。
デフォルトでは、「１」が指定されています。

基本的に「１」で問題ないと思いますが、コンテナをEC2にて起動している場合などは「２」にしないとメタデータの取得に失敗するので注意が必要です。

メタデータのタグを許可(Allow tags in metadata)

HTTPリクエストによってインスタンスに紐づくタグを取得を有効（許可）/無効（許可しない）を指定する設定です。
デフォルトでは「無効」になっています。

有効にすることで、メタデータを取得する際にタグ情報を取得する必要がなくなるため1秒当たりの API トランザクションが削減されます。
詳しくは以下をご覧ください

インスタンスのメタデータからインスタンスのタグにアクセスできます。インスタンスメタデータからタグにアクセスすると、DescribeInstances または DescribeTags API コールを使用してタグ情報を取得する必要がなくなります。これにより、1 秒あたりの API トランザクションが削減され、制御するインスタンスの数に応じてタグ取得をスケーリングできるようになります。さらに、インスタンスで実行されているローカルプロセスは、インスタンスのメタデータからインスタンスのタグ情報を直接表示できます。

デフォルトでは、インスタンスメタデータからタグは使用できません。アクセスを明示的に許可する必要があります。インスタンスの起動時、または実行中または停止したインスタンスでの起動後にアクセスを許可できます。起動テンプレートでこれを指定することで、タグへのアクセスを許可することもできます。テンプレートを使用してインスタンスが起動されると、インスタンスメタデータ内のタグへのアクセスが許可されます。

インスタンスタグを追加または削除すると、Nitro System 上に構築されたインスタンスに対してインスタンスの実行中にインスタンスのメタデータが更新されます。インスタンスを停止して起動したりする必要はありません。他のすべてのインスタンスでは、インスタンスメタデータのタグを更新するには、インスタンスを停止してから起動する必要があります。

インスタンスメタデータ内のインスタンスタグの使用抜粋

まとめ

まとめてみると私が知らなかった設定値もあり勉強になりました。
本記事が誰かの助けになれば幸いです。