$340 だったインフラ費用を、$136 まで削減した元記事の筆者は、約 5 万 MAU（Monthly Active Users = 月間アクティブユーザー数）のアプリを運用しながら、クラウド費用を 月額 $340 から $136 に削減したそうです。
削減率はなんと 60%。しかも、アプリのコードを大きく書き換えずに、です。
これ、かなり面白い話です。
「性能改善 = 開発の頑張り」と思いがちですが、実際は “どんなインフラを、どう使っているか” のほうがコストに直結することが多いんですよね。クラウドは便利な反面、放っておくと“使ってないのに課金される箱”が増えがちです。
筆者が問題視していたのは、よくある「とりあえずスケールしよう」です。
アプリが重いなら、もっと大きいサーバーを借りる。足りないなら台数を増やす。たしかに安心感はあります。でも、本当に必要な分以上のリソースを払っていることも多いです。
そこで筆者がやったのは、次の順番。
この順番がいいです。派手な改善より、ムダの発見が先。かなり現実的だと思います。
最初の見直しで見つかった節約額は、月約 $80。
筆者は 2 週間モニタリングして、production server の CPU 使用率が平均 11% しかないと分かったそうです。
筆者は、
4 vCPU / 8GB RAM から2 vCPU / 4GB RAMへダウングレードしました。
しかも、ただ小さくしただけではなく、適切な alerting（異常時通知） も設定しています。
ここが地味に重要です。小さくするのは怖い。でも、通知があれば「本当に危ないときだけ戻す」運用ができます。
個人的には、クラウド費用を減らすときに一番ありがちな失敗は「怖いから何も変えない」か「怖さを無視して雑に下げる」の二択だと思います。この記事は、その中間をちゃんと取っています。
次の節約は、月約 $60。
筆者は managed database を 3 つ動かしていたけれど、そのうち 1 つは 8か月放置した別プロジェクト用、もう 1 つは 誰も使っていない staging database だったそうです。つまり、実質必要だったのは 1 つだけ。
本番環境とは別に、動作確認のために使う環境です。
本番でいきなり試すと危ないので、事前チェック用に用意します。
ただし、作っただけで放置されやすい のも staging の怖いところ。
「念のため残しておくか」が積み重なると、請求書が静かに太ります。
記事では、30日触っていない database は
という流れを勧めています。
これはかなり現実的です。
DB はアプリ本体より“消すのが怖い”ので放置されやすい。でも、スナップショットがあれば完全な削除ではないので、心理的ハードルを下げられます。いいやり方だと思います。
ここでの節約は、月約 $45。
筆者は画像、動画、PDF をアプリサーバーから直接配信していましたが、これをやめて object storage + CDN に移しました。
元記事の図式はこうです。
アプリサーバーで静的ファイルを配ると、
一方、object storage や CDN を使うと、
筆者は、compute bandwidth が >$0.10/GB なのに対して、object storage は ~$0.02/GB と説明しています。
メディアが多いアプリでは、この差がじわじわ効くんですよね。1回あたりは小さくても、積み上がると痛い。クラウド費用の典型です。
ここは少しコードに触れていますが、アプリのロジックを作り直したわけではない のがポイントです。
やったことは、足りなかった index を追加しただけ。
節約は 月約 $19。
データベースの「検索用の目次」みたいなものです。
これがないと、DB は大量のデータを上から順番に探すことになり、遅くなります。
あると、目的のデータにすばやく辿り着けます。
記事の例では、こういうクエリがありました。
SELECT * FROM events WHERE user_id = 123 AND created_at > '2026-01-01';
index がないと full table scan（表を最初から最後まで総当たりで見ること）が起きて、2.3 秒かかっていました。
そこで、
CREATE INDEX idx_events_user_date ON events (user_id, created_at);
を追加したところ、同じクエリが 12ms になったそうです。
これはすごい。
派手さはないけど、DB の性能改善ってこういう「地味な一手」が本当に効きます。しかも、クエリが速くなると、小さい database instance でも耐えられる ので、インフラ代まで下がる。1粒で2度おいしいやつです。
最後の節約は、月約 $36。
筆者は 6か月以上ほぼ同じインフラを使っていたので、on-demand pricing から committed pricing に切り替えました。
筆者は 1年のコミットを入れて、36% の削減を得たとしています。
これは「毎月変動しないコア部分」に向いています。
もちろん、契約縛りはあるので万能ではありません。
でも、ずっと動かす前提の基盤なら、かなり有効です。
個人的には、ここは「節約」でもあり「意思決定」でもあると思います。長く使うものに、ちゃんと長期価格を当てるのは合理的です。
元記事の内訳をまとめるとこうです。
合計: $240/月 の削減。
年間では $2,880 になります。
月額 $340 が $136 になった、という数字も納得感があります。
しかも、パフォーマンスが悪化したわけではない、というのがかなり大きいです。
コスト削減って、下手をすると「安くなったけど遅くなった」で終わるんですが、このケースはそうではありません。
元記事のタイトルはかなりキャッチーですが、内容はわりと地に足がついています。
そして重要なのは、性能改善やコスト削減の打ち手は、必ずしも大規模なリファクタリングではないという点です。
このへんは、コードを読む前に見られることが多いです。
だからこそ、開発者だけでなく、運用やプロダクトの視点でも大事になります。
元記事がすすめている最初の一歩はかなりシンプルです。
この順番、実務的でいいです。
「まずは測る」が本当に大事。体感でやると、たいてい外します。
この記事は、いわゆる“すごい最適化”というより、基本の徹底で勝っているのが良いです。
しかも、やっていることはどれも再現性があります。特別な魔法はなくて、監視して、捨てて、置き場所を変えて、契約を見直す。これだけです。
でも、こういう地味なことが一番効くんですよね。
クラウド費用は、プロダクトが成長すると自然に増えるので、放置すると「なんとなく高い」が当たり前になります。そこにメスを入れるには、派手な技術よりも、冷静な棚卸しが必要だと改めて感じました。
参考: How I Reduced My Cloud Bill by 60% Without Touching My Code