【AWS経験者向け】EKSとGKE：Kubernetesのマネージドサービスを比較体験！
はじめに：コンテナ時代のインフラ戦略
皆さん、こんにちは！「30日間でGCPをマスターするAWSエンジニアの挑戦」シリーズ、8日目へようこそ。
この1週間で、GCPの基盤サービス（IAM、VPC、ストレージ、データベース）をAWSと比較してきました。今日からは、現代のクラウドアーキテクチャの中心となっているコンテナ技術の領域に踏み込んでいきます。
コンテナオーケストレーションの現状
現在、本番環境でのコンテナ運用において、Kubernetesはデファクトスタンダードとなっています。しかし、Kubernetesの運用管理は複雑で、以下のような課題があります：
- コントロールプレーンの高可用性確保
- ノードの管理とセキュリティ更新
- ネットワークとストレージの設定
- 監視とログ管理
- アクセス制御とセキュリティ
AWSとGCPのアプローチの違い
AWSは、EC2ベースの**ECS（Elastic Container Service）とKubernetesベースのEKS（Elastic Kubernetes Service）**という2つの選択肢を提供しています。
GCPは、Kubernetesを開発した企業として、**GKE（Google Kubernetes Engine）**に注力し、Kubernetesの運用を極限まで簡素化することに成功しています。
今回の記事では、AWS EKSの知識を前提に、以下の観点からGKEの革新的な特徴を深掘りします：
- 料金体系の革新：なぜGKEはコントロールプレーンが無料なのか？
- オートパイロットモードの威力：ノード管理からの完全な解放
- セキュリティ統合：IAMとKubernetesの自然な連携
- 運用性能：スケーリング、監視、トラブルシューティング
料金体系の根本的な違い
AWS EKSの料金構造
EKSクラスター料金（月額）：
├── コントロールプレーン: $72.00/月 ($0.10/時間)
├── ノード（EC2）: インスタンス料金 + EBSストレージ
├── ロードバランサー: $16.20/月 (ALB)
└── データ転送料金: 従量課金
計算例（小規模クラスター）：
- コントロールプレーン：$72/月
- ワーカーノード（t3.medium × 3）：約$95/月
- ALB：$16.20/月
- 合計：約$183/月
GCP GKEの料金構造
GKEクラスター料金（月額）：
├── コントロールプレーン: $0 (無料)
├── ノード（Compute Engine）: インスタンス料金のみ
├── ロードバランサー: ルールベース課金
└── データ転送料金: リージョン内無料
計算例（同等規模のクラスター）：
- コントロールプレーン：$0
- ワーカーノード（e2-medium × 3）：約$73/月
- ロードバランサー：約$8/月
- 合計：約$81/月
コスト効率の比較
| 項目 | AWS EKS | GCP GKE | 差額 |
|---|---|---|---|
| 小規模環境 | $183/月 | $81/月 | -56% |
| 中規模環境（10ノード） | $390/月 | $243/月 | -38% |
| 大規模環境（50ノード） | $1,272/月 | $1,215/月 | -4% |
重要な洞察：
- 小規模環境では、GKEのコスト優位性が顕著
- 大規模環境では差が縮まるが、運用コスト削減効果は大きい
GKEの革新：2つの運用モード
標準モード vs オートパイロットモード
| 比較項目 | 標準モード | オートパイロットモード |
|---|---|---|
| ノード管理 | ユーザーが管理 | GKEが完全管理 |
| 課金方式 | ノード単位（時間） | Pod単位（リソース使用量） |
| スケーリング | 手動設定が必要 | 完全自動 |
| セキュリティ更新 | ユーザー責任 | 自動実行 |
| ネットワークポリシー | 手動設定 | 自動適用 |
オートパイロットモードの威力
オートパイロットモードは、「ノードを意識しない」Kubernetes運用を実現します：
# デプロイするPodのリソース定義のみ
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
template:
spec:
containers:
- name: app
image: nginx
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "500m"
memory: "1Gi"
GKEが自動で実行すること：
- 必要なノードの自動プロビジョニング
- Pod配置の最適化
- 不要ノードの自動削除
- セキュリティパッチの自動適用
- ネットワークポリシーの自動設定
セキュリティ統合の比較
AWS EKSのセキュリティ設定
EKSでは、複数のレイヤーでセキュリティ設定が必要です：
# 1. クラスター用IAMロール
aws iam create-role \
--role-name eks-cluster-role \
--assume-role-policy-document file://cluster-trust-policy.json
# 2. ノードグループ用IAMロール
aws iam create-role \
--role-name eks-nodegroup-role \
--assume-role-policy-document file://nodegroup-trust-policy.json
# 3. aws-auth ConfigMapでKubernetes権限をマッピング
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: arn:aws:iam::ACCOUNT:role/NodeInstanceRole
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
GCP GKEのセキュリティ統合
GKEは、GCPのIAMと自然に統合されています：
# 1. GKEクラスターの作成（サービスアカウント自動設定）
gcloud container clusters create secure-cluster \
--enable-private-nodes \
--master-ipv4-cidr-block 10.0.0.0/28 \
--enable-network-policy \
--zone=asia-northeast1-a
# 2. Workload Identityの有効化（自動でIAM連携）
gcloud container clusters update secure-cluster \
--workload-pool=PROJECT_ID.svc.id.goog
# 3. KubernetesサービスアカウントとGCP IAMの直接バインディング
kubectl annotate serviceaccount my-ksa \
iam.gke.io/gcp-service-account=my-gsa@PROJECT_ID.iam.gserviceaccount.com
セキュリティ機能の比較
| セキュリティ項目 | AWS EKS | GCP GKE |
|---|---|---|
| ネットワーク分離 | セキュリティグループ + NACLs | VPCネイティブ + ネットワークポリシー |
| Pod セキュリティ | Pod Security Standards | Pod Security Policy（自動適用） |
| シークレット管理 | AWS Secrets Manager連携 | Secret Manager連携（自動） |
| 監査ログ | CloudTrail（有料） | Cloud Audit Logs（無料） |
| 脆弱性スキャン | ECR Scanning | Container Analysis（自動） |
実践ハンズオン：GKEクラスターの構築と比較
Phase 1：オートパイロットクラスターの作成
# オートパイロットクラスターの作成
gcloud container clusters create-auto production-autopilot \
--region=asia-northeast1 \
--release-channel=regular
# 認証情報の取得
gcloud container clusters get-credentials production-autopilot \
--region=asia-northeast1
# クラスター情報の確認
kubectl cluster-info
kubectl get nodes # ノードが自動でプロビジョニングされる
Phase 2：アプリケーションのデプロイ
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-app
spec:
replicas: 5
selector:
matchLabels:
app: demo
template:
metadata:
labels:
app: demo
spec:
containers:
- name: app
image: gcr.io/google-samples/hello-app:2.0
ports:
- containerPort: 8080
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "200m"
memory: "256Mi"
---
apiVersion: v1
kind: Service
metadata:
name: demo-service
spec:
selector:
app: demo
ports:
- port: 80
targetPort: 8080
type: LoadBalancer
# デプロイの実行
kubectl apply -f deployment.yaml
# スケーリングのテスト
kubectl scale deployment demo-app --replicas=10
# 自動スケーリングを確認
kubectl get nodes -w # 新しいノードが自動で追加される様子を確認
Phase 3：運用監視
# クラスターの健康状態確認
gcloud container clusters describe production-autopilot \
--region=asia-northeast1
# リソース使用量の確認
kubectl top nodes
kubectl top pods
# ログの確認（Cloud Loggingと自動連携）
gcloud logging read "resource.type=k8s_container" --limit=10
パフォーマンスとスケーリング比較
オートスケーリングの性能
| メトリクス | AWS EKS | GCP GKE（標準） | GCP GKE（オートパイロット） |
|---|---|---|---|
| Pod起動時間 | 30-60秒 | 20-40秒 | 10-30秒 |
| ノード追加時間 | 2-4分 | 1-3分 | 30秒-2分 |
| スケールダウン | 設定依存 | 設定依存 | 完全自動（15秒後） |
| リソース効率 | 70-80% | 75-85% | 85-95% |
実測値の例（東京リージョン）
# 負荷テストの実行
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never \
-- /bin/sh -c "while sleep 0.01; do wget -q -O- http://demo-service/; done"
# スケーリング結果
時刻 | CPU使用率 | Pod数 | ノード数 | 応答時間
14:00 | 30% | 5 | 2 | 50ms
14:05 | 80% | 10 | 3 | 60ms ← 自動スケール発生
14:10 | 95% | 20 | 5 | 80ms ← さらなるスケール
14:15 | 40% | 15 | 4 | 55ms ← 自動スケールダウン
トラブルシューティングと運用性
障害対応の比較
AWS EKSでの典型的な問題：
# ノードが Ready にならない場合
kubectl describe node
aws ec2 describe-instances
# IAMロール、セキュリティグループ、subnet設定を確認
GCP GKEでの同等の問題：
# オートパイロットでは、ほとんどの問題が自動解決される
kubectl get events --sort-by=.metadata.creationTimestamp
gcloud container operations list # GKEの操作履歴
監視・ログ統合
| 機能 | AWS EKS | GCP GKE |
|---|---|---|
| メトリクス収集 | CloudWatch Container Insights（追加設定） | Cloud Monitoring（自動統合） |
| ログ集約 | Fluent Bit設定が必要 | Cloud Logging（自動） |
| 分散トレース | X-Ray連携（手動設定） | Cloud Trace（自動） |
| アラート設定 | CloudWatch Alarms | Cloud Monitoring Alerts |
| コスト分析 | Cost Explorer | GKE usage metering（詳細） |
選択指針：EKS vs GKE
AWS EKSを選ぶべきケース
✅ 既存のAWS環境との深い統合が必要
✅ IAMポリシーやセキュリティグループの細かい制御が必要
✅ AWS固有のサービス（RDS、ElastiCache等）との連携が重要
✅ ECSからの段階的移行を計画している
✅ Fargateでのサーバーレスコンテナ実行を重視
✅ AWS認定資格やノウハウが社内に豊富にある
GCP GKEを選ぶべきケース
✅ 運用コストを最小化したい
✅ Kubernetesネイティブな開発・運用を重視
✅ コンテナファーストな新規プロジェクト
✅ 自動化を最大限活用したい
✅ データ分析・AI/MLワークロードとの統合
✅ グローバル展開を前提としたアーキテクチャ
移行の考慮点
EKSからGKEへの移行：
# Kubernetesマニフェストは基本的に同じ
# 主な変更点：
# 1. LoadBalancerアノテーション
metadata:
annotations:
cloud.google.com/load-balancer-type: "External" # GCP特有
# 2. ストレージクラス
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ssd-storage
provisioner: kubernetes.io/gce-pd # EKS: kubernetes.io/aws-ebs
parameters:
type: pd-ssd
まとめ：Kubernetesマネージドサービスの新基準
| 比較観点 | AWS EKS | GCP GKE |
|---|---|---|
| コスト効率 | 高い（大規模時） | 非常に高い（全規模） |
| 運用負荷 | 中程度 | 最小 |
| カスタマイズ性 | 高い | 中程度 |
| 学習コスト | 高い | 低い |
| エコシステム | AWS統合 | Kubernetes純正 |
| イノベーション | 段階的改善 | 革新的機能 |
主要な学び
- GKEのコントロールプレーン無料化により、小規模環境でのKubernetes導入コストが大幅削減
- オートパイロットモードは、Kubernetes運用の複雑さを根本的に解決する革新的アプローチ
- GCPのIAM統合により、セキュリティ設定が大幅に簡素化
- 自動化の徹底により、運用負荷とヒューマンエラーを最小化
GCP GKEは、Kubernetesを開発した企業ならではの深い理解に基づいて、コンテナオーケストレーションの運用を根本的に改善しています。特に、運用の自動化とコスト最適化において、従来の常識を覆すレベルの革新を実現しています。
次回は、コンテナイメージの管理について学びます。DockerイメージをECRとArtifact Registryのどちらに保存すべきか、それぞれの特徴と使い分けを詳しく比較していきましょう。
この記事が役に立ったという方は、ぜひ「いいね」や「ストック」をお願いします！
シリーズ記事一覧
- [【1日目】はじめの一歩！AWSエンジニアがGCPで最初にやるべきこと]
- [【2日目】GCPのIAMはAWSとどう違う？「プリンシパル」と「ロール」の理解]
- [【3日目】VPCとVPCネットワーク：GCPのネットワーク設計思想を理解する]
- [【4日目】S3とCloud Storage：オブジェクトストレージを徹底比較]
- [【5日目】RDSとCloud SQL：マネージドデータベースの運用管理の違い]
- [【6日目】EC2とCompute Engine：インスタンスの起動から課金モデルまで]
- [【7日目】1週間のまとめ：AWSとGCP、それぞれの得意なことと設計思想]
- [【8日目】EKSとGKE：Kubernetesのマネージドサービスを比較体験！]（この記事）
- [【9日目】Dockerイメージをどこに置く？ECRとArtifact Registryを比較]