適用対象のサービス全体の利用料において何%までカバーできているのか?」を示すものです。このグラフをみると、狙った「70%」ではなく平均して62%程度のカバー率であったことがわかります。購入する余地があることがわかります。確認すると良いでしょう。コミット余力があることがわかりました。コミットすることでほぼほぼカバレッジは100%に近づくと予想されますが今回は追加購入を検討しないことにしました。理由については以下の通りです。Instance」などが破棄された場合に、突然利用料が下がることもあります。悪化し最悪の場合損を生む可能性があります。程度の適用率」で留めるようにしておこうと考えています。この辺りの「SP購入戦略」はAWSの利用方法や状況によって異なってきますため、一概にこうすべきであるということは申し上げられるものではありませんため、本ブログは1つの目安と捉えて頂けますと幸いです。よってカバーされたFamily及びRegionが表示されます。Plan」で降順に並べてみました。カバーされていたのは東京リージョンのt2ファミリーであることがわかります。跨いで適用されていることもよくわかります。Plan」最大のメリットと言えるでしょう。利用率が100%未満になったら通知を行う」など、Utilizationの値を「しきい値」として設定するアラートになります。常に100%ですが、「いつの間にか100%を割っている!?」という状況にすぐ気づけるようにしたいため、これを設定します。budget」を押下して進めていきます。budget」を押下して次に進みます。Plan」にしました。種類でそれぞれ閾値を設定可能となっていますため今回は分けることにしました。Plan」の通知を作成していきます。「Period」は「Daily」を選択します。閾値ですが100%未満になった場合にアラートが欲しいため「100」を入力します。することで、100%未満になればすぐにアラートが飛びます。alerts」を押下して次に進みます。ここで、通知先を選択します。具体的な設定方法は以下のAWS公式ブログをご参考ください。budget」を押下して確認画面に進みます。Chatbothttps://aws.amazon.com/jp/blogs/devops/running-aws-commands-from-slack-using-aws-chatbot/設定を確認し、問題がなければ「Create」でBudgetを作成します。Instance」を選択して作成を行います。他の設定は先ほどと同様です。この通り、2つのアラート設定が完成しました。推移していますので、アラートは発生しません。補足しますとカバレッジでも同様の通知設定が可能です。追加で購入検討する」というシナリオでカバレッジの通知は有用です。一般的には「土日はカバレッジが上昇し、平日はカバレッジが低下する」傾向にある点はご留意ください。カバーされないために発生します。同様と考えております。通知は72時間程度遅延するBudgetsからアラートが来たタイミングでマネジメントコンソールにてUtilizationを実際に確認すると、およそ72時間前(3日前)の値になっています。12月31日に通知されるアラートは、実際には12月28日の結果で送信されます。連携にさらに24時間かかるためと推測されます。よって、最新の値を見たい場合はマネジメントコンソールからUtilizationを見たほうがより新しい値が確認できます。月初は通知が来ないAWSは月末締めを行い、月初に先月の利用料金を確定させますが、その計算のために膨大なリソースを用います。アラートの通知が届きません。「その月の1日から3日間くらいまでは通知がこない」という仕様である点は理解して運用を行う必要があります。見に行くこととなります。閾値を変更すると再度通知が行われる場合があります。これは再設定を行った場合に通知のキューが再度投げ込まれるためと想定されます。設定でも再度通知が発生します。通知処理が実行されると上の画像の通りの投稿が行われます。用いて利用率の監視通知を行う方法について記載しました。購入するだけでなく「どの程度の費用削減効果が実際にあったのか」を把握するのも非常に重要です。それではまたお会いしましょう。エンジニアブログ.TOP。