こんにちは。shuheiです。
「為替変動や利用量の増加により、クラウドの月額請求額が年々膨らんでいる…」そのような悩みを抱えてはいないでしょうか。特に、同じクラウド事業者で長年システムを動かしてきた場合ほど、気づかないうちに割高な構成のまま運用が続いていることが多くあるのではないかと思います。
こうした状況に対しては、不要なリソースの整理、契約・料金プランの見直し、キャッシュ設計の改善など、さまざまな打ち手があります。その中でも、ワークロードによっては有効な選択肢になるのが、特定のクラウド事業者に依存せず、複数の事業者を組み合わせて使う「マルチクラウド」という考え方です。今回は、実際に大規模なインフラ移行を通じてコスト削減を実現した事例をもとに、その考え方と進め方をご紹介します。
マルチクラウドとは何か
マルチクラウドとは、AWS・GCP・Azure・OCI・Cloudflareといった複数のクラウド事業者のサービスを、目的に応じて組み合わせて利用する構成のことです。1社のサービスに全面的に依存する「シングルクラウド」と対比される考え方で、大きく3つの狙いがあります。
1つ目は、サービスごとに得意な事業者を選ぶ「適材適所」の発想です。計算処理は使い慣れたクラウドに残しつつ、ストレージやコンテンツ配信だけをよりコスト効率の良い事業者に切り出す、といった組み合わせが可能になります。
2つ目は、障害耐性を高める「冗長化」の発想です。適切に設計すれば、特定事業者の障害がサービス全体を止めるリスクを下げられます。
3つ目は、特定ベンダーへの依存(ロックイン)を避け、コスト構造そのものを見直す発想です。
今回ご紹介する事例は、Webアプリケーションやデータベースといった「本体」はAWSに残しつつ、画像・ファイルの配信基盤だけをコスト効率の良いCloudflareに切り出すという、1つ目の「適材適所」に近い組み合わせ方をとっています。
事例:AWSからCloudflareへ、ブログサービス配信基盤のコスト最適化
私が携わったあるブログサービスの事例です(多数の画像・ファイルを配信する規模の大きいブログサービスでした)。
このサービスでは、画像・ファイルの配信基盤(CDN + オブジェクトストレージ)として、長年AWSの「CloudFront + S3」構成で運用していました。ストレージ容量とアクセス数の増加、そして急激な円安の影響も重なり、特にデータ転送(エグレス)にかかる費用が年々重くのしかかる構造になっていました。そこで、ブログ本体のWebアプリケーションやデータベースはこれまでどおりAWS上で稼働させたまま、変更対象を画像・ファイルの配信基盤だけに絞って見直すことにしました。
移行先には「Cloudflare R2 + Workers」構成を選びました。Cloudflareはエグレス費用がかからないオブジェクトストレージ(R2)と、CDNのエッジでプログラムを実行できるサーバーレス環境(Workers)を提供しており、画像・ファイル配信のようなトラフィック量の多いワークロードとの相性が良い選択肢でした。
この移行を実現できた背景には、サービスのURL設計にもありました。ユーザーが作成したブログ本文のURLと、ストレージから読み込む画像・ファイルの配信ドメインが分かれていたため、ブログ本体のアプリケーションやURL構造を大きく変えずに、画像・ファイル配信基盤だけを別の事業者へ移すことができました。
ただし、全体を一気に切り替えるのではなく、次のようなステップを踏んで進めました。
現状の棚卸しとリスク評価：どのデータ・機能をどこまで移行するか、コストと移行リスクの両面から優先順位をつけました。
並行稼働による安全な移行：アプリケーション側からS3とR2の両方に書き込む「ダブルライト」の仕組みを実装し、サービスを止めずに全データを段階的にコピーしていきました。
移行中のコスト監視：S3からR2へのデータコピー中、移行用サーバーの通信経路の設計によってはAWS側の想定外の課金(NAT Gateway経由の通信費用など)が発生することも分かり、日次でコストを確認しながら通信経路や作業量を調整しました。
整合性チェックと切り戻し設計：CloudFrontとWorkers双方から同じファイルを取得しレスポンスを比較する検証を行い、コピー漏れがないかを確認したうえで、万一問題が起きてもDNSをCloudFrontに戻せる状態を保ちながら本番切り替えを行いました。
この結果、配信にかかるインフラコストを大きく圧縮しながら、サービス停止を伴わない移行を実現しました。移行後もしばらくはS3とR2への書き込みを並行させ、安定稼働を確認したうえで旧基盤(CloudFront・S3)を段階的に廃止しています。
料金モデルで見るコスト差(試算例)
コスト差のイメージをつかんでいただくために、簡易な試算モデルを用意しました。条件は、ストレージ500GB、月間の配信リクエスト数1億件です。これは比較用に置いた仮の数字で、実際のプロジェクトの数値ではありません。画像・ファイルの平均サイズを200KB、月間のデータ転送量を約19.2TBと仮定し、各社の公開料金表(2026年7月時点、東京/APACリージョン想定、1ドル=162円換算)をもとに月額費用を試算しています。AWS側は、CloudFrontの従量課金ではなく、今回の条件が月間利用枠に収まるCloudFront Business定額プラン(月額$200)を使える前提で見ています。
料金は、リクエストの種類ごとに分けて数えています。
- 配信リクエスト(エンドユーザーからのアクセスを捌く分):1億件
- オリジン取得リクエスト(キャッシュに載らず、S3やR2まで取りに行く分):1,000万件(キャッシュヒット率90%を想定)
- 書き込みリクエスト(ユーザーの画像アップロード分):100万件
Workers側は、キャッシュヒット時のCPU時間が小さい軽量な処理を前提にしています。
| 項目 | AWS(CloudFront Business定額プラン + S3) | Cloudflare(R2 + Workers) |
|---|---|---|
| ストレージ(500GB) | 定額プラン内(1TBまで) | 約$7.5(約¥1,200) |
| エッジでの配信リクエスト処理(1億件) | 定額プラン内(1.25億件まで) | 約$32.0(約¥5,200) |
| オリジン取得リクエスト(キャッシュ未ヒット分、想定1,000万件) | 約$4.0(約¥650) | 約$3.6(約¥580) |
| アップロード(書き込み)リクエスト(想定100万件) | 約$5.0(約¥810) | 約$4.5(約¥730) |
| データ転送(エグレス、約19.2TB) | 定額プラン内(50TBまで) | $0(エグレス無料) |
| 定額プラン月額 | 約$200.0(約¥32,400) | - |
| 月額合計(概算) | 約$209.0(約¥33,900) | 約$47.6(約¥7,700) |
この定額プランを使える前提の試算では、AWS側のエグレス費用は定額プラン内に収まるため、従量課金で比較した場合ほど極端な差にはなりません。それでも月あたり約$161(約¥26,100)の差が生じる計算になります。R2にはエグレス費用がかからないため、配信量が増えても転送量に比例して費用が増えにくい点が効いています。
なお、これはあくまで公開料金表ベースの単純化した試算です。実際の請求額は、書き込み(PUT)リクエスト数、リージョン、キャッシュヒット率、WorkersのCPU時間などによって変動します。また、CloudFront定額プランは含まれる機能、利用上限、既存ディストリビューションへの適用可否などの条件確認が必要です。反対にCloudflare側も、取扱データ量やサポート要件によってはEnterprise向けの個別契約プランが必要になるケースがあります。弊社が移行のご提案をする際は、必ずお客様固有の利用状況をヒアリングしたうえで、利用できるプランや契約条件を含めて試算します。
複数クラウドを組み合わせる利点と注意点
クラウド事業者ごとに、計算・ストレージ・データ転送それぞれの料金体系や強みは大きく異なります。特にデータ転送費用は事業者間の価格差が大きく出やすい領域で、配信量の多いシステムほど、事業者を組み合わせることで削減の余地が大きくなる傾向があります。
そして、見落とされがちなのが、同じ事業者を使い続けること自体のコストです。契約や運用フローが固定化されるほど、料金改定や為替変動の影響をそのまま受けやすくなり、価格交渉の材料も持ちにくくなります。1社に固定しないこと自体が価格交渉力になり、定期的に他の選択肢と比較検討できる状態を保っておくことが、中長期的なコスト耐性につながります。
一方で、複数事業者を組み合わせる移行は、データ整合性の担保やコスト監視、切り戻し設計など、相応の設計・運用ノウハウが求められる取り組みでもあります。段取りを誤ると、かえって一時的なコスト増や障害リスクを招く可能性もあるため、計画的な進め方が欠かせません。
また、マルチクラウド化はどのシステムでも同じように実現できるわけではありません。アプリケーションのURL設計、画像やファイルの参照方法、認証・Cookie・セッションの扱い、管理画面やバッチ処理との結びつきによっては、単にストレージやCDNを置き換えるだけでは済まず、大幅なアプリケーション改修が必要になる場合があります。今回の事例では、ブログ本文のドメインと画像・ファイル配信ドメインが分かれていたため、配信基盤だけを比較的独立して移行できましたが、同じ前提がすべてのWebシステムに当てはまるわけではありません。
データ転送料を抑える業界の動きと選択肢
複数事業者を組み合わせるという選択肢は、クラウド業界全体の潮流としても後押しされています。Cloudflareが主導する「Bandwidth Alliance」という枠組みでは、Microsoft Azure、Oracle、IBM、DigitalOceanなど複数のクラウド・ネットワーク事業者が、Cloudflareとの間のデータ転送(エグレス)費用を割引・無料化しています。
具体例として、CloudflareとOracle Cloud Infrastructure(OCI)の組み合わせでは、Cloudflare経由でOCI Object Storageを利用する場合にエグレス費用をゼロにできる取り組みがあります。これは、CloudflareとOracleのネットワーク間をプライベート接続やピアリングで結び、Cloudflare経由でユーザーへ配信することで、相互利用する顧客のデータ転送料負担を下げるものです。
ただし、こうした取り組みは北米を中心としたグローバルな動きとして紹介されることが多く、日本国内の案件でそのまま同じ条件を利用できるとは限りません。対象となる事業者、リージョン、通信経路、契約形態によって適用条件が変わるため、実際に複数事業者を組み合わせる際には、各社の最新条件を確認したうえで設計・試算する必要があります。
一方で、日本国内で利用する場合でも、データ転送料の負担を抑える選択肢は増えています。たとえばCloudFrontには定額料金プランが用意されており、条件に合えば配信量の多いサイトでも月額費用を読みやすくできます。OCIも日本/APACを含む外向きデータ転送について、月間10TBまで無料枠を設けています。また、Cloudflare R2のようにエグレス費用をかけない設計のストレージサービスを組み合わせる方法もあります。
さらに、OCIではCloudflare@OCIとして、OCIの公開Webサイト、API、Object Storageなどの前段にCloudflareを組み合わせる公式な選択肢も出てきています。これは単なる転送料割引だけでなく、WAF、DDoS対策、CDN、キャッシュ、Bot対策などをエッジ側でまとめて扱える点も特徴です。日本では、事業者間の大規模な無料化連携が広く一般化しているというより、こうした各社の料金体系、公式連携、配信基盤の選び方を組み合わせて、転送料や運用負荷の影響を抑えていく考え方が現実的です。
クラウドコストの課題を解決します
同じクラウド事業者を長年使い続けている、データ転送量やストレージ費用が年々増加している、レガシーシステムのインフラ刷新を検討しているものの何から手をつければよいか分からない。このような課題をお持ちであれば、一度現状のインフラ構成とコスト構造を棚卸しすることをおすすめします。
私たちは、こうした大規模インフラ移行を安全かつ段階的に進めるノウハウを持っています。「今の構成のままで本当に最適なのか」を診断するところからでも構いません。まずはお気軽にご相談ください。