2026年、AWSはもういらないかもしれない

君のチームがAWSを選んだ理由は何だろうか？

もしその答えが「大企業がみんな使っているから」「ボスの指示だから」「前の職場でもそうだったから」なら、この記事が参考になるかもしれない。

AWSの隠れた代償

AWSの表面的なコストは請求書の数字だ。しかし、真の代償は別のところに隠れている。

3〜5人のチームなら、インフラを立ち上げるだけでもこれらを設定する必要がある：

• VPC：ネットワーク分離、サブネットやCIDRの設定
• ALB：ロードバランサー、トラフィック分散とヘルスチェックの処理
• ECS Cluster + Service + Task Definition：コンテナのコア設定
• ECR：コンテナレジストリ。通常は dev / staging / production ごとに1つずつ必要になる
• IAM Role：権限管理。Task Execution Role、Task Role、Service-Linked Role
• EIP：固定IP（必要な場合）
• NAT Gateway：プライベートサブネットのコンテナが外部ネットワークにアクセスできるようにする
• Route 53：DNS管理
• CloudFront：CDNを導入したい場合や、ALBが直接パブリックネットワークに露出するのを防ぎたい場合に別途設定が必要

これはまだインフラだけの話だ。アプリケーションのコードはまだ1行も書き始めていない。

IAM PolicyでActionを1つ書き間違えただけで、コンテナはECRからイメージをプルできなくなる。エラーメッセージはただ CannotPullContainerError と表示されるだけで、権限の問題だとは教えてくれない。

NAT Gatewayの設定を忘れれば、コンテナは起動しても外部APIを一切叩けない。何時間もデバッグしてようやくネットワークが通っていないことに気づく、なんてこともあり得る。

ある程度の規模がある企業であれば、これらのプロセスは通常すでに標準化されており、それに従うだけでいい。

僕の前の会社ではプライベートクラウドを採用しており、ワンクリックでK8sクラスタを構築できた。VPSであっても一般的なスクリプト設定が組み込まれており、モニタリング、OSパラメータ、ロギング、踏み台サーバーなどはインスタンス作成後に自動で設定された。

立ち上げたばかりのスタートアップにそんな規模があるはずもなく、これらの作業は何のプロダクト価値も生まないのに、少なくともエンジニア1人分のリソースを食いつぶしてしまう。

ECSデプロイ戦略という記事で、僕はある5人チームが複雑なデプロイフローのせいで毎年約200〜250万台湾ドル（約900〜1100万円）の隠れコストを支払っていると試算した。

まずは固定費を見てみよう：

• NAT Gatewayは、トラフィックの有無にかかわらず毎月少なくとも $32 USD。
• ALBの基本料金は $16 USD。
• 2 vCPU / 4GB の Fargate タスクは、コンピュート費用だけで毎月 $70-80 USD。

これらを合わせると、何も動かしていない状態でもすでに月額 $120 USD を超えている。

AWSの egress（データ送信）は従量課金制で、東京リージョンは1GBあたり $0.114 USD かかる。CDNを導入している一般的なウェブサービスで見積もると、月間アクティブユーザー（MAU）40〜50万人でおよそ1TBの egress が発生し、対応するトラフィック費用は約 $117 USD/月 になる。

もしCDNを導入していなければ、わずか1.5〜2万人のMAUで同じトラフィックに達する。さらにNAT Gatewayのデータ処理費用（$0.045/GB）も加わるため、1TBあたりさらに $46 USD 上乗せされる。

これらのトラフィック費用は、初期のコスト見積もりには現れてこない。プロダクトのリリース直後はトラフィックが非常に低いからだ。だが、ユーザーが増えるにつれて請求書は静かに膨らんでいき、固定費にトラフィック費用が加われば、毎月あっさりと $300 USD を突破してしまう。

今はもっとシンプルな選択肢がある

以前AWSが選ばれていたのは、代替となる選択肢がほとんどなかったからだ。しかし、今は違う。

プラットフォーム	適したユースケース
Railway / Render / Zeabur	フルスタックアプリケーション、APIサービス
Cloudflare Workers	V8エンジンアーキテクチャ、コールドスタートほぼゼロ、CPU実行時間のみで課金
Vercel	Edge Functionsを使いたい、Next.js製のサービス
Supabase	すぐに使えるデータベース、認証、CRUD APIが欲しい
PlanetScale	データベース開発・デプロイプラットフォーム、スキーマ変更をGitライクなワークフローに統合

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

だが、VercelとNext.jsの統合は極めて優れており（これこそが彼らのビジネス戦略だ）、Next.js プロジェクトならプッシュ一発で本番リリースできる。

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

• Railway：UIとデプロイ体験が非常に優れており、使いやすいCLIが用意され、ネイティブで複数環境の管理をサポートしている
• Supabase：組み込みの認証機能があり、SDKと連携できるため自前で実装する必要がほぼない。さらに CRUD API やWeb上でテーブルを直接編集できるエディタも備わっている

僕は Zeabur にも大いに期待しており、個人のプロジェクトはすべてZeaburを使ってデプロイしている。ただ、現時点で手放しでおすすめできない理由がいくつかある：

• プロダクトの方向性：初期は赤字覚悟の無料枠で開発者を引きつけ、その後Vibe Coder向けのデプロイサービスへと舵を切り、現在はAI DevOpsへと変化している。スタートアップが市場を模索するために方向転換を繰り返すのは理解できるが、企業にとっては不安定要素となる
• 最近の障害発生率：Zeaburがダウンする場面に何度か遭遇した

現在、Zeaburは共有クラスタの形式を廃止し、ユーザーがまずホストマシンを購入した上で、Zeaburが統一された管理インターフェースを提供する形をとっている。Zeaburの開発状況は今後も注視していきたい。

もう一つ、僕がずっと使ってみたいと思っているのが PlanetScale だ。元GitHub VPoEのSam Lambertが率いる企業で、以下の機能に強く惹かれている：

• Database branching：データベースレベルのブランチ作成。完全に隔離された環境でスキーマを変更・テストした上でマージを判断できる。異なる機能開発でスキーマの大規模な変更が伴う場合に非常に強力だ
• Deploy requests：スキーマ変更を直接本番環境に適用するのではなく、まずデプロイリクエストを発行し、差分確認とレビューを経てから適用する。以前DBAにレビューを依頼していたようなプロセスを大幅に簡略化できる
• 開発者体験：単にDBインスタンスを提供するだけでなく、開発ツールまで丸ごと整えてくれている

AWSはもはや唯一の選択肢ではない。ただ、長く使いすぎると他の道があることを忘れがちになるだけだ。

どんなときにAWSは依然として合理的か

以下のようなシナリオであれば、AWSを選ぶのは合理的だ：

• コンプライアンス要件がある：金融、医療、政府調達など、特定の認証（HIPAA、ISO 27001）やデータの国内保持要件が求められる場合。この分野におけるAWSのドキュメントとサポートは最も充実している
• トラフィックの規模が十分に大きい：MAUが100万人を超え、きめ細やかなトラフィック制御とコスト最適化が必要な場合。この規模になれば、AWSのReserved InstanceやSavings Plansによって大幅なコスト削減が見込め、代理店との割引交渉の余地も十分に生まれる
• チームに専任のインフラエンジニアがいる：Terraform、モニタリング、セキュリティなどをフルタイムで担当するメンバーがいてこそ、AWSの柔軟性を最大限に活かすことができる
• AWS独自のサービスを深く利用している：SageMaker、Kinesis、DynamoDBなど直接の代替品がないサービスであり、かつそれらがプロダクトのコアを担っている場合

もし上記の条件に1つも当てはまらないのであれば、AWSを採用するのはオーバースペック（overkill）だ。

あとから移行する場合のコスト

よくある反論に、「最初はシンプルなプラットフォームを使い、トラフィックが大きくなってからAWSに移行すればいいのでは？ でも移行コストが高すぎるのでは？」というものがある。

確かに移行にはコストがかかるが、切り分けて考える必要がある：

• アプリケーション層：サービスがコンテナ化（Docker）されていれば、どこへ持っていっても同じだ。CI/CDパイプラインは書き直す必要があるが、それは一度きりの作業で済む
• データベース：これは移行において比較的痛みを伴う部分だ。しかし、データベースの移行を本気で検討しなければならない規模に達しているなら、通常、移行自体はもはや問題ではなくなっている（対応するためのリソースや予算がすでに確保されている）
• ネットワークアーキテクチャ：シンプルなプラットフォームからAWSへ移る場合、VPCやALBは最初から設定し直すことになる。これには確かに時間がかかるが、これも一度きりの作業だ

多くのスタートアップにおけるボトルネックは、インフラが耐えられないことではなく、プロダクトがまだプロダクトマーケットフィット（PMF）を見つけられていないことにある。このフェーズにおいて、プロダクトのコードを1行も書かないまま2ヶ月もかけてAWSのインフラ構築にかかりきりになることこそが、真に高くつく選択だ。

インフラの選定はビジネス上の意思決定だ

インフラを選ぶことは、本質的に投資である。投資である以上、リターンを問わなければならない。この資金とリソースを投じることで、会社に何をもたらすことができるのか？ その答えは、会社が今どのステージにあり、今後どこへ向かおうとしているのかによって異なる。

• プロダクト初期：目標はPMFの発見であり、このフェーズで最も貴重なリソースは「時間」だ。インフラに費やす時間が1週間増えるごとに、プロダクトの仮説検証に使える時間が1週間減る。明日すぐにでもリリースできるプラットフォームを選び、すべてのエネルギーをプロダクトそのものに注ぐべきだ
• プロダクト成長期：ユーザーが急増し、システムに負荷がかかり始め、スケーラビリティが現実の課題となる。このタイミングになって初めてAWSのようなプラットフォームを評価する価値が出てくる。具体的な要件（トラフィックの成長曲線、パフォーマンスのボトルネック）が手元にあるからだ
• M&A（買収）やIPOの準備期：インフラの選択は企業の財務指標に直結する。粗利率や税引前利益といった数字の背後には、すべてインフラのコスト構造が関わっている

それぞれのステージでインフラに求められる要件は異なり、対応する投資規模やリターンも変わってくる。プロダクトの足場すら固まっていない段階でAWSに大きく賭けるのは、どんなレストランを開くかも決まっていないのに3ヶ月かけて内装工事を進めるようなものだ。

技術リーダーが陥りがちな罠は、技術的な言葉を使ってインフラの予算を獲得しようとすることだ。しかし、経営陣が気にしているのは、その投資がどれだけのROIをもたらすのか、どれだけの運用コストを削減できるのか、プロダクトをどれだけ迅速に市場へ投入できるのかという点だ。ビジネスの言葉でコミュニケーションを取れるようになって初めて、経営陣はモダン化の提案に真剣に耳を傾けてくれる。

インフラの選定は、会社のステージや戦略の進化に合わせて段階的に進めるべきだ。まずはプロダクトを作り上げ、検証を終えてから考えればいい。初日から10年後のトラフィックに備える必要など、どこにもないのだ。