要点
- ストレージクラス、egress料金、APIリクエスト料金、クラス間移行コストはそれぞれ独立した課金レイヤーです。GB単価はあくまで出発点にすぎません。
- AWS S3 Standardは月額約23ドル/TB、Glacier Deep Archiveは約1ドル/TB。この価格差が活きるのは、ライフサイクルポリシーがデータを正しく振り分けたときだけです。
- マルチクラウド環境では、egressが最大の変動コストになるケースが少なくありません。リージョン間レプリケーションやプロバイダー間転送の費用は、あっという間に膨らみます。
- インテリジェントティアリング(S3 Intelligent-Tiering、GCP Autoclass)は、アクセスパターンが読みにくいworkloadsに向いています。パターンが安定したworkloadsなら、手動のライフサイクルルールのほうが削減効果は大きくなります。
- リアルタイムの異常検知なら、暴走したジョブや誤設定のポリシーを予算問題になる前に押さえられます。月次の請求書レビューでは、いつも後手に回ります。
複数のプロバイダーにデータを置き始める時点で、多くのチームはクラウドストレージのコスト感をある程度つかんでいます。AWS、Azure、Google CloudのGB単価は簡単に比較できますが、実際の請求額はストレージ単価だけでは決まりません。egress料金、APIリクエスト料金、ストレージクラスの移行コスト、データ取り出し料金が積み重なり、その全貌は請求書が届くまで見えてこないことも珍しくありません。リアルタイムに状況を把握する仕組みがなければ、こうしたコストは数か月にわたって静かに膨らんでいきます。
本記事では、マルチクラウドストレージにおける主要なコスト要因を整理し、AWS、Azure、Google Cloudの料金体系の違いを比較したうえで、支出を実際に抑え込むための戦略を解説します。
クラウドストレージのコストは何で決まるのか?
ストレージの課金には4つの異なるレイヤーがあります。これらが絡み合うため、GB単価だけから総額を見通すのは現実的に困難です。
ストレージクラス
多くのチームが過剰に支払っている根本原因は、データが適切でないティアに置かれていることです。主要クラウドはいずれも、アクセス頻度に応じて価格設定された複数のストレージクラスを用意しています。AWSであればホットデータ向けのS3 Standard、長期保管向けのGlacier Deep Archive、その間にいくつかのティアがあります。Google Cloud StorageとAzure Blob Storageも同様の構成です。
ティア間の価格差は大きく、S3 Standardでの1TBが月額約23ドルなのに対し、Glacier Deep Archiveに移せば約1ドルまで下がります。とはいえ、この削減効果はデータが適切なティアに振り分けられて初めて得られるものです。実際の現場では、バックアップが何か月もプレミアムストレージに残ったまま、誰も触らないログファイルが1年もStandardに居座り、災害復旧用のコピーが本番データと同じ高額なティアに置かれている、といった事態が頻繁に起きています。
データ転送とegress料金
クラウドプロバイダーは受信(in)側のデータ転送には課金しません。ただし、大規模なデータ取り込みには人件費、ツール、APIの書き込みリクエストといった実コストが伴います。一方、データを送り出す(out)操作はプロバイダー側で課金されます。egress料金は、リージョン間、プロバイダー間、あるいはインターネットへデータが転送されるたびに発生します。
マルチクラウド環境では、こうした料金が短期間で積み上がります。AWSからAzureへデータを複製する災害復旧構成では、計画段階で見積もりを誤りやすい転送コストが継続的に発生します。クラウドストレージから大規模データセットを取り出して別環境で処理する分析ワークフロー、複数の地域にいるユーザーへファイルを配信するコンテンツ配信パイプラインでも、同じ問題が生じます。
APIおよびリクエスト料金
規模が大きくなると、APIリクエスト料金は無視できない明細項目になります。クラウドストレージのバケットへの読み取り、書き込み、リスト、削除はいずれも、課金対象のAPI呼び出しを生みます。1リクエストの単価は1セントの数分の一とごくわずかですが、移行作業、バッチ処理ジョブ、災害復旧テストでは、1請求期間に数百万件規模に達することもあります。
不要なLISTやGETを大量に発行する最適化されていないバックアップジョブは、誰も気づかないうちに数百~数千ドル規模のリクエスト料金を生む可能性があります。1リクエスト単位では目立ちませんが、ジョブ全体で集計したときに初めて問題として浮かび上がるのです。
運用オーバーヘッド
マルチクラウドストレージには、どのプロバイダーの請求書にも載らない「管理コスト」があります。利用状況のモニタリング、ライフサイクルポリシーの設定、請求書のレビュー、異常の調査、アカウント横断の調整──いずれもエンジニアの工数を消費し、しかもクラウドが増えるほど膨らんでいきます。
各プロバイダーは独自のツール、ダッシュボード、請求フォーマットを持っています。この分断によって全体像が見えにくくなり、ムダが蓄積しやすくなります。自動化が弱く、明確なFinOpsの仕組みが整っていないチームでは、運用オーバーヘッドこそマルチクラウドストレージにおける最大の隠れコストになりがちです。
AWS、Azure、Google Cloudのストレージ料金を比較すると?
3社とも表面的なオブジェクトストレージの料金水準は近いものの、クラス間移行、egress、リクエスト料金には明確な違いがあり、複数のクラウドでworkloadsを運用するチームにとっては実利のある最適化機会が生まれます。
プロバイダー
標準ストレージ
アーカイブストレージ
egress(第1ティア)
アーカイブの最低保持期間
AWS S3
$0.023/GB
~$0.004/GB(Glacier Deep Archive)
~$0.09/GB
180日
Azure Blob
$0.018/GB(Hotティア)
~$0.002/GB(Archiveティア)
~$0.087/GB
180日
Google Cloud
$0.020/GB(Standard)
~$0.001/GB(Archive)
~$0.12/GB
なし
表示価格は2025年3月時点の米国リージョンのリスト価格です。予算を組む前に、AWS、Azure、Google Cloudの各料金ページで最新レートをご確認ください。
米国リージョンでアクセス頻度の高いストレージの場合、AWS S3 Standardは月額0.023ドル/GBから、Azure BlobのHotティアは0.018ドル/GB、Google Cloud Storage Standardは約0.020ドル/GBです。いずれも容量が増えるほど単価は下がります。
ストレージクラス間の移行料金はどう違うのか?
AWSは、ストレージクラス間で移行されるオブジェクト1,000件単位で課金します。小さなファイルを数百万件移すと、本来見込んでいたストレージ削減額を上回る費用が発生することすらあります。AzureとGoogle Cloudも同様の移行料金を、それぞれ異なる料金体系と最低保持期間のもとで課しています。
移行コストを織り込まずにデータをコールドティアへ移すライフサイクルポリシーは、結果として赤字を生みかねません。大規模なティア移行を自動化する前に、必ずオブジェクト数を踏まえて試算してください。
egress料金が高くつくのはどんなときか?
マルチクラウド運用の費用を押し上げる主因はegressです。同一プロバイダー内なら、同一リージョンでのサービス間転送は無料ですが、リージョン間レプリケーションや異なるリージョン間のサービス転送には必ず料金が発生します。
AWSとAzureは、ネットワーク外へ出るデータに対し、容量に応じて単価が下がる料金体系を採用していますが、月初の数TBがGBあたりの単価としては最も高く設定されています。Google Cloudは従来から、特定の転送タイプについて競争力のあるegress料金と手厚い無料枠を提供してきました。
災害復旧や分析のためにクラウド間でデータを動かすチームにとって、egressは請求書上で最大の変動コストになるのが常態化しています。マルチクラウド環境においてクラウドの財務計画が決定的に重要になるのは、まさにこの理由からです。
リクエスト料金はプロバイダーによってどう異なるのか?
APIリクエストのコストはプロバイダーやストレージクラスによって異なります。S3 StandardへのGETリクエストは1セントの数分の一ですが、Glacier Flexible Retrievalへの同じリクエストはそれを大きく上回ります。AzureとGoogle Cloudにもそれぞれ独自の料金カーブがあり、その差は移行、大規模なデータ処理、四半期末のレポート実行など、リクエスト量が一気に跳ね上がる場面で最も顕著になります。
DoiTのCloud Intelligenceプラットフォームは、AWS、Azure、Google Cloudのストレージコストを単一のビューに統合します。これにより、支出が集中しているポイントや、ティアの見直し・workloadsの調整で実効性のある削減が見込める箇所を、特定ベンダーのツールに縛られずに把握できます。
クラウドストレージコストの見積もりと削減の進め方
クラウドストレージの最適化は、一度きりの整理ではなく継続的な取り組みとして回したときに、持続的な削減効果を生みます。信頼できるベースラインを起点に、自動化できる部分は自動化し、定期レビューを組み込むことで、アクセスパターンの変化によって成果が静かに帳消しになるのを防げます。
明確なベースラインから始める
見えないものは最適化できません。何かを変える前に、月次の請求総額だけでなく、ストレージクラス、リージョン、workload別の支出までを完全に把握しましょう。
各プロバイダーはネイティブのコスト管理ツールを提供しています(AWS Cost Explorer、Azure Cost Management、Google Cloud Billing Reports)。マルチクラウド環境でこれらを手作業でつなぎ合わせても全体像は不完全になり、クラウドをまたぐパターンを取りこぼしがちです。多くのチームが、実際の利用プロファイルが当初のアーキテクチャ前提から大きくずれていることに気づきます。長く運用されてきたworkloadsでは、その傾向がとくに顕著です。
DoiTのCloud Analyticsは、3社すべての請求データを単一のビューに集約し、クラウド横断のストレージ比較を自動的に可視化します。このデータをストレージ利用率やムダに関するFinOps KPIと組み合わせれば、毎月請求書を目視で追いかける運用から脱却し、進捗を持続的に測定できるようになります。
ライフサイクルポリシーはどう設計すべきか?
ライフサイクルルールは、経過日数やアクセスパターンに応じてオブジェクトを安価なストレージクラスへ自動的に移し、保持期間を過ぎたら削除します。3大プロバイダーはいずれも対応していますが、正しく機能させるには、オブジェクトの実際の使われ方を反映した移行スケジュールを設定できる程度に、自社データを理解している必要があります。
ログデータ向けに適切に設定したライフサイクルポリシーは、たとえば次のようなものになります。
- 30日間読み取りがなければ、低頻度アクセスストレージへ移動
- 90日経過後にアーカイブストレージへ移行
- 定めた保持期限を過ぎたデータは削除
最も高くつくライフサイクルの失敗は、ポリシーが「ない」ことではなく、フィルターの設定ミスで既存ポリシーが発動しないことです。静かに壊れたままのルールが原因と判明するまで、オブジェクトは何か月もプレミアムストレージに溜まり続けます。
ライフサイクル設定の四半期レビューを、FinOpsのワークフローに組み込みましょう。アプリケーションの変化に応じてアクセスパターンも変わるため、1年前のデータには合っていたポリシーが、現在の読み取られ方には合わなくなっている可能性があります。
インテリジェントティアリングが効くのはどんな場面か?
インテリジェントティアリングは、アクセスパターンが本当に予測できないworkloadsで採算が合います。AWS S3 Intelligent-Tieringは、利用状況に応じてオブジェクトをアクセスティア間で自動的に移動し、ホットなティアに戻す際の取り出し料金は発生しません。Google CloudのAutoclassも同様の仕組みで、早期削除ペナルティなしにオブジェクトを移動します。AzureもSmart Tierとして同じアプローチを導入しましたが、2026年初頭時点ではパブリックプレビュー段階です。
ただし、これらの機能は無料ではありません。S3 Intelligent-Tieringはオブジェクト単位のモニタリング料金を、Google CloudのAutoclassは管理料金を上乗せします。アクセスパターンが予測可能なworkloadsであれば、手動設定のライフサイクルルールのほうが削減効果は大きくなります。一部のオブジェクトには定常的なトラフィックがあり、その他は何か月も触られない、といったように利用が混在する大規模バケットでは、インテリジェントティアリングが手探りの設計を不要にし、追加コストを十分に取り戻すのが一般的です。
圧縮と重複排除
圧縮と重複排除は、クラウドの料金計算が始まる前段階で、保存するデータ量そのものを減らします。多くのバックアップツールやデータパイプラインフレームワークは圧縮をネイティブにサポートしており、設定を1か所変えるだけで有効化できることがほとんどです。
重複排除が最も効くのは、複数のシステムが似たデータを別々の保存先に書き込んでいるケースです。バックアップやアーカイブのワークフローが重複している環境では、こうした冗長なコピーを特定して統合することで、保存量を30%以上削減できる場合もあります。
事後ではなくリアルタイムで監視する
月次の請求レビューでは、誰かが気づくまでの30日間、問題が膨らみ続けることになります。予期しないAPI呼び出しを数百万件も発生させる暴走移行ジョブや、データを高額ティアへ流し込む誤設定のライフサイクルポリシーは、月1回の請求チェックでは表に出ないまま数週間動き続けかねません。
DoiTのプラットフォームは、3大クラウドにわたるリアルタイムの異常検知と、自動化された最適化レコメンデーションを提供します。この継続的な可視性こそが、クラウドコストをコントロールできるチームと、後追いで対応するだけのチームを分ける決定的な要素です。
CloudOpsチームが見落としがちな隠れコストとは?
FinOpsの習慣がしっかり根づいているチームでも、決まって取りこぼしがちな3つのコストカテゴリがあります。いずれもプロバイダーのドキュメントには記載されていますが、無視できない金額になるまで予算会議の議題には上がってきません。
リージョン間のデータ転送
リージョン間レプリケーション料金は、1イベントあたりのコストが小さく見える一方で合計が膨らみやすく、多くのチームの不意を突きます。データセットの更新が頻繁だと、レプリケーションのたびにegress料金が発生し、アクティブデータの場合はストレージコストに匹敵することもあります。
AWSのリージョン間レプリケーションには2種類の課金が伴います。データ転送料金と、宛先リージョンでレプリカを書き込むPUTリクエスト料金です。多くのチームは初期デプロイ時にリージョン間レプリケーションを設定したまま、当初のビジネス要件が変わったり、データの重要性が薄れたりした後も放置しがちです。
移行時のAPI料金
ストレージクラス間、プロバイダー間、リージョン間で大規模な移行を行うと、ほとんどのコスト見積もりが想定していないレベルのAPIリクエスト量が発生します。数千万件規模の小さなオブジェクトを移行するケースでは、転送料金に加えて数千ドル規模のリクエスト料金が乗ってくる可能性があります。
サンプリングからの推計は、実コストを過小評価しがちです。移行の規模が大きくなるほど、データ量よりもAPI呼び出し量のほうが速く伸びるためです。大規模な移行に踏み切る前に、実際のオブジェクト数に基づくフルスケールのドライラン試算を行いましょう。
ストレージクラスの移行料金
移行料金は、コスト削減を狙ったライフサイクル移動を、結果としてコスト増に転じさせかねません。データをコールドティアへ移したあとに頻繁に取り出す運用が続くと、移行料金と取り出し料金の合計が、元のティアにとどめておいた場合のコストを上回ることがあります。
早期削除ペナルティもリスクをさらに大きくします。Glacierには90日、Azure Archiveには180日の最低保持期間があります。それより前に削除すれば、最低期間分は丸ごと支払うことになります。これらの最低期間は、ライフサイクルルールが想定より早くデータを削除対象ティアへ移した場合にも適用されます。
これら3つのコストカテゴリには共通のパターンがあります。多数の小さな明細に分散して少しずつ蓄積し、月次の請求レビューでは見えにくいのです。目立つスパイクとして表面化する頃には、すでに数週間にわたって膨らみ続けています。リアルタイム監視なら、これらを発生源で捕捉できます。
クラウドストレージ支出を主導権を持って管理する
マルチクラウドのストレージコストは、3つの要素を並行して動かしたときに、確実に管理可能な範囲に収まります。リアルタイムで異常を捕捉する継続的な監視、人手を介さずデータを正しく振り分ける自動化されたライフサイクル&ティアリングポリシー、そしてアーキテクチャ上の判断が請求結果にどう跳ね返るのかを明確に把握する仕組みです。
DoiTのCloud Intelligenceプラットフォームは、FinOpsチームとCloudOpsチームに、AWS、Azure、Google Cloudにわたるストレージコストの統合ビューと、3社すべてに対応する自動レコメンデーションを提供します。規律あるクラウド財務計画戦略と組み合わせれば、マルチクラウドのストレージコストを確実にコントロール下に置き、その状態を維持するための実用的な道筋になります。
もしストレージの請求額がデータの伸びを上回るペースで増えているなら、一度じっくり点検する価値があります。マルチクラウドのストレージ支出をリアルタイムに可視化し、コントロールする方法については、DoiTまでお問い合わせください。