AWSの構成はどう選ぶ？中小企業の規模・用途別に5つのパターンと比較表、開発会社への確認点

2026年9月14日2026年10月4日

開発会社から「AWSで構築します」と提案されたものの、構成図には知らないサービス名が並び、それが自社の規模に合っているのか判断できない。AWSの構成の選び方は、システムを新しく発注する担当者がつまずきやすいポイントです。

「AWSで構築すると言われたけど、どんな構成がうちの規模に合っているのか分からない…」

先に結論をお伝えします。中小企業のシステムで使われるAWSの構成は、おおむね5つの型に分けられます。そして、どの型が合うかは「アクセスの量と波」「止まったときの影響」「運用を誰がどこまで担うか」の3点でほぼ決まります。

この記事では、よくある5つの構成パターンを専門用語をかみ砕いて紹介し、比較表・判断の流れ・開発会社に確認したい質問をまとめます。なお、小規模なサイトであればAWSにこだわらず、レンタルサーバーやPaaS（＝サーバー管理を事業者に任せられるアプリ実行サービス）で十分なこともあります。その点も含めて見ていきましょう。

AWSの構成選びで迷う理由と、判断の土台になる考え方

同じ「AWSで構築」でも中身はまったく違う

AWS（Amazon Web Services）には非常に多くのサービスがあり、サーバー1台の簡単な構成も、複数のデータセンターにまたがる構成も、どちらも「AWS」です。構成によって、毎月の費用の出方、障害時の止まりにくさ、運用の手間が大きく変わります。

AWS自身が示す「良い設計」の6つの観点

AWSは、設計の良し悪しを確認するための考え方として「AWS Well-Architected フレームワーク」を公開しています。

📰 出典：AWS Well-Architected（AWS公式）

執筆時点（2026年9月）では、次の6つの柱で構成されています。

柱	発注者向けの言い換え
オペレーショナルエクセレンス	運用・監視・改善を無理なく続けられるか
セキュリティ	情報とシステムを守れるか
信頼性	想定どおりに動き、障害から素早く復旧できるか
パフォーマンス効率	必要な分だけ無駄なく処理能力を使えているか
コスト最適化	不要なコストを避けられているか
持続可能性	資源を無駄に使わず環境負荷を抑えられているか

大切なのは、6つを全部「最高レベル」にする必要はないということです。止まりにくさを高めれば費用は上がり、費用を抑えれば運用の手間が増えることもあります。自社にとってどの柱をどこまで重視するかを決めることが、構成選びの本質です。

「AWSが面倒を見てくれる範囲」は構成で変わる

AWSは「責任共有モデル」という考え方を示しています。建物や物理的な機器、仮想化の土台はAWSが守り、その上で動くOSの更新やアプリケーション、アクセス権限の設定などは利用者側の責任になる、というものです。

📰 出典：責任共有モデル（AWS公式）

サーバーを自分で持つ型（後述のパターン1・2のEC2）ほど利用者側の作業が多く、サーバー管理をAWSに任せる型（パターン3〜5）ほど少なくなります。ここでいう「利用者側」とは、実際には保守を請け負う開発会社か、自社の担当者です。誰がやるのかを契約前に決めておくことが重要です。

中小企業でよく使われるAWS構成パターン5つ

パターン1：小規模・低トラフィック向け「Lightsail（またはEC2 1台）」

Amazon Lightsailは、サーバー・データベース・ストレージなどを月額のセットで使える、AWSの中でも簡易なサービスです。公式ページでは、事前設定されたクラウドリソースを月額料金で使える点や、WordPressなどのWebサイト、小規模な業務アプリの用途が紹介されています。EC2（＝AWSの仮想サーバー）を1台だけ使う構成も、考え方はほぼ同じです。

📰 出典：Amazon Lightsail（AWS公式）

向いているケース：社内の数十人が使う管理ツール、アクセスが少ないコーポレートサイト、試作品（検証用）
向かないケース：止まると売上に直結するサービス、アクセスが急増する可能性があるもの
運用の手間：OSやミドルウェアの更新・バックアップ設定は利用者側（開発会社または自社）の担当
費用の構造：月額のセット料金が中心で、予算を立てやすい固定費型
可用性の考え方：基本的にサーバー1台。故障時は「バックアップから復旧する」前提で、復旧までの時間を許容できるかがポイント

パターン2：一般的なWebシステム「ALB＋EC2／ECS（Fargate）＋RDS」

いわゆる定番の構成です。ALB（Application Load Balancer＝アクセスを複数のサーバーに振り分ける装置）の後ろにアプリを動かすサーバー（EC2、またはコンテナ実行環境のECS）を置き、データはRDS（＝AWSが管理するデータベースサービス）に保存します。ALBは振り分け先の状態を定期的に確認し、正常なところにだけアクセスを流す仕組みを持っています。

📰 出典：Application Load Balancer（AWS公式）

データベースを止まりにくくしたい場合は、RDSの「マルチAZ配置」を検討します。AZ（アベイラビリティーゾーン）とは、同じ地域内の独立したデータセンター群のことで、マルチAZでは別のAZに待機用のデータベースを用意し、障害時に自動で切り替えます。

📰 出典：Amazon RDS マルチAZ（AWS公式）

向いているケース：会員サイト、予約システム、取引先も使う業務システムなど、一定の利用者が毎日使うもの
向かないケース：ごく少人数の社内ツール（部品が多い分、費用と手間が見合わないことがある）
運用の手間：中程度。EC2を使う場合はOS更新が必要。データベースの更新やバックアップの仕組みはRDSの機能を使える
費用の構造：サーバーやデータベースを常時動かすため、固定費に近い。マルチAZにすると待機用の分だけ費用が増える
可用性の考え方：サーバーとデータベースをそれぞれ複数AZに置けば、1か所の障害で全停止しにくくなる。ただし「どこまで二重化するか」は要件次第

パターン3：アクセス変動が大きい・イベント駆動「サーバーレス」

API Gateway（＝外部からの呼び出しの受付窓口）、Lambda（＝必要なときだけプログラムを動かすサービス）、DynamoDBやAurora Serverless（＝使った分に応じて容量が伸び縮みするデータベース）を組み合わせる構成です。Lambdaの公式ページでは、サーバーを意識せずにコードを実行でき、ミリ秒単位の従量制料金であることが示されています。

📰 出典：AWS Lambda（AWS公式）

📰 出典：Aurora Serverless（AWS公式）

Aurora Serverlessの公式ページでは、需要に応じて容量を自動で増減し、ゼロまで縮小できることが説明されています（執筆時点）。

向いているケース：キャンペーン時だけアクセスが集中するサイト、ファイルが届いたら処理する・毎晩集計するといった「きっかけがあって動く」処理
向かないケース：長時間動き続ける処理、既存のアプリをそのまま移したい場合（作り方がサーバー型と異なるため）
運用の手間：サーバーのOS管理は不要。その代わり、部品が細かく分かれるため、監視や障害調査には慣れが必要
費用の構造：リクエスト数や実行時間に応じた従量型。使わなければ安く、使うほど増える。アクセスが多い状態が続くと、常時稼働型より割高になる場合もある
可用性の考え方：サーバーの二重化はAWS側の仕組みに任せられる部分が大きい。一方で、呼び出し回数の上限などサービスごとの制限の確認が必要

パターン4：静的サイト＋API「S3＋CloudFront（＋Lambda）」

S3（＝ファイル置き場のサービス）にWebページのファイルを置き、CloudFront（＝世界各地の拠点からページを配信する仕組み）で届ける構成です。問い合わせフォームの送信など、動的な処理が少しだけ必要な部分はLambdaで補います。S3の公式ドキュメントでは、S3で静的ウェブサイトをホストできる一方、サーバー側のプログラムは動かせないことが説明されています。また、S3上の静的サイトの公開にはAWS Amplify Hostingの利用が推奨されています（執筆時点）。

📰 出典：Amazon S3 を使用して静的ウェブサイトをホスティングする（AWS公式ドキュメント）

向いているケース：更新頻度が低いコーポレートサイト、製品紹介ページ、画面はブラウザ側で動かしデータだけAPIから取得するシステム
向かないケース：ログインしてデータを入出力する本格的な業務システム（別途APIやデータベースの構成が必要）
運用の手間：少ない。サーバーを持たないため、OS更新は不要
費用の構造：保存量と配信量に応じた従量型。アクセスが少なければ小さく収まりやすい
可用性の考え方：配信はAWSの仕組みに任せられる。更新作業のミス（誤ったファイルを上書きなど）への備えのほうが重要

パターン5：複数サービスを動かす「ECS Fargate中心のコンテナ構成」

コンテナ（＝アプリと動作環境をひとまとめにした箱）を、ECS（＝コンテナを管理するサービス）とFargate（＝サーバーを意識せずコンテナを動かす仕組み）で運用する構成です。Fargateの公式ページでは、サーバー管理やスケーリング（＝処理能力の増減）をAWSに任せられ、使用したコンピューティングリソースの分だけ支払う仕組みであることが説明されています。

📰 出典：AWS Fargate（AWS公式）

向いているケース：管理画面・API・バッチ処理など複数の機能を分けて動かしたい、将来機能を増やしていく予定がある
向かないケース：機能が少なく今後も大きく変わらないシステム（仕組みが大がかりになりやすい）
運用の手間：OS管理は不要。ただしコンテナを作り直して届ける仕組み（デプロイの自動化）を整えるのが前提で、その保守ができる体制が必要
費用の構造：動かしている間のCPU・メモリ量に応じた従量型。常時動かすなら実質的には固定費に近くなる
可用性の考え方：複数AZでコンテナを動かせば、1か所の障害に強くなる。パターン2と同様、どこまで二重化するかは要件次第

AWS構成パターンの比較表

観点	1 Lightsail／EC2 1台	2 ALB＋EC2/ECS＋RDS	3 サーバーレス	4 S3＋CloudFront	5 ECS Fargate
想定規模	小規模・低アクセス	中規模・継続利用	変動が大きい	閲覧中心	複数機能・拡張前提
費用の構造	固定費型（月額セット）	固定費に近い	従量型	従量型	従量型（常時稼働なら固定費に近い）
運用の手間	OS更新などが必要	中程度	OS管理不要・監視に慣れが必要	少ない	OS管理不要・デプロイの仕組みが必要
止まりにくさ	1台なので低め	二重化次第で高められる	AWS側の仕組みに任せやすい	高めやすい	二重化次第で高められる
注意点	故障時は復旧待ち	部品が多く費用が増えやすい	作り方が独特・制限の確認	動的な処理は別途必要	仕組みが大がかりになりやすい

※ 費用は構成・使用量・契約で大きく変わるため、ここでは金額ではなく「費用の出方」で比較しています。具体的な金額は、後述のAWS Pricing Calculatorで見積もりを出してもらいましょう。

どの構成を選ぶべきか：判断の流れ

次の質問に順番に答えていくと、候補が絞れます。

閲覧が中心で、ログインやデータ入力はほとんどない → パターン4（小規模ならレンタルサーバーやPaaSでも十分な場合あり）
利用者は社内の少人数で、数時間止まっても業務が回る → パターン1（バックアップと復旧手順は必ず決める）
アクセスが特定の時期に集中する、または「何かが起きたら動く」処理が中心 → パターン3
複数の機能を分けて動かし、今後も育てていく予定 → パターン5
上記以外で、毎日一定の利用者が使うWebシステム → パターン2（止まった時の影響が大きいほど二重化を厚くする）

実際には「画面はパターン4、裏側はパターン3」のように組み合わせることもよくあります。判断の流れは出発点と考えてください。

なお、そもそもスクラッチ開発（＝ゼロから作る開発）が必要か、既存のSaaSやノーコードで済むかという段階から迷っている場合は、先にそちらを整理すると構成の話もしやすくなります。

ノーコード・SaaS・スクラッチ開発どれを選ぶ？業務アプリの判断基準と比較表

構成を決める前に開発会社に確認したい6つのポイント

1. なぜこの構成なのか

「他の型ではなく、なぜこれなのか」を聞きましょう。アクセスの傾向、止まった時の影響、運用体制に沿った説明が返ってくれば、自社の事情を踏まえた提案だと判断できます。

2. 想定アクセスとその根拠

「同時に何人が使う想定か」「その数字はどこから来たか」を確認します。発注者側から、利用者数や繁忙期のデータを渡すと、構成の精度が上がります。

3. 障害時にどうなるか

「1か所止まったら、どのくらいの時間でどこまで戻るか」を具体的に聞きます。自社が許容できる停止時間と、失ってもよいデータの範囲（例：直前の1日分まで）を伝え、構成と費用のバランスを一緒に決めます。

4. 月額費用の内訳

AWSは「AWS料金見積りツール（AWS Pricing Calculator）」という無料の見積もりツールを公開しています。見積もりはリンクで共有したり、CSVやPDFで書き出したりできます。

📰 出典：AWS 料金見積りツールとは（AWS公式ドキュメント）

開発会社にはこのツールで見積もりを作ってもらい、サービスごとの内訳と、前提にした使用量を確認しましょう。アクセスが2倍・3倍になったときの試算もあると安心です。また、AWSには新規アカウント向けの無料枠やクレジットの制度がありますが（執筆時点）、期間や条件があり内容も変わることがあるため、「無料期間が終わった後の金額」で比較してください。

📰 出典：AWS 無料利用枠（AWS公式）