クラウド・インフラ

マルチクラウドで月30万円の無駄に気づくまで──失敗から学んだ現実的な使い分け

AWSとGCP、Azureを併用して請求額が急騰した実体験。ベンダーロックイン回避という名目の落とし穴と、チームで試行錯誤して辿り着いた現実的なマルチクラウド戦略を共有します。

クラウド・インフラマルチクラウドAWSGCPAzureコスト最適化

なぜマルチクラウドを始めたのか、そして失敗した

先日、決算報告の際にCFOから「クラウド費用が前月比40%増」と指摘されて、冷や汗をかきました。うちのチームは約18ヶ月前、ベンダーロックインを避けるという理由で「マルチクラウド戦略を導入しよう」と決めたんです。AWSをメインに、GCPとAzureも検証環境で試していたんですが、気づいたら本番環境にまで広がってしまったと。

正直、マルチクラウドって聞こえはいいけど、実運用は地獄です。最初の3ヶ月は「複数ベンダーのサービスを使い分けられる柔軟性」とか夢を見てたんですが、気づくとこんなことになってました：

  • AWSで月80万円、GCPで月45万円、Azureで月15万円 → 合計140万円
  • うち、実際に活用してるのはAWSだけで、GCPとAzureは検証用途でほぼ遊んでいる状態
  • 請求書の理解が複雑化して、どこで何にコストが発生してるのか不透明
  • チームのスキルも分散してしまい、問題が起きたときに対応する人が明確でない

この状態が「マルチクラウド戦略」だと思い込んでました。実は単なる「複数クラウドの垂れ流し」です。

なぜマルチクラウドは失敗しやすいのか──実務的な理由

AWS・GCP・Azureの3つを本番環境で運用してみると、いくつかの根本的な課題が見えてきます。

1. ダッシュボード・監視が統一できない

AWSはCloudWatch、GCPはCloud Monitoring、AzureはAzure Monitorと、それぞれ異なるツールです。統合ダッシュボードを作ろうとするなら、DatadogやNew Relicといった第三者監視ツールが必要になります。うちの場合、Datadog導入だけで月15万円のコストが追加されました。

各クラウドからメトリクスを取得するコマンドも全部違うんですよね：

# CloudWatchからメトリクスを取得
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-xxxxx \
  --start-time 2026-07-01T00:00:00Z \
  --end-time 2026-07-12T00:00:00Z \
  --period 300 \
  --statistics Average

# GCPからメトリクスを取得
gcloud monitoring time-series list \
  --filter 'metric.type="compute.googleapis.com/instance/cpu/utilization"'

# Azureからメトリクスを取得
az monitor metrics list \
  --resource-group myResourceGroup \
  --resource-type Microsoft.Compute/virtualMachines \
  --resource myVM \
  --metric CpuPercentage

3つの別々なコマンドを覚える必要があり、チームメンバーの学習コストも増えます。地味に、チーム全体の生産性が落ちるんですよね。

2. Kubernetes運用が複雑化する

マルチクラウドで「各クラウドのKubernetes」を使い分けようとすると、EKS（AWS）、GKE（GCP）、AKS（Azure）の3つを運用することになります。微妙に異なるネットワーク設定、ストレージクラス、Ingressの実装…。

うちのチームは最初、「複数クラウドで同じアプリケーションを展開する」という理由でマルチクラウドKubernetesを検討していたんですが、実際に試してみると、以下の問題が発生しました：

  • EKSではAWS Load Balancer Controllerを使うが、GKEではGoogle Cloud Load Balancerの仕様が異なる
  • AKSのネットワークポリシーはCalico導入が必要で、初期設定で月2日かかった
  • ストレージクラスの命名規則も異なり、IaC（Infrastructure as Code）の記述が統一できない

結果として、マルチクラウドで同じマニフェストを使い回すことは「理論上は可能」だが「実務的には不可能」という判断に至りました。やってみるまで気づかないんですよね、この壁。

3. IAM設計の複雑さが指数関数的に増える

AWSのIAM設定は比較的統一されていますが、GCPはService Account、AzureはManagedIdentityと、概念そのものが異なります。複雑さの増加パターンを見ると一目瞭然です：

xychart-beta
  title IAM設定数の増加パターン
  x-axis [AWS単体, "AWS\n+GCP", "AWS\n+GCP\n+Azure"]
  y-axis "必要なIAM設定数" 0 --> 500
  line [100, 250, 480]

実際にマルチクラウド環境でセキュリティを保ちながら権限管理をしようとすると：

  • AWS: IAMロール、ポリシー、信頼関係の3層構造
  • GCP: Service Account、IAM Binding、Custom Roleの3層構造（でも概念は異なる）
  • Azure: Azure AD、Managed Identity、Role-based Access Control（RBAC）で似ているようで異なる

これらを統一的に管理するには、Terraformなどで抽象化レイヤーを作る必要があります。でも、その抽象化層自体がチームのナレッジになってしまい、保守コストが跳ね上がります。

2026年時点での現実的なマルチクラウド戦略

この18ヶ月の失敗を経て、うちのチームが辿り着いたのは「完全なマルチクラウド」ではなく、**「戦略的な主従関係」**という考え方です。

メインクラウド（Primary）とセカンダリクラウド（Secondary）を明確に分ける

graph TB
  subgraph AWS["メインクラウド (AWS)"]
    A["EC2/ECS<br/>本番ワークロード"]
    B["RDS PostgreSQL"]
    C["S3<br/>メインデータ"]
    D["Lambda<br/>非同期処理"]
  end
  
  subgraph GCP["セカンダリクラウド (GCP)"]
    E["BigQuery<br/>分析専用"]
    F["Vertex AI<br/>ML実験用"]
  end
  
  subgraph Azure["災害復旧 (Azure)"]
    G["コールドスタンバイ"]
    H["バックアップ保管"]
  end
  
  A -->|データ同期| E
  B -->|分析用データ| E
  C -->|バックアップ| H
  D -->|機械学習| F
  G -.->|フェイルオーバー| A

我々が実装した構成は、かなりシンプルです：

  1. AWSをメイン → 日本の信頼できるリージョンに集約

    • ほぼ全てのワークロード
    • トランザクショナルデータベース
    • ホットデータ

  2. GCPはセカンダリ（分析特化） → BigQueryとVertex AIだけに絞る

    • データ分析が必要になった時点で、AWSのS3からGCPのBigQueryへ定期同期
    • 機械学習の実験的なワークロード

  3. Azureは災害復旧用 → ほぼ使わない（でも契約は生きてる）

    • 月1回のバックアップを保管
    • 万が一AWSが全リージョン落ちた場合のための最後の砦

この構成で、月140万円 → 月95万円に削減できました。実際に効果が出てきたんです。

実装パターン：AWSからGCPへの定期データ同期

AWSとGCPを同時に使うなら、データの流れを明確にしておく必要があります。うちの場合、こんな仕組みにしました：

# AWSのS3 → GCPのBigQueryへデータ移行するLambda関数
import boto3
from google.cloud import bigquery
import pandas as pd
from io import BytesIO

s3_client = boto3.client('s3')
bq_client = bigquery.Client()

def sync_s3_to_bigquery(event, context):
    """
    AWSのS3から毎日のログファイルを取得して、GCPのBigQueryに送信
    """
    bucket_name = 'our-logs-bucket'
    prefix = f'logs/{event["date"]}/'
    
    # S3からCSVを取得
    paginator = s3_client.get_paginator('list_objects_v2')
    pages = paginator.paginate(Bucket=bucket_name, Prefix=prefix)
    
    for page in pages:
        for obj in page.get('Contents', []):
            # CSVファイルを読み込む
            response = s3_client.get_object(Bucket=bucket_name, Key=obj['Key'])
            df = pd.read_csv(response['Body'])
            
            # BigQueryに書き込む
            table_id = 'gcp-project.dataset.logs'
            job_config = bigquery.LoadJobConfig(write_disposition='WRITE_APPEND')
            
            job = bq_client.load_table_from_dataframe(
                df, table_id, job_config=job_config
            )
            job.result()  # 完了まで待機
            
    return {
        'statusCode': 200,
        'body': f'Successfully synced data from S3 to BigQuery'
    }

この関数をEventBridgeで毎日深夜に実行して、自動的にAWSのログをGCPの分析プラットフォームに送り込んでいます。一度作ったら、ほぼ手がかからないシステムになるんですよね。

コスト構造の可視化：2026年版

pie title 月額クラウドコスト内訳
  "AWS EC2/ECS" : 450000
  "AWS RDS" : 280000
  "AWS Data Transfer" : 120000
  "AWS その他" : 150000
  "GCP BigQuery" : 180000
  "GCP Vertex AI" : 80000
  "Azure Backup" : 45000
  "Datadog監視" : 150000

合計　約1,455,000円/月です。

このうち、実際にビジネス価値を生み出してるのはAWSの880,000円とGCPの260,000円です。Azureの45,000円は「保険料」みたいなものだと割り切ってます。

2026年のマルチクラウド判断基準

過去18ヶ月の失敗から、以下の判断基準を作りました。チームの意思決定に活用しています：

判断項目セカンダリクラウド必要不要
ワークロード特性GCPのBigQueryが本当に必要
Azureの専用サービスが必須		単なる「複数ベンダを試してみたい」
コスト効率メインより30%以上効率的な価格設定メインと同等以上の価格
チームスキルクラウドごとに専門家がいる1人で複数クラウド対応する羽目に
運用成熟度メインクラウドの本番運用が3年以上安定本番でのトラブルが月1回以上発生
ビジネス要件明確な技術要件がある
（データレジデンシ、特定サービス依存等）		漠然とした「複数ベンダ戦略」という理由

うちのチームの場合、2026年7月時点では：

  • GCP：○ → BigQueryの分析性能はAWSのAthena+Redshiftより30%効率的（実測値）
  • Azure：△ → 本当は削除したい（でもリスク回避で契約継続中）

チーム内での「マルチクラウド疲れ」への対策

正直に話すと、チームメンバーから「複数クラウドの管理、もう疲れた」という声が出ていました。以下の対策を打ちました：

1. クラウド担当を明確に分ける

- シニアエンジニアA: AWS全般（リード）
- シニアエンジニアB: GCP BigQuery専任
- 新卒C: Azureバックアップ（月1回のチェック程度）

これだけで、意外と運用がスムーズになるんですよ。「このサービスで問題が起きたら、この人に聞く」という明確さが生まれます。

2. IaCの「抽象化レイヤー」を潔く諦める

最初はTerraformで「AWSとGCPを同じコードで定義しよう」と思ってましたが、完全に諦めました。これは割り切りです。

代わりに：

  • AWSはTerraform → 本番環境の構築・管理
  • GCPはPython + Dataflow → 分析パイプラインの構築
  • Azureは手作業 → ほぼ使わないので問題なし

各クラウドに合った言語・ツールを使う方が、実は長期的には保守しやすいんです。

3. ドキュメント「こそが資産」という割り切り

マルチクラウド環境では、コード以上に「どのワークロードがどのクラウドで、なぜか」というドキュメントが重要です。

うちのチームのドキュメント構成：

📄 全社クラウド戦略 (quarterly review)
  ├─ AWSの役割・責務・SLA
  ├─ GCPの役割・責務・SLA
  ├─ Azureの役割・責務・SLA
  ├─ データフロー図（S3 → BigQuery）
  └─ コスト分析・最適化案

このドキュメントを3ヶ月ごとに見直すことで、無駄なサービスや冗長な構成が可視化されます。「このサービス、まだ使ってるのか」という会話が自然に生まれるんですよね。

2026年時点で「マルチクラウド」は本当に必要か

ここからは個人的な意見ですが：

「完全なマルチクラウド」を目指す企業は、ほぼ失敗すると思います。

理由をまとめると：

  1. 各クラウドプロバイダが相互運用性を意図的に制限している → ベンダーロックインを避けることは理論的に困難
  2. チームのオーバーヘッドが大きすぎる → 複数クラウドの深い知識を持つ人材は稀で、採用が難しい
  3. 実運用ではセカンダリクラウドは死ぬ → メインクラウドが安定していると、セカンダリクラウドの検証・保守が疎かになる傾向がある

むしろ、**「メインクラウド1個 + 特定の高価値サービスのためだけにセカンダリクラウド」**という割り切り方が、2026年時点での現実解だと感じます。これなら、責任も明確で、チームの負担も少ないんです。

まとめ

マルチクラウド戦略で月30万円無駄にした経験から、以下のことが分かりました：

  1. マルチクラウドは「戦略」ではなく「責任」

    • メインクラウドの選択と集約が、全ての判断基準になる
    • セカンダリクラウドは限定的なユースケースに絞るべき

  2. コスト可視化がマルチクラウド運用の鍵

    • 各クラウドのコストを定期的に分析
    • セカンダリクラウドがビジネス価値を生んでるか検証

  3. チームスキルの分散を避ける

    • クラウド担当を明確に分ける
    • IaCの「統一」よりも「ドキュメント」を優先

  4. 現実的な判断基準を作る

    • 漠然とした「複数ベンダ戦略」は捨てる
    • ビジネス要件に基づいた具体的な根拠が必須

マルチクラウド導入を検討してる組織があれば、まずは「本当にセカンダリクラウドが必要か」「セカンダリクラウドで何を得たいのか」を明確にしてから検討することを強くお勧めします。

うちのチームは今後、AWS基盤を強化しつつ、GCPのBigQueryとVertex AIだけに絞った「戦略的マルチクラウド」を継続する方針です。完全なマルチクラウドで複雑さを増すより、シンプルで実行性高い構成の方が、長期的にはビジネス価値が大きいと気づきました。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

クラウド・インフラ

マルチクラウド戦略2026|最適構成とベストプラクティス

クラウド・インフラ

月額500万円の請求書を見て動いた。AWS費用を30%削減した3ヶ月の実装記録

クラウド・インフラ

DynamoDB2年本番運用で痛感した、Single Table Designの本当の使い所

クラウド・インフラ

「ローカルでは動いたのに」が消えた日——BuildKit 2026年版でチーム開発が変わった話

クラウド・インフラ

Terraformで3年分の失敗から学んだ、State管理とAI検証の正解

クラウド・インフラ

EKS3年運用で月120万円の請求を半減｜Kubernetes本番の痛すぎる失敗と対策

← 記事一覧に戻る