はじめに
個人でサービスを作っていると、どうしても気になるのが「お金」です。僕自身も本番環境を用意するにあたって、冗長化やスケーラビリティよりも、まずは毎月の請求をいかに抑えるかを重視しました。
この記事では、実際に自分が Big5-Quest というプロジェクトで使っている、最低限動くけれどコスパ重視のAWS構成を体験談として紹介します。
全体像
- フロントエンド: React + Vite → S3 + CloudFront で静的ホスティング
- バックエンド: Rails API (Puma) → EC2 + Nginx でシングルサーバ稼働
- データベース: MySQL（RDSでも自前でも可）
- ドメイン: Route53 + ACM 証明書
特徴
1. フロントはサーバーレス
- S3にビルド成果物を配置
- CloudFrontでCDN配信（グローバルにキャッシュ）
-
index.htmlはno-cache、assets/*はimmutableで長期キャッシュ
2. APIはEC2 1台のみ
- Pumaを
127.0.0.1:3000で待受 - Nginxが
api.example.comを受けてリバースプロキシ - systemd管理で
systemctl restart一発で復旧
3. DBもシングルインスタンス
- 小規模ならRDSシングルAZで十分
- バックアップは自動スナップショットで対応
コスト試算（おおよその月額）
1. EC2（API 用の t3.small インスタンス）
- オンデマンド：約 $15/月（約 2,300円）
- リザーブド・スポットならさらに低コスト
2. RDS（MySQL・db.t4g.micro シングルAZ）
- オンデマンド：約 $12/月（約 1,800円）
- 自動バックアップ付きで運用負荷低め
3. S3 + CloudFront
- S3（10GB想定）：約 $0.2/月（約30円）
- CloudFrontは無料枠あり。アクセスが少なければコストほぼゼロ
合計：約 $27/月（約 4,000円前後） で稼働可能
メリット
- コスト最小化：CloudFrontとEC2 1台だけで成立
- 運用がシンプル：構成が単純、トラブルシュートが早い
- 開発速度重視：学習・検証段階に最適
デメリット
- SPOF（単一障害点）：EC2が落ちたらAPI全停止
- スケール耐性なし：アクセス急増に弱い
- DB障害に脆弱：フェイルオーバーなし
運用の工夫
-
/upエンドポイントでヘルスチェック - CloudFrontの無効化で即座にフロントを更新
- Git + systemd デプロイで運用簡略化
将来の拡張余地
1. ALB + AutoScaling でスケーラビリティ強化
- EC2をプライベートサブネットに配置し、ALBで受ける構成に拡張可能
- ALBがヘルスチェックを行い、自動でトラフィックを振り分け
- AutoScalingでトラフィック急増に対応
2. DBのマルチAZ化
- フェイルオーバーと可用性強化
- アクセス量増加時はリードレプリカでスケールアウト
3. セキュリティ強化
- AWS WAFをALBやCloudFrontに導入
- IAMやSecrets Managerで認証情報を安全に管理
Sentryによる監視
- 目的：単一EC2構成の弱点を補うための早期検知
- 導入範囲：Rails API / React
-
コスト抑制：APM 無効・
tracesSampleRate = 0.0で開始
Rails（API）最小設定
- Gem：
sentry-ruby/sentry-rails -
config/initializers/sentry.rb：dsn、enabled_environments = %w[production]、traces_sample_rate = 0.0
React（Vite）最小設定
- 依存追加：
@sentry/react - 初期化：
Sentry.init({ dsn: import.meta.env.VITE_SENTRY_DSN, tracesSampleRate: 0 });
通知
- Slack または メールで新規エラーのみ通知（回帰/頻発などのチューニングはトラフィック増加後に調整）
まとめ
- フロントはサーバーレス（S3 + CloudFront）
- APIとDBは単一インスタンスで運用
- コストは月額 4,000円程度で済む
- 将来的に ALB + AutoScaling + マルチAZ に発展可能
- Sentry監視は Slack または メールで新規エラーのみ通知し、最低限の運用コストで壊れたらすぐ直せるように