EN

月4万円の個人サービスに、監視をタダで載せる話

前回のポストで書いたとおり、個人開発で匿名チャットサービスを作っています。まだ完成していませんが、設計の途中で「監視をどうするか」を決めた記録（ADR）が残っているので、その判断の過程をそのまま書いてみます。

結論から言うと、CloudWatch / RDS Performance Insights / Grafana Cloud Freeの 3つを使い分けて、監視の追加費用をゼロにしました。

この記事の内容は次のとおりです。

この記事の前提（2026年8月時点）

金額の話が出てくるので、先に前提を並べておきます。

  • 時点: 2026年8月の見積もりです。クラウドの料金や各サービスの無料枠は わりと頻繁に変わるので、そのまま鵜呑みにせず、読んだ時点の公式ページで確認してください。
  • 為替: 1ドル ≒ 150円で換算しています。
  • 見積もりであって実測ではありません。まだ本番稼働していないサービスの 「たぶんこのくらい」です。運用してみたらズレると思います。
  • 構成: AWS前提。EC2 2台 + RDS PostgreSQL（Multi-AZ） + ElastiCache Redis。 オートスケーリングなしの固定台数です。
  • 規模: 同時接続1,000人を上限として設計。開発・運用は1人。

そもそも何が困っていたのか

インフラの月額見積もりはこうなっていました。

項目月額目安
WebSocketサーバー（小型2台）約$40
Redis約$9〜20
PostgreSQL（Multi-AZ）約$70
DBストレージ（90日分・約240GB）約$28
バックアップ約$23
データ転送（egress）約$109
合計約$280（≒ 4.2万円）

目標が「月4万円前後」なので、すでに使い切っています。

つまり監視のために「月$30くらいなら…」という発想が最初から使えない。 ここがこの記事の出発点です。

ちなみに一番高いのはegress（サーバーから外に出る通信）で$109。 チャットサービスはWebSocketで延々とデータを流し続けるので、 通信費が最大項目になります。ここは直感に反するポイントかもしれません。

「監視」と一言で言うが、見たいものは3種類ある

やりたいことを整理すると、性質の違う3つが混ざっていました。

1. インフラは生きているか

CPU使用率、メモリ、接続数、そして今月いくら使ったか。 サーバーが落ちていないか、財布が燃えていないかを見る層です。

2. DBのどのクエリが遅いか

「なんか重い」となったときに、犯人のクエリを特定したい。 インフラのグラフを見ても「CPUが高い」までしか分からないので、別の道具が要ります。

3. アプリ固有の数字

  • 今、何人が同時に繋がっているか
  • マッチングが成立するまで何秒待たされているか
  • NGワードのフィルタがどのくらい反応しているか

サービスが「ちゃんと使えているか」はここにしか出てきません。

この3つを1つのツールで賄おうとすると、だいたいどこかが高いか、どこかが弱くなります。 なので層ごとに分けました。

決めたこと

層使うもの費用
インフラのメトリクス・アラームCloudWatch + AWS Budgets無料枠内
DBのクエリ分析RDS Performance Insights（7日保持）無料
アプリの指標とダッシュボードGrafana Cloud Free無料
負荷試験k6（Grafana Cloud Freeの500 VU時間/月）無料

アプリ側はPrometheus形式で/metricsというURLを生やして、 そこをGrafana Alloy（収集エージェント）が定期的に読みに行き、 Grafana Cloudへ送る、という流れです。

用語の補足

初めて聞くかもしれない言葉を並べておきます。

  • CloudWatch: AWS標準の監視サービス。EC2やRDSの基本的な数字は 何もしなくても勝手に集まっています。
  • AWS Budgets: 「今月$140使ったら通知して」と設定できる仕組み。 予算50% / 80% / 100%でアラートを飛ばす設定にしました。
  • Performance Insights: RDSの機能で、遅いクエリを一覧で見られるもの。 7日間の保持なら無料。
  • Prometheus形式: メトリクスをテキストで公開する事実上の標準フォーマット。 chat_active_connections 342みたいな行が並ぶだけの素朴なものです。
  • Grafana Cloud Free: グラフを描くサービスのホスティング版。 無料枠は「10,000アクティブseries・保持14日・ユーザー3人まで」。
  • series（系列）: メトリクス1個 × ラベルの組み合わせ1通り、が1 series。 ここが無料枠の上限になっているので、後で効いてきます。
  • k6 / VU: 負荷試験ツール。VU = Virtual User（仮想ユーザー）。 「500 VU時間」は、たとえば100人分の負荷を5時間かけられる、という意味です。

そして、外に出さないと決めたもの

チャット本文・セッショントークン・生のIPアドレスは、外部の監視サービスに送らない。

匿名チャットなので、会話ログは90日で消し、通報されたものだけ残す方針です。 発信者の情報も法対応の枠組みで扱う必要があります。 デバッグのつもりでログに本文を吐いて、それが外部SaaSに飛んでいく、というのが 一番ありがちな事故なので、方針として明文化しておきました。

選ばなかった案と、その理由

ADRで個人的に一番価値があると思っているのがこのセクションです。 「何を選んだか」より「何を捨てたか」の方が、後から読んだときに効きます。

案A: Datadogにする

監視SaaSの定番です。実際に見積もったら、2ホストのInfrastructure Proで$30/月、 APMを足して$92/月。RDSとElastiCacheはホスト課金の対象外なので、 思っていたより安かったです。

それでも却下したのは、単純に予算枠が埋まっていて$30も載せられないから。 無料プランは保持1日なので、「先週と比べてどうか」が見られず目的を満たしません。

ただし、負荷試験の期間だけオンデマンド（$18/ホスト）で入れて、終わったら捨てる という使い方は将来の選択肢として残しました。恒常費用でなければ話は別です。

案B: 全部CloudWatchに寄せる

AWSの中で完結するので、置き場所が1箇所にまとまるのは大きな利点です。

問題はカスタムメトリクスの料金で、$0.30/個/月。安く見えますが、掛け算になります。

トピック 8 種 × ルーム種別 2 種 × 指標 4 種 = 64 メトリクス
64 × $0.30 = 月 $19

金額そのものより、「細かく測るほど高くなる」構造が嫌でした。

マッチングの待機時間は、これから実データを見て「何秒まで待たせていいか」を 決めようとしている項目です。そこに「測ると金がかかる」という力が働くと、 測るのを我慢する方向に判断が歪みます。これは避けたかった。

案C: Prometheus + Grafanaを自分でEC2に立てる

費用はインスタンス代だけ。技術的にも普通の構成です。

却下の理由は2つ。

  1. 監視対象と同じ障害に巻き込まれる。AWS側で問題が起きたとき、 状況を教えてくれるはずの監視も一緒に沈むと意味がありません。
  2. 1人開発では、監視基盤の面倒を見る時間が取れない。 本体を作る時間を削って監視サーバーの運用をするのは本末転倒です。

この選択で受け入れたデメリット

無料で済ませた分、どこかにしわ寄せは来ます。正直に書いておきます。

  • コンテナが1つ増える。Grafana Alloyが小型インスタンス2台の上に載ります。 リソース消費はゼロではありません。
  • seriesの上限を意識しないといけない。Prometheusのヒストグラム （「何秒以内が何件」という分布を取る仕組み）は、bucketごとにseriesを食います。 1個あたり「bucket数 + 2」です。トピックごとにヒストグラムを持つと 10,000 seriesの枠をあっさり圧迫するので、ラベルの次元は最初に決める必要があります。 案Bで嫌がった「測るのを我慢する」構造が、形を変えてここに出てきているとも言えます。
  • ログインできる人が3人まで。1人開発なので今は問題なし。 人が増えたら$19/月〜のプランに移ります。

ステータスは、あえて”Proposed”のまま

このADRはまだAcceptedにしていません。Proposed（提案中）で止めています。

理由は、実装するのが先のマイルストーンだからです。 無料枠の条件は変わります。実際、RDS Performance InsightsはAWSが Database Insightsという枠組みに再編している最中で、 「無料でどこまで保持できるか」は実装時に確認しないと分かりません。

前提が変わるかもしれない決定を、確定したかのように書いておくと、 後で読んだ人（＝半年後の自分）が確認せずに信じてしまいます。

見直すきっかけも書いておきました。

  • 広告収入などで予算枠が広がったら
  • Grafana Cloud Freeのseries上限に当たったら

このどちらかが起きたら、Datadogを含めて考え直します。

まとめ

  • 予算が埋まっている個人サービスでも、層を分ければ監視は無料枠で組める
  • 料金体系は「金額」だけでなく「どういう行動を誘発するか」で見る。 細かく測るほど高くなる仕組みは、測らない方向に自分を追い込む
  • 選ばなかった案とその理由を書き残しておくと、後で条件が変わったときに ゼロから考え直さずに済む
  • 決めきれないものはProposedのまま置いておいていい。 「まだ確認していない」という事実も立派な記録

実際に運用してみたら見積もりは外れると思うので、そのときはまた書きます。

参考文献

記事中の料金・無料枠の記述は2026年8月時点で各ページを見て判断したものです。 条件は変わるので、必ず読んだ時点の公式ページを確認してください。

料金・無料枠（金額の根拠）

使うツールのドキュメント

Prometheusの考え方

ADR（この記事のもとにした記録の形式）