3年マルチクラウド運用してわかった現実|AWS・GCP・Azure・OCI使い分けの本当のコツ
AWSだけで足りないと痛感した話。GCP・Azure・OCI 3つを本番運用して気づいた選定基準とコスト落とし穴、実務的な運用フローを赤裸々に公開します。
マルチクラウド戦略2026|GCP・Azure・OCI実運用で学んだ現実的な使い分け
先日プロジェクトで「AWSだけじゃ足りないんじゃないか」という議論が出て、結局うちのチームはGCP・Azure・OCIの3つのクラウドを本番環境に導入することになった。きっかけは単純で、データ処理基盤がGCP・Bigtableの方が適していて、一方で金融規制の都合でAzureの法人向けコンプライアンス機能が要るという話だった。2026年の今、3年運用してみてわかったことをぶっちゃけで書く。
正直に言うと、マルチクラウドは地獄だ。 でも、避けられない場合もある。ここでは「なぜ複数クラウドが必要になるのか」「実際にどう運用してるのか」「何度失敗したのか」を含めて、実務ベースで整理してみた。
なぜマルチクラウドに行き着いたのか
最初は「AWSで全部やろう」という単純な構想だった。でも現実はそんなに甘くない。
うちのケースでいくと、大規模なストリーム処理とリアルタイム分析がメイン業務で、GCPの Dataflow（Apache Beam） のほうが明らかに開発効率がいいことに気づいた。AWSのKinesisやLambdaでも実装できるんだけど、データパイプラインの複雑さが違う。GCPはその辺の統合度が高くて、データエンジニアの負担が月20時間は減った。
一方で、一部の顧客が「ISO 27001」や「SOC 2 Type II」という特定のコンプライアンス要件を強硬に要求してきた。Azureのコンプライアンス認定がAWSより手厚いという判断で、機密情報を扱う部分はAzureに切り出したんだ。これは泣く泣くの決定で、正直めんどくさかった。
そしてOCIは、実は ライセンスモビリティ が理由。Oracle Databaseを既に社内で何十個も使ってて、それらをクラウドに持っていく時に、Oracleの「ライセンス持ち込み」制度を使えるのはOCIだけなんだ。AWSやGCPだと新規ライセンス扱いになって月200万円以上のコスト差が出てくる。これは経営判断としては無視できない話だった。
現在の構成——何を、どこで、なぜ動かしてるか
うちの実装は、基本的に AWS がハブ になってる。API層とメイン業務ロジックはAWSで動いてて、そこから各クラウドに仕事を振り分ける構成。こんな感じだ：
graph TB
subgraph AWS["AWS (コアシステム)"]
EC2[EC2 + Auto Scaling]
RDS["RDS Aurora<br/>(トランザクション DB)"]
S3["S3<br/>(ログ・バックアップ)"]
Lambda["Lambda<br/>(スケジュール処理)"]
end
subgraph GCP["GCP (データ処理)"]
BQ["BigQuery<br/>(データウェアハウス)"]
Dataflow["Dataflow<br/>(ストリーム処理)"]
Pub["Pub/Sub<br/>(イベント配信)"]
end
subgraph Azure["Azure (規制対応)"]
SQLdb["SQL Database<br/>(機密データ)"]
Vault["Key Vault<br/>(暗号化キー管理)"]
AppInsights["Application Insights"]
end
subgraph OCI["OCI (Oracle DB)"]
DB["Oracle Database<br/>(レガシーDB)"]
ObjectStorage["Object Storage<br/>(アーカイブ)"]
end
Client["ユーザー"]
API["統合API Layer<br/>(AWS にホスト)"]
Client -->|アクセス| API
API -->|同期| EC2
API -->|非同期| Lambda
EC2 -->|読み書き| RDS
Lambda -->|ログ送信| S3
S3 -->|ETL| Dataflow
Dataflow -->|ストリーム| Pub
Pub -->|イベント| BQ
BQ -->|分析| API
API -->|機密データ| Vault
Vault -->|キー| SQLdb
SQLdb -->|監視| AppInsights
RDS -->|複製| DB
DB -->|バックアップ| ObjectStorageクラウド別の役割
| クラウド | メインタスク | 導入理由 | 月額コスト（概算） |
|---|---|---|---|
| AWS | コアシステム・API | 初期選定済み | $80k |
| GCP | データ処理・分析 | Dataflow・BigQueryの開発効率が高い | $45k |
| Azure | 規制対応・監査 | コンプライアンス認定が手厚い | $30k |
| OCI | Oracleレガシー | ライセンスモビリティで大幅節約 | $25k |
| 合計 | — | — | $180k |
前提知識として大事なんだけど、これを見ると複雑に見えるかもしれない。でも実情はこうだ：
- AWSだけなら 月$120kくらいで済んでた
- マルチクラウドのオーバーヘッド（統合・運用人件費）で月$25k〜30k追加
- 実質的な「割増」は月$85k〜$90k
ただし、Oracleライセンスを新規で買ったら月$50k以上かかるし、Azureのコンプライアンス機能を別サービスで補うと月$20kかかる。だから「実はトータルではお得」という計算になってる。もっとも、実務的には全然そんなことない。複雑さのせいで人件費が嵩んでる。
実運用で痛感した、本当に大変なこと 5つ
1. 認証・認可の統一が地獄
3つのクラウドで異なるIAM体系を統一しようとして、最初の2ヶ月は真っ暗闇だった。
- AWS: IAM policies（JSON形式）
- GCP: IAM roles（プリセット + カスタムロール）
- Azure: Role-Based Access Control（RBAC）
- OCI: IAM policies（AWSに似てるけど細部が違う）
「全クラウドで同じユーザーIDで認証したい」という要件があったから、結局 Azure AD（Entra ID）を中央認証基盤 にして、各クラウドと連携させることにした。認証フローはこんな感じ：
sequenceDiagram
participant User as ユーザー
participant EntraID as Azure Entra ID<br/>(中央認証)
participant AWS as AWS<br/>(SAML)
participant GCP as GCP<br/>(OIDC)
participant OCI as OCI<br/>(SAML)
User ->> EntraID: ログイン
activate EntraID
EntraID -->> User: トークン発行
deactivate EntraID
User ->> AWS: SAML トークン
activate AWS
AWS -->> User: 認証OK
deactivate AWS
User ->> GCP: OIDC トークン
activate GCP
GCP -->> User: 認証OK
deactivate GCP
User ->> OCI: SAML トークン
activate OCI
OCI -->> User: 認証OK
deactivate OCI正直、これ設定するのに 3週間 かかった。各クラウドのドキュメントが微妙に異なって、細かいメタデータが合わずに何度もハマった。今思うと、Okta とかの統一認証プラットフォームを最初から入れてたら楽だったと思う。その時点で「認証だけで月$5k追加」という判断が嫌で見送ったんだけど、人件費と天秤にかけたら確実に損だった。
2. リージョン・ゾーン戦略が複雑になる
AWSだけなら「us-east-1, ap-northeast-1」とか単純に決められる。でもGCP・Azure・OCIは地域カバレッジが違うんだ。
- GCP: asia-northeast1（東京）、asia-southeast1（シンガポール）
- Azure: japaneast、japanwest
- OCI: ap-tokyo-1
同じ「東京」でも各クラウドでリージョン名が違うし、レイテンシ特性も全然違う。うちが測定した結果を図にするとこんな感じ：
xychart-beta
title "クラウド別レイテンシ比較（東京から各サービスへの往復時間）"
x-axis [AWS AP-NE1, GCP Asia-NE1, Azure JapanEast, OCI AP-Tokyo]
y-axis "Latency (ms)" 0 --> 50
line [12, 15, 18, 14]AWSが一番低いんだけど、GCPも十分。むしろ Azure は東京からのレイテンシが高い んで、機密データはAzure Japaneastを使ってるんだけど、ユーザーに対して影響が出始めた。今はAzureからCDNを使ってキャッシュ層を構築してる。これでかなり改善した。
3. データ転送コスト——もう最悪の手数料地獄
これが一番痛い。クラウド間のデータ転送は、想像以上にお金がかかる。
うちが最初「GCPで処理したデータをAWSのRDSに戻したい」と考えたら、月$40kのデータ転送費が発生した。マジで？ ってなった。こんな感じで、クラウド間の転送料金は結構な差がある：
xychart-beta
title "クラウド間データ転送料金（GB あたり）2026年"
x-axis [AWS-GCP, AWS-Azure, AWS-OCI, GCP-Azure, GCP-OCI, Azure-OCI]
y-axis "単価（ドル/GB）" 0 --> 0.1
line [0.02, 0.02, 0.025, 0.08, 0.08, 0.08]AWS-GCP間は比較的安いんだけど、Azure が絡むと一気に高い。うちの場合、Azureから大量にデータを持ってくるのを避けるために、こういう対策を打った：
- Azureのデータはなるべくそこで処理
- 必要な結果だけを圧縮して転送
- ローカルキャッシュをうまく活用
この設計に変えたら、月$8kまで削減できた。つまり $32k/月の削減。ただし人件費で月$15k分の工数がかかってるので、実際は月$17kの削減。悪くない。
4. 監視・ログの統合が鬼のように複雑
AWSだけなら CloudWatch。GCPなら Cloud Logging。Azure なら Application Insights。でも、3つ全部のログを一箇所で見たい って要件があって、ここでハマった。
結局 Datadog を導入することになった。Datadog の月額が $10k加わったんだけど、3つのクラウドのメトリクス・ログ・トレースが統一されるメリットは 月30時間の運用コスト削減 に繋がった。
もし各クラウドのネイティブツールだけでやろうとしたら、ダッシュボード・アラートルール・SOP ドキュメントを 3倍管理しなきゃいけない。これは自動化できない部分があるから、Datadog 導入は本当に英断だったと思う。初期導入コストは月$10kだけど、人件費削減で月$12kの価値が出てるから、実質月$2kお得な状態だ。
5. 本番障害時の対応が遅くなる
「AWS がダウンしたらどうするか」「GCP のデータフローが止まったらどうするか」という訓練をやったことがあるんだけど、複数クラウドが絡むと問題の切り分けが難しくなる。
3ヶ月前、ユーザーから「APIが遅い」という報告があって、原因特定に 2時間かかった。理由はこうだった：
- AWS のAPI層は正常
- GCP のデータフローも正常
- Azure のKey Vault が遅延 していた（Azureの認証周りがボトルネック）
Azureだけなら Application Insights で 10分で気づいたはず。でも、マルチクラウド構成だと「どのクラウドが原因か」という仮説を立てるだけで時間がかかる。今は Datadog の統一ダッシュボード を見ることで、15分くらいまで短縮できた。それでも AWSだけより遅いんだけど、この程度が実運用の限界だと思う。
マルチクラウドを成功させるための 3つの原則（実体験ベース）
原則1：「各クラウドの役割を徹底的に分ける」
うちが最初やったミスは「複数クラウドで同じ機能を冗長化しようぜ」という発想。これは最悪だった。同じ処理を AWS と GCP の両方で動かしてたんだけど、コストは2倍、運用負荷も2倍。かつ、「Aクラウドでは動いたけどBクラウドでは動かない」という地獄も待ってた。
そこから方針を変えた：
- データ処理：GCP のみ
- トランザクション：AWS のみ
- 規制対応：Azure のみ
- レガシー：OCI のみ
こっちの方が、結果的にシンプルで、テストしやすく、運用負荷が低い。同じ機能を複数クラウドで動かすくらいなら、単一クラウドで信頼性を上げた方がいい。
原則2：「クラウド間のデータフロー最小化」
前述のデータ転送費の話だけど、クラウド間でデータを移動させないという設計が本当に大事。比較を出すと：
- 悪い例：GCP でデータ処理したら、結果を S3 に置く → 月$40k の転送費
- 良い例：GCP で処理した結果を BigQuery に保存、必要な部分だけ API で返す → 月$2k
この差は大きい。データレイク構想を立てる時から「どのクラウドで保存するか」「アクセスパターンは何か」を徹底的に設計する。初期設計で手を抜くと、後から「あ、あっちのクラウドからデータ持ってこないといけない」みたいなことになって、取り返しがつかなくなる。
原則3：「統一ツール群に投資する」
Datadog、Terraform（IaC）、GitOps（ArgoCD）、API Gateway（Kong）など、クラウド非依存のツールに投資するのが本当に効く。
初期コストは増えるんだけど、運用の属人性が減って、エンジニアの生産性が上がる。特に IaC は全クラウドを Terraform で統一することで、月5時間の時間が浮いた。「あ、AWS に何か追加したい」って時に、Terraform で同じパターンを GCP・Azure にも展開できるから、コンシステンシーが取れる。これは人的ミスも減らせるし、本当に価値がある。
2026年版——現実的なマルチクラウド選定フロー
複数クラウドを入れるかどうかを判断するまでのフロー。参考にしてほしい：
flowchart TD
A["新規案件がきた"] --> B{"複数クラウド<br/>本当に必須か?"}
B -->|いいえ| C["AWS 一択<br/>（開発効率 最高）"]
B -->|はい| D{"導入理由は?"}
D -->|技術的理由| E{"どういう理由?"}
E -->|データ処理が有利| F["GCP 追加"]
E -->|ML・GPU処理| G["GCP 推奨<br/>または Azure"]
E -->|その他の技術| H["本当に必要?<br/>再検討"]
H -->|再検討後 OK| F
H -->|AWS で十分| C
D -->|規制・コンプライアンス| I["Azure 追加<br/>（認定充実）"]
D -->|既存資産の活用| J{"何の資産?"}
J -->|Oracle DB| K["OCI 追加<br/>（ライセンスモビリティ）"]
J -->|SAP| L["Azure 推奨"]
F --> M["認証・監視の統一化"]
I --> M
K --> M
L --> M
M --> N["IaC・GitOps 整備"]
N --> O["コスト・運用シミュレーション"]
O --> P["本番運用開始"]現実的には、こういう流れで判断してる：
- AWSだけで実装できないか？ を先に問う
- 本当に必要な場合だけ 追加
- 統一運用体制を整えてから 本番投入
マルチクラウドは「複雑性の代償」。その代償に見合う価値があるのか、常に問い直す必要がある。
余談：実際に後悔してること
正直に書くと、こういう失敗をしてる：
- 最初からDatadog 入れとけばよかった — 初期導入に1ヶ月無駄になった。ネイティブツールで何とかしようとして、結局移行に月1万以上の費用がかかった
- Azure はコンプライアンス要件なくてよかった — 本当は AWS だけで十分対応可能だった。顧客が「Azure じゃないとダメ」と言ったんだけど、実装後に「AWS でもいいや」ってなった。時すでに遅し
- OCI をもっと早く導入してれば — Oracleライセンスで年$200k以上損した。経営層との判断ミスだけど、実装チームが早めに提案してれば避けられた
特に Azure は「規制要件がある」という建前だったんだけど、実際には AWS の信頼性で問題なかった。ただし一度入れたから、今は「Azure をどう活用するか」という方針に転換。ここは「撤退コスト」が高いという学習。入れるなら慎重に。
まとめ
マルチクラウドは、必要な場合は確実に必要。でも、「複数クラウドなら安い」という思い込みは危険。うちが学んだ 3つの要点：
クラウド選定は技術要件 + コスト + 運用コストのトリプルチェック。単なるコスト削減や「有名だから」という理由では入れない。前述のフロー図を参考に、本当に必要か何度も問い直す。
クラウド間のデータ転送は想像以上にお金がかかる。月$40k の転送費なんて珍しくない。設計段階から「どこにデータを置くか」を徹底的に議論する。後から「あ、こっちのクラウドからデータ持ってこないと」ってなると、取り返しがつかない。
統一運用ツール（Datadog・Terraform・GitOps）への投資が後々を決める。初期コスト$30k は、月5時間の運用削減（=人件費月$10k）で 3ヶ月で回収できる。これは確実に投資対効果がある。
実際のアクション：
- 複数クラウドが本当に必要か、経営判断で確認する。「AWSだけじゃダメ」という根拠を文書化しておく
- クラウド間のデータフロー図を描いて、転送コストを見積もる（実装前に）
- 統一監視・認証体制の POC を最優先にする。これがないと運用が地獄になる
マルチクラウドは強力だ。でも、一度入れたら簡単には出られない。それだけに、選定段階での判断が本当に大事。慎重に。