Amazon EKSの料金とは?
Amazon EKSでは、各クラスターのコントロールプレーンに対して1時間あたり0.10ドル(月額約72ドル)の固定料金が課金されます。これに加えて、ワーカーノードやアプリケーションの実行に使用する基盤のAWSリソース(EC2インスタンス、Fargate、EBSボリューム、ロードバランサー)の料金が発生します。古いKubernetesバージョンの延長サポートは1時間あたり0.60ドルです。
EKSの料金体系を理解することは、クラウド費用を正確に見積もり、想定外のコストを回避するうえで極めて重要です。AWSはEKSに複数の運用モードを提供しており、それぞれに独自のコスト構造があります。標準クラスター、マネージドノードグループ、オートスケーリングオプション、オプションのアドオンを使用する際の料金への影響を評価する必要があります。これらの構成要素を事前に分析することで、効果的な予算計画とコスト最適化が可能になります。
本記事は、Kubernetesの料金に関する連載記事の一部です。
本記事の内容:
AWS EKSの料金構成要素を理解する
Amazon EKSクラスターの主なコスト構成要素を見ていきましょう。
Amazon EKSクラスターの料金
Amazon EKSでは、EKSクラスターごとに時間単位の料金が課金されます。料金は、クラスターが使用するKubernetesバージョンのサポート区分によって異なります。
- 標準サポート対象のKubernetesバージョンを実行するクラスターは、クラスターあたり1時間0.10ドルです。
- Kubernetesバージョンは、Amazon EKSでリリースされてから最初の14か月間、標準サポートの対象となります。
- 標準サポート終了後は、続く12か月間、延長サポートに移行します。
- 延長サポートはクラスターあたり1時間0.60ドルです。これは標準の時間料金0.10ドルに、クラスターあたり1時間0.50ドルが追加されたものです。
この料金はEKSクラスター自体に適用されるものです。EC2インスタンス、EBSボリューム、パブリックIPv4アドレス、Fargateコンピューティングなど、ワークロードが使用するAWSリソースの料金は別途発生します。
Amazon EKS Provisioned Control Planeの料金
Amazon EKS Provisioned Control Planeでは、クラスターのコントロールプレーン容量を一定量確保できます。このオプションは、安定したコントロールプレーン性能、トラフィック急増への迅速な対応、より大規模なKubernetes運用への対応が必要なワークロードを対象としています。
料金は、選択したコントロールプレーンのスケーリングティアに基づきます。時間単位で課金され、標準のEKSクラスター料金に加算されます。前払い金や長期契約は不要です。
- XLティアはクラスターあたり1時間1.65ドルです。
- 2XLティアはクラスターあたり1時間3.40ドルです。
- 4XLティアはクラスターあたり1時間6.90ドルです。
- 8XLティアはクラスターあたり1時間13.90ドルです。
スケーリングティア間の変更や、標準のコントロールプレーンへの復帰も可能です。8XLを超えるティアについては、料金をAWSアカウントチームに問い合わせる必要があります。
Amazon EKS Auto Mode
Amazon EKS Auto Modeの料金は、EKS Auto Modeが有効化されたクラスターに適用されます。課金は、EKS Auto Modeが起動・管理するAmazon EC2インスタンスのタイプと稼働時間に基づきます。この料金はEC2インスタンスの料金とは別に発生します。基盤となるインスタンスには通常のEC2料金がかかり、EKS Auto Modeはそれに独自の管理料金を上乗せする形です。
EKS Auto Modeは秒単位で課金され、最低課金時間は1分です。課金はEC2の購入オプションに関係なく適用されるため、インスタンスがオンデマンド、リザーブドインスタンス、Compute Savings Plans、Spotインスタンスのいずれを使用していても対象となります。150ノードを超える規模でEKS Auto Modeを利用する予定の組織は、料金についてAWSアカウントチームに問い合わせる必要があります。
Amazon EKS Capabilitiesの料金
Amazon EKS Capabilitiesの料金は、EKSクラスターで特定のCapabilityを有効にした場合に適用されます。料金は時間単位の2つの要素で構成されます。有効化した各Capabilityの基本料金と、そのCapabilityが管理するリソース数に基づく使用料金です。
- Argo CDの場合、米国東部(オハイオ)では基本料金がArgo CD Capability 1時間あたり0.02771ドルです。使用料金はArgo CDアプリケーション1時間あたり0.00136ドルです。各アプリケーションはデプロイ先クラスターごとにカウントされるため、1つのアプリケーションを5つのクラスターにデプロイすると5アプリケーションとしてカウントされます。
- **AWS Controllers for Kubernetes(ACK)**の場合、基本料金はACK Capability 1時間あたり0.004482ドル、使用料金はACKリソース1時間あたり0.000045ドルです。
- **Kubernetes Resource Orchestrator(KRO)**の場合、基本料金はKRO Capability 1時間あたり0.004482ドル、使用料金はKRO RGDインスタンス1時間あたり0.000045ドルです。
- EKS Capabilitiesのすべての料金は時間単位で請求されます。前払い金や最低利用のコミットメントはありません。
Amazon EKS Hybrid Nodesの料金
Amazon EKS Hybrid Nodesを使用すると、オンプレミスやエッジのインフラをAmazon EKSクラスターに接続できます。これにより、クラスター管理はAmazon EKSに残したまま、KubernetesワークロードでAWS以外のインフラを利用できます。
料金は、Kubernetesに報告されるvCPU時間に基づきます。
- 課金は、ハイブリッドノードがクラスターに参加した時点で開始され、ノードが削除された時点で終了します。
- ハイパースレッディングが有効なベアメタル環境では、物理CPUコア1つにつき2 vCPUがKubernetesに報告され、課金は報告されたvCPU数に基づいて行われます。
Hybrid Nodesの料金は、同一AWSリージョン内の月間合計vCPU時間の使用量に応じた段階制です。
- 最初の月間576,000 vCPU時間は、1 vCPU時間あたり0.020ドルです。
- 次の576,000 vCPU時間は、1 vCPU時間あたり0.014ドルです。
- 次の月間4,608,000 vCPU時間は、1 vCPU時間あたり0.010ドルです。
- 次の5,760,000 vCPU時間は、1 vCPU時間あたり0.008ドルです。
- 月間11,520,000 vCPU時間を超える使用分は、1 vCPU時間あたり0.006ドルです。
AWS Organizationsで一括請求を利用している場合、これらの段階は同一リージョン内で組織のアカウント全体に適用されます。1台あたり32 vCPUを超えるマシンでハイブリッドノードを実行する予定の場合は、AWSアカウントチームへの問い合わせが必要です。
EKS Anywhereの料金
Amazon EKS Anywhereは、データセンターやエッジ環境のハードウェア上でKubernetesクラスターを実行するオープンソースソフトウェアです。ソフトウェア自体はオープンソースとして提供されていますが、AWSはサポートと追加機能を提供するEnterprise Subscriptionを販売しています。
- Amazon EKS Anywhere Enterprise Subscriptionは、ライセンスされたEKS Anywhereクラスターに対するサポートを提供します。また、ロードバランシング、可観測性、オートスケーリングなどの機能を追加するEKS Anywhere Curated Packagesへのアクセスも含まれます。
- EKS Anywhere Enterprise Subscriptionを購入するには、事前にAWS Enterprise SupportまたはAWS Enterprise On-Ramp Supportの契約が必要です。
- サブスクリプションは、Amazon EKSコンソール、API、またはAWS CLIから購入できます。
- 料金はクラスター単位の定額制で、クラスターの規模には依存しません。1年契約はクラスターあたり24,000ドルで、月額2,000ドルで請求されます。3年契約はクラスターあたり年間18,000ドルで、月額1,500ドルで請求されます。
- 1回のサブスクリプション購入に、複数のEKS Anywhereクラスターライセンスを含めることができます。
- サブスクリプションは自動更新の設定が可能で、購入後7日以内であれば無料でキャンセルできます。
Amazon EKSの隠れたコストとアドオンコスト
基本的な構成要素以外にも、EKSクラスターに関連して見落としがちな追加コストがあります。
ストレージコスト
Amazon EKS上でワークロードを実行する場合、多くは永続ストレージが必要となり、追加コストが発生します。これらのコストは通常、Amazon EBSボリューム、Amazon EFS(Elastic File System)、またはオブジェクトストレージ用のS3バケットの利用から生じます。これらのストレージサービスの料金は、プロビジョニングしたストレージ容量、ストレージの種類(SSDかHDDかなど)、IOPS要件に基づきます。高性能ストレージや大容量が必要なワークロードでは、ストレージコストがEKSクラスターの基本料金を上回ることもあります。
ストレージコストには、バックアップ、スナップショット、データ転送の料金も含まれます。たとえば、災害復旧やコンプライアンス目的で定期的なEBSスナップショットを作成すると、毎月の追加料金につながります。ストレージ使用量を監視し、未使用のボリュームを削除し、ストレージクラスを適切なサイズに調整して、不要な支出を回避すべきです。ストレージコストの全体像を把握することが、EKS環境での予算超過の防止に役立ちます。
データ転送コスト
Amazon EKSのデータ転送コストは見落とされがちですが、AWSの請求額全体に影響を及ぼす可能性があります。AWSは、EKSクラスターからインターネットへのデータ転送、アベイラビリティゾーン間の転送、場合によっては異なるリージョンのAWSサービス間の転送に対して課金します。アウトバウンドトラフィックの多いアプリケーションやゾーン間通信が多い環境では、これらの料金が積み重なり、総コストの大きな割合を占めることがあります。
不要なデータ転送を最小限に抑えるようにEKSワークロードを設計しましょう。たとえば、可能な限り同一のアベイラビリティゾーン内でトラフィックを完結させる、サービス間通信にAWS PrivateLinkを使用してコストを削減する、といった方法があります。データ転送のパターンを定期的に確認し、ネットワークトポロジーを調整することで、EKSデプロイメントにおけるこれらの費用を抑制できます。
NATゲートウェイのコスト
プライベートサブネットからインターネットへのアクセスが必要なAmazon EKSクラスターでは、通常NATゲートウェイを使用します。AWSは、各NATゲートウェイの時間単位の利用料金と、ゲートウェイを通過したデータ処理量の両方に課金します。トラフィックの多い環境や複数のプライベートサブネットを持つクラスターでは、NATゲートウェイの料金が急速に膨らむことがあります。
NATゲートウェイのコストを削減するには、より少ないゲートウェイにトラフィックを集約する、スループット要件が低い場合はNATインスタンスを使用するといった方法を検討しましょう。NATゲートウェイの利用状況を監視し、ネットワークアーキテクチャを見直して、コスト削減の機会を特定してください。NATゲートウェイの料金はEKSのコントロールプレーンやノードの料金には含まれていないため、EKSの総保有コストの計算に組み込む必要があります。
CloudWatchのロギングとモニタリング
Amazon CloudWatchはEKSクラスターのロギングとモニタリングに広く使われていますが、そのコストはEKSの料金とは別に発生します。CloudWatchの料金は、取り込まれたログの量、保存されるメトリクス、作成されたダッシュボードの数に基づきます。高頻度のロギング、冗長なアプリケーションログ、大量のカスタムメトリクスは、特に大規模または変化の激しいEKS環境でコストを押し上げる要因になります。
CloudWatchの費用を抑えるには、ログの保持ポリシーを実装し、不要なログをフィルタリングし、メトリクスを集約すべきです。ログのサンプリングやサードパーティ製のロギングソリューションの利用もコスト削減につながります。CloudWatchの利用状況を定期的に確認し、EKSワークロードに十分な可観測性を維持しながらログとメトリクスの収集を最適化して、想定外の請求を回避しましょう。
Amazon EKSの料金例
例1:標準サポートと延長サポートにおけるEKSクラスターの料金
あるEKSクラスターが、コントロールプレーンをアップグレードせずに同じKubernetesバージョンを26か月間実行するとします。最初の14か月間は標準サポート対象で、クラスターあたり1時間0.10ドルです。その後、12か月間の延長サポートに移行し、クラスターあたり1時間0.60ドルになります。
コストの差を具体的に見てみましょう。標準サポートの14か月間のクラスター料金は合計約1,022ドル(14 × 730時間 × 0.10ドル)です。延長サポートの12か月間では5,256ドル(12 × 730時間 × 0.60ドル)に跳ね上がり、期間が2か月短いにもかかわらず5倍以上のコストになります。26か月間全体で平均すると、実効レートはクラスターあたり1時間0.33ドルです。
例2:複数の事業部門におけるEKS Hybrid Nodesの料金
3つの事業部門がEKS Hybrid Nodesを利用しており、それぞれが標準サポート対象のKubernetesバージョンで専用のEKSクラスターを運用しているため、各部門のクラスター料金は月額73ドル(730時間 × 0.10ドル)です。
事業部門1は8 vCPUのノードを8台実行しており、46,720 vCPU時間でノード料金は934.40ドルです。事業部門2は16 vCPUのノードを4台実行しており、46,720 vCPU時間でノード料金は934.40ドルです。事業部門3は4 vCPUのノードを6台実行しており、17,520 vCPU時間でノード料金は350.40ドルです。
3部門合計の月間使用量は110,960 vCPU時間です。これは第1段階の上限である月間576,000 vCPU時間を大きく下回るため、すべての使用量が1 vCPU時間あたり0.02ドルで課金されます。月間のEKS請求額は合計2,438.20ドルで、内訳はクラスター料金219ドルとノード料金2,219.20ドルです。
例3:Amazon EKS Auto Modeの料金例
コンテナ化されたアプリケーションが、米国西部(オレゴン)リージョンのAmazon EKS Auto Mode上で稼働しているとします。このアプリケーションは、フロントエンドポッド、バックエンドポッド、バッチ処理ポッドで構成されています。EKS Auto Modeは、これらのワークロード要件を満たすEC2インスタンスの組み合わせを選択します。
選択されたインスタンスはc6a.2xlarge、c6a.4xlarge、m5a.2xlarge、m5a.xlargeで、EC2の合計コストは1時間あたり1.434ドルです。EKS Auto Modeは、これらのインスタンスに対して1時間あたり0.17208ドルの管理料金を別途加算します。
1か月では、EC2インスタンスコストが1,046.82ドル、EKS Auto Mode料金が125.62ドルになります。この例から、EKS Auto Modeの料金は基盤のEC2コストを置き換えるのではなく、その上に加算されることがわかります。
Amazon EKSのコストを削減・最適化する6つの方法
1. ワーカーノードとポッドのリクエストをライトサイジングする
過剰にプロビジョニングされたワーカーノードと過大なポッドのリソースリクエストは、EKSにおける無駄な支出の代表的な原因です。Kubernetesは実際の使用量ではなく、リクエストされたCPUとメモリに基づいてポッドをスケジュールします。リクエストが高すぎると、クラスターが不必要にスケールアウトし、ノード容量の大部分が未使用のままEC2コストだけが発生し続けることになります。
チームは実際のリソース消費量を定期的に分析し、リクエストとリミットを適宜調整すべきです。Kubernetesメトリクスサーバー、Prometheus、Vertical Pod Autoscaler(VPA)、KEDA、Goldilocksなどのツールは、非効率な割り当ての特定に役立ちます。より小さなインスタンスタイプ、混在インスタンスグループ、Gravitonベースのインスタンスの利用も、コスト効率の向上につながります。
クラスターオートスケーリングは、未使用ノードを自動的に削除するように設定すべきです。正確なポッドサイジングとオートスケーリングを組み合わせることで、遊休インフラを減らし、クラスター全体のワークロード密度を高めることができます。
2. 耐障害性のあるワークロードにSpotインスタンスを使用する
Amazon EC2 Spotインスタンスは、AWSの余剰キャパシティを割引価格で利用するため、EKSのコンピューティングコストを削減できます。Spotの価格は標準のオンデマンド価格より70〜90%低いことが多く、中断を許容できるワークロードに適しています。
ステートレスなアプリケーション、バッチジョブ、CI/CDパイプライン、バックグラウンドワーカー、データ処理タスクは、Spot利用の有力な候補です。Kubernetesのノードグループでは、Spotとオンデマンドインスタンスを混在させることができるため、重要なワークロードの安定性を維持しながら、耐障害性のあるワークロードには低コストのキャパシティを利用できます。
信頼性を高めるには、Spotノードグループで複数のインスタンスタイプとアベイラビリティゾーンを使用しましょう。Pod Disruption BudgetsやCluster AutoscalerといったKubernetesの機能により、Spotの中断が発生してもワークロードは自動的に復旧できます。
3. ロードバランサーとIngressを最適化する
EKSでは、LoadBalancerタイプのKubernetesサービスごとに、通常は専用のAWSロードバランサーがプロビジョニングされます。大規模な環境では、不要または重複したロードバランサーが、特にApplication Load BalancerやNetwork Load Balancerを使用している場合、毎月の大きなコストにつながる可能性があります。
集中型のIngressコントローラーを使用すると、サービスごとにロードバランサーをプロビジョニングする代わりに、複数のアプリケーションで1つのロードバランサーを共有できます。AWS Load Balancer Controllerは、ホストベースまたはパスベースのルーティングルールを使用して、共有ロードバランサー経由で複数のアプリケーションをルーティングできます。
未使用のロードバランサーを削除し、遊休状態のIngressリソースを定期的に確認しましょう。内部専用のサービスは、外部アクセスが必要な場合を除き、インターネット向けロードバランサーの利用を避けるべきです。Ingressアーキテクチャの最適化により、ロードバランサーの料金と関連するデータ転送コストの両方を削減できます。
4. 遊休リソースと使用率の低いリソースを特定する
未使用のKubernetesリソースは、アプリケーションが稼働していなくてもAWSの課金が発生し続けることがよくあります。遊休状態のEC2ノード、アタッチされていないEBSボリューム、使われないまま残ったロードバランサー、未使用のElastic IP、非アクティブなネームスペースは、EKS環境における典型的な無駄の例です。
コストと使用率の定期的なレビューにより、削除または統合できるリソースを特定できます。AWS Cost Explorer、AWS Compute Optimizer、Kubecost、Kubernetesモニタリングツールを使えば、クラスター全体で非効率なリソース使用を追跡できます。
クリーンアップ処理の自動化はコスト管理の向上につながります。ライフサイクルポリシー、非本番環境のスケジュール停止、ネームスペースの有効期限ルールを活用して、不要な支出を削減できます。ワークロードのスケールや新しいサービスのデプロイに伴ってKubernetes環境は頻繁に変化するため、継続的な監視が重要です。
5. 延長サポートに入る前にKubernetesバージョンをアップグレードする
Amazon EKSでは、Kubernetesバージョンが標準サポートから延長サポートに移行すると、クラスターの料金が上がります。時間あたりのクラスター料金が0.10ドルから0.60ドルに上昇するため、複数のクラスターでコストが増加する可能性があります。
定期的なKubernetesのアップグレードにより、こうした追加料金を回避できるだけでなく、セキュリティ、安定性、利用できる機能も向上します。予測可能なアップグレードスケジュールを確立することで、クラスターがサポート対象外のバージョンに長期間とどまるリスクを減らせます。
運用リスクを軽減するため、本番環境への展開前にステージング環境でアップグレードをテストしましょう。また、Amazon EKSのリリースカレンダーを確認し、サポート期限直前の慌ただしい移行を避けられるよう、十分に余裕を持ってアップグレードを計画すべきです。
6. Karpenterでよりスマートなノードプロビジョニングを実現する
Karpenterは、事前定義されたノードグループだけに依存するのではなく、実際のポッド要件に基づいてコンピューティングキャパシティをプロビジョニングすることで、Amazon EKSのコスト削減に役立ちます。保留中のポッドを評価し、ワークロードのニーズに合った適切なサイズのEC2インスタンスを起動するため、ビンパッキングの改善、遊休キャパシティの削減、スケーリングの高速化が期待できます。
Auto Scaling Groupsに大きく依存する従来のCluster Autoscaler構成とは異なり、Karpenterはより幅広いインスタンスタイプ、サイズ、アベイラビリティゾーン、アーキテクチャ、キャパシティタイプから選択できます。この柔軟性により、アプリケーションの可用性を維持しながら、オンデマンド、Spot、Gravitonベースのインスタンスをより多様に組み合わせて利用できます。
Karpenterは、ポッドがスケジュールできない場合には素早くキャパシティを追加し、需要が減少した際には使用率の低いノードを統合できるため、動的または変動の大きいワークロードに特に有効です。コスト削減と信頼性のバランスを取るために、適切なインスタンス要件、中断制御、統合ポリシー、ワークロード制約を備えたNodePoolを設定すべきです。
PerfectScaleでEKSコストを最適化する
EKSはコンテナ化されたワークロードを実行する強力なプラットフォームですが、その料金モデルでは、非効率なリソース構成がそのまま請求額の増加に直結します。CPUとメモリのリクエストが過剰にプロビジョニングされていると、クラスターが必要以上にスケールアウトし、EC2ノードが低い使用率のまま稼働し続けてコストが積み上がります。PerfectScale by DoiTは、EKSクラスター全体の実際のワークロード消費を継続的に分析し、CPUとメモリのリクエストとリミットを自律的にライトサイジングすることで、この無駄を排除します。手動でのチューニングやエンジニアリングの工数は不要です。
チームが対応しきれない提案を生成するだけの推奨型ツールとは異なり、PerfectScaleは、パフォーマンスと可用性を守るガードレールを維持しながら、最適化を自動的に適用します。OOM Kill、CPUスロットリング、ポッドの退避といったレジリエンシーに関わるリスクをリアルタイムで検知・修復するため、コスト削減が安定性の犠牲になることはありません。その結果、不要なEC2キャパシティへの支出を抑えながら、ワークロードに必要な信頼性を維持する、無駄のない高使用率のクラスターが実現します。