このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
Amazon EKS 自動モードl マネージドインスタンスについての説明
このトピックではAmazon EKS 自動モードl が EKS クラスター内の Amazon EC2 インスタンスを管理する方法について説明します。EKS 自動モードl を有効にすると、クラスターのコンピューティングリソースが EKS によって自動的にプロビジョニングおよび管理され、クラスター内のノードとして機能する EC2 インスタンスの操作方法が変わります。
Amazon EKS 自動モードl がインスタンスを管理する方法を理解することはワークロードのデプロイ戦略と運用手順を計画するのに不可欠です。従来の EC2 インスタンスやマネージドノードグループとは異なり、これらのインスタンスは特定のタイプのアクセスとカスタマイズを制限しながら、EKS が多くの運用面に対して責任を負う別のライフサイクルモデルに従います。
Amazon EKS 自動モードl は新しい EC2 インスタンスを作成するためのルーチンタスクを自動化し、それらをノードとして EKS クラスターにアタッチします。EKS 自動モードl はワークロードが既存のノードに収まらない状況を検出し、新しい EC2 インスタンスを作成します。
Amazon EKS 自動モードl はEC2 インスタンスの作成、削除、パッチ適用を担います。インスタンスにデプロイされたコンテナとポッドについてはユーザーの責任となります。
EKS 自動モードl によって作成された EC2 インスタンスは他の EC2 インスタンスとは異なり、マネージドインスタンスです。このマネージドインスタンスは EKS によって所有され、制限が厳しくなっています。EKS 自動モードl によって管理されているインスタンスに直接アクセスしたりソフトウェアをインストールしたりすることはできません。
AWS ではEKS 自動モードl またはセルフマネージド Karpenter の実行をお勧めします。移行中でも高度な設定においてでもインストールが可能です。両方がインストールされている場合はワークロードが Karpenter または EKS 自動モードl に関連付けられるようにノードプールを設定します。
詳細については「Amazon EC2 ユーザーガイド」の「Amazon EC2 管理されたインスタンス」を参照してください。
比較表
| スタンダード EC2 インスタンス | EKS 自動モードl マネージドインスタンス |
|---|---|
|
インスタンスのパッチ適用と更新はユーザーの責任となります。 |
AWS で自動的にインスタンスのパッチ適用と更新が行われます。 |
|
EKS はインスタンス上のソフトウェアに関与しません。 |
EKS は |
|
EC2 API を使用して EC2 インスタンスを削除できます。 |
EKS によりアカウントにデプロイされたインスタンスの数が決定されます。ワークロードを削除すると、EKS によりアカウント内のインスタンスの数が減ります。 |
|
SSH を使用して EC2 インスタンスにアクセスできます。 |
ポッドとコンテナをマネージドインスタンスにデプロイできます。 |
|
ユーザーがオペレーティングシステムとイメージ (AMI) を決定します。 |
AWS によりオペレーティングシステムとイメージが決定されます。 |
|
Windows または Ubuntu の機能に依存するワークロードをデプロイできます。 |
Linux に基づいてコンテナをデプロイできますが、特定の OS 依存関係はありません。 |
|
ユーザーが起動するインスタンスタイプとファミリーを決定します。 |
AWS により起動するインスタンスタイプとファミリーが決定されます。ノードプールを使用して、EKS 自動モードl が選択するインスタンスタイプを制限できます。 |
次の機能はマネージドインスタンスとスタンダード EC2 インスタンスの両方で機能します：
-
インスタンスストレージは、ワークロードのエフェメラルストレージとして使用できます。
AMI サポート
EKS Auto Mode では、AWS がコンピューティングノードに使用されるイメージ (AMI) を決定します。AWS は新しい EKS Auto Mode AMI バージョンのロールアウトをモニタリングします。AMI バージョンに関連するワークロードの問題が発生した場合は、サポートケースを作成します。詳細については、「AWS サポートユーザーガイド」の「Creating support cases and case management」を参照してください。
EKS の場合、通常、CVE とセキュリティ修正を含む新しい AMI が毎週リリースされます。
マネージドリソースの可視性
注記
2026 年 4 月 22 日以降、EKS オートモードによって作成された新しい Amazon EC2 マネージドインスタンスと関連リソース (EC2 起動テンプレート、EBS ボリューム、ネットワークインターフェイス (ENI) など) は、EC2 コンソールビューと describe API リストオペレーションからデフォルトで非表示になります。その日付より前にアカウントに既に存在していたマネージドリソースは表示され続けます。この動作は、マネージドリソースの可視性設定を使用して変更できます。
Amazon EC2 には、マネージドリソースが EC2 コンソールビューと API リストオペレーション (DescribeInstances など) に表示されるかどうかを制御するマネージドリソースの可視性設定が用意されています。
マネージドリソースが非表示になっている場合、EKS オートモードマネージドインスタンスとその関連リソース (EBS ボリューム、起動テンプレート、ネットワークインターフェイス) は EC2 コンソールまたは describe API レスポンスに表示されません。これにより、ガバナンスダッシュボードを簡素化し、オブザーバビリティツールのノイズを減らし、マネージドリソースを顧客の設定ミスとしてフラグ付けするクラウドセキュリティ体制管理 (CSPM) スキャナーの誤検出を防ぐことができます。
可視性設定は、すべての IAM プリンシパルにアカウント全体で適用されます。リソースタイプまたはリソースを作成したサービスによって、マネージドリソースを選択的に表示または非表示にすることはできません。非表示のリソースは完全に動作し、請求可能です。
可視性設定は、Amazon EC2 コンソールまたは AWS CLI を使用していつでも変更できます。詳細については、「Amazon EC2 ユーザーガイド」の「マネージドリソースの可視性設定」を参照してください。
注記
マネージドリソースが EC2 コンソールビューとリスト API から非表示になっていても、以下を通じて EKS オートモードインスタンスを表示できます。
-
クラスターの [コンピューティング] タブの下にある Amazon EKS コンソール。
-
Kubernetes API (
kubectl get nodesなど)。 -
インスタンス ID によるダイレクト EC2 API クエリ (
describe-instances --instance-ids i-0123456789abcdef0など)。 -
include-managed-resourcesパラメータを使用したDescribeInstancesAPI。 -
マネージドリソースの可視性設定を変更した後の EC2 コンソール。
EKS Auto Mode でサポートされているインスタンスリファレンス
EKS Auto Mode は、サポートされているタイプの、最小サイズ要件を満たしたインスタンスのみを作成します。
EKS 自動モードでは、次のインスタンスタイプがサポートされています：
| ファミリー | インスタンスタイプ |
|---|---|
|
コンピューティングの最適化 © |
c8id、c8i、c8i-flex、c8gd、c8gn、c8g、c8a、c8gb、c7a、c7g、c7gn、c7gd、c7i、c7i-flex、c6a、c6g、c6i、c6gn、c6id、c6in、c6gd、c5、c5a、c5d、c5ad、c5n、c4 |
|
汎用 (M) |
m8id、m8i、m8i-flex、m8a、m8azn、m8gn、m8gb、m8gd、m8g、m7i、m7a、m7g、m7gd、m7i-flex、m6a、m6i、m6in、m6g、m6idn、m6id、m6gd、m5、m5a、m5ad、m5n、m5dn、 m5d、m5zn、m4 |
|
メモリを最適化 ® |
r8id、r8i、r8i-flex、r8gn、r8gb、r8gd、r8g、r8a、r7a、r7iz、r7gd、r7i、r7g、r6a、r6i、r6id、r6in、r6idn、r6g、r6gd、r5、r5n、r5a、r5dn、r5b、r5ad、r5d、r4 |
|
バースト可能 (T) |
t4g、t3、t3a、t2 |
|
ハイメモリ (Z/X) |
z1d、x8aedz、x8g、x8i、x2gd |
|
ストレージ最適化 (I/D) |
i8ge、i7i、i8g、i7ie、i4g、i4i、i3、i3en、is4gen、d3、d3en、im4gn |
|
高速コンピューティング (P/G/Inf/Trn) |
p6-b200、p6-b300、p5、p5e、p5en、p4d、p4de、p3、p3dn、g7e、g6、gr6、g6e、g5g、g5、g4dn、g4ad、inf2、inf1、trn1、trn1n、trn2 |
|
ハイパフォーマンスコンピューティング (HPC/X2) |
hpc8a、x2iezn、x2iedn、x2idn |
さらに、EKS Auto Mode は、次の要件を満たす EC2 インスタンスのみを作成します。
-
複数の CPU
-
インスタンスサイズがナノ、マイクロ、スモールではない
詳細については、「Amazon EC2 インスタンスタイプの命名規則」を参照してください。
インスタンスメタデータサービス
-
EKS Auto Mode では、デフォルトでホップ制限が 1 の IMDSv2 が実施され、AWS セキュリティのベストプラクティスに準拠します。
-
このデフォルト設定は自動モードでは変更できません。
-
通常は IMDS アクセスが必要なアドオンの場合、IMDS ルックアップを避けるため、インストール中にパラメータ (AWS リージョンなど) を指定します。詳細については、Amazon EKS アドオンのためにカスタマイズできるフィールドを決定する を参照してください。
-
自動モードで実行するときにポッドが IMDS アクセスを絶対に必要とする場合は、ポッドを で実行するように設定する必要があります
hostNetwork: true。ポッドがインスタンスメタデータサービスに直接アクセスできるようになります。 -
ポッドにインスタンスメタデータへのアクセスを付与する場合、セキュリティ上の影響などを配慮してください。
Amazon EC2 インスタンスメタデータサービス (IMDS) に関する詳細については、「Amazon EC2 ユーザーガイド」の「インスタンスメタデータサービスのオプション設定」を参照してください。
考慮事項
-
NodeClass で設定されたエフェメラルストレージがインスタンスの NVMe ローカルストレージよりも小さい場合、EKS Auto Mode は次のアクションを自動的に実行することで、手動設定の必要性を排除します。
-
より小さい (20 GiB) Amazon EBS データボリュームを使用し、コストを削減します。
-
エフェメラルデータ用に NVMe ローカルストレージをフォーマットして設定します。複数の NVMe ドライブがある場合、これには RAID 0 アレイの設定が含まれます。
-
-
ephemeralStorage.sizeがローカルの NVMe 容量と等しいかそれより大きい場合、以下のアクションが実行されます。-
Auto Mode では、容量の少ない EBS ボリュームはスキップされます。
-
NVMe ドライブは、ワークロードに直接公開されます。
-
-
Amazon EKS 自動モードは、以下の AWS Fault Injection Service アクションをサポートしていません。
-
ec2:RebootInstances -
ec2:SendSpotInstanceInterruptions -
ec2:StartInstances -
ec2:StopInstances -
ec2:TerminateInstances -
ec2:PauseVolumeIO
-
-
Amazon EKS 自動モードは、AWS Fault Injection Service EKS ポッドアクションをサポートしています。詳細については「AWS レジリエンスハブユーザーガイド」の「Fault Injection Service の実験管理」と「AWS FIS aws:eks:pod アクション」を参照してください。
-
EKS 自動モードのノードに
Neuron Device Pluginをインストールする必要はありません。クラスター内に他のタイプのノードがある場合、自動モードのノードで実行されないように Neuron Device プラグインを設定する必要があります。詳細については、ワークロードが EKS Auto Mode ノードにデプロイされるかどうかを制御する を参照してください。
