EKS と AKS を活用したマルチクラウドKubernetes導入ガイド

2026年4月27日

Contents

1 1. マルチクラウドで利用できる主要マネージド K8s サービス
2 2. 設計指針 ― ネットワーク・認証・運用の三本柱
3 3. 実装事例 – Heartbeats.jp の二重クラスタ構成
4 4. 可用性・ディザスタリカバリの実装パターン
- 4.1 4.1 フェイルオーバー自動化フロー
- 4.2 4.2 データレプリケーション戦略（公式サポート範囲）
5 5. 運用体制と人員配置 ― Reddit の議論から学ぶポイント
- 5.1 インシデント情報共有のベストプラクティス
6 6. ハイブリッド／エッジシナリオとの比較 – IBM の指針とマルチクラウド
7 7. 推奨ツールスタックとコスト・パフォーマンス測定
- 7.1 7.1 ツール構成例
- 7.2 7.2 コスト・パフォーマンス指標
  - 7.2.1 PDCA サイクルの実践例
8 8. まとめ
- 8.1 参考文献

スポンサードリンク

1. マルチクラウドで利用できる主要マネージド K8s サービス

項目	Amazon EKS	Azure AKS	Google GKE	Anthos (Google)
提供形態	フルマネージド（コントロールプレーンはサーバーレス）	フルマネージド（自動アップグレード可）	フルマネージド＋Autopilot オプション	ハイブリッド/オンプレ含む統合管理
認証	IAM ロール、OIDC、IAM Identity Center	Azure AD、AAD Pod Identity	Cloud IAM、Workload Identity	上記に加えてカスタム認証プラグイン
ネットワーク	VPC CNI（ENI ベース）＋ PrivateLink	Azure CNI、VNet Integration	VPC‑native（Alias IPs）	任意の CNI を統一的に管理
自動スケーリング	Cluster Autoscaler、EC2 Spot インスタンス	Virtual Node、Cluster Autoscaler	Autopilot 自動スケール、Cluster Autoscaler	Anthos Config Management で統一
マルチリージョン対応	Global Accelerator・Transit Gateway 経由のクロスリージョン通信	Front Door・VNet Peering	Cloud Router・Global Load Balancing	複数クラウド・リージョンを単一 UI で管理
料金体系	コントロールプレーン $0.10/時間 + ワーカーノード課金	コントロールプレーン無料、ノード課金	クラスタ作成料なし（Autopilot は使用分課金）	ライセンス＋基盤リソース課金

ポイント
- 認証は IdP（Okta・Keycloak 等）で OIDC 統一すると、各クラウドの IAM とマッピングできるため運用負荷が大幅に減少する。
- ネットワークは VPC/VNet Peering に加えて Transit Gateway（AWS）や ExpressRoute（Azure）のハイブリッド接続を組み合わせると、暗号化トラフィックも低遅延で相互接続できる。

2. 設計指針 ― ネットワーク・認証・運用の三本柱

項目	推奨アプローチ
ネットワーク	- VPC ↔︎ VNet の相互 Peering（トラフィックは内部 IP） - 必要に応じて Transit Gateway + ExpressRoute で暗号化トンネルを構築
認証統一	OIDC プロバイダー（例：Okta）を中心に、各クラウドの IAM と `aws-auth`・`azure-ad-pod-identity` を紐付ける。
GitOps の徹底	Flux または Argo CD をマルチクラスターで共通化し、`ApplicationSet` により新規クラスター追加を自動生成。

3. 実装事例 – Heartbeats.jp の二重クラスタ構成

3.1 背景と要件

要件	内容
可用性	単一リージョン・単一ベンダー障害でのサービス停止が許容できない。
運用負荷削減	従来は自前サーバ上の Docker 管理だったが、スケールアウトと復旧手順をコード化したい。

3.2 アーキテクチャ概要

+-------------------+        +-------------------+
|   EKS (us-east-1) |&lt;-----&gt;|   AKS (Japan East)|
+--------+----------+  VPC/VNet Peering  +----------+--------+
         |                                          |
    Consul Connect                               Consul Connect
         |                                          |
   Aurora (us‑east‑1)                      Azure Cosmos DB (Japan)

+-------------------+ +-------------------+

| EKS (us-east-1) |<----->| AKS (Japan East)|

+--------+----------+ VPC/VNet Peering +----------+--------+

| |

Consul Connect Consul Connect

| |

Aurora (us‑east‑1) Azure Cosmos DB (Japan)

主な構成要素

項目	内容・留意点
クラスタ	EKS（米国）と AKS（日本）の二重構成。両方に同一マニフェストを GitOps で配布。
ネットワーク	VPC ↔︎ VNet の相互 Peering＋TLS 終端後の内部 IP 通信。
サービスディスカバリ	Consul Connect の Multi‑Cloud モードで DNS 同期を自動化。
データストア	Aurora はリージョン間リーダー/レプリカを利用し、1 秒未満のレプリケーション遅延（※AWS 公式ドキュメント参照[^1]）。 Cosmos DB はマルチマスターモードを使用し、各リージョンで書き込み可能。双方向レプリは提供されていないため、変更データキャプチャ (CDC) とカスタム同期パイプライン（Debezium + Kafka）で実装することが推奨される。
CI/CD	GitHub → Flux でマニフェスト生成 → Argo CD が EKS・AKS に自動デプロイ。テストは GitHub Actions 上の Helm lint と integration test。
監視	Prometheus + Grafana（Federated）でメトリクス集約、Fluent Bit で CloudWatch (EKS) / Azure Monitor (AKS)。Alertmanager → PagerDuty。

注記：Aurora Global Database の「双方向レプリケーション」は公式にはサポートされていない。上記構成では Aurora は リーダーレプリカ として使用し、書き込みはプライマリリージョンに限定する形で実装している。

3.成果

指標	結果
デプロイ頻度	1日5回以上の自動デプロイを安定稼働。
障害復旧時間 (MTTR)	自動フェイルオーバーと Terraform + Cluster API による再構築で 15 分以内に完了。
運用コスト削減	スポットインスタンス導入により、ノードコストを約 30 % 削減。

（詳細は Heartbeats.jp 公式ブログ[^2] を参照）

4. 可用性・ディザスタリカバリの実装パターン

4.1 フェイルオーバー自動化フロー

flowchart TD
    A[障害検知 (CloudWatch Event / Azure Monitor)] --&gt; B{GitOps リポジトリ}
    B -- failover=true --&gt; C[Terraform + Cluster API]
    C --&gt; D[新規クラスター作成（代替リージョン）]
    D --&gt; E[Istio VirtualService weight 更新]
    E --&gt; F[トラフィックシフト完了]

flowchart TD

A[障害検知 (CloudWatch Event / Azure Monitor)] --> B{GitOps リポジトリ}

B -- failover=true --> C[Terraform + Cluster API]

C --> D[新規クラスター作成（代替リージョン）]

D --> E[Istio VirtualService weight 更新]

E --> F[トラフィックシフト完了]

インフラコード化：Terraform と Cluster API (CAPA/CAPI) でクラスタのプロビジョニングを宣言的に管理。
GitOps トリガー：障害検知時に failover=true をプッシュし、パイプラインが自動実行。
トラフィック切替：Istio の VirtualService で重み (weight) を変更し、段階的に代替クラスタへシフト。

4.2 データレプリケーション戦略（公式サポート範囲）

ストア	推奨構成	主な特長
Amazon Aurora	プライマリリージョンに書き込み、他リージョンはリーダー/レプリカとして利用。AWS の公式ベンチマークでは < 1 秒の遅延が報告されている[^1]。	書き込み分散は不可だが、読み取り負荷を各リージョンで吸収可能。
Azure Cosmos DB	マルチマスターモード（All‑Region Writes）を有効化し、全リージョンで書き込み可。データ整合性は 5 種類から選択できる（Strong, Bounded Staleness 等）。	書き込み分散が必要なシナリオに最適。ただし Aurora と直接の双方向レプリは不可。
カスタム CDC	Debezium + Kafka Connect を介した変更データキャプチャで、Aurora → Cosmos DB あるいは逆方向へ非同期コピーを実装。	完全自動化は可能だが、運用コストとスキーマ管理に注意。

5. 運用体制と人員配置 ― Reddit の議論から学ぶポイント

Reddit の r/kubernetes スレッド（2023 年 11 月）では、マルチクラウド環境での エンジニア規模 と スキルマトリクス が成功要因として頻繁に言及されている[^3]。日本語訳がないため要点を以下に整理した。

役割	推奨人数（例）	必須スキル
プラットフォームエンジニア	2 名	IaC (Terraform/CloudFormation)、K8s クラスター設計、CNI 設定
SRE / Site Reliability Engineer	3 名	Observability (Prometheus/Grafana)、Alerting (PagerDuty)、自動復旧スクリプト
DevSecOps	1 名	CI/CD（GitHub Actions, Argo CD）、コンテナセキュリティ（OPA、Trivy）
ネットワークエンジニア（パートタイム）	0.5–1 名	VPC/VNet Peering、Transit Gateway/ExpressRoute、TLS 設定

経験年数の目安：SRE のうち 1 人は 10 年以上 の大規模クラスター運用実績が望ましいと指摘。
ローテーション例：2 週間単位でオンコールシフトを回し、週末は「フェイルオーバー待機」エンジニアを専任配置。

インシデント情報共有のベストプラクティス

Slack の #incident チャンネルに Incident.io（または PagerDuty）の自動生成ページリンクを貼付。
事後は Confluence にテンプレート化した ポストモーテム を 48 時間以内に作成し、改善アクションを次回のスプリントに組み込む。

6. ハイブリッド／エッジシナリオとの比較 – IBM の指針とマルチクラウド

IBM が示す ハイブリッド/エッジ のガイドライン（[IBM Kubernetes Use Cases][^4]）は、オンプレミスや IoT デバイスへのデプロイが前提となる。一方、本稿で扱う パブリックマルチクラウド は以下の点で異なる。

観点	IBM ハイブリッド/エッジ	パブリックマルチクラウド（本稿）
対象	OpenShift + IBM Cloud Satellite、オンプレ Bare Metal、IoT デバイス	EKS、AKS、GKE のみで構成するパブリック環境
データ主権	法規制に応じたローカルストレージ必須	Aurora Global / Cosmos DB のリージョン横断レプリで対応（ただしデータ所在地は各リージョン）
運用統一性	Red Hat OpenShift + Satellite による単一管理面	Flux/Argo CD で GitOps 統一、しかしクラウド固有設定は別途管理必要
レイテンシ要件	エッジデバイス近接が必須（数ミリ秒）	CDN (CloudFront + Front Door) による HTTP レベルの最適化で 100 ms 以下を目指す

選定ポイント
- リアルタイム制御 が必要な場合は K3s 等軽量 K8s をエッジ側に展開し、IBM Satellite のような管理レイヤーと併用する方が適切。
- 法的要件でデータを特定国内に保存しなければならないケースでは、マルチクラウドは バックアップ/DR 用に限定すべき。

7. 推奨ツールスタックとコスト・パフォーマンス測定

7.1 ツール構成例

カテゴリ	推奨ツール	主な役割
GitOps	Flux（シングルソース） / Argo CD（マルチテナント）	マニフェスト自動同期、クラスター追加の `ApplicationSet`
監視・可観測性	Prometheus (Federated) + Grafana	メトリクス集約とダッシュボード共通化
サービスメッシュ	Istio（MeshGateway）	VPC/VNet 間の暗号化トラフィック、フェイルオーバー時の重み変更
インフラ自動化	Terraform + Cluster API (CAPA/CAPI)	クラスター・ノードプールのコード化
CI/CD パイプライン	GitHub Actions + Helm + Kustomize	ビルド、テスト、デプロイを一元管理

7.2 コスト・パフォーマンス指標

指標	測定方法	改善アクション例
クラウド利用料 (CPU/Memory)	CloudWatch + Azure Monitor の日次レポート	未使用リソースの自動スケールダウン、スポットインスタンス活用
ライセンス費	SaaS サブスク費を集計（Excel/BI）	必要機能だけに絞り、不要オプション削除
オンコール工数	PagerDuty のインシデント時間 × 時給	フェイルオーバー自動化でインシデント解決時間を 30 % 短縮
CPU/Memory 使用率	Prometheus `node_cpu_seconds_total`、`container_memory_usage_bytes`	リクエスト/リミット調整、HPA の閾値最適化
デプロイ同期時間	Argo CD の `sync_duration_seconds` メトリック	イメージキャッシュやマルチステージビルドで 20 % 短縮
MTTR (障害復旧時間)	Incident.io の平均解決時間	Terraform + Cluster API による自動再構築スクリプト導入

PDCA サイクルの実践例

Plan：月次で「CPU 平均使用率 60 % 未満」「MTTR ≤ 30 分」を目標に設定。
Do：Terraform の scale-down ジョブを追加し、未使用ノードを自動停止。
Check：Grafana アラートで「CPU > 80 %」が何回発生したか測定し、前月比で減少確認。
4 Act：効果が不十分ならスポットインスタンス比率を上げる、または HPA の閾値を再調整。

8. まとめ

項目	キーとなるポイント
サービス選定	EKS・AKS・GKE・Anthos を比較し、認証・ネットワーク・自動スケールの要件で最適な組み合わせを決定。
実装事例	Heartbeats.jp の二重クラスタと GitOps による統一パイプラインは、24/7 監視と自動フェイルオーバーを実現した好例。ただし Aurora と Cosmos DB の双方向レプリは公式非対応のため、CDC 等でカバーする必要あり。
可用性設計	Cluster API + Terraform によるインフラコード化、Istio でトラフィックシフト、Aurora リーダーレプリと Cosmos DB のマルチマスタを組み合わせたデータレプリ戦略。
運用体制	Reddit 議論に沿った 4〜6 人規模のエンジニアチームとローテーション、インシデント情報は Slack + Incident.io で即時共有し、ポストモーテムをスプリントに反映。
ハイブリッド/エッジ比較	エッジ側のミリ秒レベル要求がある場合は IBM Satellite や K3s を検討。一方、パブリックマルチクラウドでは CDN と GitOps が主戦力になる。
コスト・パフォーマンス管理	Prometheus/Grafana で指標を可視化し、PDCA に基づく継続的最適化で運用費と MTTR を削減。

本稿の内容を自社の要件（障害許容度・データ主権・運用リソース）に照らし合わせ、マルチクラウド Kubernetes の導入計画を策定してください。

参考文献

[^1]: Amazon Aurora Global Database – Replication Latency. AWS Documentation, 2024年5月版, https://docs.aws.amazon.com/aurora/latest/global-database/replication-latency.html
[^2]: Heartbeats.jp 公式ブログ「EKS と AKS によるマルチクラウド Kubernetes」, 2024年1月, https://heartbeats.jp/hbblog/2024/01/eks-aks-kubernetes.html
[^3]: Reddit投稿「Managing large‑scale Kubernetes across multicloud」, r/kubernetes, 2023年11月, https://www.reddit.com/r/kubernetes/comments/1jtqqtm/managing_largescale_kubernetes_across_multicloud/
[^4]: IBM Japan 「Kubernetes の事例、用途、ユースケース」, 2024年2月, https://www.ibm.com/jp-ja/think/topics/kubernetes-use-cases