LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Amazon EKSのコスト構造：コントロールプレーンとデータプレーン

Amazon EKS（Amazon Elastic Kubernetes Service）のコスト最適化とは、Kubernetesクラスターの運用費用を、ワークロードの可用性と性能を維持しながら計画的に削減する取り組みです。AWS公式のコスト最適化ベストプラクティスでは「ワークロードの適切なサイズ設定」「未使用容量の削減」「コンピューティングキャパシティタイプの最適化」の3段階が推奨されています^*1。

EKSの料金体系は「コントロールプレーン」と「データプレーン」の2層で構成されています。それぞれの特性を正確に把握することが、無駄のない設計の出発点です。

コントロールプレーン料金の仕組み

コントロールプレーンはKubernetesクラスター自体の管理基盤です。AWSが可用性・スケーラビリティを管理し、利用者はAPIサーバーやetcdの運用を意識せずに済みます。

料金はクラスター単位の時間課金で、Kubernetesバージョンリリース後14ヶ月間の「標準サポート期間」は1クラスターあたり0.10USD/時間です^*2。その後の12ヶ月間は「拡張サポート期間」となり、0.60USD/時間まで上がります^*2。複数クラスターを稼働させる場合、この課金が積み重なるため、不要なクラスターを整理するだけでもコスト削減につながります。

データプレーン料金の選択肢

データプレーンはPodが実際に動作するコンピューティングリソースです。EC2ノードとFargateの2つを使い分けられます。

EC2ノードは利用者がインスタンスを管理する代わりに、購入オプション（オンデマンド・スポット・リザーブド・Savings Plans）を選べます。柔軟性が高く、複数Podをまとめて1台に配置できるため、コスト効率を追求しやすい選択肢です。

Fargateはノード管理が不要なサーバーレス型で、vCPUとメモリの使用時間に応じた従量課金です^*3。管理の手間は減りますが、1Podごとの占有配置となるためEC2と比べてリソース効率が下がる点に注意が必要です。なお、Fargateを主軸とするECSのコスト最適化はECS/Fargateのコストを最適化する外注の進め方、コンテナ全般の最適化はKubernetes/コンテナのコスト最適化を外注する進め方で解説している。

Karpenterで実現するノード効率化

Karpenter（カーペンター）はKubernetes向けのオープンソースのノードライフサイクル管理ツールで、スケジューラーが「配置不可」とマークしたPodを検出し、その要件に合ったノードを自動でプロビジョニングします^*4。

従来のCluster Autoscalerがノードグループ単位で増減するのに対し、Karpenterはグループレスアプローチでより細かい粒度でノードを選択できます。AWS公式のベストプラクティスでは「ビンパッキングにより、より少ないインスタンスでより多くのワークロードを配置できる」と説明されており、ワークロード実行のコスト効率が大幅に向上します^*1。

Karpenterのビンパッキング効果

ビンパッキング（bin packing）とは、複数のPodを既存のノードに詰め込んで無駄なスペースを最小化する最適化手法です。Karpenterは各Podのリソース要求（CPU・メモリ）を分析し、利用率の低いノードにPodを再配置した上で空きノードを削除します。

この統合機能（consolidation）はKarpenterのNodePoolで有効化できます。中断を許容できないワークロードは個別に保護設定を行い、安定性を担保しながら効率化を進めることが可能です。

Cluster Autoscalerとの使い分け

Karpenterは比較的新しいツールで、導入には設定ファイルへの習熟が必要です。既存クラスターがCluster Autoscalerで安定稼働している場合、移行コストと効果を試算した上で判断することが大切です。開発環境や新規クラスターはKarpenter、既存の本番環境はCluster Autoscalerを維持しながら段階的に移行するケースが見られます。

スポットインスタンスとSavings Plansの組み合わせ戦略

データプレーンのコストは購入オプションの選択で大きく変わります。AWS公式の情報では、スポットインスタンスはオンデマンド価格と比べて90%まで割引で利用できます^*5。Compute Savings Plansは66%まで割引、EC2 Instance Savings Plansは72%まで割引になります^*1。

スポットインスタンス活用の注意点

スポットインスタンスはAWSの余剰EC2キャパシティを活用するため、需要が高まると2分前の通知で中断されます。このリスクを低減するには、複数のインスタンスタイプと複数のアベイラビリティゾーンを組み合わせることが推奨されています^*1。

ステートレスで再起動に耐えるバッチ処理やCI/CDワークロードはスポットに向いています。一方、データベース層やセッション情報を保持する常時稼働型のPodはオンデマンドまたはリザーブドインスタンスで稼働させるのが基本です。

Savings Plansの種類と選び方

Savings Plansは1年または3年のコミットメントで割引を受ける仕組みです。Compute Savings Plansはインスタンスタイプ・リージョン・OS・テナンシーを問わず適用できる柔軟な方式で、EKS上のEC2ノードにも適用可能です。EC2 Instance Savings Plansはリージョンとインスタンスファミリーを指定する代わりに割引率が高くなります。

Karpenterによるノード変動が大きいクラスターではCompute Savings Plansの方が適用しやすく、安定した同一インスタンスファミリーを継続利用するケースではEC2 Instance Savings Plansが有効です。

インスタンスタイプ選定とクラスタ統合によるコスト削減

適切なインスタンスタイプの選定は、リソース無駄のないノード配置を実現するための基本です。Podのリソース要求（requests）と制限（limits）を実際の使用率に合わせずに設定すると、表面上は空きがあるように見えてノードが増え続ける原因になります。

Gravitonインスタンスによる価格性能比の向上

AWS Gravitonプロセッサ搭載インスタンス（arm64アーキテクチャ）は、x86ベースと比べて価格性能比が40%まで優れる場合があると公表されています^*5。コンテナ化されたワークロードはarm64への対応が比較的容易なため、EKSとの親和性が高い選択肢です。Karpenterのプロビジョナーにarm64とamd64の両方を指定し、コスト効率の高いノードを自動選択させる構成が推奨されています^*1。

Pod・ノードのサイズ最適化ツール

AWS公式のベストプラクティスではGoldilocks、KRR（Kubernetes Resource Recommender）、Kubecostの3ツールがリソース推奨ツールとして挙げられています^*1。Kubecostはポッド・ノード・ネームスペース単位のコスト追跡も可能で、EKSクラスター内のどのワークロードがコストを多く消費しているかを可視化できます。

クラスタ統合の効果

開発・テスト・ステージング用に複数の小規模クラスターが乱立している場合、クラスタを統合して名前空間（Namespace）とResource Quotaで分離する方式に移行するとコントロールプレーン料金を削減できます。コントロールプレーンは0.10USD/時間の定額課金のため、クラスター数が減るほど直接費用が下がります。

ただし、セキュリティ要件が異なるワークロード（本番と開発）を同一クラスターに混在させることには別途リスク評価が必要です。統合前に権限分離・ネットワークポリシーの設計を行うことが大切です。

EKSコスト最適化を外注する際の選定ポイント

EKSのコスト最適化は、Kubernetesの運用知識・AWSサービスの理解・コスト分析スキルが組み合わさった複合領域です。内製で取り組む場合、Kubernetes認定エンジニア（CKA/CKAD）レベルの知識に加え、AWS Well-Architectedフレームワークのコスト最適化の柱の理解と、Karpenter・Kubecostなどのツール経験が必要です。

内製対応のリスク

設定ミスが発生した場合のコストは無視できません。例えばPodのリソース制限を過剰に設定したまま放置すると、ノードが常にオーバープロビジョンされ月次で数十万円単位の無駄が積み重なります。Karpenterの統合設定を誤ると意図しないノードの強制削除が発生し、本番サービスの中断につながるリスクもあります。

逆にスポットインスタンスの設定を誤れば、中断に対応できないワークロードが予期せず停止します。これらのリスクを管理しながら継続的にコストを監視する体制を社内で構築するには、専任エンジニアの工数が継続的に必要です。

外注先に確認すべき技術要件

外注で進めるEKSコスト最適化：5つのステップ

外注パートナーと進める場合の標準的な流れを整理します。フェーズを明確にすることで、受け渡しのポイントと期待成果を双方で共有しやすくなります。

ステップ1：現状のコスト可視化と診断

最初にAWSコストエクスプローラーとKubecostを組み合わせて現状のコスト配分を可視化します。コントロールプレーン・EC2ノード・Fargate・データ転送の各項目を分解し、コストの集中箇所を特定します。この診断がなければ、その後の施策の優先順位が立てられません。

ステップ2：PodとNodeのリソース設定見直し

KubecostやGoldilocksのような推奨ツールで、実際の使用率と設定値の乖離を確認します。requests（要求）を実使用率に近づけることで、ノード1台あたりの配置可能Pod数が増え、ノード数の削減につながります。

ステップ3：Karpenterの設計・導入

新規クラスターまたは段階的移行でKarpenterを導入します。NodePoolの設定でインスタンスタイプの優先度・スポットとオンデマンドの混合比率・統合（consolidation）の有効化を設計します。中断不可ワークロードの保護設定を先に確定してから本番適用に進む順序が一般的です。

ステップ4：購入オプションの最適化

3〜6ヶ月の使用実績データをもとにSavings Plansの適切なコミットメント量を算出します。スポットインスタンスを適用できるワークロードを識別し、中断時の適切な切り離しを担保します。Karpenterやマネージドノードグループは中断通知を自動的に処理しますが、自己管理ノードを使う場合はNode Termination Handlerを別途設定します。

ステップ5：継続監視とクラスタ統合

月次のコストレビューと定期的なリソース推奨の適用を仕組みとして確立します。不要なクラスターの整理やNamespaceによる論理分離への移行を検討し、コントロールプレーン料金の最適化も進めます。

内製と外注の比較：必要スキルと工数の実態

EKSコスト最適化を内製で一通り実施するには、Kubernetes管理・AWSコスト設計・監視ツール運用の3領域の知識が必要です。初期設計と実装だけでなく、月次の監視・レポート・設定調整を継続する体制も求められます。

CKA（Certified Kubernetes Administrator）を保有するエンジニアを1名配置したとしても、Karpenter設計・Savings Plans試算・継続監視まで兼務させると、本来のアプリケーション開発の工数を圧迫します。専任でアサインするのが難しい組織では、外注でこれらを担わせることでエンジニアリソースを製品開発に集中できます。

外注先に任せられる範囲は、現状診断から設計・実装・継続監視まで一貫して委託するフルマネージド型と、設計だけ委託して実装は内製するコンサルティング型に分かれます。予算と社内の実装能力に応じて組み合わせを検討することが大切です。

まとめ：Amazon EKSコスト最適化の3つの判断軸

本稿ではAmazon EKSのコスト最適化を外注で進める手順を整理しました。要点を3つに集約します。

第一に、EKSの料金はコントロールプレーン（0.10USD/時間）とデータプレーン（EC2・Fargate）の2層で構成され、クラスター数の整理とノード配置の効率化が基本的な削減レバーです。第二に、KarpenterによるPodベースの自動プロビジョニングとビンパッキング、スポットインスタンス（90%まで割引）とSavings Plans（66%まで割引）の組み合わせがデータプレーンコスト削減の中心施策です。第三に、これらを適切に設計・実装・継続監視するにはKubernetes・AWS双方の専門知識が必要で、設定ミスは本番停止やコスト増というリスクを伴います。外注先には現状診断から継続監視まで一貫した体制があるかを確認することが成果を左右します。

よくある質問

Amazon EKSのコントロールプレーン料金はいくらですか？

AWSの料金ページによると、Kubernetesバージョンリリース後14ヶ月間の標準サポート期間は1クラスターあたり0.10USD/時間（月換算で約73USD）です^*2。その後の12ヶ月間は拡張サポート期間となり0.60USD/時間に上がります。複数クラスターを稼働させている場合は、不要なクラスターを整理するだけでもコスト削減につながります。

KarpenterとCluster Autoscalerはどちらを使うべきですか？

AWS公式のベストプラクティスではKarpenterが推奨されています^*1。KarpenterはノードグループなしでPodの要件に合ったインスタンスを直接選択し、ビンパッキングにより未使用ノードを削除する統合機能が優れています。ただし既存クラスターへの移行コストがあるため、新規クラスターはKarpenter、既存の安定稼働中クラスターは段階的移行を検討するのが現実的です。

スポットインスタンスを本番環境で使っても問題ありませんか？

スポットインスタンスには2分前通知での中断リスクがあります。AWS公式では複数のインスタンスタイプと複数のアベイラビリティゾーンを組み合わせることでリスク低減が推奨されています^*1。ステートレスなバッチ処理やCI/CDワークロードはスポットに向いていますが、データベースやセッション保持が必要なアプリはオンデマンドまたはリザーブドインスタンスを使うことが基本です。本番での利用はワークロードの性質を慎重に見極める必要があります。

Compute Savings PlansはEKSのEC2ノードに適用されますか？

はい、Compute Savings PlansはEC2インスタンス料金に適用されます。EKSのデータプレーンとしてEC2ノードを使用している場合、そのEC2インスタンス料金にCompute Savings Plansが適用され、66%まで割引になります^*1。Karpenterで複数のインスタンスタイプを動的に使い分ける構成でもインスタンスタイプを問わず適用できるCompute Savings Plansが有効です。

EKSコスト最適化の外注費用の目安はどのくらいですか？

外注費用は、対象クラスター数・ワークロードの複雑さ・監視継続の有無によって異なります。公式に公表されている標準単価がないため、本稿では具体的な数値を提示しません。複数のパートナーにRFP（提案依頼書）を出して見積もりを比較することをお勧めします。費用の妥当性を判断する際は、初期診断・設計・実装・継続監視の各フェーズが含まれているかを確認してください。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

※本稿で示すAWSの料金・割引率は2026年6月時点の公表値に基づく。料金体系は改定される場合があるため、最新の数値は各出典の公式ページで確認されたい。

1. *1　出典：Amazon Web Services「Amazon EKS Best Practices Guide – Cost Optimization for Compute」
2. *2　出典：Amazon Web Services「Amazon EKS の料金」
3. *3　出典：Amazon Web Services「AWS Fargate の料金」
4. *4　出典：Karpenter「Karpenter Documentation」
5. *5　出典：Amazon Web Services「AWS コスト最適化」