この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
請求額の更新タイミングについて、公式サイトの変更にともない修正しています。（2020.06.12 時点）
園部です。
昨今の情勢もあり、お問い合わせなどから Amazon WorkSpaces の利用や導入検討をされる方が増えている印象を受けます。厳しい状況の中、ビジネスを継続するため、まずは環境を整えることが優先される課題となるかと思います。その上で検討しなければならないのでコストではないでしょうか。そこで今回は WorkSpaces のコスト最適化に役立つソリューションを紹介します。
OverView やデプロイ方法 については既に、弊社メンバーが記事にしてくれています！
この記事では何をするのか？
デプロイが完了している前提として、以下の二つをやってみます。
- WorkSpaces Cost Optimizer のパラメータ変更
- 料金モデルは変更せず CloudWatch Logs メトリクスフィルターで閾値を超えた場合に検知する
- 料金モデルの変更を検討した方がいいよ〜という指標として利用するケース
やってみた
Amazon WorkSpaces Cost Optimizer のパラメータ変更
CFn からデプロイする際に各種パラメータを設定しますが、途中で変更するケースが想定されます。例えば、ドキュメントによると数ヶ月 ドライラン をして ソリューションの結果を評価した方が良いと記載もあり デフォルトはドライランモードが有効になっています。また 時間課金と月課金モデルを評価する閾値は、損益分岐点付近がデフォルトの値として設定されています。この辺りは、どの程度シビアに設定するか、いつから自動でモデルを変更する設定とするかは、利用者によって判断が異なる部分ではないでしょうか。
引用元： AWS Solutions Amazon WorkSpaces Cost Optimizer - 実装に関する考慮事項
というわけで、運用中にパラメータを変更することがあるはずです！ こちらを今回やってみます。主に WorkSpaces のコストチェックに関するパラメータは以下の構成図の赤枠である Fargate で定義しています。
（引用元： AWS Solutions Amazon WorkSpaces Cost Optimizer ）
この辺りで設定しています。
さっそく、パラメータを変更していきます。
Amazon ECS >>> タスク定義 >>> wco-task を選択
設定を変更するタスク定義を選択 >>> アクション >>> 登録解除
Inactive に遷移しているため、先ほどのタスク定義を選択 >>> 新しいリビジョンの作成
新しい作成画面が表示されます。
中段の方へスクロール >>> コンテナ名 >>> wco2-container を選択
編集画面が表示されます。
中段の方へスクロール >>> 環境変数 に CFn で指定してパラメータがあります。
今回は、のちほど 検証するため StandardLimit: 81 → 1 に変更 >>> 更新 を選択
リビジョンの画面に戻ったら 保存 を選択
Active になっているタスクを選択して 環境変数で設定を確認します。
これでパラメータの変更は完了です。
CloudWatch Logs メトリクスフィルターで閾値を超えた場合に検知する
まずは WorkSpaces を1台起動しておきます。
- 時間課金モデル（AUTO_STOP）
- Standard
このソリューションは CloudWatch Events により 日次でチェック処理が行われます。
- 時間課金から月課金モデルへ
- 毎日 23:55 GMT にチェックが実行されて使用量を計算します。
- 月課金から時間課金モデルへ
- 月末にのみチェックが実行されます。
引用元： AWS Solutions Amazon WorkSpaces Cost Optimizer - 実装に関する考慮事項
なぜ、月課金から時間課金の変更が月末のみなのかは以下が参考になります。
Q: 時間単位の課金と月単位の課金を切り替えられますか?
はい。Amazon WorkSpaces の課金方法は、AWS マネジメントコンソールまたは Amazon WorkSpaces API を使用して実行モードを AlwaysOn に切り替えることで、いつでも時間単位から月単位に切り替えられます。切り替えると、すぐに課金方法が時間単位から月単位に変わり、その月の残りの日数分の使用料は月単位の料金の按分計算となり、その月の切り替え前の月単位と時間単位の使用料に追加されます。実行モードを再び AutoStop に切り替えない限り、引き続き Amazon WorkSpaces に対して月単位で課金されます。
AWS マネジメントコンソールまたは Amazon WorkSpaces API を使用して実行モードを AutoStop に設定することで、いつでも月単位の課金から時間単位の課金に切り替えられます。その月の Amazon WorkSpaces 料金のお支払いは済んでいるため、月単位の課金から時間単位の課金への切り替えは翌月に有効になります。実行モードを再び AlwaysOn に切り替えない限り、引き続き Amazon WorkSpaces に対して時間単位で課金されます。実行モードを再び AlwaysOn に切り替えない限り、引き続き Amazon WorkSpaces に対して時間単位で課金されます。請求額の更新は、毎月 1 日の 00:00 UTC に行われることにご注意ください。
また、このセルフサービスマネジメント機能が WorkSpaces 管理者によって有効化されている場合、WorkSpaces ユーザーは請求を月単位または時間単位のいずれかで WorkSpaces クライアントから直接切り替えることができます。
今回は検証のために、手動でチェック処理を実行します。
Lambda >>> WorkSpacesCostOptimizer-CostOptimizerCreateTaskFun-*** を選択
サンプルテストに名前をつけて作成 >>> テスト を選択
結果は CloudWatch Logs と S3 に出力されています。 今回は新しいデザインが使える CloudWatch Logs で見ていきます。
下段の方に、チェックを行った結果が出力されています。
INFO: Workspace 1 -> {'workspaceID': 'ws-xv31gcchz', 'billableTime': 1, 'hourlyThreshold': 1, 'optimizationResult': '-N-', 'newMode': 'AUTO_STOP', 'bundleType': 'STANDARD', 'initialMode': 'AUTO_STOP'}初期モードも新しいモードも AUTO_STOP（時間課金モデル）となっています。これは閾値を下回っているため、料金モデルを変更する必要がない状況です。
- initialMode : AUTO_STOP
- newMode : AUTO_STOP
WorkSpaces が閾値で指定した 1時間以上起動したのちに...
再び Lambda を実行します。
INFO: Workspace 1 -> {'workspaceID': 'ws-xv31gcchz', 'billableTime': 2, 'hourlyThreshold': 1, 'optimizationResult': '-M-', 'newMode': 'ALWAYS_ON', 'bundleType': 'STANDARD', 'initialMode': 'AUTO_STOP'}今後は、新しいモードが ALWAYS_ON（月課金モデル）となっています。 閾値を上回っているためです。
- initialMode : AUTO_STOP
- newMode : ALWAYS_ON
ドライランモードが有効なため、実際にはモード（料金モデル）は変更されていません。
閾値（モデルの変更を検討するタイミング）を超えると CloudWatch Logs に 'newMode': 'ALWAYS_ON' が出力されることがわかりました。'initialMode': 'AUTO_STOP' をセットで条件として、メトリクスフィルターを作成すれば、料金モデルを見直した方が良いことを検知することができそうです。
時間課金と月課金が混在している場合では newMode だけでは料金モデルの変更が必要かを判断することが出来ないため initialMode とあわせてメトリクスフィルターを作成します。今回は 時間課金から月課金への変更を条件としていますが、反対のパターンが必要であれば、もう一つメトリクスフィルターを作成することで可能です。
CloudWatch >>> ログ グループ >>> /ecs/wco-task/WorkSpacesCostOptimizer >>> メトリクスフィルター >>> メトリクスフィルターを作成 を選択
今回は早めに結果が欲しいので手動で処理を実行します。
CloudWatch >>> メトリクス >>> WorkSpaces_Cost_Check >>> ディメンションなし >>> StandardLimit を選択
ログにフィルター条件とした 時間課金 （AUTO_STOP） から月課金 （ALWAYS_ON） に変更した方が良い対象が検知できました。
あとは、アラームにしてメールなり Slack へ通知することで把握できそうです！
困ったこと
実は CloudWatch Events の実行タイミングを変更して メトリクスフィルタで検知するのを検証したかったのですが、CFn で作成した CloudWatch Events ルールを編集したところエラーとなりました。。
メッセージ内容からすると、ルールの名称が長いのが原因のようです。。 設定されているルールは簡単な内容ですので新しく作成するなどの回避できると思います。
さいごに
Amazon WorkSpaces Cost Optimizer を実際に利用するシーンを想定して、２つほどやってみました。恥ずかしながら WorkSpaces も Fargate も普段からあまり利用するサービスではなかったので、思ったより手間取ってしまいました。 WorkSpaces の状況を把握する方法として CloudWatch のメトリクスも有効な手段かと思います。
公式ドキュメント - CloudWatch メトリクスを使用して WorkSpaces をモニタリングする
33
