クラウドPostgreSQLのコスト構造とAWS RDS自前運用比較、ストレージ料金対策の実例

## $47,000のクラウドデータベース請求書がもたらした衝撃

ちょっと前の話。とある中規模SaaS企業にAWSから届いた1通の請求書──そこにはPostgreSQLホスティング利用料として$47,000という、驚愕の数字が記されていました。それまでの月額は$3,200で安定していたはず。別にトラフィックが劇的に増えたり、新機能を立ち上げたりした形跡もないし、不思議としか言いようがありません。気付かぬ間にクラウド上でPostgreSQLは淡々とリソースを食い続け、気づけば手遅れなほどコストが膨張していました。このパターン、実際そんなに珍しくもないんですよね……。

ま、いいか。でも改めて振り返ってみると、「自分だったらどう防げただろう？」とか一瞬止まっちゃいます。本当に油断できません。

最近さ、クラウドプロバイダーがデータベースホスティングでけっこう稼いでるって話をよく聞きます。実際、その利益率は、古典的な金融業界の水準と比べても相当エグい感じなんですよね。マネージドデータベースの便利さには違いないんだけど、スタートアップとか企業の経理担当からすると、思わず眉をひそめるようなコストがかかるケースも多かったりする。

それに、公にはあんまり語られませんが、管理されたPostgreSQLサービスって、自分たちで構築運用する場合と比べてだいたい300〜500％も割高になることも指摘されてます。この価格差って便利さや自動化、それから運用周りの不安なんかによってつい見落としがちだけど、本当にその分の価値があるかどうか…悩む人もいるでしょうね。

ま、とりあえず具体例出すならAWS RDS PostgreSQL（db.r6g.2xlarge）かなぁ。8 vCPU・64 GB RAMの構成だと月額およそ$1,200なんですよ。そして当然ストレージ代も別途必要です。一言で言えば「うーん、高！」と思う人、多いんじゃないかな。

バックアップストレージの料金、意外と複雑ですね。115 per GB-monthって数字が書いてあったんですが、しかもデータ転送は$0.09 per GB、それからもう一つバックアップストレージの値段が$0.095 per GB-monthという記載も発見。こういう細かい部分まで見ると、結構ややこしいなと素直に思っちゃいました。

そして、「Equivalent EC2 Instance（r6g.2xlarge）」を例にすると、月額で約$300かかります。このEC2だとストレージにはEBSを使うことになってて、その価格が$0.08 per GB-month。ついでにスナップショットにもお金かかって、こっちは$0.05 per GB-monthだったりするんですよね。ふーむ…。

でもね、この仕組みだと最終的には同じハードウェアなのに400％ものマークアップになってる計算。これ、聞いただけだとピンと来ないんだけど……まあ要は「えっ？」と思うくらいの差額感。そして、この手の隠れコストが積み重なることで、知らず知らず予算面で大打撃になること、多分珍しくないと思います。（ま、いいか。）

細かい数値チェックが得意な人じゃなくても、「なんとなく高すぎじゃ？」と不安になる感じです。本当に全部必要なのかな…たまには疑ってもいいよね。

クラウドプロバイダーって、だいたいコンピュートとストレージを分けて、それぞれに追加料金をかけてくる感じなんですよね。つまり「あ、結局こんなにかかるの？」ってケースも珍しくありません。
-- 例えば、急成長中ECデータベースの場合：
-- 500GB（本体）＋200GB（インデックス）＋100GB（ログ）＝合計800GB
-- RDSではこのストレージだけで800GB × $0.115=$92/月
-- 自動バックアップが同じ量×$0.095で$76/月発生。
-- 全部合わせて月$168ですね。
-- ちなみにセルフ管理なら800GB×$0.08＝$64/月。
-- ストレージ代だけで毎月104ドル差が出る…けっこう大きくない？

## 2. コネクションプールまわりの落とし穴

アプリケーション側でDBコネクション数の最適化がおざなりになっているパターン、実はすごく多いです。その結果として、無駄に余計なスペックを割当てられてしまうんですよ。ruby

# よくある“惜しい”DB接続のイメージ

class DatabaseConnection:

    def __init__(self):

        # 各サービスごと20コネクション張っちゃう…

        self.pool_size = 20

python

def get_connection(self):

        return psycopg2.connect(DATABASE_URL)

# サーバー10台並べるだけでも合計200コネクション！

# db.t3.medium ($70/月)→db.r5.large($180/月)へアップせざるを得なくなることも。

**実際これ直せば約110ドル／月下げられる例：**ruby

# 見直したコネクション運用スタイル

class DatabaseConnection:

    def __init__(self):

        # プール共用&サイズ減らしてpool_size=5とかで済むなら…！

        self.pool_size = 5 

        self.connection_pool = ConnectionPool(

            minconn=1,

            maxconn=5,

            host=DATABASE_HOST

        )

# 全体コネクション50でOK→ちいさいインスタンスでも十分やれますよ。

## 3. リードレプリカは“増えるもの”説

クラウド事業者が「リードレプリカ入れれば解決！」みたいに勧めてくれるのですが……ぶっちゃけコストがえげつなく跳ね上がったりします。

**よくあるパターン：**
- プライマリーDB: db.r5.xlarge（$350/月）
- リードレプリカ3台分：3 × $350＝$1,050／月
- **合計:$1,400／月**

**賢いやり方（一例）：**
- 単一・最適チューン済みdb.r5.xlarge ($350／月)
- PgBouncer系のソフトウェア型プール導入: $0　
- **総額:$350／月**
- **なんと節約:$1,050／月**

## 実際によくあるコスト膨張事例

## ケーススタディ1: アナリティクスダッシュボード問題

**企業:** マーケティング解析系スタートアップ
**課題:** リアルタイムダッシュボード用の複雑重たいSQL対応
**提案された方法:** レプリカ最大5台＋大型インスタンスいっぱい使う形
**想定コスト:** 月額8,400ドル　
**実際やった対策（一例）：**
-- レプリカ多重構成やめて、集計マテビュー運用に振る方法：
CREATE MATERIALIZED VIEW daily_user_metrics AS
SELECT
date_trunc('day', created_at) as day,
count(*) as new_users,
sum(revenue) as daily_revenue
FROM users
GROUP BY date_trunc('day', created_at);

-- 更新頻度は「毎時」でリアルタイム性との妥協：
CREATE OR REPLACE FUNCTION refresh_metrics()
RETURNS void AS $$
BEGIN
REFRESH MATERIALIZED VIEW CONCURRENTLY daily_user_metrics;
END;
$$ LANGUAGE plpgsql;

-- pg_cronスケジューリング活用イメージ：
SELECT cron.schedule('refresh-metrics', '0 * * * *', 'SELECT refresh_metrics();');
**この結果:** 構成シンプル化しつつ420ドル／月まで抑え込み！すご……95%超の節約幅。

## ケーススタディ2: バックアップ＆保存費問題

**企業:** 医療記録プラットフォーム
**悩み:** 法規上7年分残す必要あり、普通設定だと自動バックアップ料金だけで月2,800ドル取られて困る…
【まあ見直し案】はこちら↓　　
# 高圧縮+独自スクリプト方式切替パターン一例bash
#!/bin/bash
# 毎週フル、日次差分。軽～く説明するならこんな流れです：
if [ "$(date +%u)" = "1" ]; then
# 月曜日は全量dumpして高圧縮（gzip -9）
pg_dump -Fc database_name | gzip -9 > backup_$(date +%Y%m%d).sql.gz

# 安価S3 Glacier Deep Archiveへの転送手順付き:
aws s3 cp backup_$(date +%Y%m%d).sql.gz s3://backups/ --storage-class DEEP_ARCHIVE
else
# 差分はWAL-E等使う案も悪くないかな、と。
wal-e backup-push /var/lib/postgresql/12/main
fi
# ローカル保持7日超えたら自動削除するようにもできたりしますね。
find /backups -name "*.gz" -mtime +7 -delete

**比較すると…**
- 通常RDSバックアップなら：2,800ドル/月　
- S3 Glacier駆使時：180ドルくらい　
- **差額2,620ドル、お財布嬉しい展開！**

## クラウド事業者が仕組むロックインについて思うこと

各社固有APIとかサービス連携・拡張モジュール込み前提など、小さ～な依存ポイント増えてきます。「全部乗っかったほう楽じゃん」……気づいた頃にはガッツリ囲われます（笑）。ま、いいか。

プロプライエタリ拡張機能
-- AWS RDSならではの拡張機能、つまりrds_tools.aurora_db_clusters()を呼ぶと、がっつりベンダーロックインされちゃうことも……。
SELECT * FROM rds_tools.aurora_db_clusters();
-- こういうの気になる場合は、無理せず素直に標準PostgreSQL系の機能（pg_stat_databaseとか）だけ使っておく方が安心です。
SELECT * FROM pg_stat_database;

## 2. インテグレーションの複雑性
なんだかんだで各サービスは、それぞれ自社独自のエコシステムにフィットする形になっています。でもね、いざ別環境への移行ってなった瞬間に意外とゴリゴリ衝突する場面が出てきます。あ～しんどい。

## 3. 価格設定の複雑性
値段体系もめっちゃ多層的なので、ちょっとIT系弱めな人には正直ややこしすぎ。専門用語とか細かな計算ロジック抜きで単純に選ぶことって、ほぼ不可能じゃないかなあと僕は思います（たまに「あれ？これ結局何円？」みたいな錯覚に陥る）。

最近のインフラ運用だと、「自己管理型インフラはもう古いよ」って空気もあるけど、Docker Composeで本番環境を組むやり方も、実際にはまだしっかり機能してる。具体例を挙げるなら、PostgreSQL（15-alpine）、pgbouncer（コネプー）、それにPrometheusで監視を入れる構成かな。サービスごとに環境変数とかボリューム、ポート設定、それぞれのコマンド内容まで細かくymlで書いておくイメージだね。一息ついて…`postgresql.conf`の調整にも注目したいところ。たとえばshared_buffers=2GB、effective_cache_size=6GBみたいなパフォーマンス用値を設定したり（これVM向け）、SSD用としてrandom_page_cost=1.1やeffective_io_concurrency=200みたいな値で合わせ込んだりするのがコツ。最大接続数やログの出力ルールなんかも漏れなく明記すること、大事。

さて、ハイブリッド戦略についてだけど、これ案外便利でさ。開発やステージングではクラウド側のマネージドDBサービス使いつつ、本番だけ自前でガッチリ最適化されたインフラを置くことで、両方のおいしいとこ取りできる。身近な実例ではTerraformによるマルチクラウド運用があるね。AWS上にはプライマリDB（例:r5.xlarge）、GCP上にはレプリカDB（n2-highmem-4）…こう配置することで障害時でも耐性が高まっている感じ。

コスト管理に関しては、押さえるべきポイントが主に三つある。まず一つ目、「使ってない資源のリサイズ」―これはpg_stat_databaseとかpg_stat_user_tablesなどPostgreSQLシステムビューから集めたデータで判断してくやり方が有効なんだ。例えば不要に大きすぎるインスタンスとかも洗い出せるし、「このテーブルあんまりアクセスされてないな」みたいなのも分かったら再割当する、とかね。そして二つ目は「ストレージ面」。SQLで各テーブルやインデックスごとの容量計測したり、自動で古いログ削除＆期限切れセッション掃除用PL/pgSQL関数を書く―こんな地味だけど大切な流れも推奨されている。最後になるけど、こういう細かな方針や手法って結局自分たちで管理・設計しているからこそ、その場その場の状況にあわせて柔軟に調整できる。それがパフォーマンスもコストも両立させる肝じゃないかな。ま、いいか。

# アプリケーションレベルの接続最適化

import psycopg2.pool

class DatabaseManager:

    def __init__(self):

        self.connection_pool = psycopg2.pool.ThreadedConnectionPool(

            minconn=1,

            maxconn=10,  # デフォルトよりかなり低い設定値にしたよ

            host=os.getenv('DB_HOST'),

            database=os.getenv('DB_NAME'),

            user=os.getenv('DB_USER'),

            password=os.getenv('DB_PASSWORD')

        )

def execute_query(self, query, params=None):

        conn = self.connection_pool.getconn()

        try:

            with conn.cursor() as cursor:

                cursor.execute(query, params)

                return cursor.fetchall()

        finally:

            self.connection_pool.putconn(conn)

## 移行プレイブック：クラウドデータベースから脱出したい時のメモ ##

フェーズ1: 評価と計画
# コストを調べる簡単スクリプト（ちょっと古風だけど）
#!/bin/bash
echo "Current RDS Costs Analysis"
aws rds describe-db-instances --query 'DBInstances[*].[DBInstanceIdentifier,DBInstanceClass,AllocatedStorage]' --output table
# 性能チェックの基準点ね
echo "Performance Metrics"
aws cloudwatch get-metric-statistics \
--namespace AWS/RDS \
--metric-name CPUUtilization \
--start-time $(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%S) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
--period 86400 \
--statistics Average

フェーズ2: インフラ準備＆セットアップ

# 本番サーバ向けTerraformサンプル

resource "aws_instance" "postgres_primary" {

  ami                     = var.postgres_ami_id

  instance_type          = "r5.xlarge"

  key_name               = var.key_name

  vpc_security_group_ids = [aws_security_group.postgres.id]

  subnet_id              = var.private_subnet_idcss

root_block_device {

    volume_type = "gp3"

    volume_size = 100

    encrypted   = true

  }

css

ebs_block_device {

    device_name = "/dev/sdf"

    volume_type = "gp3"

    volume_size = 500

    encrypted   = true

  }

user_data = base64encode(templatefile("${path.module}/postgres_setup.sh", {
postgres_version = var.postgres_version
}))

tags = {
Name = "postgres-primary"
Environment = "production"
}
}

フェーズ3: データマイグレーション本番！
# ゼロダウンタイムで乗り換えた例だよ（少しヒヤッとするけど…）
#!/bin/bash
# RDS側にリードレプリカを用意してdump取得しておく感じかなぁ。
pg_dump -h rds-endpoint.amazonaws.com -U username -d database | \
pv -p -t -e -r -b | \
psql -h new-postgres-server -U username -d database

# ストリーミングレプリケーション、こんなふうに指定
echo "primary_conninfo = 'host=rds-endpoint.amazonaws.com port=5432 user=replica_user'" >> recovery.conf
echo "standby_mode = on" >> recovery.conf

# データ整合性は実際ざっくり確認くらいだけど一応
psql -h new-server -c "SELECT count(*) FROM users;" -t
psql -h rds-endpoint -c "SELECT count(*) FROM users;" -t

## データベース独立性で得られるROIって？

### 即効コスト削減について
- **ハードウェア費:** およそ60〜75％オフになるケースが多い気がする
- **ストレージ費:** おそらく40〜60％くらい安くなる場面もあるかも
- **バックアップ関連:** バックアップ用途では80〜90％節約もめずらしくない印象。
- **サポート費:** 社内スキル次第でけっこう上下。丸投げは楽だけど、それなりのお金も飛ぶ感じ。

### 長期メリット視点だと…？
- **ベンダー縛り回避:** ロックイン料金という“御料”から抜けやすくなるの、悪くない。
- **自力チューニング:** 必要になった時に性能最適化しやすい（人手かかるが）
- **コンプライアンス細分対応:** 細かなルールも柔軟にカバーしやすい雰囲気。まあケースバイケースだけどね。
- **機能開発ペースUP:** ベンダー次第で新機能待つ必要がなくて割と小回り利きます。

## 合算！3年間のコストシミュレーション比較

**クラウドマネージド型（そこそこ成長中パターン）**
- Year 1: $48,000 (RDS＋ストレージ＋バックアップ合算)
- Year 2: $84,000 (スケール増強分)
- Year 3: $156,000 (多重化＋プレミアムサポートとか…)
- **合計：$288,000**

**自前運用型シナリオの場合**
- Year 1: $18,000 (初期インフラ／セットアップ込み)
- Year 2: $28,000 (拡張増設分など追加)
- Year 3: $42,000 (更なるキャパ補強…)
- **合計：$88,000**

**差額ざっくり：3年で$200,000浮いた！**

## 今後どう変わってゆきそう？

最近は各社とも、クラウド業者によるデータベース商売への依存度上昇→利益率激高って状況ですよね…。あちら側サービス提供エリア広げるたび、コスト上昇も続いてて（肌感覚ですが）。今、この流れを嫌う現場勢や会社では、自前ノウハウ蓄積そのものを武器として捉え直す動きもちょこちょこ見受けます。それこそ、「エンジニア集団が持続成長できる会社」って観点になると、外部への恒常的依頼ばかりでは追いつかなくなりますし - 地道ながら自社体制強化の種蒔きをしている企業ほど、先々かなり息長めに戦える素地が育つような気配です。ま、いいか。

正しい選択って、たぶん状況をちゃんと見て考えることが大事なんだよね。うーん、特に【クラウドマネージド型を選ぶべき場合】については、例えばだけど、「チームの中にデータベース専門の人がいない」とか、「アプリケーションの成長スピードや将来どれくらい拡張するかわからない」とか、その辺で迷ったら有力候補になっちゃうかな。他にも、コンプライアンスでどうしてもマネージドサービス優先とか、便利さ重視だけど3–5倍のコスト増もしっかり予算で受け止められるケースもあるし。

逆に【セルフマネージド型へ移行すべき時】なんだけど、月額$2,000超えてくるデータベース費用だったり、とことんパフォーマンスが問われる状況、それから「このメンバーなら運用ノウハウ積めそうだな」みたいなときだよね。あとやっぱり長期的な費用見通し重視すると、自分達で主導権握る方に寄ってく傾向もありそう。

まあ…結局のところ、自分たちで管理する選択肢をちゃんと検討しておく価値はあると思うよ。ここ数年クラウドDBの値段上昇って偶然じゃなくて、それ自体が完全にビジネスモデル化してる雰囲気なんだ。各プロバイダーが「DB管理は超複雑！普通は手出し無理！」ってイメージ作ることで、この業界以外では考えづらいような高価格にも説得力持たせてるわけ。でも実際には最近はツールやコンテナ、自動化系も充実してきてるし──昔ほど「敷居高っ！」とも言い切れなくなってきた印象あるなぁ。一応ぼく自身もそのあたり全部断言できない部分もちょっと残るけど……ま、いいか。

目が覚めて、ぼーっとしたまま考えてみると──いまこの現実にちゃんと気付いている企業って、他の会社が「便利だし」と言い訳しては無駄な資金を垂れ流しているあいだに、いつの間にかしっかり持続可能な競争優位を築き上げちゃってたりするんですよね。ふうん、不思議でもないかな。正直、選択肢自体はけっこうシンプルで、「ずっとクラウドのプレミアム料金を払い続けます」なのか、それとも「長期的にリターンがある仕組みに本腰入れて投資します」なのか、そのどっちかしかなくてさ。面白いのは、本当に結果出してる会社ほど「コスパより使いやすさ重視！」って感じじゃなくて、その二つの両取り（ちゃっかり知見も貯めつつ）できる路線へ着々進化中──たぶんだけど。そのあたりやデータベース費用最適化とかパフォーマンス向上ノウハウについて興味あれば、一度覗いてみてください。

スケーラブルなインフラづくりを、できるだけコスト控えめに進めたい人は、良かったらふわっとフォローしてもらえると嬉しいです。ぼんやりしてますが、自分でもちょっと興味あります。

【💡 ざっくり要点まとめ】
- クラウドDBのマークアップってね、ときどき400％超えるケースもあってびっくりします。
- コネクションプールだけでも、月1,000ドル以上のコストカットが現実的かもしれません。
- セルフマネージドに切り替えることで、60～75％の費用圧縮になることも普通にありえます。
- 専門性への投資（知見やスキル）は早ければ6～12カ月で元取れる場合もあるとか。

「なんとなく役立ったかも？」と思った方は、ぜひエンジニアリングチームや経理部にも転送してみてください――たぶん誰かの予算改善につながるはずです。ま、いいか。