· 8分で読了

2026年、あなたはAWSを必要としないかもしれない

# ソフトウェアエンジニアリング
この記事は中国語から自動翻訳されたものです。翻訳によりニュアンスが失われている場合があります。

あなたのチームがAWSを選ぶ理由は何だろうか？

もし答えが「大企業も使っているから」「上司が使えと言ったから」「前の職場でもそうだったから」なら、この記事は参考になるはずだ。

AWS の隠れた代償

AWSの表面的なコストは請求書に載る数字だ。本当の代償は別のところにある。

3〜5人のチームが、インフラを動かすだけでも設定が必要になる。

  • VPC：ネットワーク分離。subnet、CIDRの設定
  • ALB：Load Balancer。トラフィック分散とヘルスチェックを処理する
  • ECS Cluster + Service + Task Definition：コンテナの中核設定
  • ECR：Container Registry。しかも通常は dev / staging / production ごとに1つずつ必要になる
  • IAM Role：権限管理。Task Execution Role、Task Role、Service-Linked Role
  • EIP：固定IP（必要なら）
  • NAT Gateway：private subnet のコンテナが外部ネットワークにアクセスするためのもの
  • Route 53：DNS管理
  • Cloudfront：CDNをつなぎたい場合、あるいはALBを外部ネットワークに露出させたくない場合に追加設定が必要

これはまだインフラにすぎない。アプリケーションコードを1行も書いていない。

IAM Policy のActionを1つ書き間違えるだけで、container は ECR から image を取得できなくなる。エラーメッセージは CannotPullContainerError としか言わず、権限の問題だとは教えてくれない。

NAT Gateway の設定を忘れると、container は起動しても外部APIに一切つながらない。ネットワーク不通だと気づくまで、何時間もdebugすることになるかもしれない。

ある程度規模のある会社では、こうした手順はたいてい標準化されているので、その通りやればいい。

前職では Private Cloud を使い、K8S クラスターをワンクリックで作成できた。VPS であっても、よく使うスクリプト設定、監視、OSパラメータ、Logging、踏み台サーバーまで、Instance を作ったあとにそのまま設定されるようになっていた。

立ち上げたばかりの会社には、そうした規模はまずない。これらの作業は何の製品価値も生まないのに、少なくとも1人分のエンジニアの生産性を食い潰す。

ECS 部署策略 という記事では、5人チームが複雑なデプロイフローのせいで負担する隠れコストを、年間およそ200〜250万台湾ドルと試算した。

まず固定費を見てみよう。

  • NAT Gateway は、トラフィックがあるかどうかに関係なく、毎月少なくとも $32 USD かかる。
  • ALB の基本費用は $16 USD
  • 2 vCPU / 4GB の Fargate task は、計算費用だけで毎月 $70-80 USD かかる

これらを合計すると、何も動いていない状態でもすでに $120 USD/月 を超える。

AWS の egress（データ転出）は従量課金だ。東京リージョンでは 1GB あたり $0.114 USD。CDN をつないだ一般的な web service を前提にすると、月間アクティブユーザーが40〜50万人で約1TBの egress が発生し、対応する通信費は約 $117 USD/月 になる。

CDN をつながない場合は、1.5〜2万 MAU でも同じ程度の通信量に達する。さらに NAT Gateway の data processing fee（$0.045/GB）が加わるので、1TB につきさらに $46 USD 増える。

こうした通信費は、最初のコスト見積もりには出てこない。製品の公開直後はトラフィックが少ないからだ。だがユーザーが増えるにつれて、請求額は静かに膨らみ、固定費と通信費を合わせると月 $300 USD をあっさり超える。

今はもっと簡単な選択肢がある

昔は代替手段がほとんどなかったからAWSを選んでいた。今は違う。

プラットフォーム向いているケース
Railway / Render / Zeaburフルスタックアプリ、APIサービス
Cloudflare WorkersV8エンジンベース。コールドスタート時間はほぼゼロで、CPU計算時間のみに課金される
VercelEdge Function を使いたい、サービスを Next.js で書いている
Supabaseすぐ使える Database と認証、CRUD API がほしい
PlanetScaleデータベースの開発・デプロイ基盤。schema変更を Git 風の workflow に載せられる

Vercel はもう少し触れておく価値がある。Next.js は近年、複雑さがかなり増した。React Server Components により、開発者はブラウザ側とサーバー側の違いを意識する必要があり、ISR/CSR/SSR にはそれぞれトレードオフがある。

だが Vercel と Next.js の統合は非常に良い（それ自体が彼らのビジネス戦略でもある）。Next.js プロジェクトは push するだけで一発で公開できる。

僕自身が気に入っているサービスをいくつか挙げる。

  • Railway：UI とデプロイ体験が非常に良い。CLI もあり、複数環境のサポートも最初から備わっている
  • Supabase：内蔵 auth があり、SDK に接続できるので、ほとんど自前実装が不要だ。CRUD API も使えるし、Web上で Table を編集できるエディタもある

僕は Zeabur にかなり期待している。自分の個人プロジェクトも、全部 Zeabur でデプロイしている。現時点で僕がおすすめしない理由はいくつかある。

  • プロダクトの方向性：開発初期は資金を投じて無料で開発者を集め、その後は Vibe Coder 向けのデプロイサービスへと変わり、今では AI DevOps になっている。新興企業が市場を探るためにはプロダクトの方向性を変え続ける必要があるが、会社にとっては不安定要因だ
  • 最近のエラー率：Zeabur が落ちるケースを何度か経験した

現在、Zeabur は共有 Cluster 方式を採っていない。先にマシンを購入する必要があり、Zeabur は統一されたインターフェースを提供してそのマシンを管理してくれる。開発状況は今後も追い続けるつもりだ。

もう1つ、僕がずっと使ってみたいと思っているのが PlanetScale だ。これは GitHub の元 VPoE、Sam Lambert が率いる会社で、僕がぜひ使いたい機能がいくつかある。

  • Database branching：データベースレベルのブランチ。まず隔離環境で schema を変更してテストし、そのうえでマージするか決められる。別機能の開発時に schema を大きく変える場合に非常に便利だ
  • Deploy requests：schema 変更を直接 production に当てるのではなく、まず deploy request を出し、diff を確認してレビューしてからデプロイする。以前のように DBA に審査してもらう流れを簡略化できる
  • 開発者体験：DB Instance を提供するだけでなく、開発ツールまで用意されている

AWS はもはや唯一の選択肢ではない。ただ、使い慣れてしまうと他の道があることを忘れがちだ。

それでもAWSが合理的な場合

以下のような状況では、AWSを選ぶのは合理的だ。

  • コンプライアンス要件：金融、医療、政府案件など、特定の認証（HIPAA、ISO 27001）やデータ所在要件が必要な場合。AWS はこの分野のドキュメントとサポートが最も充実している
  • トラフィック規模が十分大きい：月間アクティブユーザーが100万人を超え、きめ細かなトラフィック制御とコスト最適化が必要な場合。この規模なら AWS の Reserved Instance や Savings Plan でかなり節約できるし、代理店と交渉して割引を引き出す材料もある
  • 専任のインフラエンジニアがいる：Terraform、監視、セキュリティを専任で担当する人がいれば、AWS の柔軟性を活かせる
  • AWS専用サービスを深く使っている：SageMaker、Kinesis、DynamoDB など、直接の代替がないサービスがあり、それらが製品の中核を担っている場合

上の条件にひとつも当てはまらないなら、AWS は overkill だ。

後から移行するコスト

よくある反論はこうだ。「じゃあ最初は簡単なプラットフォームを使って、トラフィックが増えたら AWS に移せばいい。移行コストは高いだろう？」

確かに移行コストはある。ただし、分けて考える必要がある。

  • アプリケーション層：サービスがコンテナ化されている（Docker）なら、どこへ移しても同じだ。CI/CD pipeline は書き直す必要があるが、これは一度きりの作業だ
  • データベース：ここが移行で最も痛い部分だ。もし規模がすでにデータベース移行を考慮しなければならないほど大きいなら、通常は移行自体が問題になることはない（対応する資源と予算がすでにある）
  • ネットワークアーキテクチャ：簡単なプラットフォームからAWSへ移ると、VPC と ALB を一から設定し直す必要がある。確かに時間はかかるが、これも一度きりだ

多くのスタートアップにとってのボトルネックは、インフラが耐えられないことではない。まだ product-market fit を見つけられていないことだ。この段階でAWSのインフラ整備に2か月費やし、製品コードを1行も書かないのは、本当に高くつく選択だ。

インフラの選択はビジネス判断だ

インフラを選ぶことは、本質的には投資だ。投資ならリターンを問わなければならない。この金と人手を投じて、会社に何をもたらすのか。答えは、会社が今どの段階にいるか、そして将来どこへ向かうかによって変わる。

  • 製品初期：目標は Product Market Fit を探すことだ。この段階で最も高価な資源は時間である。インフラに1週間多く費やすたびに、製品仮説の検証が1週間遅れる。明日には公開できるプラットフォームを選び、すべての力を製品そのものに注ぐべきだ
  • 製品成長期：ユーザーが急増し、システムが圧力にさらされ始めると、拡張性が本当の問題になる。この段階になって初めて AWS のようなプラットフォームを評価する価値がある。なぜなら、具体的な要件（トラフィック成長曲線、性能ボトルネック）が見えているからだ
  • 買収やIPOを見据える段階：インフラの選択は会社の財務指標に直接影響する。粗利率や税引前純利益といった数字の裏には、インフラコスト構造がある

各段階でインフラに求められるものは違い、それに応じた投資規模とリターンも違う。製品がまだ足場を固めていない段階でAWSに重く賭けるのは、何を出すか決めていないのに3か月かけてレストランの内装を作り込むようなものだ。

技術リーダーが陥りやすい落とし穴は、技術用語でインフラ予算を取りにいくことだ。しかし経営層が気にしているのは、その投資がどれだけの ROI を生むか、運用コストをどれだけ下げるか、製品をどれだけ早く市場に出せるかだ。商業言語で伝えることを学んでこそ、経営層はモダナイゼーションの提案を真剣に受け止める。

インフラの選択は、会社の段階と戦略に合わせて進化させるべきだ。まずは製品を作り、検証してから考えればいい。初日から10年後のトラフィックに備える必要はない。