Why AWS Doesn't Consolidate Its Services - The Two-Pizza Team and Service Separation Design Philosophy
Explore why AWS continues to offer 200+ services individually, examining Bezos's API Mandate, the Two-Pizza Team organizational principle, and Conway's Law. This article analyzes the benefits and trade-offs of service separation.
The Question of Too Many Similar Services
There's a question that everyone new to AWS inevitably asks. Why do both SQS and Kinesis exist when they both handle messages? Why aren't ECS and EKS consolidated when they both run containers? Why aren't CodeCommit, CodeBuild, CodeDeploy, and CodePipeline combined into a single tool? AWS, which started in 2006 with just S3 and EC2, now offers over 200 services. This vast service portfolio is not an accident but an inevitable result of Amazon's organizational structure and design philosophy. To understand its origins, we need to go back to a single memo that Jeff Bezos sent to the entire company in 2002.
Bezos's API Mandate - Where It All Began
In 2002, Amazon's codebase had grown into a massive monolith, and inter-team dependencies had become a scaling bottleneck. Bezos addressed this problem with a clear directive to all teams: (1) All teams must expose their data and functionality through service interfaces. (2) All inter-team communication must go through these interfaces. (3) Direct access to another team's data store is absolutely prohibited. (4) Anyone who doesn't comply will be fired. This directive later became known as the "Bezos API Mandate." The critical point was that it required all interfaces to be designed at a quality suitable for external exposure. Cutting corners because something was internal-only was not permitted. This principle later led to the birth of AWS, where Amazon's internal tools were carved out as external services. S3 originated from Amazon's internal storage service, and EC2 was built on the foundation of their internal computing resource management system.
The Two-Pizza Team and Conway's Law
Another organizational principle Bezos introduced was the Two-Pizza Team. A single team should be small enough that two pizzas can feed everyone - roughly 6 to 10 people. This small team owns the entire lifecycle of a single service: design, development, and operations. This is where Conway's Law comes into play. Proposed by Melvin Conway in 1967, this law observes that organizations design systems that mirror their own communication structures. Amazon turned this law to its advantage. They defined the desired architecture (loosely coupled services) first, then designed the organizational structure to match. Since each Two-Pizza Team owns an independent service, the number of services grows proportionally with the number of teams. SQS and Kinesis exist separately because independent teams own each one, solving different customer problems. SQS specializes in reliability for asynchronous messaging, while Kinesis specializes in throughput for real-time streaming. Consolidation might seem convenient, but it's difficult for a single team to simultaneously optimize for both sets of requirements.
Three Benefits of Service Separation
First, release velocity independence. Each team can deploy their service independently without depending on other teams' release schedules. This independence is why AWS can ship thousands of feature improvements per year. Second, localized blast radius for failures. When one service experiences an outage, the impact on other services is minimized. The 2017 S3 outage affected many services, but this served as a lesson about concentrated dependency on S3, and AWS subsequently made further design improvements to make inter-service dependencies even more loosely coupled. Third, granularity of choice for customers. If you want a fully managed container execution environment, choose Fargate. If you need Kubernetes ecosystem compatibility, choose EKS. If a simple Docker execution environment is sufficient, choose ECS. A single consolidated service would struggle to offer this level of granular choice.
The Cost of Separation - Learning Curve and Integration Complexity
Service separation comes with clear trade-offs. The most prominent is the increased learning curve. When starting a new project, understanding the differences between similar services and selecting the right one takes considerable time. Pricing models also differ by service, making cost estimation complex. Friction also arises in inter-service integration. In a setup where Lambda calls DynamoDB, sends results to SQS, and another Lambda processes them, you need to individually design IAM permissions, error handling, and retry strategies for each service. AWS itself recognizes this problem and takes the approach of providing integration views after the fact. Application Composer is a tool for visually designing serverless architectures, reducing the complexity of combining individual services. Step Functions lets you declaratively describe inter-service orchestration. In other words, the strategy is to keep services separated while layering integration on top.
Implications for Your Own System Design
AWS's service separation philosophy offers insights for your own system design. When deciding microservice granularity, the criterion should be "can an independent team own this?" rather than "can this be technically split?" Aligning team boundaries with service boundaries lets you leverage Conway's Law to your advantage. On the other hand, a small organization splitting services at the same granularity as AWS is overkill. A team of 3 operating 20 microservices will find that operational costs outweigh the benefits of separation. Choosing the right granularity for your organization's size is crucial. Feeling overwhelmed by the number of AWS services is a natural reaction, but behind it lies a consistent design philosophy of aligning organizational structure with architecture. Understanding this structure clarifies the criteria for choosing between similar services. Ask yourself: what specific problem is each service trying to solve, and which problem-solution best matches your use case? For a deeper understanding of cloud architecture design philosophy, related books on Amazon are also helpful.
Summary
The reason AWS continues to offer 200+ services individually without consolidation is rooted in the 2002 Bezos API Mandate and the Two-Pizza Team organizational principle. As Conway's Law suggests, organizational structure dictates architecture, and the model of small independent teams each owning their own service produces the benefits of release velocity independence, localized failure blast radius, and granular customer choice. While there are trade-offs in learning curve and integration complexity, AWS addresses these with integration layers like Application Composer and Step Functions.