はじめに
本記事では、Oracle Cloud Infrastructure (OCI) の見積りツールの使い方や、見積もる上での基本的な考え方について説明していきます。
参考までに金額情報も掲載していますが、最新情報については 必ず 価格表 を確認してください。また、内容には十分注意していますが、正確な見積りに当たっては ご自身で責任を持って行ってください
（もしも本記事の内容で誤りにお気づきの方がいらっしゃったら、ぜひご指摘頂ければ幸いです。）
《22/12/13 追記》
2022/12/1 より、昨今の為替市場の変動に伴い 価格改定がされています。
本記事は、見積りの考え方を理解する上ではご参考にしていただけると思いますが、改定前の価格で算出している点にご注意ください。
長くなってしまったので、お急ぎの方はこちらからどうぞ…!! m(__)m
・コンピュート・サービス
・ブロック・ボリューム
・オブジェクト・ストレージ
・データベース・サービス
・仮想クラウド・ネットワーク
・ロード・バランサ
・見積りのサンプル
・参考情報
Cost Estimator の使い方
Oracle Cloud の見積りを行う際、Cost Estimator というツールが公式で公開されています。こちらのツールを用いて、必要なサービスや、その条件を設定していくことで試算できます。簡単に画面の見方や使い方について触れておきます。
- Cost Estimator：https://www.oracle.com/cloud/cost-estimator.html
※但し、最新の価格体系などはすぐに反映されていない可能性もありますので、やはり 価格表 も合わせて確認することをおすすめします。
《21/11/30 追記》
Cost Estimator が、新しく「Cost Estimator Generation 2」というバージョンで提供されるようになりました。従来の Cost Estimator も「Legacy」版としてまだ利用可能なようです。
本記事は「Legacy」版を利用した場合の説明となっているため、「Generation 2」版でのお見積りについては、OCI の公式ドキュメントをご参照ください。
- Cost Estimator Generation 2：https://www.oracle.com/cloud/costestimator.html
- Cost Estimator に関する公式ドキュメント：https://docs.oracle.com/en-us/iaas/Content/GSG/Tasks/signingup_topic-Estimating_Costs.htm
画面の構成
Cost Estimator の画面は、大きく上段と下段に分かれるようなレイアウトになっています。
上段で試算したいサービスを「add」し、下段で そのサービスに関する条件設定 (使用する時間数や作成するリソースの数などの設定) を行う流れになります。
まずは画面上段から見て行きます。
- [1]：試算した結果（月額）が表記されます。
-
[2]：通貨を変更できます。
Oracle Cloudは為替レートで変動せず国ごとに固定なので、日本円で利用したい場合は、こちらを「JPY - Japanese Yen (￥)」で設定します。 -
[3]：サービスのカテゴリを選択します。
例えば、仮想マシンであれば「Infrastructure」を選択します。どのカテゴリに対象のサービスが含まれているか分からない場合は、ここを「Search all products」とすることで、サービスを検索して追加していくことが出来ます。いや、どういうワードで検索したら良いの…という方は、こちら もご参照ください。 -
[4]：[3] で選択したカテゴリに応じてサービスが表示されます。表示されるサービスが多い場合には、横スクロールボタン (
＜／＞) をクリックし、ページを切り替えます。
対象のサービスを「add」することで、画面下段で詳細な設定を行えるようになります。
続いて下段です。
-
[5]：試算した情報を一時保存したり、他者への共有ができます。
-
Load/Save：見積もった内容に名称を付けて一時保存できます。構成Aの場合、構成Bの場合、といった形で比較しながら見積りたい時などに利用できるかもしれません。 -
Save at PDF：見積もった内容をPDFに保存できます。 -
Export：見積もった内容をファイル (*.oce) に出力できます。出力されたファイルをImportすることで、別環境にも Cost Estimator で見積もった状態を共有できます。 -
Import：Exportで出力したファイル (*.oce) を Cost Estimator に読込みます。 -
Share：私が試した際は上手く動作しなかったのですが、こちらも見積もった内容を他社に共有するためのボタンで、リンクが発行されるようです。
-
-
[6]：上段の [4] で
addしたサービスに応じて、そのサービスの設定項目が表示されます。
ゴミ箱アイコンを押下することで項目を削除できます。
上の画像は、コンピュート・インスタンスを追加した際の例になります。 -
[7]：試算した結果（月額）が表記されます。
上段の [1] で表示される内容と同一のものになります。
利用時間や構成の設定
各サービスの設定項目は大きく分けて、以下のようになっています。
・[1]：Utilization
・[2]：Configuration
[1] Utilization では、作成するインスタンスの数 や、その 利用時間・日数 を設定します。
サービスによっては 停止することでコストを抑えられるものがありますし、停止できないサービスであっても、１か月まるまる利用するのではなく、数日利用して削除する場合などに、ここを設定することで、より細かく試算することが出来ます。
【memo】 仮想マシンは停止することでCPU課金を停止することが出来ますし、ロード・バランサのように停止できないインスタンスも、５日間の検証後に削除する場合のコスト を試算できます。
[2] Configuration では、構成 に関する設定を行います。
ただし、その内容については、サービスによって様々となっています。どういった項目があり、それぞれが どういった意味を持つのか、初めての人にとっては直感的ではない部分もあると思うので、次のステップで一緒に見て行きたいと思います。
サービス別課金の考え方
ここでは、Cost Estimator での設定方法はもちろん、各サービスごとの課金に関する全般的な説明をしていきます。とはいえ 全てのサービスについて解説すると膨大になってしまうので、一部に絞って説明していきます。
コンピュート・サービス
ひとくちにコンピュートといっても、Cost Estimator 上で「Compute」で検索してみると、様々な候補が表示されるかと思います。
どれを選べば良いのか悩むと思いますが、一旦忘れて、まず始めに、そもそもコンピュート・インスタンスってどういう構成になってるんだっけ？という所をおさらいします…！
コンピュート・インスタンスは下記イメージの通り、大きく４つのレイヤで構成されています。
上記のうち、(1) については Marktetplace上で個別に確認して計算していく必要があるため、本記事では割愛します。また、(4) については、ブロック・ボリュームの項目となるため、後ほど説明します。残る (2)、(3) が、コンピュート・サービスとしてここで見積もる対象となります。
OSイメージにかかるコスト
まず、(2) について、(記載の通りになりますが、) Linux系OS は利用するに当たってライセンス費用などは掛かりませんが、Windows系OS などを利用する場合には時間単位で費用が発生します。Cost Estimator では「Compute - OS Images」という Product 名が該当します。
《OS イメージの Configuration》
Windows OS を利用する場合は、Configuration の「Compute - Windows OS (B88318)」を設定します。課金のメトリックに「OCPU Per Hour」とあるので、利用する コンピュート・インスタンスのシェイプ に応じて、CPU数 を設定します。
例えば、VM.Standard2.1 を利用する場合には、含まれるCPU数は「1」となるので、ここには「1」を入力します。必ず シェイプ の CPU 数を確認した上で、その値を設定します。※「OCPU (ｵｰｼｰﾋﾟｰﾕｰ)」とは、OCI におけるCPUの単位のことで、物理コア１つを意味します。
《OS イメージの Utilization》
Windows OS は、インスタンスを停止することで課金も止めることが出来るため、必要に応じて Utilization の値を変更しましょう。
インスタンスの種類にかかるコスト
続いて (3) についてです。インスタンスの種類、つまり、CPU や ハードウェアの種類 に応じて料金が発生します。Cost Estimator を使って この "インスタンスの種類" を設定する場合、単に ”VM.Standard2.1” など、利用したいシェイプを選択すれば良い形式であれば直感的で良かったんですが、残念ながら Cost Estimator は少しクセがあります。
まず、Product 名は「1. Compute - GPU」「2. Compute - Bare Metal」「3. Compute - Virtual Machine」の３種類に分かれています。
GPU のシェイプは ベアメタル／VM、いずれのタイプでも提供されているのですが、こちらを利用する場合は「2」や「3」の Product 名ではなく、独立した「1」の Product 名を選択してください。
《インスタンスの種類毎の Configuration》
次に、各 Productで Configuration を設定していきます。Product 名は違えど、Configuration の考え方は一緒なので、ここでは 例として ベアメタル をベースに見て行きます。
シェイプ は「BM.Standard2.52」や「BM.DenseIO2.52」といった表記ですが、Configuration では 「X5」「X7」といった 謎の文字 があります。ドキュメント で 各シェイプの記述を見てみると、下記のように記載されています。
BM.Standard1: X5ベース の標準コンピュート。プロセッサ: Intel Xeon E5-2699 v3。
(中略)
BM.Standard2: X7ベース の標準コンピュート。プロセッサ: Intel Xeon Platinum 8167M。
これを見てピンと来た方も多いと思いますが、各 Product の Configuration では、まず 利用したい シェイプ が、「Standard」「DenseI/O」など、どのシェイプ・タイプかを判断 し、更に、そのタイプにシリーズ (=CPUのバージョン／世代のようなイメージ) が複数ある場合、どのシリーズに該当するのかを判断 の上、選択していく必要があります。
え、分かりにく過ぎません…?
また、各Configuration の 課金のメトリックは「OCPU Per Hour」とあるので、OS イメージの時と同様、利用する コンピュート・インスタンスのシェイプ に応じて、CPU数 を設定します。
《インスタンスの種類毎の Utilization》
Utilization はそのままの通り、コンピュート・インスタンスの利用時間や、そのインスタンス数に応じて 設定してください。
ただし注意点として、コンピュート・インスタンスは「停止によってCPU課金を止められるもの」と「インスタンスを削除するまで課金されるもの」に分かれます。
具体的には、標準シェイプ（xx.Standard～）以外は、「インスタンスを削除するまで課金されるもの」となります。例えば DenseI/Oタイプのインスタンスを 節約のために停止しようと思っても、課金は停止されない ので注意してください。
詳しくは、ドキュメントの 停止したインスタンスのリソース請求 を参照してください。
補足）バックアップにかかるコスト
コンピュート・インスタンスをバックアップするための仕組みとして、「カスタム・イメージ」の取得や、「ブート・ボリューム」のバックアップが出来ますが、それぞれにかかる料金について補足します。
-
カスタム・イメージ：（バックアップ用途だけでなく、インスタンスの複製などにも利用可能ですが）内部的にはオブジェクト・ストレージに保存されており、そのサイズ分だけ「オブジェクト・ストレージ」の料金が必要となります。※2021/5/26以降のカスタム・イメージに関して
自身の任意のオブジェクト・ストレージにエクスポートすることもできますが、こちらも同様に容量に応じた費用が必要です。 - ブート・ボリュームのバックアップ：こちらも内部的にはオブジェクト・ストレージに保存されており、そのバックアップサイズに応じて「オブジェクト・ストレージ」の料金が必要となります。
補足）Marketplaceで提供されるイメージの注意点
前述した通り、Marketplaceで提供されるイメージは、インスタンスの種類・OSイメージへの課金に加えて、アプリケーション・ライセンス費用など、イメージを利用するために必要なコストが 別途かかるケースがあります。それらの料金体系については、Marketplace上に記載された情報を個別に確認する必要があります。
ここで注意して頂きたいのは、提供されるイメージの中には「最低利用要件」が設定されているものもある という事です。
例として、Microsoft SQL Server Standard を挙げます。Microsoft SQL Server Standard イメージの詳細を見てみると、「Minimum 744 hours requirement」 という文言があり、たとえ 744時間以内にインスタンスを終了(削除)しても、744時間分の課金がされる 旨が明記されています。
ブロック・ボリューム
コンピュート・サービスは中々に複雑でしたが、ここからは 比較的 分かり易くなっていると思います。
Cost Estimator 上で「Block Volume」というワードで検索してみると、「Storage - Block Volumes」という Product 名が表示されるので、そちらを選択していきます。尚、コンピュート・サービスのところで触れたように、「ブート・ボリューム」の見積を行う際も、こちらの Product 名を指定し、試算していくことになります。考え方は同じなので、特に区分けせず見て行きます。
《ブロック・ボリュームの Configuration》
Configuration を見てみると、「1. Storage - Block Volume - Free 100GB (B91445)」「2. Storage - Block Volume - Storage (B91961)」「3. Storage - Block Volume - Performance Units (B91962)」といった３種類の項目があります。
「1」は、ブロック・ボリュームに設けられた無償枠を意味しています。ここにいくら値を設定しようが、無償枠なので金額は変動しません。「全体で 〇GB 使用するけれど、そのうち △GB は無償枠を使用するよ」と明示的に示したい場合などを除けば、一旦無視して良いと思います。
「2」については、メトリックに「Gigabyte Storage Capacity Per Month」とあり、単に 月当りに使用するストレージ容量 を指定すれば良いと分かります。例えば、無償枠を超えて 月 500GB が必要だとすると、ここに「500」と設定します。ここで注意すべきは、ここで指定するサイズは実際に使用しているデータ量ではなく、「ブロック・ボリュームの作成時に指定したサイズ」となることです。
また、ブート・ボリューム分として計算する場合は、指定可能な最小サイズが決まっている ので注意してください。（Linux系であればデフォルト50GB、Windows系であれば256GB）
2021/10/14 以降の Windows Image を使用する場合、ブート・ボリュームのデフォルト・サイズは『50GB』になります。
「3」については、メトリックに「Performance Units Per Gigabyte Per Month」とあります。この、”Performance Units” というキーワードですが、ドキュメント 上では「Volume Performance Unit (VPU)」と記載されていて、価格表 には、以下の通り補足されています。
0 VPUs at $0 for Lower Cost
10 VPUs at $0.017 for Balanced
20 VPUs at $0.034 for Higher Performance
ブロック・ボリュームは 必要な 性能 や コスト に応じた３つのオプション、「Lower Cost (より低いコスト)」、「Balanced (バランス)」、「Higher Performance(より高いパフォーマンス)」から選べるようになっていますが、この項目は、そのオプションに応じた 追加費用を設定するためのものになります。
先ほどの補足の通り、「Lower Cost」であれば 0VPU なので 気にする必要はありませんが、「Balanced」以上のタイプを利用する場合、使用するストレージサイズ (GB単位) に応じて、対象のタイプの VPU を乗算した値を設定 する必要があります。例えば、500GB のストレージを Balanced タイプで使用する場合、10 VPU × 500 GB = 5000 Performance Units Per Gigabyte Per Month を設定することになります。
尚、ブート・ボリュームは「Lower Cost」は選択できない為、ブート・ボリューム分を計算する際には、ご注意ください。
《ブロック・ボリュームの Utilization》
Cost Estimator 上で、ブロック・ボリュームの Utilization の利用時間や日数を変更しても、金額は変動しません。その為、ブロック・ボリュームは一度作成したら 必ず１か月分のコストが掛かるの？と思われるかもしれませんが、数日で削除すればその時点までの課金になります。（例えば １か月使用した場合の試算が1200円だったとしても、10日間利用した後 削除した場合には、その約1/3の金額、400円程度が実際のコストとなります。）
ただし、Cost Estimatior 上ではそういった指定ができないので、１か月分の金額を見て、「〇日の利用後に削除するからこのくらいの金額かな」という理解に留めるしかありません。
補足）バックアップにかかるコスト
ブロック・ボリュームのバックアップにかかるコストについては、ブート・ボリュームに関して触れた時と同じく、内部的にはオブジェクト・ストレージに保存されるため、そのバックアップサイズに応じた「オブジェクト・ストレージ」の料金が必要となります。
補足）パフォーマンスの自動チューニング
ブロック・ボリュームやブート・ボリュームは、コンピュート・インスタンスからデタッチしておくことも可能ですが、「自動チューニング」の設定を ON にしている場合は、インスタンスからデタッチされると自動で「Lower Cost」パフォーマンスに変動します。デタッチしている間のストレージ・コストを少し抑えることが可能です。
見積る際にはそこまで厳密に試算しないと思いますが、運用の際に意識しておくと良いです。
21/6/10 追記：Ultra High Performance について
2021/6/10 に、新しい性能オプション「Ultra High Performance」がリリースされました。これまでのオプションでは、「Higher Performance(より高いパフォーマンス)」の75 IOPS/GB が最も性能が良いものでしたが、この新しいオプションでは、VPU を 30 ～ 最大120 VPU の間で自由に設定ができ、30VPU で 90 IOPS/GB、そこから 10VPU ごとに 15 IOPS/GB ずつ 性能を強化していくことが できます。
見積り方法は基本的にこれまでと変わりませんが、VPUを 30 ～ 120 の間で自由に設定できますので、利用したい性能の要件に応じて、「Performance Unit」を追加するようにしてください。
21/4/7 追記："ブロック・ボリュームのレプリケーション" について
2021/4/6 に、ブロック・ボリューム(ブート・ボリューム含む) に新しく「レプリケーション機能」が追加されました。DR用途などを目的に、別リージョンへ ブロック・ボリュームのレプリカを作成することができます。
レプリカ自体にかかる費用としては、バックアップの時と異なり、「ブロック・ボリューム」としての料金が必要 になります。
この際、性能コスト(VPU) は、レプリケーション元の ボリュームのタイプに関係なく、「Lower Cost (より低いコスト)」 となります。
従って、例えば 元のサイズが 50GB の場合、レプリカにかかる費用は、「50GB 分のストレージ・コスト ＋ ( 0 VPU (Lowe Cost) × 50GB)」となります。
また、リージョン間のレプリケーションは ネットワークのアウトバウンド転送量の対象となる ため、有効化する場合には留意してください。
オブジェクト・ストレージ
続いては、実質容量無制限、使った分だけ課金となるオブジェクト・ストレージ・サービスの見積りです。Cost Estimator 上で「Object Storage」というワードで検索してみると、「Storage - Object Storage」という Product 名が表示されるので、そちらを選択していきます。
《オブジェクト・ストレージの Configuration》
Configuration には、「1. Storage - Object Storage - Requests (B91627)」「2. Storage - Object Storage - Storage (B91628)」「3. Storage - Archive Storage - Storage (B91633)」の３種類があります。
「2」と「3」は、利用するオブジェクト・ストレージのバケットが**「標準タイプ」か「アーカイブタイプ」かの違い** になります。「アーカイブ・バケット」を利用する場合、単価は安くなりますが、その分データの取り出しに時間がかかるタイプになります。
それぞれメトリックは同じで、「Gigabyte Storage Capacity Per Month」となっていますので、例えば１か月に 100GB 利用する想定であれば、ここの値を「100」と設定します。ただし、オブジェクト・ストレージにも テナント単位で設けられた無償枠が「標準タイプ」「アーカイブタイプ」それぞれ 10GB ずつあります。Block Volume の時のように別の Configuration となっておらず、自動的に 無料枠 10GB 分の料金を差し引いた額が表示される仕様になっているようです。
「1」は、オブジェクト・ストレージに対するリクエスト数（GETやPUTといった操作）に応じた課金 を意味しています。こちらも無償枠があり、初めの 50,000 リクエストに関しては無償となります。ただし、こちらについては Cost Estimatior 上で自動的に マイナスされず、50,000リクエストを超過するリクエスト数を設定していく形になります。どちらかに統一してほしい…。
50,000 リクエストを超過するケースは 中々ないと思いますので、あまりこちらの Configuration は意識しなくて良いかもしれません。
《オブジェクト・ストレージの Utilization》
オブジェクト・ストレージの Utilization についても、ブロック・ボリュームと同様に、Cost Estimator 上で 利用時間や日数を変更しても、特に金額に反映されませんが、数日で削除すればその時点までの課金になります。
ただし、アーカイブ・ストレージについては 最小利用要件が90日 と定められている為、アーカイブ・ストレージにオブジェクトを追加し、すぐに消したとしても、90日分の費用が必要になるので注意してください。
尚、オブジェクト・ストレージは使った分だけ課金、なので、ブロック・ボリュームと異なり、消費しているストレージサイズが、月の中でも 多分に変動します。
ある時点では 1TB だったけど、ある時点では 100GB だった、というようなケースでは課金はどうなるのか？と疑問に思われると思います。詳しくは 下記の資料をご確認頂きたいのですが、それぞれ、そのストレージサイズを消費していた ”時間単位”で コストが計上される形になります。
これを 厳密に見積もろうとすると複雑すぎるので、個人的には おおよそ月平均でこのくらい利用するだろう、といった塩梅で決めて良いのかなと思います。
-
ストレージ・サービスの積算に関する基本的な考え方 (資料「OCI 課金にまつわるエトセトラ」より抜粋)
補足）バージョニングにかかるコスト
オブジェクト・ストレージには、バージョニングという機能があります。この機能を利用する場合、過去のバージョンについてもそれぞれストレージコストの課金対象となりますし、明示的にバージョンを指定した削除をしない限り (＝単なる削除ではダメ) 消えない ので、その点忘れずに考慮しましょう。
21/3/7 追記："頻度の低いアクセス層" について
2021/2/2 に、オブジェクト・ストレージに新しく「頻度の低いアクセス層 (Infrequent Access tier)」がリリース されました。
これに伴って、Cost Estimator の「Storage - Object Storage」→ Configuration に、下記２つのメニューが追加されています。
- 「
Storage - Infrequent Access Storage - Storage (B93000)」:
メトリックは「Gigabyte Storage Capacity Per Month」となっていて、「頻度の低いアクセス層」に設定されたオブジェクトの容量に応じた値を設定する項目になっています。 - 「
Storage - Infrequent Access Storage - Data Retrieval (B93001)」:
「頻度の低いアクセス層」に設定されたオブジェクトは、取り出す際に 別途コストがかかります。これは、その取り出し回数を設定する項目になっています。
また、「頻度の低いアクセス層 (Infrequent Access tier)」にも、最小利用要件：31日 が定められている 点にご注意ください。
データベース・サービス
続いて、データベース・サービスです。OCI で提供されているデータベースのサービスには様々な種類がありますが、本記事では 仮想マシンタイプのデータベース・サービス、いわゆる「DBCS (VM)」に絞って説明していきます。
Cost Estimator 上では「Database - Oracle Database Cloud Service - Virtual Machine」という Product名で 検索することができます。
《DBCS (VM)の Configuration》
Configuration はシンプルに「DVCS_VM」という１行のみになっていますが、開いてみると「Select Option」とあり、Oracle Database の エディションを選択する 項目があります。利用したいエディションを選択し、コンピュート・サービスの時と同様に、使用したい シェイプ に含まれる CPU数を確認の上、メトリックを指定しましょう。例えば、「VM.Standard2.2」を利用したい場合は、「2」を設定します。
どのエディションを選択するかによって利用可能な機能が異なってきますが、どのエディションでどういった機能が利用できるのかは下記の資料を参考にしてください。
《DBCS (VM)の Utilization》
DBCS (VM) も、ノードを停止することによって、CPU課金を停止することが可能です。利用したい時間に合わせて、適宜 Utilization を変更しましょう。
補足）ストレージにかかるコスト
ここまで あえて触れていませんでしたが、DBCS も コンピュート・サービスの時と同様、ストレージ部分のコストが必要になります。また、そのコストは、ブロック・ボリュームの項目で計算します。
ただし、DBCS の場合は、ストレージ・サイズを自由に選択できず、決まったサイズからしか選択できません。また、ユーザーが使用能なストレージ・サイズに加えて、Database が使用する領域も含んだ全体のストレージ・サイズが課金の対象となります。
例えば、データ領域として「400GB」必要な場合、それが収まるストレージ・オプションは「512GB」となり、その場合の全体サイズは「968GB」となります。この「968GB」をブロック・ボリュームの項目で計算します。また、DBCS の ストレージについては、Balanced タイプのストレージで固定 となっていますので、Performance Units は ストレージ・サイズ × 10 VPU で計算します。
補足）バックアップにかかるコスト
DBCS のバックアップは、ブロック・ボリュームなどの場合と同じく、内部的にはオブジェクト・ストレージに保存されるため、そのバックアップサイズに応じた「オブジェクト・ストレージ」の料金が必要となります。
仮想クラウド・ネットワーク
続いて 仮想クラウド・ネットワークに関する見積りを見て行きます。ネットワークの Product 名は「Networking - Virtual Cloud Networks」となります。Cost Estimator 上で検索し、追加します。
《仮想クラウド・ネットワークの Configuration》
Configuration は「Networking - Virtual Cloud Networks - Outbound Data Transfer (B88327)」のみとなっています。OCI の仮想クラウド・ネットワークから外部に出ていくトラフィック量に応じた課金項目 で、メトリックは「Gigabyte Outbound Data Transfer Per Month」となっています。
この項目にも無償枠があり、月10TBまで無償 となっています。Cost Esitmator 上でも、「10240」GB までは 指定しても「￥0」の表示になります。
なかなか この「10TB」を超えて使用されるケースはないと思うので、あまり気にしないで良いかもしれません。
ちなみに、どこからが「アウトバウンド」とみなされるの？という点についてですが、同一リージョン内であれば VCNが異なっていても、別AD間であろうと、無償 になります。リージョンを跨ぐ場合や、インターネットに出ていく場合が「アウトバウンド」の対象となります。詳しくは、下記の資料を参考にしてください。
-
Outbound Data Transfer 課金のポイント (資料「OCI 課金にまつわるエトセトラ」より抜粋)
《仮想クラウド・ネットワークの Utilization》
仮想クラウド・ネットワークは使用したアウトバウンド転送量に応じた課金なので、正直日数や時間は関係ないのですが、このツールの仕様上 Utilization の項目もあります。特にデフォルト値のまま変更せず進めて良いと思います。
補足）バックボーン回線を使用する機能
各リージョン間は、Oracle が持つ「Backbone 回線」で結ばれています。この回線は、リージョンを跨いで VCN をリモート・ピアリングする場合などに使用されるだけでなく、各サービスの機能を利用する場合にも 使用されます。
例えば、オブジェクト・ストレージに保存してあるデータをコピーする場合、オブジェクト・ストレージをリージョン間で レプリケーション する場合、カスタム・イメージを別リージョンにコピーする場合、ブロック・ボリュームのバックアップを別リージョンにコピーする場合、などです。
こういった機能を利用する場合は、インターネットへの通信だけでなく、それらの機能で発生するトラフィック量も、「アウトバウンド転送量」として考慮する必要がある ということを忘れないようにしましょう。
補足）グローバルIPアドレス・NATゲートウェイにかかる費用
OCIでは、グローバルIPアドレスや、NATゲートウェイを利用する際、追加のコストは一切かかりません。
予約したグローバルIPアドレスが インスタンスにアタッチされていても いなくとも、費用は一切かかりませんし、NATゲートウェイの作成や、NATゲートウェイを通過するトラフィックに応じた追加コストも一切ありません。（外部に出るトラフィックは Outbound転送量(月10TBまで無料) のカウント対象にはなります。）
ロード・バランサ
いよいよ最後になります。最後は「ロード・バランサ」の見積りです。Cost Estimator 上では「Networking - Load Balancing」という Product 名になっています。
《ロード・バランサの Configuration》
Configuration には、「1. Networking - Load Balancing - Load Balancer Base (B93030)」と「2. Networking - Load Balancing - Load Balancer Bandwidth (B93031)」という２つの項目があります。
「1」については、使用するロード・バランサのインスタンス数 に応じた基本料 となっていて、インスタンスを時間当たりでいくつ使用するのか？でメトリックを指定します。ただし、テナントで 1インスタンスは 無償枠になりますので、2インスタンス目以降で コストが発生してきます。
「2」については、ロード・バランサの「帯域」を 時間当たり 何Mbps 使用するのか？を意味しています。使用する帯域に応じた料金が、「1」の基本料金に上乗りしてきます。
以前は、OCI のロード・バランサは 固定の帯域幅 (10Mbps, 100Mbps, 400Mbps, 8000Mbps) から選択して利用していく方式でしたが、最近、”フレキシブル・シェイプ” と呼ばれる、最小と最大の帯域幅を指定し、その中で、実際に使用される帯域幅が変動するタイプに変わりました。(最小値と最大値を同じ値にすることで変動なしの固定幅を使用することもできます)
ドキュメント には、その課金ロジックについて、以下のように記述されています。
ロードバランサーのベースインスタンスの請求は1分あたりで、帯域幅の使用料が加算されます。実際の使用量が 指定された最小帯域幅以下の場合、最小帯域幅に対して請求されます。実際の使用量が最小帯域幅を超える場合、その分に使用された実際の帯域幅に対して請求されます。
実際に利用される帯域幅に応じた見積を厳密に行うのは難しいと思うので、「平均してこの程度の帯域幅が使用される」という想定の元、ここのメトリックを設定するのが良いかと思います。
《ロード・バランサの Utilization》
ロード・バランサは、コンピュート・サービス等と異なり、「停止する」ということは出来ません。ただし、数日検証して削除するようなケースなどでは、こちらの Utilization を設定することで、利用する日数にあったコストの見積りが可能です。必要に応じて、編集してください。尚、OCI のロード・バランサは、１インスタンスで 内部的にプライマリ／スタンバイの冗長構成 となっています。
見積りのサンプル
最後に、実際に見積もってみるとどんな感じなの？という感触を知るため、試しに、以下の構成で見積もった例を紹介します。あくまで例なので、なんでこの構成？などと突っ込んではいけません…！
主な構成要素としては、ゲートウェイなどのコンポーネントを含む 仮想クラウドネットワーク (vcn) × １、ロード・バランサ × １、Windows OS の仮想マシン × １、Linux OS の仮想マシン × １、Oracle Database × １、オブジェクト・ストレージ × １、というシンプルな構成です。
月額 約4.6万円 という結果になりました。テナントに割り当てられた無料枠も考慮に入れいてるので結構お安く見えます。
仮想マシンについては 利用時間を削減することで 更にコストを抑えることも 可能 ですが、簡略化のために 24時間 × 31日、合計 744時間 起動し続けた場合の月額となっています。また、バックアップ分などは一旦考慮していません。
終わりに
いかがでしたでしょうか。個人でクラウドを勉強しようと思い立っても、思わぬ課金が怖くてなかなか手が進まない、という方は多いと思います。
今まで OCI を利用しようと思っても「どうやって試算したら良いのか分からない！」「情報少なすぎない？」と思われていた方にとって、本記事が少しでもお役に立てば幸いです。
補足になりますが、思わぬ課金を防ぐ／課金されても早期に発見するためにも、予算の設定 は 是非行うようにして頂ければと思います。
参考情報
その他、参考になる Webサイトをいくつか紹介しておきます。
1, 2 は特に、課金の考え方について細かく解説されていますし、動画もあるのでオススメです。3 ～ は少し古い情報にはなりますが、今も通用する考え方などが とても分かり易く記載されているので、是非こちらも参考にしてください。