EKS Auto ModeとEKS on Fargateの違い｜制約一覧・料金の分岐点・併用時の落とし穴

EKSでノードの管理から手を引きたいとき、実質的な候補はEKS Auto ModeとEKS on Fargateの2つです。どちらも「ノードを自分で運用しない」点は同じですが、片方はAWSが所有するEC2インスタンスを裏で動かし、もう片方はそもそもノードを持ちません。この差が、DaemonSetを配れるか、GPUを載せられるか、Pod単位でセキュリティグループを付けられるか、という具体的な可否に直結します。本記事では2026年8月時点の公式ドキュメントと東京リージョンの実価格をもとに、両者の制約とコストの分岐点、そして同一クラスタで併用するときの注意点を整理します。

まとめ：Auto ModeとFargateの選び分け

DaemonSetを前提にした監視・ログ収集の仕組みを持っているなら、EKS on Fargateは選べません。FargateはDaemonSetを実行できず、GuardDuty Runtime Monitoringの対象外でもあるため、既存のセキュリティ運用がそのまま乗りません。GPU、Spotインスタンス、EBSボリュームが必要な場合も同様にFargateは外れます。

逆に、Pod単位でセキュリティグループを割り当てる要件があるならAuto Modeは選べません。EKS Auto Modeはsecurity groups for Pods（SGPP）に非対応で、公式ドキュメントは代わりにNodeClassのpodSecurityGroupSelectorTermsを使うよう案内しています。要件がSGPPそのもので固まっている場合、この差は設計変更を伴います。

コストは稼働率で判断が割れます。東京リージョンの実価格では、1 vCPU／メモリ枠3 GBのFargate Pod 約6.4本分がc6a.2xlargeのAuto Modeノード1台と釣り合います。常時稼働のPodを7本以上詰められるならAuto Mode、動いていない時間が長いバッチならFargateです。以降で分岐点の計算根拠と、併用時にCoreDNSで踏む落とし穴を順に見ていきます。

マネージドEC2ノードとノードレス、責任分界の違い

両者の制約はすべてアーキテクチャの違いから導かれます。EKS Auto Modeは実体としてEC2インスタンスを起動しますが、それはAWSが所有する「マネージドインスタンス」です。EKS on Fargateにはノードという実体がなく、公式ドキュメントが「Amazon EKS Fargate runs only one Pod per node」と明記する通り、Kubernetesから見えるノードとPodが1対1で対応します。

EC2マネージドインスタンスとして扱われるAuto Modeのノード

Auto Modeのノードは、Bottlerocketベースの読み取り専用ルートファイルシステムを持ち、SELinuxがenforcingモードで動きます。公式ドキュメントは「Prevents direct access to the nodes by disallowing SSH or SSM access」と記述しており、SSHもSSMも通りません。ノードの寿命は最大21日で、短縮はできますが延長はできず、期限が来ると自動的に新しいノードへ置き換わります。

比較の観点では、ここがFargateとの実質的な同一点になります。どちらを選んでもノードへログインしての調査は成立しません。違うのは理由で、Auto Modeは存在するノードへの経路を塞いでおり、Fargateはそもそもノードを持ちません。ノード側の仕様（AMIの更新周期、IMDSv2のホップ数固定、対応インスタンスタイプ）はEKS Auto Modeの自動化範囲とNodePoolの制約で個別に扱っています。

資産棚卸しでコンピュートが見えなくなる非対称性

両者はインベントリ管理の見え方でも非対称です。Fargateはノードを持たないため、EC2の資産台帳に何も現れません。Auto Modeは現れますが、公式ドキュメントの注記によれば2026年4月22日以降に作成されたマネージドインスタンスと関連リソースは、EC2コンソールの一覧とdescribe系APIの一覧操作から既定で非表示になります（同日より前のリソースは引き続き表示）。隠れていても課金と稼働は続きます。

つまり、EC2のDescribeInstancesを起点にしたCSPMや棚卸しスクリプトは、どちらを選んでもコンピュートを把握できません。可視性設定の戻し方や確認手段はEKS Auto Modeの自動化範囲とNodePoolの制約にまとめています。

機能制約の対応表で見る選定の分岐点

選定に効く項目だけを公式ドキュメントの記述から抜き出すと、次のようになります。判断が割れるのは表の上半分、つまりDaemonSet・GPU・Spot・Pod単位セキュリティグループの4行です。

Windowsの行だけ補足します。Fargateの比較表は「Can run containers that require Windows: No」、Auto Mode側は「You can deploy containers based on Linux, but without specific OS dependencies」で、どちらもWindows向けのノードを提供しません。Windowsコンテナが必要なら、マネージドノードグループやセルフマネージドノードを併用します。4つの提供形態を横断した整理はAmazon EKSの仕組みとノード提供形態・料金モデルにあります。

DaemonSet前提の監視・ログ収集はFargateで成立しない

実務でFargateが真っ先に候補から落ちる理由が、この行です。公式ドキュメントは「Daemonsets aren’t supported on Fargate. If your application requires a daemon, reconfigure that daemon to run as a sidecar container in your Pods」と書いています。回避策はサイドカー化ですが、Podの数だけエージェントが増え、その分のvCPUとメモリがすべて課金対象になります。

影響はログ収集やメトリクス収集にとどまりません。GuardDutyのRuntime Monitoringは、セキュリティエージェントをEKSアドオンとしてノードに配る方式です。公式ドキュメントは対象範囲を「Runtime Monitoring supports Amazon EKS clusters running on Amazon EC2 instances and Amazon EKS Auto Mode」とし、続けて「doesn’t support Amazon EKS clusters with Amazon EKS Hybrid Nodes, and those running on AWS Fargate」と明示しています。ランタイム脅威検知を組織のセキュリティ標準にしているなら、Fargateはその時点で候補から外れます。Auto Modeは名指しで対応済みなので、この観点では迷う余地がありません。

Pod単位セキュリティグループはFargate限定、Auto ModeはNodeClassで代替

逆方向の制約がPod単位のセキュリティグループです。security groups for Podsの公式ドキュメントには「Security groups for Pods can’t be used with Windows nodes or EKS Auto Mode」という一文があり、Auto Modeは名指しで除外されています。一方Fargateの比較表は「Can assign different VPC security groups to individual Pods: Yes」です。ここだけはFargateが明確に上を行きます。

ただしAuto Modeでネットワーク分離ができないわけではありません。Auto Modeのネットワークドキュメントは、SGPPを非対応と書いたうえで「To apply separate security groups to Pod traffic in Auto Mode, use podSecurityGroupSelectorTerms in the NodeClass instead」と代替手段を案内しています。Podを別サブネットへ寄せ、ノードのトラフィックから分離する設計です。粒度はPodごとではなくNodeClassごとになるため、「このDeploymentだけ別のセキュリティグループ」という要件がPod単位で細かく決まっている場合は移行コストが発生します。要件を書き換えられるかどうかが判断の分かれ目です。

東京リージョンの実価格で見る損益分岐点

コスト比較は一般論では答えが出ません。AWS Price List APIから取得した東京リージョン（ap-northeast-1）の単価を並べます。いずれも2026年8月18日時点のオンデマンド価格です。

クラスター料金の0.10 USD／時はどちらを選んでも同額でかかります。管理手数料はインスタンスタイプごとに違い、c6a.2xlargeならEC2料金の約12%です。なお公式のEKS料金ページに載っているc6a.2xlargeの例（0.03672 USD／時）はオレゴンリージョンの値です。東京で見積もるならAPI側の0.04622を使ってください。クラスター料金・料金三層の内訳はEKS Auto Modeの自動化範囲とNodePoolの制約で詳しく扱っています。

Fargateは要求値ではなく丸め上げ後の枠で課金される

Fargateの見積もりで最初に外すのがここです。Fargateはrequestsに書いた値をそのまま課金しません。公式ドキュメントによれば、まずKubernetesコンポーネント（kubelet、kube-proxy、containerd）用に各Podへ256 MBが加算され、その合計値が、あらかじめ決められたvCPUとメモリの組み合わせ表の中で最も近い上位の枠へ丸め上げられます。

公式ドキュメント自身が挙げている例が分かりやすいので引用します。1 vCPU・メモリ8 GBを要求すると256 MBが足されて8.25 GBになりますが、1 vCPUの枠には8 GBまでしかありません。結果として2 vCPU・9 GBのタスクが確保され、要求していないvCPUの分まで課金されます。エフェメラルストレージの既定は20 GiB（うちkubeletなどが消費するため実際に使える量は20 GiB未満）で、上限は175 GiBです。こちらは丸め上げとは別の挙動で、100 GiBを要求すると115 GiBが確保されますが、超過分はシステム用途としての確保であり、課金の基準は20 GiBを超えて要求した分になります。

実際にどの枠が割り当てられたかは、Podのアノテーションで確認できます。

kubectl describe pod --namespace batch my-job-pod | grep CapacityProvisioned

公式ドキュメントの出力例ではCapacityProvisioned: 0.25vCPU 0.5GBのように表示され、この値がそのまま課金額の基準になります。kubectl get nodesが返すノードサイズはPodの容量と対応しないため、そちらを見て見積もっても意味がありません。

Auto Modeノード1台と釣り合うFargate Podの本数

丸め上げのルールが分かったので、実際に釣り合う本数を出します。1 vCPU・2 GBを要求するPodは、256 MB加算後の2.25 GBが1 vCPUの枠（2／3／4／5／6／7／8 GB）の中で3 GBへ丸め上げられます。

Fargate Pod 1本（1 vCPU / メモリ枠 3 GB）
  1 x 0.05056 + 3 x 0.00553 = 0.06715 USD/時
  730時間換算 = 49.02 USD/月

Auto Mode ノード 1台（c6a.2xlarge・8 vCPU / 16 GiB）
  EC2 0.3852 + 管理手数料 0.04622 = 0.43142 USD/時
  730時間換算 = 314.94 USD/月

損益分岐  0.43142 ÷ 0.06715 = 6.42 本

つまり、同じ要求値のPodを1台のc6a.2xlargeに7本以上詰められればAuto Modeが安く、6本以下ならFargateが安いという関係です。ここで注意したいのは、8 vCPU・16 GiBのインスタンスに1 vCPU・2 GiBのPodを7本載せると7 vCPU・14 GiBを占有し、kubeletやOSの予約分を差し引いた実際の割り当て可能量にかなり近づくという点です。分岐点の6.42本と現実的な上限がほぼ重なるため、この構成では両者のコスト差はほとんど出ません。「Fargateは割高」という一般論は、常時稼働かつビンパッキングが効く前提でのみ成り立ちます。

差が開くのは2つの場合です。1つは稼働率が低いワークロード。Fargateは1分の最低課金でPod単位に止まるため、日次バッチやイベント駆動の処理なら、24時間動き続けるノードを持つより明確に安くなります。もう1つはSpotを許容できる場合で、こちらはAuto Modeの独壇場です。EKSのFargateではFargate Spotが使えず、Auto ModeはカスタムNodePoolでSpotを指定でき中断通知の処理もサービス側が引き受けます。

同一クラスタでの併用手順とCoreDNSの落とし穴

どちらか一方に寄せる必要はありません。1つのクラスタでAuto ModeのNodePoolとFargateプロファイルを同時に持ち、ワークロードごとに振り分ける構成が取れます。常駐APIはAuto Modeのノードへ、日次バッチはFargateへ、という分け方です。

振り分けはeks.amazonaws.com/compute-typeラベルで行います。Auto Modeのノードにはこのラベルへautoという値が設定されているので、Auto Modeへ寄せたいワークロードにはnodeSelectorを付けます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      nodeSelector:
        eks.amazonaws.com/compute-type: auto

反対に、Auto Modeのノードへ載せたくないワークロードにはnodeAffinityで除外条件を書きます。Fargateプロファイルのセレクタと組み合わせることで、意図しない側へスケジュールされる事故を防げます。

spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: eks.amazonaws.com/compute-type
                operator: NotIn
                values:
                - auto

Fargate側はネームスペースやラベルでプロファイルのセレクタを定義します。Podはスケジュール時点でプロファイルに一致している必要があり、一致しないPodはPendingのまま止まる場合があります。

aws eks create-fargate-profile \
  --cluster-name my-cluster \
  --fargate-profile-name batch-jobs \
  --pod-execution-role-arn arn:aws:iam::111122223333:role/AmazonEKSFargatePodExecutionRole \
  --subnets subnet-0abc1234 subnet-0def5678 \
  --selectors namespace=batch

併用構成で最も踏みやすい落とし穴はCoreDNSにあります。Auto Modeは従来のCoreDNS Deploymentを使わず、各ノード上でシステムサービスとして動くCoreDNSでクラスタ内の名前解決を行います。そのため、既存クラスタをAuto Modeへ移した際に「CoreDNSのPodが不要になった」と判断して削除したくなります。

公式ドキュメントはここに重要事項として「If you plan to maintain a cluster with both Auto Mode and non-Auto Mode nodes, you must retain the CoreDNS deployment」と警告を置いています。非Auto Modeのノードはノードレベルのサービスへアクセスできず、従来のCoreDNS Podに依存するためです。FargateのPodはAuto Modeが管理するノードの上では動かないので、この「非Auto Modeノード」の条件に当てはまります。したがって、Auto ModeとFargateを併用する構成ではCoreDNSのDeploymentを残すべきで、削除すればFargate側のPodが名前解決に失敗すると考えられます。安全に削除できるのは、Auto Mode単独へ完全移行したときだけです。

ロードバランサ周りにも併用時の制約があります。Auto Modeのターゲティングは既定でIPモード（インスタンスモードではない）で、NLBはセキュリティグループモードのみサポートされます。加えて、セルフマネージドのAWS Load Balancer ControllerからAuto Modeの管理へロードバランサを移行する経路はサポートされていません。既存のコントローラを使い続けるか、新規に作り直すかを移行計画の段階で決めておく必要があります。

Auto ModeとFargate、それぞれを選ぶべきでない場面

EKS on Fargateを選ぶべきでない場面は、DaemonSetで配るエージェントが運用の前提になっているとき、GPUを使うとき、Spot前提でコストを設計しているとき、そしてEBSの永続ボリュームが要るときです。とくに1つ目は要注意で、サイドカー化で形式上は回避できてもPodの数だけエージェントが増えるため、Pod数が多い環境ほど課金と運用の両方で不利になります。

EKS Auto Modeを選ぶべきでない場面で、Fargateとの比較上ほぼ唯一の決定打になるのがPod単位のセキュリティグループです。要件がSGPPで確定していてNodeClass単位の代替へ書き換えられないなら、この一点でAuto Modeが落ちます。AMIやカーネルパラメータを自分で握りたい、Windowsコンテナを動かしたいといった条件もAuto Modeでは満たせませんが、それらはFargateでも同じく満たせないため、比較相手はマネージドノードグループやセルフマネージドノードになります。

よくある質問

EKS Auto ModeとEKS on Fargateは同じクラスタで併用できますか？

できます。Auto ModeのNodePoolとFargateプロファイルを同じクラスタに共存させ、eks.amazonaws.com/compute-type: autoラベルへのnodeSelectorやnodeAffinityでワークロードを振り分けます。ただし併用時はCoreDNSのDeploymentを削除してはいけません。Auto Modeはノード常駐のCoreDNSを使いますが、Fargate側のPodはそれを利用できず、Deploymentを消すとFargateのPodだけ名前解決に失敗します。

EKS on FargateでDaemonSetは使えますか？

使えません。公式ドキュメントは「Daemonsets aren’t supported on Fargate」と明記し、デーモンが必要な場合はPod内のサイドカーコンテナとして構成し直すよう案内しています。ログ収集や監視のエージェントをDaemonSetで配っている環境では、Pod単位にサイドカーを持たせる設計変更が必要になります。

EKS on FargateでSpotを使ってコストを下げられますか？

できません。公式ドキュメントに「Amazon EKS doesn’t support Fargate Spot」とあり、EKSのFargateではFargate Spotが利用できません（ECSのFargateとは扱いが異なります）。中断を許容できるワークロードでコストを下げたい場合は、EKS Auto ModeのカスタムNodePoolでSpotのキャパシティタイプを指定する方法を取ります。Auto ModeはEC2のSpot中断通知を自動で処理します。

GPUを使うPodはどちらで動かせますか？

EKS Auto Modeです。Auto ModeはNVIDIAとNeuron向けのカーネルドライバとプラグインを標準で内蔵しており、Neuron Device Pluginを別途インストールする必要もありません。対応インスタンスタイプにはp6-b200、p5、g6e、inf2、trn2などが含まれます。EKS on Fargateは「GPUs aren’t currently available on Fargate」と記述されており、現時点ではGPUワークロードを動かせません。

Pod単位でセキュリティグループを割り当てられるのはどちらですか？

EKS on Fargateだけです。security groups for Podsの公式ドキュメントは「Security groups for Pods can’t be used with Windows nodes or EKS Auto Mode」としてAuto Modeを名指しで除外しています。Auto Modeでは代わりにNodeClassのpodSecurityGroupSelectorTermsが案内されていますが、粒度はPodごとではなくNodeClass単位です。

関連記事

• EKS Auto Modeとは？自動化される範囲・料金・NodePoolの制約【2026年版】
• AWS Fargateとは？EC2との違い・料金をわかりやすく解説【2026年版】
• Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説
• AWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い【2026年版】
• Kubernetes 1.34の新機能・変更点とEOL｜DRA GA・再起動ルール・EKS対応を解説