毎月の請求額が突然20倍に——当サイトのサーバーを丸ごとシンプルにした一部始終

2026年7月29日

こんにちは！AIフル装備 powered by みらいラボのモモです。

今日はいつものAIニュースではなく、このサイト自身の裏側の話です。先日、当サイト「AIフル装備！」のサーバー構成を丸ごと見直しました。きっかけは、構成を何も変えていないのに、契約の満了でデータベースの毎月の請求額がおよそ20倍になっていたこと。調査の途中で1時間サイトを止めてしまう失敗もあったので、その顛末も隠さず書きます。

なお本記事は、当社が自社で運営するこのメディアの話です。お客様の環境の事例ではありません。同じようにサイトをクラウドで運用している方の参考になれば嬉しいです。

ある日、毎月の請求額が20倍になっていた

当サイトはAWSのEC2（仮想サーバー）1台とAmazon Aurora（データベースサービス）で動いていました。データベースは3年前に「リザーブドインスタンス（RI）」という3年分の前払い契約を結んでいたため、月々の請求はストレージ分の約4.5ドルだけでした（前払い分をならすと実質は月43ドルほどの契約です）。

その3年契約が、2026年7月に満了しました。以降、データベースは通常のオンデマンド料金（使った分だけの都度課金）に切り替わり、月々の請求は約4.5ドルから約95ドルへ、およそ20倍になりました。ここで言う「20倍」は、あくまで毎月の請求額どうしの比較です（前払い分をならした実質負担で比べると、差はもっと小さくなります）。

怖いのは、満了が静かにやってくることです。サービスは止まらず、料金だけが切り替わる。少なくとも私たちは、満了に気づけませんでした。AIエージェントに定期的なコスト点検をさせていたので発見できましたが、点検していなければ毎月95ドルを払い続けていたはずです。

調査の途中で判断を誤った（そして1時間止まった）

コスト調査の途中で、判断を1つ間違えました。

満了日の前後から請求が跳ね上がっていたのを見て、「この日に誰かがデータベースを起動したのでは？それまで止まっていたなら、そもそも不要では？」と解釈し、データベースを停止・削除してしまったのです。結果、当サイトは約1時間停止しました。

実際に起きていたのは「起動」ではなく「前払い契約の満了」。請求のグラフが変わっただけで、サーバーの状態は何も変わっていませんでした。接続数が少なかったことも「使われていない」と読んでしまいましたが、アクセスが穏やかなメディアサイトとしては正常な値でした。

救いは、削除の直前にスナップショット（データの完全な複製）を取ってあったことです。そこから復元し、サイトは約1時間で復旧。データの損失はゼロでした。

教訓その1: 請求の変化と、サーバーの状態の変化は別物。請求グラフだけで判断しない
教訓その2: 消す前に必ずスナップショット。これが命綱になりました

「そもそもAuroraは要るのか」

この事故をきっかけに、根本的な問いに向き合うことになりました。2週間分の実測値を見ると、CPUもデータベースへの接続もごく低負荷で、データの量も小さいまま。アクセスが穏やかなメディアサイトとして、想定どおりの数字でした。

Amazon Auroraは可用性やスケーラビリティに優れた高機能なデータベースサービスですが、この規模のサイトにはっきり言って過剰装備でした。そこで、データベースをアプリと同じサーバーに同居させるシンプルな構成へ変えることにしました。昔ながらの、アプリとデータベースが1台で動く形です。

検討した代替案も一応書いておきます。マネージドDBの最小プランに縮める案（月12ドル程度かかり運用も残る）、サイトを静的化する案（問い合わせフォームと管理画面が失われる）、別のホスティングサービスへ引っ越す案（同じく月12ドル程度）——いずれも「同居なら追加費用ゼロ」に勝てず、不採用にしました。

移行の実際——つまずきメモ

移行作業では、細かい落とし穴がいくつかあったので記録しておきます。

入れる予定だったデータベースを、別のものに変更。パッケージの衝突があり、移行元と同系統のオープンソースRDBを採用しました
cronが入っていない。最近のディストリビューションは最小構成にcronがないことがあり、定期バックアップはsystemdタイマーで組みました
パスワードに「#」が入っていて認証失敗。設定ファイルでは#以降がコメント扱いされ、パスワードが途中で切れていました。引用符で囲んで解決
移行後の照合では、公開記事の件数も投稿データも移行前と完全一致。文字化けもありませんでした

結果：月123ドル → 約23ドル

項目	移行前（前払い満了後）	移行後
月額合計	約123ドル	約23ドル

月およそ100ドル、年に直すと約1,200ドルの削減（いずれも見積もり）です。日本円だと年間およそ19.7万円ほど（2026年7月時点・1ドル163円台での換算の目安）。ダウンタイムは、例の事故の約1時間だけでした。

ひとつ割り切りも書いておきます。1台にまとめた構成は、可用性よりコストを優先した選択です。当サイトはバックアップと死活監視をセットにしたうえで、アクセス規模から見て許容できると判断しました。

念のため補足すると、これは自社メディアだからできた割り切りです。お客様の環境をお預かりする場合は、権限の分離・変更前の承認・削除操作のガードを前提に設計しています。

この件から持ち帰れる教訓3つ

前払い契約には「満了日」がある。 満了してもサービスは止まらず、料金だけが静かに変わる。契約の満了日は台帳に書き、60日前にアラートが飛ぶようにしておく
請求イベントとリソースの状態を混同しない。 グラフの変化は「何かが起動した」ことを意味しない
外形監視を入れる。 実は当サイト、過去にも原因不明のダウンを経験していて、どちらも自力検知できていませんでした。今回を機に死活監視を導入します