なぜ AWS はサービスを統合しないのか - Two-Pizza Team とサービス分離の設計哲学
AWS が 200 以上のサービスを個別に提供し続ける理由を、Bezos の API Mandate、Two-Pizza Team の組織原則、Conway の法則の観点から解説し、サービス分離がもたらす利点と代償を考察します。
似たサービスが多すぎるという疑問
AWS を使い始めた人が必ず抱く疑問があります。SQS と Kinesis はどちらもメッセージを扱うのになぜ 2 つあるのか。ECS と EKS はどちらもコンテナを動かすのに統合しないのか。CodeCommit、CodeBuild、CodeDeploy、CodePipeline はなぜ 1 つのツールにまとめないのか。2006 年に S3、SQS、EC2 の 3 サービスから始まった AWS は、現在 200 以上のサービスを提供しています。この膨大なサービス群は偶然の産物ではなく、Amazon という組織の構造と設計思想が生み出した必然的な結果です。その根源を理解するには、2002 年に Jeff Bezos が社内に発した 1 通のメモまで遡る必要があります。
Bezos の API Mandate - すべてはここから始まった
2002 年、Amazon のコードベースは巨大なモノリスに成長し、チーム間の依存関係がスケーリングのボトルネックになっていました。Bezos はこの問題に対し、全チームへ向けた指令を出したと伝えられています。この指令は後に「Bezos API Mandate」として知られるようになりました。ただし、条文の形で流布している文面は Amazon が公式に公表したものではなく、元 Amazon の技術者が 2011 年に公開した回想が事実上唯一の出所です。そこで伝えられている要点は、(1) すべてのチームは自分たちのデータと機能をサービスインターフェースを通じて公開すること、(2) チーム間の通信はすべてこのインターフェースを経由すること、(3) 他のチームのデータストアへ直接アクセスすることは認めないこと、(4) 従わない場合は職を失うという強い調子の警告、の 4 点です。重要なのは、この指令がすべてのインターフェースを外部公開可能な品質で設計することを求めた点です。内部用だからといって手を抜くことは許されませんでした。この原則の下では、社内向けの機能であっても、ネットワーク越しの API だけで呼び出せる独立した部品として設計することになります。データストアを共有して手早く済ませる近道が塞がれる代わりに、各チームは相手の実装を知らないまま機能を組み合わせられます。外から使える単位でサービスを切り出すというこの習慣が、後に AWS が独立したサービスを個別に提供していく土壌になりました。
Two-Pizza Team と Conway の法則
Bezos が導入したもう 1 つの組織原則が Two-Pizza Team です。1 つのチームは 2 枚のピザで全員が食事できる規模に収めるというルールです。人数を厳密に定めた規定ではなく、全員が同じテーブルで議論を終えられる小ささを保つという考え方です。この小さなチームが 1 つのサービスの設計、開発、運用のすべてに責任を持ちます。ここで作用するのが Conway の法則です。1968 年に Melvin Conway が論文「How Do Committees Invent?」で示したこの法則は、組織が設計するシステムは、その組織のコミュニケーション構造を反映するという観察です。Amazon はこの法則を逆手に取りました。望ましいアーキテクチャ (疎結合なサービス群) を先に定義し、それに合わせて組織構造を設計したのです。各 Two-Pizza Team が独立したサービスを持つため、サービスの数はチームの数に比例して増えていきます。SQS と Kinesis が別々に存在するのは、それぞれを担当する独立したチームが存在し、異なる顧客課題を解決しているからです。SQS は非同期メッセージングの信頼性に特化し、Kinesis はリアルタイムストリーミングのスループットに特化しています。統合すれば便利に見えますが、1 つのチームが両方の要件を同時に最適化することは困難です。
サービス分離がもたらす 3 つの利点
第一に、リリース速度の独立性です。各チームが自分のサービスを独立してデプロイできるため、他チームのリリーススケジュールに依存しません。AWS の新機能や改善が絶え間なく積み上がっていくのは、この独立性があるからです。リリースの単位がサービスごとに閉じているため、全体を止めずに個別の改善を続けられます。第二に、障害の爆発半径の局所化です。1 つのサービスに障害が発生しても、他のサービスへの影響を最小限に抑えられます。2017 年の S3 障害では多くのサービスが影響を受けましたが、これは逆に S3 への依存が集中していたことの教訓となり、AWS はその後サービス間の依存関係をさらに疎結合にする設計改善を進めました。第三に、顧客にとっての選択の粒度です。コンテナを動かす場合、まず管理の仕組みとして、AWS に寄せた運用の簡潔さを取るなら ECS、Kubernetes エコシステムとの互換性が必要なら EKS を選びます。そのうえで実行基盤を、サーバーの管理を手放したいなら Fargate、インスタンスの種類や配置を自分で制御したいなら EC2 から選びます。Fargate は ECS と EKS のどちらからも利用できるコンピュートエンジンであり、ECS や EKS の代わりになるものではありません。統合された 1 つのサービスでは、この粒度の選択肢を提供することが難しくなります。
分離の代償 - 学習コストと統合の複雑さ
サービス分離には明確な代償もあります。最も顕著なのは学習コストの増大です。新しいプロジェクトを始めるとき、類似サービスの違いを理解し、適切なものを選定するだけで相当な時間を要します。料金体系もサービスごとに異なるため、コスト見積もりが複雑になります。サービス間の連携にも摩擦が生じます。Lambda から DynamoDB を呼び出し、結果を SQS に送り、別の Lambda で処理するといった構成では、各サービスの IAM 権限、エラーハンドリング、リトライ戦略をそれぞれ個別に設計する必要があります。AWS 自身もこの問題を認識しており、後から統合ビューを提供するアプローチを取っています。Infrastructure Composer は、CloudFormation が扱えるリソースをブラウザや VS Code のキャンバス上に配置して構成を組み立て、CloudFormation や AWS SAM のテンプレートを生成できるツールです (2026 年 8 月時点の公式ドキュメント記載の位置づけ)。サーバーレス構成の設計から広がったツールですが、対象はサーバーレスに限られず、個別のサービスを組み合わせる複雑さを軽減します。Step Functions はサービス間のオーケストレーションを宣言的に記述できます。つまり、サービスそのものは分離したまま、統合のレイヤーを上に被せるという戦略です。
自分のシステム設計への示唆
AWS のサービス分離の思想は、自社のシステム設計にも示唆を与えます。マイクロサービスの粒度を決めるとき、「技術的に分割できるか」ではなく「独立したチームが責任を持てるか」を基準にすべきです。チームの境界とサービスの境界を一致させることで、Conway の法則を味方につけられます。一方で、小さな組織が AWS と同じ粒度でサービスを分割するのは過剰です。3 人のチームが 20 のマイクロサービスを運用するのは、分離の利点よりも運用コストが上回ります。組織の規模に合った分割粒度を選ぶことが重要です。AWS のサービスが多すぎると感じるのは自然な反応ですが、その背景には組織構造とアーキテクチャを一致させるという一貫した設計哲学があります。この構造を理解すれば、類似サービスの選定基準も明確になります。各サービスが解決しようとしている具体的な課題は何か、自分のユースケースにはどの課題解決が最も合致するか、という視点で選べばよいのです。
まとめ
AWS が 200 以上のサービスを統合せず個別に提供し続ける理由は、2002 年の Bezos API Mandate と Two-Pizza Team という組織原則に根ざしています。Conway の法則が示すとおり、組織構造がアーキテクチャを規定し、小さな独立チームがそれぞれのサービスを所有する体制が、リリース速度の独立性、障害の局所化、顧客の選択肢の粒度という利点を生み出しています。学習コストや統合の複雑さという代償はありますが、AWS は Infrastructure Composer や Step Functions といった統合レイヤーで補完する戦略を取っています。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
- AWS Infrastructure Composer 公式ページ
- AWS Organizations 公式ページ
- AWS Well-Architected Tool 公式ページ
- AWS ドキュメント (公式)
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。