モビンギの幸道です。前回に引き続きAWSビリンクのネタ第４回です。
前回の内容で請求データCSVを使った集計方法について理解できたと思います。。
今回は、ビリンクレポートのタグとRI（リザーブドインスタンス）について、なんとなく福井弁でお送りしたいと思います。
福井弁で妄想シーン
上司 ー＞ 部下 （サーバー管理兼任）
上司）今月のぉサーバー利用コストやけどのぉ、タグで分類してほしいんやけどぉ、そんなんことできるんか？
部下）そうですねぇ、タグの管理をうまいことぉつけてくれればぁ、問題ないでのー。
ピー子さんー、うまことやってや。
２行書いてみて、名古屋が割長で福井５年在住なだけでは無理があると判断したため、通常通りでいきたいと思います。ただ、ドラマ版チアダンを見て、子供はあんな風にしゃべらんとは言いますが・・・そう聞こえてると思う今日この頃。
請求をタグで分類するとは？
弟２回で書いたタグを請求レコードに出力する設定をしているとCSVにタグ付きの請求レコードが出力されるようになります。
コスト配分タグを設定しておくとコストエクスプローラからタグによる分類ができるようにもなります。
レコードの末尾のほうに、「resourceTags/aws:[タグKey名]」または、「resourceTags/user:[タグKey名]」が並びます。
ビポットテーブルを作る場合、以下のようにしておくとアカウント・サービス単位で振分がみれるようになります。
横軸
lineItem/LineItemType
縦軸
resourceTags/xxxx
lineItem/UsageAccount
lineItem/ProductCode
タグの重複、タグの按分
リソースを複数の部門などに按分したい場合、タグを複数割り当てたいこともあると思います。しかし！？、同じキーのタグ割当は１つのみなので残念ながらタグの値のみでは、無理やりカンマ区切りで指定する等となり煩雑な状態になります。
または、按分用のタグを設けて振分作るなどでしょうか。この場合、タグ無し分と按分先が重複してしまうので、それなりに算出に労力がかかりますね・・・。
タグ無し分 ー 按分対象 ＝ 共通分
按分対象（該当分）/ 該当分数 ＝ 按分対象分コスト
Dept | Dept按分１| Dept按分２ | Dept按分３
EC2-AAAA （指定なし） 部署A 部署B
普通にカンマ区切りなどで複数部署を割り当てた方がマシですね。
指定キー分を、対象のタグに対して比率で振分けてくれると誰かが楽になるのかもー。
「DeptAAAA,BBBB」 の集計分 ー＞ ７：３で「DeptAAAA」 と 「DeptBBBB」 に按分。
請求のRI利用分を見てみる
上司）ちょっと今月なんだけど、コスト削減になるからって一部RI利用してもらったんだけど、集計どうなる？
部下）え！？そうなんですか。前払いで購入する場合、会社の経理ルールによっては計上方法が通常のサーバー利用と異なることがあるので、その点を経理部の方に確認してますか？
上司）おーそうなのか。ちょっと詳しく説明してよ。
部下）RIの購入種類によって請求データに入ってくる状態が異なるのと、前払いになる場合、会社によっては計上方法が異なることがあるので、データの出し方を経理部に確認してもらう必要もありますね。
RI（リザーブドインスタンス）と購入種類
RI（リザーブドインスタンス）とは、期間契約による前払い、または、後払いによって「サーバー利用料をディスカウントできる権利」を購入してるに過ぎません。
まあ、正直わかりずらいですね。AWS を利用していてもRIの購入になると敷居が高い感があります。
購入方法ですが、EC2の場合だと主には「インスタンスタイプ、支払方法、契約期間」を指定して購入します。
インスタンスタイプ：t2.microなどのサイズになります。
スコープ(regionやAZ）、テナンシー、プラットフォーム（OS）
支払方法：
すべて前払い（All Upfront）、一部前払い（Partial Upfront）、前払いなし（No Upfront）
契約期間：１２ヶ月、３６ヶ月
携帯電話の２年縛りみたいなものですね。ただ確実に起動できることを保証してるようなので、その辺が利用メリットにもなってきます。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-reserved-instances.html
RI（リザーブドインスタンス）の運用
基本的な購入方法を説明しましたが、実際の運用でどうするのか疑問があるところです。
権利を購入しているだけなので、実際には適用対象になるサービスを利用しなくてはいけません。
また、一部前払い・後払いを選択した場合、契約期間中、RI適用対象が無い状態でも常に請求が発生します。
例えばEC2の場合、購入したRIと同条件のインスタンスを起動することになります。この状態で初めてRIが適用された状態になります。
購入したRIの適用状況をコストエクスプローラのレポートで確認することができるので、日々チェックしながらサーバの利用割当を調整するなどの作業が必要になります。つまり適用状況１００％が理想であり下回った状態の場合、前払いや後払いで発生するコストが無駄になることになります。
一定のディスカウントがついてると考えると、一定の割合で運用する分にはOnDemand以下で運用できることになります。
購入計画
RI（リザーブドインスタンス）を前払いで購入する場合、最初から１００％適用されるように全利用対象分を購入すると、契約期間を更新のタイミングで大きな支払コストが発生することになります。
利用想定の６割などに抑えて時期をずらして購入することで、大きな支払を抑制したり実際の利用のブレを吸収する効果が期待できます。
利用変動とRI購入計画のイメージ
RI（リザーブドインスタンス）の請求レコード
RIの請求レコードはどのように出力されるのでしょうか。これらは、lineItem/LineItemTypeに「RIFee, DiscountedUsage」として出力されます。
Fee:
前払い分がリザーブドインスタンス購入の翌日にビリングレポートに出力されます。
RIFee:
定額課金対象のリザーブドインスタンス分の課金が出力されます。
DiscountedUsage:
リザーブドインスタンスが適用されたインスタンスサイズの利用料に対して適用時間とコストが出力されます。
主には、この３つのレコードを確認していきます。
FeeやRIFeeについては過去購入を請求レコードで追うことは出来ないのでビリングレポートを設定以前に購入しているRIがある場合、別途抽出するかEC2のコンソールなどで確認する必要があります。
RI（リザーブドインスタンス）のまとめ
利用分全てを一気にRI購入はオススメしません、ご利用は計画的に。
RI絡みのコスト適用についてはブレンドレートなるものがあるのですが、次回その部分について書きたいと思います。
ではでは、また来週〜。
４回目
９．５ ダグで集計したいって・・・
１０ RI買いたいってさ
次回以降の連載ネタはこんな予定。
１１ RIの闇にせまる
１２ なんか良いツールないか探す
