新規事業やスタートアップの案件では、「まだ利用者数も分からない」「事業がどう伸びるか未知数」という状態でインフラ構成を決めなければならない場面が数多くあります。

25年以上Webシステムの開発・運用に携わり、EC2・Route53・ELB・S3・RDSなどAWSの各サービスを使ったインフラ設計を数多く経験してきました。企画段階から一貫して関わることが多いからこそ、「技術的に正しい構成」だけでなく、「事業の不確実性に耐えられる構成」をどう決めるかを重視してきました。この記事では、要件が曖昧な段階でAWS構成を決めるときの考え方をお伝えします。

「完璧な構成」を最初から目指さない

新規事業のインフラ構成でよくある失敗は、最初から将来の大規模利用を見越した、複雑で高度な構成を組んでしまうことです。

利用者数が読めない段階で、オートスケーリングやマルチAZ構成、複雑なマイクロサービス構成を最初から組み込むと、運用コストと管理の複雑さだけが先行し、実際にはオーバースペックになるケースが多々あります。

事業が本当にうまくいくかどうかも分からない段階では、「今すぐ困らない最小限の構成」で始め、実際のアクセス数やデータ量の伸びを見ながら段階的に構成を強化していく方が、結果的にコストとリスクの両方を抑えられます。

最小構成として、まず押さえておきたい組み合わせ

新規サービスの立ち上げ時によく使う、基本的な組み合わせは次の通りです。

  • EC2：アプリケーションサーバー。まずは最小構成の1台から始め、必要に応じてスケールアップ・スケールアウトを検討する
  • RDS：データベース。自前でDBサーバーを管理するより、バックアップやパッチ適用が自動化されるRDSを使うことで、運用の手間を大きく減らせる
  • S3：画像・ファイルなどの静的コンテンツの保存先。容量を気にせず使え、耐久性も高い
  • Route53：ドメイン管理とDNS。独自ドメインでのサービス提供や、後述するELBとの組み合わせで柔軟な構成が組める
  • ELB：将来的にサーバーを複数台に増やす可能性があるなら、最初からELBを挟んでおくと、あとからの構成変更がスムーズになる

最初からすべてを揃える必要はありませんが、「あとから追加しやすい構成」を意識しておくことで、事業の成長に合わせた拡張がしやすくなります。

要件定義の段階で、インフラについて確認していること

企画段階から関わる案件では、機能要件だけでなく、インフラに関わる質問も早い段階で行うようにしています。

  • 想定される初期のユーザー数、将来的にどこまで伸びる可能性があるか
  • アクセスが集中しやすいタイミングはあるか（キャンペーンやセール、特定の時間帯など）
  • 個人情報や決済情報など、セキュリティ要件が特に厳しいデータを扱うか
  • 障害時に許容できる停止時間はどのくらいか（サービスの性質によって大きく変わる）
  • 将来的に他システムとの連携予定はあるか

これらを聞くことで、「最初から冗長構成が必須か」「まずは最小構成で様子を見られるか」の判断がつきやすくなります。特に、障害時に許容できる停止時間は、マルチAZ構成や自動フェイルオーバーの要否に直結するため、必ず確認する項目です。

運用しながら育てていくという考え方

倉庫業務の効率化を目的としたシステム開発など、業務システムの立ち上げに携わった際も、最初から完璧な構成を組むのではなく、実際の業務運用を見ながらインフラを調整していくアプローチを取ってきました。

具体的には、リリース初期はモニタリングを厚めに設定し、CPU使用率やDBの負荷状況を継続的に確認しながら、「実際にどこがボトルネックになりやすいか」を見極めます。想定と違う箇所に負荷が集中することは珍しくないため、最初の構成にこだわりすぎず、実データをもとに調整していく姿勢が重要です。

コスト管理で気をつけていること

新規事業では、インフラコストがそのまま事業の収益性に直結します。特に気をつけているのは次の点です。

  • 検証環境や一時的に使うリソースは、使わないときに停止・削除する運用ルールを最初から決めておく
  • S3のストレージクラスを、アクセス頻度に応じて使い分ける（頻繁にアクセスするデータと、アーカイブ用データを同じ設定にしない）
  • 予算アラートを設定し、想定外のコスト増加に早く気づける状態にしておく

インフラのコストは、放置すると気づかないうちに膨らんでいきやすい領域です。技術的な設計と同時に、コストの見える化もセットで考えるようにしています。

まとめ

要件が固まっていない段階でのAWS構成は、「正解の構成を最初から作る」ことより、「事業の変化に合わせて調整しやすい構成を作る」ことの方が重要です。

  • 最初から完璧を目指さず、最小構成から始める
  • EC2・RDS・S3・Route53・ELBの基本構成を押さえつつ、拡張しやすさを意識する
  • 要件定義の段階で、利用者数・アクセス特性・セキュリティ要件・許容停止時間を確認する
  • リリース後もモニタリングをもとに、実データに合わせて調整していく
  • コストは放置せず、最初から見える化・管理の仕組みを作る

事業の先行きが見えない中でインフラを決める難しさは、技術力だけでなく、事業側の状況をどれだけ引き出せるかにも左右されます。要件定義の延長線上にインフラ設計があると捉えることが、新規事業のAWS構成を決めるうえで大切な視点だと感じています。