先に要点
- AWSで小さなWebサービスを複数運用するなら、最初から全部をマイクロサービス化するより、運用できる単位で分ける方が現実的です。
- 小規模なら、静的サイトは Amplify Hosting や S3 + CloudFront、単純なWebアプリは Lightsail、コンテナアプリは App Runner や ECS が候補になります。
- 分ける基準は、サービス数ではなく、障害影響、DB共有、デプロイ頻度、権限境界、コスト管理、運用担当者の習熟度です。
小さなWebサービスを複数作っていると、どこかで AWSにまとめて載せていいのか という話になります。
コーポレートサイト、LP、管理画面、API、会員向けサービス、社内ツール、バッチ。
1つずつは小さくても、数が増えると構成に迷います。
AWSは選択肢が多いぶん、最初から正解を選ぶのが難しいです。
Lightsail でシンプルに始めるのか、App Runner に寄せるのか、ECS + Fargate にするのか、静的サイトは Amplify Hosting でよいのか。
どれも使えますが、向いている場面が違います。
この記事では、2026年4月21日時点のAWS公式情報を確認しながら、小さなWebサービスを複数運用するときの構成パターンを実務目線で整理します。
複数サービスをどこで分けるかの考え方は、AWSで複数サービス展開は大丈夫？AIに相談するときの伝え方と分ける基準 でも扱っています。今回は、より具体的な構成候補に寄せます。
まず結論：小規模では「運用できる構成」が強い
小規模サービスで大事なのは、かっこいい構成より、日々運用できる構成です。
最初から複雑な構成にすると、リリース、証明書、ログ、監視、バックアップ、費用確認、障害対応が全部重くなります。
まずは次のように考えると整理しやすいです。
| 用途 | 候補構成 | 向いている場面 |
|---|---|---|
| 静的サイト、LP | Amplify Hosting / S3 + CloudFront | HTML、JS、画像中心。サーバー処理が少ない |
| 小さなWebアプリ | Lightsail | Laravel、WordPress、小規模APIをシンプルに動かしたい |
| コンテナ化したWebアプリ | App Runner | コンテナを使いたいがECS運用までは重い |
| 複数コンテナ、長期運用 | ECS + Fargate | Web、API、ワーカー、バッチを分けたい |
| DBを分けて運用 | RDS / Lightsail managed database | バックアップ、可用性、DB単独の保守を考えたい |
小さいから全部1台 でも始められます。
ただし、増える前提があるなら、どこから分けるかを早めに決めておくと後が楽です。
パターン1：静的サイトは Amplify Hosting か S3 + CloudFront
LP、ドキュメントサイト、フロントエンドだけのSPA、静的に生成したサイトなら、サーバーを立てない構成が向いています。
候補は主に2つです。
AWS公式では、Amplify Hosting はGitリポジトリと接続してWebアプリをデプロイでき、静的サイトやSPA、SSRフレームワークにも対応するホスティングとして案内されています。
S3 + CloudFront は、静的ファイルをS3に置き、CloudFrontで配信する定番構成です。
小規模でおすすめしやすい判断は次です。
Amplify Hosting
Git連携、ビルド、デプロイ、プレビューをまとめて扱いたいときに向いています。
S3 + CloudFront
静的ファイル配信をシンプルに持ち、配信経路やキャッシュを自分で管理したいときに向いています。
複数のLPや静的サイトがあるなら、静的サイトはこの系統に寄せ、アプリサーバーと分けるだけでもかなり運用が軽くなります。
パターン2：小さなWebアプリをLightsailにまとめる
Lightsailは、AWSの中でも小規模なWebサイトやWebアプリを始めやすいサービスです。
AWS公式でも、Webサイト、Webアプリ、プロジェクトを素早く立ち上げる用途として案内されています。
たとえば、次のような構成です。
- LightsailインスタンスにNginx、PHP、Node.jsなどを入れる
- 小さなLaravelアプリを1つ動かす
- 管理画面や社内ツールも同じサーバーで動かす
- 必要に応じてLightsail managed databaseを使う
この構成の良さは分かりやすさです。
VPSに近い感覚で扱えるので、AWSの細かいサービスを大量に覚えなくても始められます。
ただし、複数サービスを1台へ詰め込みすぎると、次の問題が出ます。
- 1つの障害で全部止まる
- デプロイ作業が衝突する
- メモリやCPUの食い合いが起きる
- ログやバックアップの責任範囲が曖昧になる
- サービスごとの権限分離が弱くなる
Lightsailは 小さく始める には強いですが、増えてきたら、静的サイト、DB、バッチ、重いAPIから順に分けることを考えます。
パターン3：コンテナ1サービスならApp Runner
アプリをコンテナ化しているなら、App Runnerは候補になります。
AWS公式では、App Runner はソースコードまたはコンテナイメージからWebアプリやAPIサービスをビルド、デプロイ、実行できるフルマネージドなコンテナアプリケーションサービスとして案内されています。
App Runnerが向いているのは、次のような場面です。
複数の小さなAPIをそれぞれApp Runnerサービスとして分けると、デプロイ単位を分けやすくなります。
一方で、複雑なネットワーク制御、複数コンテナの密な連携、細かいオートスケール設計、常駐ワーカーの運用が必要なら、ECSの方が合う場面があります。
App Runnerは ECSの全部を簡単にしたもの ではなく、WebアプリやAPIを素早く動かすための選択肢として見る方が安全です。
パターン4：長く増えそうならECS + Fargate
複数のWebサービス、API、ワーカー、バッチを長く運用するなら、ECS + Fargateが候補になります。
ECS はAWSのコンテナオーケストレーションサービスで、Fargate はサーバー管理を減らしてコンテナを実行できる仕組みです。
向いている場面は次です。
ただし、小さなサービスをいきなりECSへ載せると、学習コストや設定項目が増えます。
ECR、タスク定義、サービス、クラスター、ロードバランサー、ログ、IAM、ネットワークを理解する必要があります。
そのため、ECS + Fargateは 最初から全部これ ではなく、次のようなタイミングで検討すると現実的です。
- LightsailやApp Runnerではサービス数が増えて管理しにくくなった
- ワーカーやバッチもコンテナで統一したい
- デプロイとロールバックを標準化したい
- 本番と検証環境をきちんと分けたい
- チームで長期運用する前提になった
パターン5：DBは早めに分ける
小規模サービスでは、最初はアプリサーバーとDBを同じサーバーに置くこともあります。
ただ、複数サービスを運用するなら、DBは早めに分ける価値があります。
候補は次です。
DBを分ける理由は、性能だけではありません。
- バックアップを取りやすい
- アプリサーバー交換時にDBを守りやすい
- 障害影響を切り分けやすい
- サービスごとのデータ責任を分けやすい
- 本番データへの権限管理をしやすい
逆に、複数サービスで1つのDBを共有すると、初期は速いですが後でつらくなることがあります。
サービスAの変更がサービスBに影響する。権限が広がる。削除やマイグレーションが怖くなる。
小規模でも、顧客データや課金データが絡むなら、DB共有は慎重に見るべきです。
ドメインと入口は Route 53 + CloudFront / ALB で整理する
複数サービスになると、入口の整理も重要です。
example.comapp.example.comadmin.example.comapi.example.comdocs.example.com
このようにサブドメインで分けるだけでも、役割が分かりやすくなります。
AWSでDNSを管理するなら Route 53 が候補です。
静的サイトや画像配信は CloudFront、ECSやEC2系のWebアプリはロードバランサー経由、App Runnerは独自ドメイン割り当て、というように入口をそろえます。
小規模では、入口を複雑にしすぎないことも大事です。
ただし、サービスごとにドメイン、証明書、リダイレクト、WAF、ログの扱いがバラバラになると、あとで調査が難しくなります。
小規模でよくある構成例
例1：会社サイト + 小さな管理アプリ
| 会社サイト | Amplify Hosting または S3 + CloudFront |
|---|---|
| 管理アプリ | Lightsail |
| DB | Lightsail managed database または RDS |
| 向く理由 | 静的サイトとアプリを分け、アプリ側の障害が会社サイトへ波及しにくい |
小規模受託や社内システムで現実的な形です。
最初はLightsailで始め、データが重要になったらDBを分ける進め方がしやすいです。
例2：複数の小さなAPI
| API | App Runnerをサービスごとに分ける |
|---|---|
| フロント | Amplify Hosting |
| DB | RDSをサービスごと、または用途ごとに分ける |
| 向く理由 | APIごとにデプロイでき、ECSほど運用が重くなりにくい |
APIが軽く、Webリクエスト中心ならApp Runnerは候補になります。
ただし、常駐ワーカーや複雑な内部通信が増えるならECSを検討します。
例3：Web、ワーカー、バッチが増えるサービス群
最初からこの構成にすると重いですが、長く育てる前提なら選びやすい構成です。
特にチーム開発や複数環境運用が必要なら、標準化しやすいです。
分けるべきもの、共有してよいもの
複数サービス運用では、何でも分ければよいわけではありません。
分けすぎると、請求、監視、デプロイ、証明書、ログの管理が増えます。
目安は次です。
| 対象 | 共有しやすい | 分けた方がよい |
|---|---|---|
| ドメイン | 同一ブランド配下のサブドメイン | 顧客向けと社内向け、別事業 |
| DB | 同じアプリ内の管理画面とAPI | 別サービス、別顧客、課金データ |
| サーバー | 低トラフィックの社内ツール | 障害影響を分けたい公開サービス |
| ログ | 集約先は共有 | 閲覧権限や保持期間はサービス別 |
| 請求 | 同一プロジェクト内 | 顧客別、事業別、採算を分けたい場合 |
小さいから全部共有 は短期的には楽です。
ただし、障害影響、権限、データ、請求が混ざると、後から分けるのが大変になります。
コストで見落としやすいこと
小規模AWS運用では、サーバー代だけ見ても足りません。
次も見ます。
特に小規模では、アプリ本体より周辺費用が気になることがあります。
たとえばECS構成でALBやNAT Gatewayを使うと、アプリが軽くても固定費が増えます。
LightsailやApp Runnerの方が分かりやすい場面もあります。
コストは 安いサービスを選ぶ だけでなく、運用工数を含めて安いか で見ます。
月数千円を節約するために、復旧や監視が人力だらけになるなら、結果的に高くつくことがあります。
よくある失敗
失敗例1：小さいから全部1台に載せる
最初は楽ですが、デプロイ、ログ、バックアップ、障害調査が混ざります。
会社サイト、管理画面、API、バッチが全部同じサーバーだと、1つの作業で全部に影響することがあります。
失敗例2：最初からECSで作り込みすぎる
ECSは強力ですが、理解する範囲が広いです。
小さなLPや単純な管理画面だけなら、Amplify HostingやLightsailの方が早いことがあります。
失敗例3：DB共有を軽く見る
サービスが別なのにDBを共有すると、あとから権限、マイグレーション、バックアップ、障害影響が絡みます。
別サービスとして育てるなら、DB境界は早めに検討します。
失敗例4：監視とバックアップを後回しにする
小規模でも、公開サービスなら最低限の監視とバックアップは必要です。
構成を立派にするより、障害に気づけること、戻せることの方が先に効く場面は多いです。
構成を選ぶチェックリスト
AWSで小さなWebサービスを複数運用する前に、次を確認します。
- 静的サイトとWebアプリを分けられるか
- サービスごとにデプロイ頻度が違うか
- 障害影響を分けたいサービスがあるか
- DBを共有してよい理由があるか
- 顧客データや課金データを扱うか
- 本番と検証環境を分けるか
- ログをどこに集めるか
- バックアップと復旧手順があるか
- 月額固定費をどこまで許容できるか
- 運用担当者がその構成を理解できるか
このチェックに答えられない段階では、複雑な構成を先に決めるより、まず小さく動かして、分ける境界を見つける方が安全です。
まとめ
AWSで小さなWebサービスを複数運用するときは、最初から大きな正解を探すより、用途ごとに構成を分けて考える方が現実的です。
静的サイトはAmplify HostingやS3 + CloudFront、小さなWebアプリはLightsail、コンテナWebアプリはApp Runner、長く増えるサービス群はECS + Fargate、DBはRDSやマネージドDBを検討します。
大事なのは、サービス数そのものではなく、障害影響、DB共有、権限、デプロイ、監視、コスト、運用できる人がいるかです。
小規模だからこそ、作り込みすぎず、でも戻せる・分けられる構成にしておくと後が楽になります。