AWSフリーティア超過を防ぐ：CloudWatch請求アラームで$5超えをメール通知する設定手順

AWSアカウントを作成したばかりのとき、フリーティアの範囲内で収まっているつもりが、月末に予想外の請求が届いた——そういう経験をしたエンジニアは少なくない。CloudWatchの請求アラームを使えば、推定料金が指定した閾値を超えた時点でメール通知を受け取れる。この記事では、推定料金が$5を超えた場合にアラートを送る設定を、CLIとコンソール両方の手順で解説する。

TL;DR：請求アラーム設定の概要

手順内容注意点
1. 請求アラートを有効化アカウントの請求設定でモニタリングを有効にするus-east-1リージョン限定の操作
2. SNSトピック作成メール通知用のSNSトピックとサブスクリプションを作成サブスクリプション確認メールへの承認が必要
3. CloudWatchアラーム作成EstimatedChargesメトリクスに$5の閾値を設定メトリクスはus-east-1にのみ存在する
4. 動作確認アラームの状態とSNS連携を確認メトリクスデータは数時間遅延する場合がある

請求アラームの仕組みを理解する

CloudWatchの請求アラームは、AWSが内部で集計する推定請求額（EstimatedCharges）メトリクスを監視する。このメトリクスはAWSサービス全体の推定コストを反映しており、us-east-1リージョンにのみ存在する。他のリージョンでは参照できないため、アラームの作成もus-east-1で行う必要がある。

メトリクスの更新頻度はおおよそ数時間ごとであり、リアルタイムの課金状況を反映するものではない。あくまで推定値であることを前提に運用する必要がある。

通知の経路はSNS（Simple Notification Service）を経由する。CloudWatchアラームがSNSトピックにメッセージをパブリッシュし、そのトピックにサブスクライブしたメールアドレスへ通知が届く。

graph LR A["AWSサービス利用
EC2 / S3 など"] --> B["推定料金を集計
数時間ごとに更新"] B --> C["EstimatedCharges
メトリクス (us-east-1)"] C --> D["CloudWatchアラーム
閾値: $5"] D -->|"閾値超過"| E["ALARM状態に遷移"] E --> F["SNSトピックへ
メッセージ送信"] F --> G["メール通知受信"]
  1. AWSサービス利用：EC2、S3などの利用料金が発生する
  2. 推定料金の集計：AWSが内部でEstimatedChargesメトリクスを更新（数時間ごと）
  3. CloudWatchが監視：設定した閾値（$5）と比較する
  4. アラーム状態に遷移：閾値を超えるとALARM状態になる
  5. SNSへ通知：SNSトピックにメッセージがパブリッシュされる
  6. メール受信：サブスクライブしたアドレスにメールが届く

前提条件：請求アラートの有効化

CloudWatchで請求メトリクスを利用するには、まずアカウントレベルで請求アラートを有効化する必要がある。この設定はAWSマネジメントコンソールのアカウント設定から行う。CLIで直接この設定を変更するAPIは現時点では提供されていないため、コンソールから操作する。

手順：

  1. AWSマネジメントコンソールにルートユーザーまたは請求情報へのアクセス権を持つIAMユーザーでサインインする
  2. 右上のアカウント名をクリックし、「請求とコスト管理」を選択する
  3. 左メニューから「請求設定」を開く
  4. 「CloudWatch請求アラートを受け取る」にチェックを入れて保存する
この設定はアカウント全体に適用される一度きりの操作だ。有効化後、EstimatedChargesメトリクスがus-east-1に表示されるまで数時間かかることがある。

ステップ1：SNSトピックとサブスクリプションを作成する

CloudWatchアラームが通知を送るためのSNSトピックを先に作成する。アラームを先に作ってしまうと、通知先が未確定のまま設定が完了してしまう。SNSのサブスクリプション確認（メールへの承認リンクのクリック）が完了していないと、実際にアラームが発火しても通知が届かない。

# SNSトピックを作成する（us-east-1で実行すること）
aws sns create-topic \
  --name billing-alert-topic \
  --region us-east-1

コマンドの出力にTopicArnが含まれる。次のステップで使用するため、この値を控えておく。

# メールアドレスをサブスクライブする
# TopicArnは上のコマンドで取得した値に置き換えること
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:billing-alert-topic \
  --protocol email \
  --notification-endpoint your-email@example.com \
  --region us-east-1

コマンド実行後、指定したメールアドレスにAWSから確認メールが届く。メール内の「Confirm subscription」リンクをクリックして承認を完了させる。この承認が完了するまで、SNSはそのアドレスへの通知を送信しない。

ステップ2：CloudWatch請求アラームを作成する

SNSサブスクリプションの確認が完了したら、CloudWatchアラームを作成する。EstimatedChargesメトリクスはus-east-1にのみ存在するため、アラームも必ずus-east-1で作成する。他のリージョンで作成しようとしてもメトリクスが見つからない。

aws cloudwatch put-metric-alarm \
  --alarm-name "FreeTierBillingAlarm" \
  --alarm-description "推定料金が$5を超えた場合に通知する" \
  --metric-name EstimatedCharges \
  --namespace AWS/Billing \
  --statistic Maximum \
  --period 86400 \
  --threshold 5 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:billing-alert-topic \
  --dimensions Name=Currency,Value=USD \
  --treat-missing-data notBreaching \
  --region us-east-1

各パラメータの意図を補足する：

  • --period 86400：評価期間を86400秒（24時間）に設定する。EstimatedChargesは頻繁に更新されないため、短い期間を設定しても意味がない
  • --statistic Maximum：期間内の最大値で評価する。請求額の監視には最大値が適切
  • --treat-missing-data notBreaching：メトリクスデータが存在しない場合（アカウント作成直後など）にアラームがALARM状態にならないようにする
  • --dimensions Name=Currency,Value=USD：通貨をUSDに指定する。このディメンションは必須

ステップ3：アラームの状態を確認する

アラームを作成した直後は、メトリクスデータが不足しているためINSUFFICIENT_DATA状態になることがある。これは正常な動作だ。数時間後にEstimatedChargesメトリクスが更新されると、OK状態またはALARM状態に遷移する。

aws cloudwatch describe-alarms \
  --alarm-names "FreeTierBillingAlarm" \
  --region us-east-1

出力のStateValueフィールドで現在の状態を確認できる。OK、ALARM、INSUFFICIENT_DATAのいずれかが返る。

IAMポリシー：必要な権限

IAMユーザーでこれらの操作を行う場合、以下の権限が必要になる。ルートユーザーでの日常操作は推奨されないため、専用のIAMユーザーまたはロールで操作することを前提にしている。

🔽 IAMポリシーの例（クリックして展開） 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SNSOperations",
      "Effect": "Allow",
      "Action": [
        "sns:CreateTopic",
        "sns:Subscribe",
        "sns:ListTopics"
      ],
      "Resource": "*"
    },
    {
      "Sid": "CloudWatchBillingAlarm",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:PutMetricAlarm",
        "cloudwatch:DescribeAlarms",
        "cloudwatch:GetMetricStatistics"
      ],
      "Resource": "*"
    }
  ]
}

なお、請求設定の変更（請求アラートの有効化）はIAMポリシーだけでなく、アカウントレベルの請求情報へのアクセス許可も必要になる。IAMユーザーに請求情報へのアクセスを許可するには、アカウントのルートユーザーがIAMアクセスの有効化を行う必要がある。

よくある失敗パターン：メトリクスが見つからない

アラームを作成したのにINSUFFICIENT_DATAのまま変化しない、あるいはCLIでメトリクスを確認しようとしても何も返ってこない——この状況に陥ったとき、最初に疑うのはリージョンの指定ミスだ。

実際にあった誤りのパターン：ap-northeast-1（東京リージョン）でアラームを作成してしまい、EstimatedChargesメトリクスが永遠に見つからない。コンソールで確認するとアラームは存在するが、メトリクスとの紐付けが機能していない状態になる。

正しい診断手順：

# us-east-1でEstimatedChargesメトリクスが存在するか確認する
aws cloudwatch list-metrics \
  --namespace AWS/Billing \
  --metric-name EstimatedCharges \
  --region us-east-1

このコマンドがメトリクスを返さない場合、請求アラートが有効化されていないか、有効化後の反映待ちの可能性がある。us-east-1以外のリージョンで実行しても結果は返らない。

もう一つの見落としやすいポイント：SNSサブスクリプションの承認を忘れていること。アラームがALARM状態に遷移してもメールが届かない場合、まずSNSコンソールでサブスクリプションのステータスを確認する。

aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:us-east-1:123456789012:billing-alert-topic \
  --region us-east-1

SubscriptionArnがPendingConfirmationになっていれば、確認メールの承認が完了していない。

設定フローの全体像

graph TD A["1. 請求アラート有効化
コンソールのアカウント設定"] --> B["2. SNSトピック作成
us-east-1"] B --> C["3. メールアドレスをサブスクライブ"] C --> D{"4. 確認メールを承認したか？"} D -->|"未承認"| E["確認メールの
リンクをクリック"] E --> D D -->|"承認済み"| F["5. CloudWatchアラーム作成
us-east-1 / $5閾値"] F --> G["6. アラーム状態を確認
describe-alarms"] G --> H{"StateValueは？"} H -->|"OK"| I["設定完了 ✓"] H -->|"INSUFFICIENT_DATA"| J["数時間待機後に再確認"] H -->|"ALARM"| K["メール通知を確認"]
  1. 請求アラート有効化：コンソールのアカウント設定から一度だけ実施する
  2. SNSトピック作成：通知の宛先となるトピックを用意する
  3. メール承認：サブスクリプション確認メールを承認しないと通知が届かない
  4. CloudWatchアラーム作成：us-east-1でEstimatedChargesを監視するアラームを設定する
  5. 状態確認：INSUFFICIENT_DATAからOKへの遷移を確認して設定完了

まとめと次のステップ：請求アラームの設定を完了させる

CloudWatch請求アラームの設定は手順自体は単純だが、us-east-1限定のメトリクスとSNSサブスクリプションの承認という2つの落とし穴を知っているかどうかで、設定が機能するかどうかが決まる。$5という閾値はフリーティアの早期警告として機能するが、実際のフリーティア上限はサービスごとに異なるため、AWS Cost Explorerや予算アラート（AWS Budgets）との併用も検討する価値がある。

AWS Budgetsを使うと、サービス別の使用量アラートや、フリーティアの使用率に対するアラートも設定できる。CloudWatch請求アラームは推定料金の総額監視に適しており、より細かいサービス別の監視にはAWS Budgetsが補完的に機能する。

用語集

用語説明
EstimatedChargesAWSが集計する推定請求額のCloudWatchメトリクス。us-east-1にのみ存在し、数時間ごとに更新される
SNSトピックメッセージの配信先となるエンドポイント。CloudWatchアラームはここにメッセージをパブリッシュする
サブスクリプション確認SNSがメールアドレスへの通知を開始する前に必要な承認プロセス
INSUFFICIENT_DATA評価に必要なメトリクスデータが不足している場合のアラーム状態。アラーム作成直後に発生することがある
treat-missing-dataメトリクスデータが存在しない場合のアラーム評価動作を制御するパラメータ

コメント

コメントを投稿

このブログの人気の投稿

EC2 SSH接続タイムアウトの原因と修正方法 — セキュリティグループのインバウンドルール完全ガイド

新しいEC2インスタンスを起動してSSH接続を試みたとき、 ssh: connect to host xx.xx.xx.xx port 22: Connection timed out というエラーで止まった経験は多くのエンジニアにある。アプリケーションのエラーではなく、パケットがインスタンスに届いていないことを示すタイムアウトだ。原因の大半はセキュリティグループのインバウンドルール設定にあるが、それだけで解決しないケースも存在する。 TL;DR — EC2 SSHタイムアウトの主な原因と対処 原因レイヤー 確認項目 修正方向 セキュリティグループ ポート22のインバウンドルールが存在するか TCP 22をソースIPに対して許可 ネットワークACL サブネットレベルでポート22がブロックされていないか インバウンド/アウトバウンド両方のルールを確認 パブリックIPアドレス インスタンスにパブリックIPが割り当てられているか ElasticIPの関連付けまたはパブリックIP自動割り当ての有効化 インターネットゲートウェイ VPCにIGWがアタッチされているか IGWを作成してVPCにアタッチ ルートテーブル サブネットのルートテーブルに0.0.0.0/0 → IGWのルートがあるか デフォルトルートをIGWに向ける EC2 SSH接続の仕組み — パケットが届くまでの経路 SSHタイムアウトを正確に診断するには、クライアントのパケットがEC2インスタンスに到達するまでに通過するレイヤーを理解する必要がある。セキュリティグループだけを見て終わりにすると、別のレイヤーでブロックされているケースを見逃す。 graph LR Client["クライアント ローカルマシン"] -->|"TCP SYN port 22"| IGW["インターネット ゲートウェイ (IGW)"] IGW --> RT["ルートテーブル 0.0.0.0/0 → IGW"] RT --> ...
続きを読む

S3パブリックアクセス拒否の原因と解決策：バケットレベルの「Block Public Access」が優先される仕組み

S3に画像をアップロードしてオブジェクトACLを「public-read」に設定したのに、URLにアクセスすると「Access Denied」が返ってくる。オブジェクト単体の設定は正しいはずなのに、なぜ拒否されるのか——この問題の原因はほぼ確実に、バケットレベルの「Block Public Access」設定にある。オブジェクトACLより上位のレイヤーが存在することを知らないと、何度設定を変えても解決しない。 TL;DR：S3パブリックアクセス拒否の原因まとめ 確認レイヤー 設定項目 影響範囲 アカウントレベル S3 Block Public Access（アカウント全体） 全バケットに適用 バケットレベル S3 Block Public Access（バケット個別） そのバケット内の全オブジェクト バケットポリシー Principal: * を許可するポリシーの有無 ポリシーで指定したリソース オブジェクトACL public-read ACL 個別オブジェクト 結論： オブジェクトACLを「public-read」にしても、バケットまたはアカウントレベルの「Block Public Access」が有効な場合、そのACLは無効化される。上位レイヤーの設定が下位を上書きする構造になっている。 S3パブリックアクセス制御の仕組み：なぜオブジェクトACLだけでは不十分か S3のアクセス制御は複数のレイヤーが重なって機能する。オブジェクトACLはその中で最も下位のレイヤーに位置する。AWSは2018年以降、誤ったパブリック公開によるデータ漏洩を防ぐため「Block Public Access」という上位の制御機構を導入した。この設定が有効な場合、オブジェクトACLやバケットポリシーで「public」を許可しようとしても、Block Public Accessがそれを遮断する。 Block Public Accessには4つの独立した設定項目がある。それぞれが異なるシナリオをカバーしており、全部オフにしないとパブリックアクセスが通らないケースもある。 graph TD A[...
続きを読む

EC2インスタンスIDをメタデータから取得する方法 — IMDSv2が安全な理由

サーバー上で動作するスクリプトから自分のインスタンスIDを取得したい場面は多い。デプロイスクリプト、ログ集約、Auto Scalingグループのインベントリ管理など、用途は様々だ。ただし、EC2インスタンスメタデータサービス（IMDS）には2つのバージョンが存在し、 IMDSv1とIMDSv2の選択はセキュリティ上の重大な差異 を生む。本番環境でIMDSv1を使い続けることは、SSRF（Server-Side Request Forgery）攻撃の踏み台になるリスクを放置することと同義だ。 TL;DR — IMDSv1 vs IMDSv2 早見表 観点 IMDSv1 IMDSv2 認証方式 なし（直接GETのみ） セッショントークン必須（PUT → GET） SSRF耐性 なし あり（PUT不可なSSRFはトークン取得不可） TTL制御 なし X-aws-ec2-metadata-token-ttl-secondsで指定 デフォルト状態 新規インスタンスでも有効（設定次第） IMDSv2-onlyに変更可能 推奨度 非推奨 AWS公式推奨 IMDSの仕組み — なぜインスタンス内からだけ到達できるのか EC2インスタンスメタデータサービスは、リンクローカルアドレス 169.254.169.254 で提供される。このアドレスはRFC 3927で定義されたリンクローカル範囲であり、インスタンスのネットワークインターフェース外には到達できない。つまり、インターネット経由や他のインスタンスから直接アクセスすることは原理的に不可能だ。 ただし、 SSRF脆弱性があるアプリケーションが動作している場合は話が変わる 。攻撃者がアプリケーションを経由して http://169.254.169.254/latest/meta-data/iam/security-credentials/ へリクエストを誘導できれば、インスタンスにアタッチされたIAMロールの一時クレデンシャルを盗める。IMDSv1はこのシナリオに対して無防備だ。 graph TD subgraph v1[...
続きを読む