EKS

EKS とは

Amazon EKS (Elastic Kubernetes Service) は、AWS が提供するマネージド Kubernetes サービスである。コントロールプレーン (API サーバー、etcd) の運用を AWS が担い、ユーザーはワーカーノードとワークロードの管理に集中できる。

ECS vs EKS

選定の分かれ目は「Kubernetes の資産とエコシステムを使うか」の一点にほぼ集約される。運用チームの習熟度と、クラスター単位で発生する固定費を天秤にかける。

観点	ECS	EKS
オーケストレーター	AWS 独自	Kubernetes (OSS)
学習コスト	低い	高い
エコシステム	AWS に閉じる	Kubernetes エコシステム全体
ポータビリティ	AWS のみ	マルチクラウド、オンプレミス
運用コスト	コントロールプレーン無料	1 クラスター $0.10/時間 (約 $73/月)
適用場面	AWS に特化したシンプルな構成	大規模、マルチクラウド、既存 K8s 資産

AWS だけで完結するなら ECS の方がシンプルで安い。Kubernetes のエコシステム (Helm、Istio、ArgoCD) を活用したい場合や、マルチクラウド戦略がある場合は EKS を選択する。

固定費の話には続きがある。EKS は Kubernetes のマイナーバージョンごとに標準サポート 14 ヶ月、その後の拡張サポート 12 ヶ月の合計 26 ヶ月まで同じバージョンに留まれるが、拡張サポート期間に入るとクラスター料金に 1 クラスターあたり $0.50/時間 が上乗せされ、合計 $0.60/時間 になる (東京・バージニア北部いずれも。2026 年 8 月時点)。標準サポート時の 6 倍である。しかも拡張サポートは既定で有効なので、アップグレードを後回しにしていると気付かないうちに課金が増える。拡張サポートの期限まで放置したクラスターは、サポート中の最も古いバージョンへ自動的にアップグレードされる。バージョン追従を誰の定期作業にするかを決めておかないと、この 2 つのどちらかを踏むことになる。

ワーカーノードの選択肢

選択軸は「ノードの OS 更新・スケーリング・AMI をどこまで自分で握るか」である。握る範囲を狭めるほど運用は軽くなるが、GPU やカスタムカーネルのような特殊要件は通らなくなる。

タイプ	管理負荷	コスト	適用場面
EKS Auto Mode	最小	EC2 料金 + 管理料金	ノード運用そのものを手放したい
Managed Node Groups	中	EC2 料金	汎用ワークロード
Fargate	低	Fargate 料金 (割高)	Pod ごとの分離を優先
Self-managed Nodes	高	EC2 料金	GPU、カスタム AMI
Karpenter (自前運用)	低〜中	EC2 料金 (最適化)	動的スケーリング

EKS Auto Mode は Karpenter と Bottlerocket を AWS 側で組み込んだ形態で、ノードの調達・パッチ適用・Spot 中断の処理まで任せられる。ノードは最長 21 日で入れ替わる前提なので、同じノードに居続けることを仮定した Pod は書けない。EC2 料金にインスタンスタイプ別の管理料金が乗るため、Karpenter を自前で回す (OSS なので EC2 料金だけで済む) 構成との比較になる。

Fargate on EKS は Pod ごとに独立した実行環境が割り当たるので分離は強いが、制約は多い。DaemonSet が使えない (ログ収集はサイドカー方式へ組み替える)、永続ボリュームは EFS のみで EBS はマウントできない、GPU と特権コンテナが使えない、配置先はプライベートサブネットに限られる、インスタンスメタデータサービスが無いので認証情報は IRSA 経由になる。さらに Fargate プロファイルのセレクターに一致しない Pod は起動先が決まらず Pending のまま残る。EC2 ノードからの移行はここで詰まりやすい。

EKS のアーキテクチャ

責任分界点はコントロールプレーンとワーカーノードの境界にある。境界の上は AWS が動かし、ユーザーは直接触れない。

[AWS マネージド]
  コントロールプレーン: API Server, etcd, Scheduler, Controller Manager
       ↓
[ユーザー管理]
  ワーカーノード (EC2 / Fargate)
    ├── Pod A (アプリ)
    ├── Pod B (アプリ)
    └── Pod C (サイドカー: Envoy, Fluent Bit)

コントロールプレーンは 3 つのアベイラビリティーゾーンにまたがって配置される (AWS の公式ドキュメントでは API サーバーを 2 インスタンス以上、etcd を 3 インスタンスとしている)。可用性の約束は SLA として明文化されており、標準コントロールプレーンの Kubernetes API エンドポイントで月間稼働率 99.95 % (2026 年 8 月時点) である。対象は AWS が運用するエンドポイントだけで、ワーカーノードとその上の Pod は含まれない。「マネージドだから落ちない」ではなく「落ちる範囲が AWS 側に限定される」と読むのが正確である。

コスト最適化

• Karpenter: Pod の要求に応じて最適なインスタンスタイプを自動選択し、ビンパッキング効率を最大化
• Spot Instances: 中断耐性のあるワークロードに Spot を使い、最大 90% のコスト削減
• Graviton: AWS は ARM ベースの Graviton インスタンスを同等の x86 ベースインスタンスより最大 20 % 低コストとしている (2026 年 8 月時点の公表値)。コンテナイメージを arm64 向けにビルドし直す手間が前提になるので、マルチアーキテクチャ対応の工数と見合うかで決める
• リクエスト値の適正化: ビンパッキングもオートスケーラーの判断も、実使用量ではなく requests の宣言値で動く。過大な requests はノードの空席を買い続けるのと同じなので、kubectl top pods (metrics-server の導入が前提) の実測と突き合わせて絞る

迷ったときの目安は単純である。AWS だけで完結し Kubernetes の資産も無いなら ECS、クラスターの固定費を払ってもエコシステムとポータビリティが要るなら EKS。EKS を選んだ後は、ノード運用を Auto Mode と Karpenter のどちらへ寄せるか、そして Kubernetes バージョンのアップグレードを誰の定期作業にするかを先に決める。この 2 つを決めないまま走り出したクラスターが、拡張サポート課金と塩漬けバージョンの温床になる。