Google Kubernetes Engine（GKE）とは？Autopilot／Standardの違い・料金モデルとEKSとの使い分けを実装者目線で解説

Google Kubernetes Engine（GKE）は、KubernetesのコントロールプレーンをGoogle Cloudが運用してくれるマネージドサービスです。この記事では、ノード運用をGoogleへ任せるAutopilotと自分で持つStandardという2つの運用モードの違い、リージョン構成で冗長化されるコントロールプレーンの仕組み、1クラスターあたり0.10ドル毎時のクラスター管理費から積み上がる料金構造を一次情報で整理します。AWSのAmazon EKSやサーバーレスのCloud Runとの使い分け、そしてGKEを採用すべき条件と見送るべき場面まで、構成設計で迷う論点を数値で示します。

まとめ：GKEの運用モード・料金と採用判断の要点

GKEは、Kubernetesの頭脳にあたるコントロールプレーン（APIサーバーやetcd）をGoogleが冗長化して運用し、利用者はアプリを載せるワーカーノードとマニフェストの管理に集中できるマネージドKubernetesです。素のKubernetesを自前で構築するとコントロールプレーンの可用性設計やバージョン追従が重い運用負荷になりますが、GKEはそこをGoogleへ委ねられます。最大の選択軸は運用モードで、ノードの起動から縮退・パッチまで丸ごと任せるAutopilotと、ノード群を自分で設計・運用するStandardの二択になります。

料金はクラスター管理費が1クラスター0.10ドル毎時で、これにコンピューティング費が乗る二階建てです。Autopilotは動かしたPodの要求リソースへ秒単位で課金し、Standardはノード（Compute Engine）の実費で課金します。コンテナを動かしたいだけでKubernetesの表現力が要らないならCloud Run、AWS側で同じことをするならAmazon EKSも含めて比較すべきで、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめて判断してください。

GKEの運用モードとマネージドコントロールプレーンの構成を理解する

GKEを設計に落とすには、Googleが管理する範囲と利用者が管理する範囲の境界線を最初に押さえます。Kubernetesのコンテナオーケストレーションとしての役割を前提に、コントロールプレーンとデータプレーン（ノード）を分けて捉えると構成が整理できます。

ノード運用を任せるAutopilotと自分で持つStandardの責任分界

GKEには2つの運用モードがあります。Autopilotは、ノードのプロビジョニング・スケーリング・OSパッチ・修復までをGoogleが担い、利用者はPodのマニフェストだけを書けばよいモードです。ノードという単位を意識せず、実行中Podが要求したvCPU・メモリ・一時ストレージに対して課金されます。一方のStandardは、ノード（Compute Engineインスタンス）を利用者が設計・運用し、ノードプールのマシンタイプや台数、自動スケーリングの範囲まで自分で握ります。このノードの実体となるVMの仕組みは、Compute Engineとは？の解説で確認できます。細かなカーネル調整や特殊なハードウェア、ノードへの直接アクセスが要るならStandard、運用負荷を抑えたい新規構築ならAutopilotが起点です。なおAutopilotはHostPortやhostNetworkの利用とノードへのSSHが制限されるため、そうしたホストレベルの操作を前提にした構成はStandardを選びます。

ゾーンクラスタ・リージョンクラスタとコントロールプレーンの冗長化

GKEのコントロールプレーンは、単一ゾーンに置くゾーンクラスターと、複数ゾーンへ冗長化するリージョンクラスターを選べます。リージョンクラスターはコントロールプレーンを複数ゾーンに複製するため、ゾーン障害時もAPIサーバーが生き残り、本番向けの可用性を確保できる構成です。Autopilotは常にリージョン構成で提供され、この冗長化が既定で効きます。Standardは要件に応じてゾーンかリージョンを選択でき、開発・検証はゾーン、本番はリージョンといった使い分けが定石です。Kubernetesのバージョンはリリースチャンネル（Rapid／Regular／Stable／Extended）で自動更新の速さを選び、Rapidは上流Kubernetesの新しいマイナー版（2026年7月時点）を早く取り込み、Stableは枯れた版で安定を優先します。

Workload Identity・VPCネイティブなどGCPと統合する要素

GKEはKubernetesに準拠しつつ、Google Cloudのネットワークや認証と統合する仕組みを備えます。中心にあるのはPodへGoogle Cloudのリソース権限を渡すWorkload Identityで、KubernetesのサービスアカウントをGoogle CloudのIAMへ結び付け、ノード全体に強い権限を与えずPod単位で最小限の権限を渡せる認証方式です。ネットワークはVPCネイティブでPodへVPCのIPを割り当て、外部公開はCloud Load BalancingがL4/L7で受け持ちます。コンテナイメージの置き場所はArtifact Registry、監視・ログはCloud Monitoring／Cloud Loggingが標準の担当です。ステートフルなアプリを載せるなら、永続化ストレージ（PV/PVC）の設計やService/Ingressを含むネットワーク設計まで含めて組むと、クラスターが素直に立ち上がります。

GKEの料金モデルとコスト構造・付帯コストを実務目線で押さえる

GKEのコストは、クラスター管理費という固定費とコンピューティング費という変動費の二階建てで捉えると読み違えません。同じクラスターでも運用モードとエディションで積み上がり方が変わります。

クラスター管理費と無料クレジットで決まるGKEの固定費の考え方

クラスター管理費は1クラスターあたり0.10ドル毎時で、AutopilotとStandardのどちらでも、コントロールプレーンの運用対価としてこの単価がかかります（Standard editionの場合・2026年7月時点のGoogle Cloud公式）。月換算では固定で数十ドル規模になり、クラスター数がそのまま倍数で効きます。一方で無料枠があり、月74.40ドル相当のクレジットが1つのゾーンクラスターまたは1つのAutopilotクラスターに適用されるため、小規模な単一クラスターなら管理費が相殺される設計です。クラスターを無闇に分割せず、無料枠の範囲を意識して統合すると固定費を抑えられます。

AutopilotとStandardで変わるコンピューティング費の課金基盤

ノード側の費用は運用モードで計算基盤が異なります。Autopilotは実行中Podが要求したvCPU・メモリ・一時ストレージに対し秒単位で課金するため、空いているノードの無駄が生じにくく、リソース見積もりがそのまま請求に直結します。Standardはノードとして起動したCompute Engineの料金がそのまま乗るため、確約利用割引（Committed Use Discounts）やスポット（Spot VM）をノードに効かせて単価を下げられる点が違いです。常時稼働の土台はStandardのノードで割引を効かせ、変動の激しいワークロードや運用工数を減らしたい構成はAutopilotへ寄せる、という組み合わせが総額を抑える起点になります。

StandardとEnterpriseのエディション差と付帯コスト

GKEにはエディションが2つあります。Standard editionは単一クラスターの運用が中心で、前述のクラスター管理費で使えます。Enterprise editionは複数クラスターをまとめて統治するフリート管理、Config管理、サービスメッシュ、セキュリティ体制の可視化といった機能を加え、GKEが管理するvCPU時間に応じて課金される体系です。これはかつてAnthosとして提供されていたマルチクラウド管理機能がGKE Enterpriseへ統合されたもので、多数のクラスターを組織横断で運用する規模になって初めて費用対効果が出ます。加えて、コンピューティング費だけを見積もると総額を外します。ノードやPodが使う永続ディスク、Cloud Load Balancingの費用、そして下り（外部）通信やリージョン間・ゾーン間のデータ転送料が積み上がるためです。通信の多いPodは同一リージョンへ寄せ、未使用の永続ディスクやロードバランサを棚卸しすると、請求の想定外を減らせます。

GKEを採用すべき条件とEKS・Cloud Runとの使い分け

ここでは判断を言い切ります。GKEはKubernetesの表現力をそのまま得られる反面、クラスター運用やGCP連携の学習コストが伴います。自社システムのどこにGKEを差し込むかを、条件付きで見極めてください。

GKEの採用が効くワークロードの条件と最初に決める設計の観点

採用が効くのは、Google Cloud上でKubernetesの標準APIやエコシステム（Helm・Operator・Argo CD・サービスメッシュなど）をそのまま使いたい、BigQueryやCloud SQLといったGCPのマネージドサービスと同一VPCで密に連携させたい、マイクロサービスを本格的にオーケストレーションしたい、という条件が重なるときです。運用負荷を抑えたい新規構築ならAutopilotから入ると立ち上げが速く、本番の可用性はリージョンクラスターで担保できます。こうしたGoogle Cloud上のコンテナ基盤を自社に取り入れるなら、AWS・Google Cloud・Azureを横断したクラウドインフラ構築の相談窓口で、運用モードの選定やコスト設計、運用体制の妥当性を相談するとよいでしょう。

Amazon EKS・Cloud Runへ寄せるべき場面の見極め

クラウドの選択がAWS前提なら、同じマネージドKubernetesでもAmazon EKSが土俵になります。GKEとEKSはKubernetesという共通言語を持ちつつ、ノード提供形態や課金体系、周辺サービス連携がクラウドごとに異なり、既存の資産とチームの習熟がどちらへ寄っているかが選定の軸です。一方、コンテナを動かしたいだけでクラスターの運用そのものを持ちたくないなら、リクエスト単位で自動スケールするCloud Runが向きます。Cloud Runはクラスター管理費もノード運用もなく、断続的なWebサービスやAPI、イベント駆動の処理に有利です。Kubernetesの豊富なリソース定義やステートフルワークロード、ノードレベルの制御が要る場合にGKE、そこまで要らないならCloud Run、という分岐が実務の起点になります。

GKEを見送るべき場面と実際の運用ではまりやすい失敗パターン

見送るべきなのは、コンテナ化していない単一のアプリを載せたいだけの用途、Kubernetesを運用できる人員がいない小規模チーム、そしてクラスター1つに小さなアプリを1本だけ載せてクラスター管理費に見合わない構成です。これらをGKEで抱えると、学習コストと固定費が回収できません。もう1つの失敗パターンは、Autopilotで各PodのCPU・メモリrequestを過大に設定して課金だけ膨らませる、あるいはゾーン間・下り通信を意識せずデータ転送料を積み上げる構成です。requestを実測値へ寄せ、通信の局所化と付帯コストの棚卸しを前提に組めば、GKEの表現力を過剰投資なしに使えます。GKEはあくまでコンテナオーケストレーションを担う一部品で、要件がCloud Runで足りるなら無理に選ぶ必要はありません。

よくある質問

GKEの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

GKEのAutopilotとStandardはどちらを選ぶべきですか？

ノード運用の手間を抑えたい新規構築や、リソース見積もりをそのまま請求に反映したい場合はAutopilot、ノードのマシンタイプやカーネルを細かく制御したい、GPUや特殊構成、ノードへの直接アクセスが要る場合はStandardが基本の分岐です。AutopilotはHostPortやSSHに制限があるため、そうしたホスト操作を前提とする構成はStandardを選びます。多くの新規案件ではAutopilotを起点に検討し、要件が収まらない部分だけStandardへ切り替えると設計が進めやすくなります。

GKEのクラスター管理費はいくらですか？

1クラスターあたり0.10ドル毎時で、AutopilotとStandardのどちらでもかかります（Standard edition・2026年7月時点のGoogle Cloud公式）。ただし月74.40ドル相当の無料クレジットが1つのゾーンクラスターまたは1つのAutopilotクラスターに適用されるため、小規模な単一クラスターなら管理費が相殺されます。これとは別にコンピューティング費（AutopilotはPodの要求リソース、Standardはノードの費用）や、永続ディスク・ロードバランサ・下り通信の費用が乗ります。

GKEとAmazon EKSは何が違いますか？

どちらもKubernetesのコントロールプレーンを各クラウドが運用するマネージドサービスで、Kubernetesとしての使い勝手は共通です。違いはノードの提供形態や課金体系、そして周辺サービスとの連携先で、GKEはGoogle CloudのVPC・IAM・Artifact Registryと、EKSはAWSのVPC・IAM・ECRと統合します。選定は、既存インフラがGCPかAWSか、チームの習熟がどちらへ寄っているかで決めるのが実務的です。

GKE EnterpriseとStandard editionの違いは何ですか？

Standard editionは単一クラスターの運用が中心で、クラスター管理費で使えます。Enterprise editionは複数クラスターを組織横断で統治するフリート管理、Config管理、サービスメッシュ、セキュリティ体制の可視化を加え、GKEが管理するvCPU時間で課金されます。旧Anthosの機能群が統合されたもので、多数のクラスターを運用する規模になって初めて費用対効果が出るため、単一クラスターならStandard editionで十分です。

素のKubernetesを自前構築するのと比べて何が楽になりますか？

コントロールプレーン（APIサーバーやetcd）の冗長化・バックアップ・バージョンパッチをGoogleが肩代わりする点が最大の差です。とくにAutopilotではノードのプロビジョニングや修復まで任せられるため、自前構築で重かったマスターの可用性設計やノード運用から解放され、アプリの管理へ集中できます。その代わりクラスター管理費が発生し、無料枠を超える規模では固定費として乗ります。

関連記事

• コンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断：GKEの前提となるオーケストレーションの上位概念
• Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分け：AWS側のマネージドKubernetesと迷ったときの比較軸
• Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金：クラスター運用を持たずコンテナを動かす選択肢との使い分け
• Anthosとは？GKE Enterpriseへ統合されたマルチクラウド管理の全体像：GKE Enterprise editionの機能群の前身
• Kubernetes永続化ストレージ入門｜PV・PVC・StorageClassの設計：GKEでステートフルアプリを載せる際の実装深掘り