Datafyでビジネス開発を統括するグルディップ・カリー氏は、Amazon EBSの特徴について「Amazon EBSは実質的に、直接接続型ストレージDAS（Direct-Attached Storage）のように機能する」とし、これがコストを見積もる上での課題の一つになると説明する。この特徴は、AWSが提供する1対多のストレージ共有が可能なファイルストレージサービス「Amazon FSx」など他のクラウドストレージとは性質が異なる。仮想マシンサービス「Amazon Elastic Compute Cloud」（EC2）のインスタンス1台に1対1で接続されることが基本となれば、必要な容量はインスタンスごとに個別に見積もらなければならない。

　特にAmazon EBSを仮にコンテナオーケストレーター「Kubernetes」のサービスと組み合わせて活用する場合、ストレージ使用量の予測が困難になる可能性があるという。Kubernetesではワークロード（処理の負荷）が頻繁に変化し、コンテナのスケーリングや移動が繰り返される特性があるためだ。エンジニアは可用性やサービス継続性を重視する結果、必要以上に大きなストレージ容量を割り当てしてしまう傾向がある。

　カリー氏は「Amazon EBSはストレージ容量を拡張しやすいという意味では弾力性があるが、コスト面ではそうではない」と指摘する。実際に使うかどうかに関係なく、必要以上の容量を確保するとなれば、スマートフォンのストレージを見積もって購入するのと同じように無駄が出る可能性があるからだ。こうした懸念がある一方、同氏は「Amazon EBSは既存のアプリケーションをリフト＆シフトする際の最も簡単な方法の一つとして広く採用されている」と語る。

　スケーリングに関しても課題がある。Amazon EBSでは、容量を増やす「スケールアップ」は比較的容易だが、容量を減らす「スケールダウン」はそれほど簡単ではないとカリー氏は指摘する。スケールダウンをするには、新たに小さなボリューム（ストレージの論理的な保存領域）を作成し、既存データをそのボリュームに移動させた上で、アプリケーションから古いボリュームの接続を全て解除し、新しいボリュームに再接続する必要がある。「ユーザーにとって、スケールダウンは実質的に“ストレージの移行”作業に等しく、繰り返し実施することは現実的ではない」（同氏）

EBSの無駄を削減

　Datafyのアプローチは、ユーザーのAWS環境にある全てのインスタンスに独自のエージェントをデプロイすることから始まる。このエージェントは接続されたAmazon EBSボリュームの使用状況やサイズを解析し、必要に応じて1つの大容量ボリュームを複数の適切なサイズのボリュームに分割し、置き換える。このエージェントは複数のAmazon EBSボリュームを仮想的に統合し、アプリケーションに対してはあたかも1つのボリュームであるかのように見せる。状況に応じてボリュームを自動的に追加、削除することで、ストレージ容量を適切なサイズに保ちつつ、柔軟にスケーリングができるようにする。

　同エージェントとそれに搭載されたインテリジェンス（分析・自動最適化機能）は、「AWSの設計思想に反するものではない」とカリー氏は強調する。ユーザーのデータは、もともと使っていたボリュームから、Datafyが管理する複数のボリュームにコピーされる。コピーが完了すれば、従来のボリュームは削除できるため、その分のコストを削減できる。このDatafyのボリュームは必要に応じて容量をリアルタイムに拡張、縮小でき、中断を最小限に抑えたスケーリングが可能になる。

　料金はDatafyが管理するストレージ容量を基準に算出され、AWSが同じ容量を直接管理する場合に比べて20％の追加料金が上乗せされる仕組みだ。この20％という加算率は一見すると高く感じられるだろう。だがAmazon EBSの容量を必要以上に割り当てる場合に比べれば、トータルコストを大幅に抑えられる可能性がある。

　例えば、AWSに対して月額100ドルを支払っているケースを考えてみよう。オーバープロビジョニングの影響で実際のストレージ使用率が40％にとどまっている場合、実質的には40ドル分しか利用していないことになる。この状況でDatafyの仕組みを導入すれば、実際に使った分（40ドル相当）に対して20％の追加料金（8ドル）が加算され、最終的なコストは48ドルとなる。それでも従来の100ドルよりも大幅に安くなる計算だ。しかも、コスト削減が実現できなかった場合は、Datafy側からの課金は発生しないという。