個人開発でAWSサーバーレス構成を選んだ理由

Posted at 2026-06-27

はじめに

個人開発で Web アプリを AWS に載せるとき、最初に迷うのがインフラの選び方だと思います。

EC2 で全部載せる？
ECS / Fargate にする？
サーバーレスに振る？

私は趣味でCloudFormation テンプレートをフォーム入力で生成する Web ツールを開発しており、Phase1 では サーバーレス構成 を採用しました。

フロントは React、インフラは CDK、デプロイは GitHub Actions です。

この記事では、実際に採用した構成図をもとに、なぜサーバーレスを選んだか、各サービスの役割、個人開発ならではの判断を整理します。

製品の機能紹介より、構成選定の記録として読んでもらえると嬉しいです。

全体構成

Phase1 の本番構成は、おおよそ次のとおりです。

図の読み方はシンプルです。

左側（ユーザー〜CloudFront）: ブラウザからアクセスする入口
中央（API Gateway〜Lambda）: バックエンド API
右側（Cognito / DynamoDB / S3 / SNS）: 認証・保存・通知
下部（CloudWatch）: ログとメトリクス

EC2 や RDS は使っていません。常時起動するサーバーを持たない構成です。

なぜサーバーレスを選んだか

個人開発では、次の3点を優先しました。

優先したこと	サーバーレスでの答え
運用負荷を下げたい	OS パッチやサーバー監視が不要
アクセスが少なくても維持したい	使わない時間のコストを抑えやすい
学習と実装のバランス	AWS でよく見る構成をそのまま試せる

1. サーバー管理をしたくなかった

個人開発は、機能実装とインフラ運用を同じ人が担います。

EC2 を選ぶと、OS 更新・ディスク・セキュリティグループ・スケール設計まで自分で面倒を見る必要があります。趣味のプロジェクトで、ここに時間を取りすぎたくありませんでした。

Lambda / API Gateway / DynamoDB はマネージドサービスなので、「動かし続ける」より「必要なときだけ動かす」 発想に寄せやすいです。

2. 低トラフィック前提でも破綻しにくい

個人開発の現実として、アクセス数は最初ほとんど伸びません。

それでもドメイン・HTTPS・認証・保存機能は必要です。CloudFront + S3 で静的配信、API は Lambda で処理する形なら、アクセスゼロに近い月でもインフラを維持しやすいと感じました。

（料金の細かい話は環境や設定で変わるので、ここでは「常時起動サーバーより固定費を抑えやすい」という判断軸だけ書きます）

3. 学習内容と製品の方向性が一致した

IaCraftStudio 自体が CloudFormation / S3 / Lambda / API Gateway などを扱うツールです。

自分の本番構成も、ツールが扱うサービス群に近い方が、「自分が実際に運用している構成」として説明しやすいと考えました。

各コンポーネントの役割

構成図の要素ごとに、Phase1 での役割を整理します。

フロント配信: Route 53 / ACM / CloudFront / S3

サービス	役割
Route 53	カスタムドメインの DNS
ACM	HTTPS 証明書
CloudFront	CDN。静的ファイル配信と `/api/*` の振り分け
S3	React ビルド成果物のホスティング

ブラウザから見えるのはほぼ CloudFront だけです。

フロントと API を同じオリジン配下（/api/*）にまとめることで、CORS 設定をシンプルに保てました。

API 層: API Gateway / Lambda

API Gateway が入口で、Lambda が実際の処理を担当します。

図では Lambda を3つに分けていますが、実装では用途ごとに関数を分けています。

論理グループ	主な処理
アカウント系	認証連携、ユーザーメタデータ
保存系	テンプレートの保存・一覧・取得・削除
通知系	お問い合わせメール送信

個人開発でも、認証・保存・通知は責務を分けた方が後から直しやすいと感じました。

データ層: Cognito / DynamoDB / S3

サービス	保存するもの
Cognito	ユーザー認証（サインアップ / ログイン）
DynamoDB	保存メタデータ、ユーザー情報
S3	テンプレート JSON（payload）

メタデータは DynamoDB、サイズの大きい JSON は S3、という分担です。

RDB を使わなかった理由は、個人開発のデータ構造が比較的フラットで、スキーマ変更の柔軟さを優先したためです。複雑な JOIN が主戦場になるアプリなら、RDS を選ぶ判断も十分あります。

通知: SNS

お問い合わせフォームの通知先として SNS を使っています。

メール送信を Lambda から直接組むより、通知経路を SNS に寄せた方が後から拡張しやすいと判断しました。

監視: CloudWatch

Lambda ログ、API エラー、メトリクスは CloudWatch で確認します。

prod では CloudFront アクセスログを S3 に出し、Athena で分析する運用も別途整えています（詳細は関連記事参照）。

検討したが採用しなかった選択肢

正直に書くと、次の構成も候補にありました。

EC2 1台構成

メリット: 慣れていれば分かりやすい、何でも載せられる
見送り理由: 常時起動の運用コスト（時間と料金）が個人開発には重い

ECS / Fargate

メリット: コンテナ運用の学習になる、API をまとめやすい
見送り理由: Phase1 の API 規模に対して構成が重い

RDS

メリット: SQL で集計・参照がしやすい
見送り理由: 最小構成の保存要件なら DynamoDB + S3 で足りる

「最小で動かす」「後から足せる」ことを優先し、サーバーレスに寄せました。

サーバーレスのデメリット（実際に感じたこと）

良いことばかりではありません。個人開発で実感した注意点です。

ローカル開発と本番の差: API Gateway / Cognito 周りは、ローカルだけでは再現しきれない
コールドスタート: Lambda は初回応答が遅くなることがある（体感は許容範囲）
構成要素が多い: サービス数は EC2 1台より多く、初見の理解コストはある
デバッグの分散: ログが CloudWatch / API Gateway / Lambda に散らばる

そのため、インフラは CDK でコード化し、CI/CD で同じ手順を繰り返すようにしています。

IaC の重要性については、別記事で詳しく書いています。

個人開発者向けの選び方メモ

同じ悩みをしている方の参考までに、私なりの判断基準です。

サーバーレスが向きやすいケース

フロント + API + 認証 + 少量データ保存
24時間有人運用はしない
まず小さく公開して様子を見たい

別構成を検討した方がよいケース

常時接続（WebSocket 中心）や重いバッチ処理
複雑な SQL / トランザクションが中心
既に Docker 運用のノウハウがある

個人開発は「正解の構成」より「続けられる構成」が大事だと思っています。

同じプロジェクトで書いている記事です。読む順番の参考にしてください。

まとめ

個人開発の Web アプリでは、CloudFront + S3 + API Gateway + Lambda + DynamoDB + Cognito のサーバーレス構成を選びました。

理由はシンプルで、

サーバー運用を最小化したい
低トラフィックでも維持しやすい
自分が作っているツールの学習テーマと一致する

からです。

構成図は 後から自分が読み返して理解できること を優先して作りました。個人開発のインフラ選定で迷っている方の参考になれば嬉しいです。

構成についてのコメントや、「個人開発ならこうした」という話があれば、ぜひ教えてください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up