本技術情報は、Amazon Web Services （以下、AWS）における利用料金に着目し、 AWSの料金体系に向いたシステムパターンの明確化、AWSの料金を削減するための運用制御、 料金の可視化や料金配賦といったテーマについて解説します。

本技術情報は、次の３回からなるシリーズです。

第1回 AWSの料金から見る効果的なAWS利用方法
第2回 運用によるAWS利用料金削減
第3回 利用料金の配賦と可視化

クラウドの利用料金はクラウドサービスによって様々です。そのため、各クラウドサービスの料金体系の特長を正確に把握することで、そのクラウドサービスの提供するIaaS/PaaS/SaaSといった機能やロケーションのメリットを、コストメリットをもって適材適所で利用することが出来ます。

本技術情報ではAWSに絞って、このクラウドの利用料金の管理に関する課題を解説します。

今回の第1回では、AWSの料金から見る効果的なAWS利用方法、をテーマに、AWSの利用料金に関する考え方から、AWSの料金体系を活かせる利用パターンを紹介していきます。

従来のオンプレミス環境においては、システムのインフラ料金は

・イニシャルコスト（ハードウェアの購入費用等）
・ランニングコスト（データセンタ等の利用料金・ハードウェアの保守料金等）

のような形で構成されています。

ハードウェアを調達した時点で、比較的大きなイニシャルコストが発生します。 その後のランニングコストは、ハードウェアの稼働率によって多少変化はしますが、 仮に稼働率が0であったとしても、ランニングコストは確実に発生します。

図1：オンプレ環境での稼働率ごとの累積コストイメージ

そのため、購入したハードウェア資産を可能な限り使い切って、 アウトプットを最大化することが、投資対効果（コストパフォーマンス）を最大化することができます。
（逆にリソースの使用を控えれば控えるほど、コストパフォーマンスは悪化します）

一方でAWS環境においては、発生するインフラ料金は基本的に

・ランニングコスト（サービスの起動時間・使用量）

のみで構成されています。 また、使った量（時間）がダイレクトに料金に反映されるような料金体系になっています。

図：AWS環境での稼働率ごとの累積コストイメージ

オンプレミス環境とは異なり、料金はインスタンスの稼働時間に完全に比例するため、 ハードウェア資産を使い切るという考え方は存在しません。 必要最低限の資産を使い、ある程度のアウトプットを出力することが、 投資対効果（コストパフォーマンス）の最大化といえます。

こうした料金体系による考え方の違いについて考慮せず、 コスト削減を狙って従来のシステム構成をそのままAWS上に移行した場合に、インフラの料金的に全くメリットが出ない （それどころかコストパフォーマンスが悪化する・利用料金が増加する）ケースがありえます。

AWSの、特にEC2の利用料金は、おおよそ次の計算式のような概念で算出されます。

インスタンス数 × インスタンスタイプ × 時間

これは、インスタンス数をN倍に増やしたとしても、利用する時間を1/Nに削減することで、 利用料金の観点では変らないということを意味しています。
同様に、N倍高額なインスタンスタイプを利用したとしても、利用時間を1/Nに削減することで、 利用料金は変わらないということを示しています。

AWSでのデータ通信量に関する料金体系は、

・AWS内に入る通信：無料
・AWS外で出る通信：従量課金

となっています。そのため、データ通信にかかる料金を減らすためには、 AWSに対して入る通信ではなくAWSから外部へ出る通信に着目し、その量を減らす必要があります。

AWSの利用料金の考え方 の内容を踏まえると、 AWSの料金体系を活かせる利用パターンとしては次のような例が挙げられます。

・ピーク／オフピークが明確に存在するパターン
・インスタンスの存在に価値があるパターン
・分量が決まっていて、処理期間を短縮することに価値があるパターン
・大量のインプットに対して少量のアウトプットがあるパターン

それぞれを次に解説します。

時間によってシステムの利用状況に大きく差がある場合、 AWSの利用料金を大きく下げられる可能性があります。

例えば、スケールアウトが可能な以下のような利用特性のシステムの場合

・平日の日中帯（8時～18時）は業務量が多い（5台のインスタンスが必要）
・平日の夜間帯（18時～翌8時）は業務量が少ない（1台のインスタンスで処理可能）
・休日は業務停止（インスタンスは不要）

図：ピーク／オフピークが明確に存在するパターンの例

インスタンスの起動数、起動時間を必要最低限となるようにコントロールすることで、 全てのインスタンスを常時稼働させていた場合に比べ、4割弱の稼働率 （＝4割弱のコスト）で運用することが可能となります。

また、スケールアウトが難しい処理であったとしても、高スペックのEC2と低スペックのEC2を用意し、 状況によって切り替える（どちらか片方のみが稼動している）とすることで、 同様に料金の削減が可能です。

ピーク／オフピークが明確に存在するパターン の最たる例が、 インスタンスが存在していることそのものに価値がある場合です。

これは、インスタンスが「起動していること」ではなく、 「停止状態」でそのインスタンスが存在していることに意味があるケース、 具体的にはディザスタリカバリのスタンバイサイトなどが挙げられます。

図：インスタンスの存在に価値があるパターンの例

ディザスタリカバリのスタンバイサイトでは、通常は殆どのサーバは稼働中である必要は無く、 マスタと同じサービスが提供可能な非稼動状態のサーバが「存在している」ことに意味があります。

このパターンの場合、（ストレージの料金はかかるものの） インスタンスの稼働時間に関わる利用料金はほぼ0になります。

処理するべきタスクの分量が決まっているようなシステムで、 スケールアウト（インスタンス数を増やす）やスケールアップ（インスタンスタイプを上げる） によって処理時間を大きく短縮できるような特性のタスクの場合、 AWSの料金体系を活かしやすい利用パターンである可能性があります。

料金を決める3要素 で示したように、 利用料金はサーバ台数・インスタンスタイプ・時間の3つの要素で決定されます。 そのため、たとえサーバ台数を増やしたり、インスタンスタイプをあげたとしても、 稼働時間を減らすことにより、利用料金が大幅には上昇しないためです。

図：分量が決まっていて、処理期間を短縮することに価値があるパターンの例

例えば、サーバを2倍用意することで、処理にかかる時間を1/2にできるような特性のタスクがあると仮定します。この場合、EC2インスタンスの起動時間が半分になるので、ほぼ同じコストで処理時間を1/2とする処理が実現できます。

これは理想的なモデルですので、もう少し現実に即したモデルを見てみましょう。例えば、処理するサーバを10倍用意することで、 処理にかかる時間を1/5にできるような特性のタスクがあると仮定します。
オンプレ環境の場合、処理時間を1/5にするためには、 サーバを10倍用意する必要があり、イニシャルコストが10倍かかることになります。 （ オンプレ環境における料金の考え方 に示した通り、 オンプレ環境においては料金の大半をイニシャルコストが占めます）
一方でAWS環境の場合、処理時間を1/5にするためには、 サーバを10倍稼動させるものの、稼動時間は1/5で済みます。 そのため、結果としてわずか2倍のランニングコストで処理時間1/5が達成可能です。 （ AWSの利用料金の考え方 に示した通り、AWS環境においてはランニングコストが利用料金の大部分を占めます）

タスクの処理時間を短縮することそのものに大きな価値がある場合、 より一層AWSを利用する優位性が高まります。

通信に関する特殊な料金体系 に示したように、AWSに流入する通信については、 データ転送にかかる費用は無料です。

そのため、例えばリアルタイム・大量なプローブデータを常時収集し、 そこから定期的に分析結果を出力するようなシステムの場合であれば、 データをAWSに収集する際の転送量に関しては料金はかからず、 アウトプットするデータが少量になることで、 通信のデータ転送量に関してかかる費用を抑えることができ、 AWSの料金体系を活かせる例と言えます。
（但し、大量のデータを蓄積するストレージ・分析基盤環境が必要になるため、 そのデータをどの程度蓄積し続けるのかといった運用次第では、 データ転送量以上に保存領域の利用料金がかさむ点に注意が必要です）

図：大量のインプットに対して少量のアウトプットがあるパターンの例

次回の第2回では、運用によるAWS利用料金削減、をテーマに解説します。

クラウド運用管理特集

クラウド仮想化オプション

お問い合わせフォームへ