CloudWatch カスタムメトリクスの課金に要注意！【無料利用枠】

Blog-Thumbnail_KUDs-01 AWS
2023.09.11

はじめに

こんにちは、KUDs です。

この記事では、EC2 Linux でカスタムメトリクスを取得している方向けに、CloudWatch のコストを抑える方法及び注意点について解説します。

想定される読者層

この記事では、主に以下のような方向けに執筆します。

  • EC2 Linux でカスタムメトリクスを取得したい/している方
  • 無料利用枠の「10 カスタムメトリクス」を超過しそうな方
  • AWS の無料利用枠を使い倒したい方
  • AWS 初心者で、費用とかがよくわかっていない方

AWS CloudWatch とは

月並みな概説です。
既にご存じの方は読み飛ばしてください。

まず、CloudWatch は AWS が提供する監視サービスです。
リソースやアプリケーションのパフォーマンスやログを監視し、異常を即座にキャッチできるように設計されています。
これによって、インフラの健全性や適切な動作が確保されるだけでなく、問題が発生した際の対応速度も大幅に向上します。

AWS 無料利用枠とは

AWS 無料利用枠は、AWS が提供するサービスの一部を無料で使用できる特典です。
初心者が AWS サービスを学んだり、プロトタイプ作成に非常に有用です。

無料利用枠には以下のようなカテゴリがあります。

  • 常に無料の利用枠
    • AWS が提供するいくつかのサービスは、一定の範囲内ならずっと無料で利用できます。
      例えば、DynamoDB では毎月 25 GB までのストレージが常に無料で利用可能です。
  • 12 か月間無料の利用枠
    • 新規 AWS アカウントを開設してから 12 か月間、AWS の主要サービスを無料で利用できます。
      例えば、EC2 や S3 など、様々なサービスがこの範疇に含まれます。
  • 試用期間の利用枠
    • 一部の AWS サービスは、新規にサービスを開始した日から一定期間無料で利用できます。

しかし、これらの無料利用枠は各サービスやリソースに制限があります。
もちろん、それらの制限範囲を超えると通常の料金が発生します。
そのため、無料利用枠を利用する際には、具体的な制限範囲の理解が重要です。

この記事では特に CloudWatch カスタムメトリクスの常に無料の利用枠について詳細と注意点を解説します。

CloudWatch メトリクスの基本と無料利用枠について

CloudWatch メトリクスの基本

まず、AWS CloudWatch メトリクスとは、AWS リソースやアプリケーションの動作を数値的に表現したものです。
例えば、EC2 インスタンスの CPU 使用率や、RDS のディスク空き容量など、多くの異なる情報がメトリクスとして収集・保存されます。

また、これらのメトリクスはリアルタイムでダッシュボードに表示されるほか、特定の閾値を超えた場合にアラートを送るトリガーとしても利用できます。

CloudWatch メトリクスの無料利用枠

現時点で CloudWatch 無料利用枠は以下の通りです。

  • 10 カスタムメトリクスおよび 10 アラーム
  • 100 万件の API リクエスト
  • 5 GB のログデータの取り込みおよび 5 GB のログデータのアーカイブ
  • 毎月最大 50 メトリクスのダッシュボード 3 個

CloudWatch では、カスタムメトリクスは 10 個まで無料利用可能です。

最新情報は AWS 公式ドキュメントをご参照ください。

無料利用枠超過アラートメール

AWS では、無料利用枠が超過しそうな際に対象のアカウントにアラートメールを発報します。
具体的には、無料利用枠の 85% を消費した時点でアラートが届きます。

例えば、CloudWatch メトリクスの無料利用枠が超過アラートメールは以下の通りです。

AWS Free Tier usage limit alerting via AWS Budgets 08/09/2023

Dear AWS Customer,

Your AWS account 123456789012 has exceeded 85% of the usage limit for one or more AWS Free Tier-eligible services for the month of August.

ProductAWS Free Tier Usage as of 09/09/2023Usage LimitAWS Free Tier Usage Limit
AmazonCloudWatch8.54973055 Metrics10 Metrics10.0 Metrics are always free per month as part of AWS Free Usage Tier (Global-CW:MetricMonitorUsage)

To learn more about your AWS Free Tier usage, please access the AWS Billing & Cost Management Dashboard. You can find more information on AWS Free Tier here.

E-Mail “AWS Free Tier limit alert”

上記のメールでは約 8.5 メトリクスを消費していることがわかります。
月間 10 メトリクスまでが無料利用枠のため、85% オーバーしていることがわかります。

また、メール送信 (9/9) 時点で 8.5 メトリクス消費しているため、このままでは月末までに大幅に無料利用枠を超過しそうなことがわかります。

つまり、費用を抑えるためには、このカウントされているメトリクス数を抑える必要があります。

CW Agent 設定ファイルの基本と罠

CW Agent 設定ファイルとは

EC2 Linux でカスタムメトリクスを取得する場合、CW Agent 設定ファイルによって対象メトリクスを制御します。
※CW Agent: CloudWatch Agent

あくまで一例ですが、設定ファイルは以下のような形式で記述されます。

# cat /opt/aws/amazon-cloudwatch-agent/bin/config.json
{
        "agent": {
                "metrics_collection_interval": 60,
                "run_as_user": "root"
        },
        "metrics": {
                "aggregation_dimensions": [
                        [
                                "InstanceId"
                        ]
                ],
                "append_dimensions": {
                        "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
                        "ImageId": "${aws:ImageId}",
                        "InstanceId": "${aws:InstanceId}",
                        "InstanceType": "${aws:InstanceType}"
                },
                "metrics_collected": {
                        "disk": {
                                "measurement": [
                                        "used_percent",
                                        "inodes_free"
                                ],
                                "metrics_collection_interval": 60,
                                "resources": [
                                        "*"
                                ]
                        },
                        "mem": {
                                "measurement": [
                                        "mem_used_percent"
                                ],
                                "metrics_collection_interval": 60
                        },
                        "swap": {
                                "measurement": [
                                        "swap_used_percent"
                                ],
                                "metrics_collection_interval": 60
                        }
                }
        }
}

上記の設定から、CW Agent によって以下のカスタムメトリクスが収集されていることがわかります。

  • disk_used_percent
  • disk_inodes_free
  • mem_used_percent
  • swap_used_percent

問題「カウントされるメトリクス数はいくらか？」

では、先程のCW Agent 設定ファイルにおいて、カスタムメトリクスはいくつカウントされるのでしょうか？

答えは、20 メトリクス / 月 です。

「え？ 4 メトリクス / 月 じゃないの？」

と思われたかもしれません。
この辺りに、CloudWatch カスタムメトリクスの罠があるので、しっかり把握しておきましょう。

append_dimensions には要注意

append_dimensions とは

CloudWatch Agentの設定パラメータの一つに「append_dimensions」があります。
先程の設定ファイルでは、以下のように記述されていました。
これによって、収集されるメトリクスに追加のディメンションを付与することができます。

            "append_dimensions": {
                    "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
                    "ImageId": "${aws:ImageId}",
                    "InstanceId": "${aws:InstanceId}",
                    "InstanceType": "${aws:InstanceType}"
            },

例えば、上記の設定では以下のような識別情報がカスタムメトリクスに付加されています。

  • AutoScalingGroupName: AutoScaling グループ名
  • ImageId: イメージ ID
  • InstanceId: インスタンス ID
  • InstanceType: インスタンスタイプ

CloudWatch メトリクスを実際に確認すると、しっかり追加されています。

CloudWatch メトリクス「append_dimensions ( mem_used_percent, swap_used_percent )」
CloudWatch メトリクス「append_dimensions ( mem_used_percent, swap_used_percent )」

メトリクス数に与える影響

append_dimensions を使用してディメンションを追加すると、そのディメンションの異なる組み合わせごとに新しいメトリクスが生成される可能性があります。
例えば、2 つの異なるインスタンス ID と 2 つの異なる AutoScaling グループ名を持つ場合、これらの全ての組み合わせに対してメトリクスが生成されるため、合計 4 つのメトリクスが作成されます。

冗長なディメンションを追加することによって、必要以上に多くのメトリクスが生成される可能性があります。
これによって、カスタムメトリクス数が増加し、費用が増加します。

disk メトリクスには要注意

disk メトリクスとは

CloudWatch Agent を利用してディスクのメトリクスを収集する際、様々な情報が取得されます。
これには、ディスクの使用率や I/O のステータスなどの基本的な情報の他、各ディスクやパーティションに関する情報も含まれます。
先程の設定ファイルでは以下のように記載されていました。

                    "disk": {
                            "measurement": [
                                    "used_percent",
                                    "inodes_free"
                            ],
                            "metrics_collection_interval": 60,
                            "resources": [
                                    "*"
                            ]
                    },

上記の設定から、ディスク使用量と inode 空き容量を取得していることがわかります。

disk メトリクスの追加ディメンション

disk メトリクスには、その情報がどのパーティションやディスクから収集されたかを示す「Partition」というディメンションがあります。
このディメンションは、異なるディスクやパーティションごとに異なる値を取ります。
このことは、実は公式ドキュメントにもしっかりと記載があります。

disk などの disk_used_percent メトリクスには Partition のディメンションがあります。つまり、生成されるカスタムメトリクスの数は、インスタンスに関連付けられたパーティションの数によって異なります。ディスクパーティションの数は、使用している AMI とサーバーにアタッチする Amazon EBS ボリュームの数によって異なります。

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html

予期しないディメンションの追加と課金の影響

システムの特定の状況下では、想定外のディメンションが生成されることがあります。
これによって、メトリクスの数が増加し、課金も増加する可能性があります。

例えば、tmpfs や devtmpfs などのシステムで使用される特別なパーティションは、一般的にユーザーが直接監視の対象とするものではありません。
しかし、CW Agent のデフォルト設定ではこれらのメトリクスも収集されます。
そのため、監視が必要なディスクやパーティションのみを指定する必要があります。
これによって、不要なメトリクスの収集を回避し、費用を抑えられます。

なお、先程の設定ファイルでは以下のようなメトリクスが生成されていました。

CloudWatch メトリクス「Partition ( disk_used_percent, disk_inodes_free )」
CloudWatch メトリクス「Partition ( disk_used_percent, disk_inodes_free )」

パーティションの指定が無かったため、各パーティション毎に生成されています。
また、disk_used_percent も同様に、各パーティションで生成されていました。

CW Agent 設定ファイルの修正とフェッチ

修正例

例えば、ルートのみのメトリクスを取得できれば良い場合は以下のように修正します。

                "disk": {
                        "measurement": [
                                "used_percent",
                                "inodes_free"
                        ],
                        "metrics_collection_interval": 60,
                        "resources": [
                                "/"
                        ]
                },

これによって、ルート ( “/” ) のメトリクスのみが収集されるようになります。
つまり、他の不要なディメンションやメトリクスの収集が排除されます。
結果として、CloudWatch の課金が削減されます。
加えて、エージェントの動作も軽量化される可能性があります。

CW Agent 設定ファイルのフェッチ

CloudWatch Agent 設定ファイルの修正は完了したでしょうか。
では次に、その変更を適用するために以下のコマンドを実行しましょう。

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

以下、コマンドオプションの簡単な補足です。

  • -a fetch-config:
    • 設定ファイルを適用する
    • ターゲットは -c で指定可能
  • -m ec2:
    • EC2 モード
    • ホストが EC2 であることを示す
  • -s:
    • 再起動オプション
    • 以下のアクションでのみ使用可
      • fetch-config
      • append-config
      • remove-config
  • -c file:
    • amazon-cloudwatch-agent の設定
    • SSM パラメータストア名、ホスト上のファイルパス等を指定可能

さいごに

以上で、カスタムメトリクス数の制御は完了です。
少し時間を開けて、AWS Billing から効果測定をしてみてください。

もし、まだカスタムメトリクスの導入を検討している段階の方は、是非今回の記事を参考に、費用を抑えられるか試してみてください。
また、導入手順については、以下の記事もやり方の参考になるかと思います。

【EC2】メモリ使用率・スワップ使用率を CloudWatch で表示する
はじめに おはようございます。KUDs です。 突然ですが、リソースのモニタリングはしておりますでしょうか。システムのパフォーマンスを保つため、インフラストラクチャの監視は重要です。 AWS には、CloudWatch という強力なモニタリ...
kuds.blog
2023.07.23
【EC2】メモリ使用率・スワップ使用率を CloudWatch で表示する

以上です。

コメント