実際、今後5年間に生成されるデータ量は約175ゼタバイト（1,750億テラバイト）に上ると見られており、その60%は、企業から生み出されることになります。ネットアップの計算では、3.5インチ フロッピー ディスク11京6,000兆枚分のデータに相当します（もし、『バック・トゥ・ザ・フューチャー』のタイムマシンに乗って1985年頃からやって来た人がこれを読んでいたら、この数字は大いに参考になることでしょう）。さらに興味深いのは、このデータの半分がパブリック クラウドに存在すると予想されることです。

それと同時に、データの生成元である組織では、多数のユーザがますます頻繁にデータを使用するようにもなるでしょう。データスフェア（これは実際にある用語です。検索してみてください）では、ユーザは約1分間に1回の割合でデータにアクセスしていると見られていますが、2025年には、その頻度が、18秒に1回になる見込みです。 

でも、慌てる必要はありません。皆様は上手に切り抜けられるはずです。実際、次の標準として何が来ようとも、データがビジネス成功のカギであることに変わりはありません。クラウドはビジネスに欠かせないツールであり、ビジネスでさらに役立てるには適切な戦略が必要です。このクラウド支出ガイドでは、皆様の行く手に待ち構えるデータの洪水を乗り切るための戦略をご案内します。

沈滞するデータセンターから平穏なクラウドへ

クラウドが登場するまで、組織では、CAPEX（設備投資）で大量のストレージを購入し、固定されたデータセンター エコシステムの中でそれを運用するのが当たり前でした。似たようなハードウェアに複数のデータ タイプが混在していたので、ストレージの割り当ては（本当にストレージが必要なのかどうかはさておき）大して難しいタスクではありませんでした。IOPSは使い放題、セキュリティはラスベガスのカジノのように水も漏らさぬ厳しさです。ストレージに関して、どんな気まぐれを起こしても、それに対応してくれるストレージ管理者チームが社内にいたのではないでしょうか。 

ところがその後、事態は行き詰まりを見せ始め、役所のような煩雑な手続きによって、すばやいリカバリが妨げられるという問題が出てきました。人々は、熱意に溢れた実習生が大量のスプレッドシートをじっくり調べてくれるように、もっと働いてくれるストレージを夢見るようになりました。 

その後、その夢はストレージのクラウド化というひとつの現実になりました。そして今、月々の運用コスト（OPEX）を支払うだけという手軽さと引き換えに、データセンター管理の複雑さから解放され、文字どおり、制限のない拡張性と柔軟性を手に入れました。素晴らしいことだと思いませんか？しかし、賢明な会計担当者ならおわかりだと思いますが、月末になるとこの運用コストが忍び寄り、利益はオアシスのようにゆっくり消えていきます。ストレージ関連の支出は、ストレージの種類、使用する階層、プロトコル、コストといった複数の要素で決まります。 

予想外のコストは、当然、最終的な収益を低下させます。原因は何でしょう。階層化されていないストレージ、プロビジョニングが解除されていない古い仮想マシン（VM）、不要なスナップショットなど、さまざまな要因が考えられます。残念ながら、クラウド化は夢見たように簡単には行きません。クラウド ストレージの最適化が目標であれ、クラウド ストレージをコスト効率よく使用する方法を模索しているのであれ、クラウド ストレージのコスト削減という飽くなきニーズがどこまでもついて回るのは間違いないでしょう。

ここからは、クラウドの支出に問題がある場合に点灯する5つの危険信号について見ていきます。その後、このページの目的である、抑えの効かないクラウド コストに文字どおり今日からすぐに対処できる10の方法を説明します。

この章をお読みになるということは、おそらく、クラウドに費用がかかりすぎという問題が組織にあるということでしょう。以下に示す状況が1つでも見られたら、クラウドの支出に問題があると考えて間違いありません。

01. 社内にパブリック クラウドのアカウントがいくつあるのか誰も把握していない

大企業には、複数のクラウド プロバイダのアカウントが複数あるのが一般的です。パブリック クラウドは、組織内の誰かがアカウントをセットアップしてリソースを割り当てる仕組みになっています。アカウント作成の知らせを一元管理していないと、支払いに関して決定権を持つ人物がアカウントを作成しても誰にもわからず、シャドウITのアカウントが社内の至る所に存在することになります。どれも、アカウントが一元管理されていないこと、社内にどういうアカウントがあり、どれが実際に使用されているのかを把握している担当者がいないことが原因です。こうしたケースは、建設的な話し合いで真の問題点を洗い出すよりも、責任のなすり合いに終わる場合がほとんどです。

皆様の組織では毎月、クラウドに関して、目のくらむような何ページにも上る請求書が発生しているのではないでしょうか。何百行にもわたる明細には、さまざまなサービス名、インスタンス タイプ、リージョンが書かれていますが、それだけでは何のことかわかりません。もちろん、ストレージ ボリュームの料金は一目ですぐわかるかもしれませんが、試しに前回の請求書を引っ張り出して明細に目を通してみてください。ストレージ ボリューム以外の料金のどれが、どのビジネス イニシアチブに関係しているか、理解したうえで説明することができますか？不可能に近いとしたら、そろそろ、クラウドの費用を解明する時期ではないでしょうか。

危険信号の3つ目は、原因不明の無駄遣いです。組織は、誰による支出なのか、なぜそれほど費用がかかるのかを追跡できなければなりません。2つ目の危険信号にも関連しますが、多数のチーム、プロジェクト、予算が社内で動いていると、クラウド ストレージやクラウド サービスの消費が、どのプロジェクトやコスト センターに結びついているのかをチェックする時間がないことがほとんどです。しかし、そのために誰も説明できない支出が何度も発生するのでは、大いに問題です。

クラウドの大きなメリットは、必要なストレージやクラウド リソースを何でもオンデマンドで利用できることです。この従量課金制は、組織にとって追加のストレージを簡単に調達できる便利な方法ではありますが、実は皮肉にも、購入したストレージが必ずしもニーズに応えていない場合がほとんどです。

先ほどの、複雑すぎて訳のわからない請求書を思い出してください。そこには、管理者の知らないところで処理されたストレージの調達や、組織の知らないところでまとめて購入された複数のリソースが含まれているはずです。たとえば、AWSのインスタンスをオンデマンドで利用するとしましょう。オンデマンドならVMを好きなタイミングで自由に起動できて便利ですが、AWSの予約されたインスタンスを利用すれば、最大75%の割引を受けることができます。さらにもう一歩踏み込んでスポット インスタンスを選べば、最大90%割引で購入できます（スポット インスタンスは、ニーズに合わせて購入する予備のElastic Compute Cloudインスタンスのことです）。

いかがでしょう？見境のないオンデマンド購入を認めるということは、組織としての支出戦略や消費計画が何もなく、身近にいるシャドウITユーザと同じように、社員による自由気ままな購入を野放しにしてしまうことにほかなりません。社員は当然、購入しすぎて余っても会社が払ってくれるから構わないと考え、実際そうなるわけです。でもビジネスにとって、これは何の費用になるのでしょうか。

驚きのニュースです。データの使用には、最初にそのデータを割り当てるのと同じだけのコストがかかる場合があります。ここには2つの問題があります。まず、ストレージをどれほど効率よく使用しているかという問題です。まったく使用していないストレージにお金を払いたい人はいません。同じく、安価なストレージ階層に格納できるデータを、わざわざお金をかけて高価なストレージ階層に格納しようとする人もいません。アクセス頻度の低いデータを適切なストレージ階層に格納すれば、1カ月につきGBあたり0.20～0.30ドルかかっていたコストを、0.02ドルまで引き下げられます。

2つ目は、クラウドからのデータの取り出し（または、クラウド間でのデータ移動）です。この処理に料金がかかることを考え方として十分に理解していても、1カ月に実際いくらかかっているかを正確に把握している組織はありません。ここでも結局、コストがどのイニシアチブに結びついているかという、犯罪捜査のような調査が必要です。取り出されたデータを追跡して、何度もデータを取り出すことに意味があるのかどうかを検討しなければなりません。たとえば、深く考えない開発者が、コードのテスト時間を短縮しようと、テスト データをオンプレミスのエンドポイントにコピーしているだけなのかもしれません。これが何度も発生すれば、料金は膨らむ一方です。しかし、避けようと思えばいつでも避けられます。誰かが責任を持って、こうした料金の発生をチェックして中身を確認し、ベストプラクティスを適用しなければなりません。

クラウド ストレージの費用に問題があることは、組織の規模に関係なく、簡単にわかります。最大の問題には、2つの側面があります。

1つは、クラウドは自分のニーズを満たすためだけにあると誰もが信じて使用しているため、結果的に経費がいくらになるかを気にする人がいないことです。 

もう1つは、可視化が難しいことです。ビジネス ニーズや発生元であるユーザに費用を結びつけるのが簡単ではありません。可視化できないということは、誰も説明責任を求められないということです。その結果、組織は、本来必要な料金以上を支払わされるという残念な状況に陥ります。

クラウド ストレージの支出に問題があるのは決して良いことではありませんが、問題の存在を認めるという、最初の（難しい）一歩を踏み出せたことは喜ぶべきことです。ここでは、問題の解決策として、文字どおり今日から取り組める実践的な方法を紹介します。以下に挙げる10のヒントは、IT部門を対象としたものがほとんどですが、クラウド ストレージに格納された移動可能なデータの所有者も、このヒントを参考にデータの使用状況をチェックすれば、ストレージの設置面積を削減して、組織の支出を抑制できます。

01. 接続されていないクラウド ストレージを削除する

VMを終了すると、通常はVMに関連付けられたルート ボリュームのみが自動的に削除されますが、追加されたストレージ ボリュームはそのまま残り、ストレージ コストが発生します。場合によっては、誤った削除を避けるため、そのような仕様になっている場合もあります。クラウド コストを削減する簡単な方法は、接続されていないボリュームを見つけて削除することです。使用していないストレージは削除しましょう。ただし、紐付けられていないリソースと同様、これを行うには、検出作業によってストレージの所有者を洗い出し、そのストレージが必要かどうかを本人に確かめなければなりません。データに存在意義があるかどうかは、本人でないとわからないからです。

02. 適切なストレージ階層を選択する

パブリック クラウド プロバイダからは、さまざまなストレージ階層が提供されているにもかかわらず、誰もが最速の（かつ最も値の張る）階層を選ぶ傾向があります。そこにはコスト意識がほとんど感じられません。料金が高いほどストレージ階層として適切なのでしょうか。そうとはかぎりません。

一般に、階層の1カ月あたりのGB単価は、データへのアクセス頻度とアクセス速度に基づいて設定されており、「ホット」なストレージ階層（通常、アクセス頻度の高いデータを格納するため、低レイテンシ、高パフォーマンスと高スループット、高可用性が求められる）は、「コールド」階層（バックアップやアーカイブなど、アクセス頻度の低いデータに最適な階層）と比べて、料金が5倍もかかることがあります。

ストレージ階層の評価では、必要なパフォーマンスとコストの2つを考慮し、目標とする予算とニーズをバランス良く実現できるかを考えることが重要です。データは後から、別の階層にいつでも移動することができます。

クラウド ストレージに無駄な費用をかけたければ、最も簡単な方法は、作成したストレージ ボリュームを遊ばせておくことです。クラウド プロバイダは、ストレージ ボリュームのサイズが大きすぎても、縮小するよう言ってはくれません。まずは、必要以上に大きいボリュームがないかを確認し、もし見つかったら、本当に必要なスペースを備えたボリュームを新たに作成し、そこに既存のデータを移行してから大きすぎるボリュームを削除することを推奨します。そうすれば、今後はボリュームを作成する際に、必要なストレージの評価プロセスを適用するだけで済みます。

クラウド プロバイダからは、顧客のスループット要件を満たせるよう、さまざまなパフォーマンス階層も提供されています。ボリュームごとに実際の読み取り / 書き込みアクセスを監視し、スループットが低いボリュームが見つかったらパフォーマンス階層をダウングレードすると、ストレージ コストを削減できます。ストレージのIOPSもワークロードに適した値に低減するので、併せてコスト削減に貢献できます。

データをどこにでもレプリケートできると伝えると、なぜかお客様は冷静さを失い、はるか遠くの場所を選びがちです。しかし、米国のデータを、たとえばハリケーンによる損失から保護するためにイギリスにレプリケートする必要が本当にあるでしょうか？答えはもちろん「ノー」です。超大型ハリケーンに備えるためだとしても、そこまでする必要はありません。こうした選択はコストにも影響します。たとえば、地理的にまったく異なる地域間で冗長構成を組むと、同じ地域内で組む場合と比べて費用が2倍になる場合があります。ビジネスへの影響とリスクを評価したうえで、本当に必要な冗長性のレベルを見極め、必要な冗長構成計画を賢く考えることが重要です。

仮想マシンのリカバリ戦略に、スナップショットは欠かせません。スナップショットがいくつも取得されていれば、ディザスタ リカバリの際に特定の時点のデータをリストアできます。ワークロードの所有者が必要としているものを消去してしまうのは、絶対にやってはいけないことですが、VMが何百もある環境で、前日のスナップショットが削除されないまま、それぞれのVMで日々スナップショットが作成されていては、クラウド ストレージの費用が膨らむ一方です。スナップショットの有効期限に関する戦略が必要です。幸い、大半のクラウド プロバイダには何らかのスナップショット ライフサイクル管理ポリシーがあり、それに基づいてスナップショットが自動で削除されるので、1人の管理者だけに頼る必要はありません。

データ移動にお金がかかるのは事実です。ただし、すべての場合で同じように費用が発生するわけではありません。クラウドの場合、データ転送費はソースとデスティネーションのクラウド サーバの場所によって異なります。通常、インバウンド トラフィックは無料（または、ほぼ無料）ですが、クラウド プロバイダのネットワーク外にデータを転送すると（データ エグレス）、たちまち料金が跳ね上がります。また、忘れてならないのは、データの所有者としては、データ転送は「必要だから行う」のであって、「どうすればコスト効率よく行えるか」は関係ないということです。この問題に対処するには、実際に使用する場所のできるだけ近くにデータを格納するよう所有者に勧めて、データを別の場所に移動する必要性をなくすことです。さらに、データ移動の前に圧縮や重複排除を実行し、差分のみの同期を利用すれば、転送コストを抑えられます。最後に、データの削除やアーカイブ階層への移動が可能なら、積極的に行うことを推奨します。

データを別のリージョンや別の国、別のアベイラビリティ ゾーンに移動すると、クラウド プロバイダから追加料金を請求されます。アプリケーションのアーキテクチャには、DevOpsがテスト データの維持に使用できるよう、こうしたデータ転送が組み込まれている場合があります。冗長性戦略の一部に組み込まれている場合もあります。そのためデータ転送には、明確な目的と承認の両方が必要です。必要なデータは、できるだけユーザベースと地理的に近い場所でホストするよう心がけてください。長期的には、ソリューションのアーキテクチャを見直して、データ移動の経路を最短化することを検討すると良いでしょう。

ストレージとデータ転送の料金設定には、どちらも、消費量に基づいて料金が追加されるプランが含まれていることがよくあります。クラウド プロバイダの料金表の一定レベル（「<ストレージ量>を超えている場合」などと示されています）に達していたら、よりお得な料金プランを交渉できるかもしれません。ただし、大幅割引が適用されるのは、料金設定要件を満たしたデータに限られるので注意してください。最後に、複数年契約に縛られている可能性はありませんか。契約期間に縛りがあると、月日の経過とともに使用量が増えて、よりお得な契約を交渉したいと思っても、期間中は別の契約に切り替えられないので、これも注意が必要です。

10. 完了しなかったアップロードをストレージから削除する

ワークロードの中には、ユーザがファイルをアップロードしなければならないものがあります。その際、アップロードが途中で停止すると、オブジェクトの一部が使用不可能なデータとしてクラウド ストレージに残り、それが原因で料金が発生することがあります。サイズによっては、不完全なアップロードのために取り残されたデータの破片が、積もり積もって大量になる場合もあります。これは管理者に、不明なデータの削除や移動を避ける傾向があるからです（ステップ6を参照）。対処としては、アップロードが完了しなかった場合は、バックアップしてから削除する方法を推奨します。

重要なのは、今すぐ何かに手を付けることです。 

以上の10のステップを実践すれば、クラウド ストレージのコストを大幅に削減できるのは確かですが、本当に必要なのは、どのストレージが購入され、割り当てられ、消費され、無駄にされているのかを組織全体で正確に可視化する方法です。 

それには、組織から1人以上のメンバーを選び、何に費用がかかっているのか、クラウド ストレージが効果的に使われているかをチェックする権限を与えることが必要です。クラウド プロバイダから提供されているレポート作成ツールや計算ツールなどを活用することも、クラウド関連の費用を可視化して一元管理するうえで欠かせない第一歩です。 

こうした基本をすべて押さえたら、次はサードパーティのソリューションで、クラウド関連の費用（ストレージを含む）を収集、集約し、分析して評価し、レポートにまとめます。 

クラウド関連の費用に問題があることをまず認識し、上記の10のステップを参考にすぐさま対策に乗り出せば、やがて、クラウド ストレージのコストを管理できるようになるはずです。コスト削減を確実に持続できるよう、ポリシーとプロセスを整備し、テクノロジを追加して、管理不能だったクラウド費用を抑え込むための答えを導き出しましょう。