こんにちは、CSM課の城です。
本日はAmazon WorkSpaces Cost Optimizer（以下、Cost Optimizer）のご紹介です。
WorkSpacesのAlwaysOn(定額課金)、AutoStop（従量課金）がどっち使っていいか分からないという方や、そもそもWorkSpacesの数が多すぎて、手動で変更とかやってられないよー、という方にお勧めのソリューションです。
前々から触ろう、やってみよう、と思いつつ触らないまま1年近くたってしまいました。
一念発起してブログにしたいと思います。
1.Amazon WorkSpaces Cost Optimizerとは
Cost OptimizerはAWS ソリューションの中の一つであり、AWSが提供する、一般的な問題解決のための検証済みのテクニカルリファレンス実装です。
ユーザーの個別の使用状況に基づき、請求モデル（AlwaysOn(定額課金)、AutoStop（従量課金））を自動的に変更してくれます。
https://aws.amazon.com/jp/solutions/amazon-workspaces-cost-optimizer/
動作概要としては、スケジュールトリガーであるCloudWatch Event RuleからLambdaが呼び出され、Fargateを実行し、Directory Service、CloudWatchから情報を収集します。
それをもとにWorkSpacesの実行モードを変更し、ログをS3に出力します。
AWS ソリューションについては、下記のページをご覧ください。色々なソリューションが紹介されています。
https://aws.amazon.com/jp/solutions/
2.Amazon WorkSpaces Cost Optimizerをローンチしてみる
CloudFormationテンプレートが用意されており、ぽちぽちパラメータを入れていくことで簡単にローンチできます。
下記ページのドキュメントのお勧めどおり、とりあえずはDryRunでローンチしてみます。
DryRunでローンチすると実行モードの変更はされないそうです。
CloudFormationダッシュボードにて、[スタックの作成]をクリックします。
テンプレートソースは[Amazon S3 URL]のまま、URL欄には下記のURLを入力し、[次へ]をクリックします。
https://s3.amazonaws.com/solutions-reference/workspaces-cost-optimizer/latest/workspaces-cost-optimizer.template
スタックの詳細を指定の画面では[スタックの名前]に任意の名前、[Launch in Dry Run Mode]をYesを入力し、[次へ]をクリックします。
スタックオプションの設定はそのまま[次へ]をクリックします。
最後にレビューはパラメータを確認して問題なければ、最下部にある[AWS CloudformationによってIAMリソースが作成される場合があることを承認します。]をチェックし、[スタックの作成]をクリックします。
ステータスがCreate_Completeになれば完了です。
3.DryRunしてみる
CloudWatch Event Ruleにデフォルトでは次のように設定されており、GMTの23:55に実行されます。
実行時間を変更するにはこちらのcron式を変更すればよいです。
CloudWatch Eventが発動するとFargateが1台起動されます。
実行結果がS3にCSVで次の名前で保存されていました。
cost-optimizer-costoptimizerbucket-************/YYYY/MM/DD/ap-northeast-1_d-**********_daily_dry-run.csv
内容は下記について記録されています。
WorkspaceID：WorkSpace ID Billable Hours：利用した時間 Usage Threshold：閾値（CloudFormationのパラメーターで指定したもの） Change Reported：変更内容（例；NoChange,ToMonthlyなど） Bundle Type：バンドルタイプ（Value、Standard、Performanceなど） Initial Mode：Cost Optimizer実行前のモード New Mode：Cost Optimizer実行後のモード
今回はDryRunなので、AutoStopのままでした。
実行完了後、しばらくするとFargateは削除されていました。お財布にやさしいですね！！
4.本番実行用にCloudFormationを更新する
次は本番実行時のように実際に実行モードが変更されるよう試してみたいと思います。
先ほど作成したCloudFormationスタックを開き、[更新する]をクリックします。
テンプレートの準備の画面では[現在のテンプレートの使用]にチェックをいれ、[次へ]をクリックします。
スタックの詳細を指定の画面では[Launch in Dry Run Mode]をNoへ、[Standard Limit]を3へ変更し、[次へ]をクリックします。
※今回はWorkSpacesのStandardを利用しており、閾値をあえて越えるようにStandard Limitの値を3へ変更しています。
スタックオプションの設定はそのまま[次へ]をクリックします。
最後にレビューはパラメータを確認して問題なければ、最下部にある[AWS CloudformationによってIAMリソースが作成される場合があることを承認します。]をチェックし、[スタックの更新]をクリックします。
ステータスがUpdate_Completeになれば完了です。
5.本番実行の挙動について – 閾値を上回った場合（AutoStop⇒AlwaysOn）
DryRunの時と同様CloudWatch Eventを発動させてみます。
DryRun時と同様にFargateが1台起動され処理が実行されます。
実行結果のCSVファイルは_dry-runが除かれ、次の名前で保存されていました。
cost-optimizer-costoptimizerbucket-************/YYYY/MM/DD/ap-northeast-1_d-**********_daily.csv
閾値も変更して条件に引っかかりWorkSpacesの実行モードが変更された結果となっていました。
なお、特定のWorkSpacesを自動実行モード変更の対象から外したい場合、WorkSpacesのタグkeyにSkip_Convert、Valueに任意の値を設定すると対象から外れます。 https://docs.aws.amazon.com/solutions/latest/workspaces-cost-optimizer/considerations.html]
6.本番実行の挙動について – 閾値を下回った場合（AlwaysOn⇒AutoStop）
閾値を下回った場合については条件があります。
GMTで月末の日付（例えば3/31）の場合は実行モードが変更されますが、その他の場合はAlwaysOnのままとなります。
テストする場合はスタックのパラメータのSimulate End of Month CleanupをYesにすることで月末時の挙動をテスト可能です。
実行結果のCSVファイルは次の名前で保存されていました。
cost-optimizer-costoptimizerbucket-************/YYYY/MM/DD/ap-northeast-1_d-**********_end-of-month.csv
7.月の途中で実行モードを変更した際の課金について
こちらについてはFAQに記載があった内容を引用します。
いつでも時間単位から月単位に切り替えられます。切り替えると、すぐに課金方法が時間単位から月単位に変わり、その月の残りの日数分の使用料は月単位の料金の按分計算となり、その月の切り替え前の月単位と時間単位の使用料に追加されます。実行モードを再び AutoStop に切り替えない限り、引き続き Amazon WorkSpaces に対して月単位で課金されます。
—-途中略—-
いつでも月単位の課金から時間単位の課金に切り替えられます。その月の Amazon WorkSpaces 料金のお支払いは済んでいるため、月単位の課金から時間単位の課金への切り替えは翌月に有効になります。
—-途中略—-
請求額の更新は、毎月 1 日の太平洋標準時 00:00 に行われることにご注意ください。
https://aws.amazon.com/jp/workspaces/faqs/
30日の月で、1日からAutoStopで起動、15日にStandardのデフォルト閾値85hを越えAlwaysOnに変更された場合のWorkSpaces利用料金（東京リージョン）を試算してみます。
AutoStopの月額料金：14USD
時間料金：0.36USD/時間 × 85時間 = 29.75USD
AlwaysOnの月額料金：43USD × 15日/30日 = 21.5USD
合計：65.25USD
AlwaysOnの月額料金に比べるとやはり割高ですね。
※Standard ルートボリューム80GB ユーザーボリューム50GBの料金で計算 https://aws.amazon.com/jp/workspaces/pricing/
8.本番利用時における注意点の考察
これまでに確認した仕様から注意点を考察してみると、下記のポイントについては注意した方がよりコストを抑えられそうです。
- 予め利用時間が目安として80時間を越えそうな利用のユーザーについてはAlwaysOn、かつ、
Skip_Convertタグを指定しておく - 普段は利用が少ないユーザーで特定の月のみ利用が増えてしまった場合は 手動でのAutoStopへの変更を検討
ただし、その辺りを管理する人のコストもあると思うので、バランスを見て利用するのが良いと思います。
たとえば、DryRunのままにしておき、実行モード設定の参考にするのも良いでしょう。
さいごに
試してみると思ったよりも容易にデプロイでき、数百台レベルで運用されているお客様にとってはかなり有用な機能かと思われます。
AWSソリューションは他にも便利なソリューションがあるようなので、チェックしていきたいと思います。
ではでは。
城 航太 (記事一覧)
営業部カスタマーサクセス課・課長
AWSへの移行、AWSアカウントセキュリティ、ネットワーク広く浅くといった感じです。最近はAmazon WorkSpacesやAmazon AppStream2.0が好きです。APN Ambassador 2019,2020
