As organizations scale their cloud-based applications, managing development across multiple teams in AWS becomes crucial. Without a well-structured approach, teams can face inefficiencies, security risks, and deployment bottlenecks. In this blog post, we’ll explore several strategies to organize development across multiple teams in AWS, each with its own pros and cons.
Before we jump into the propositions, a couple of assumptions:
- we are designing an application that can be distributed
- we have N teams where N > 2. For a project that consists of a small number of teams, the rules are different
Single AWS Account for everything
This is the simplest organizational model. However, simplicity often comes with trade-offs. The biggest drawback here is the risk of tightly coupling different application environments. While you may intend to keep them separate, this model makes unintended dependencies highly likely. Sharing resources should be avoided at all costs.
Due to this fundamental limitation, we won’t delve further into this approach. Instead, let’s explore a more robust organizational model.
Single AWS Account per environment
I’ve seen this type of development organization in several companies. While it can function, it comes with significant drawbacks that need to be addressed.
- Many AWS services, such as IAM, Trusted Advisor, and ECR, operate at the account or region level. These services can’t be deployed in the team’s VPC. This makes it challenging to restrict access to specific teams, leading to potential security and governance issues.
- Cost tracking is another challenge. Since all teams share the same account, effectively monitoring and attributing costs requires extensive use of tagging, which can be difficult to enforce consistently.
- With multiple teams working within a single account, you’re likely to hit AWS quota limits quickly. While quotas can be increased, managing these limits during development can be frustrating and disruptive.
- It can be tempting to use a single Terraform project for managing an entire AWS account, especially when the account structure encourages it. However, in my experience, this approach introduces a new set of challenges, including increased cognitive load, unclear code ownership, frequent Git conflicts, and, ultimately, team friction. In the world of microservices, having standardized practices is crucial. However, teams should also have the flexibility to structure their Infrastructure-as-Code (IaC) in a way that best suits their workflows. No one wants a rigid, top-down dictatorship dictating how to organize directories. Striking a balance between standardization and autonomy is key to maintaining both efficiency and team harmony.
- Lastly, resource ownership becomes ambiguous. When everyone deploys to the same account, who takes responsibility for shared resources? Who reviews Trusted Advisor findings? Who maintains alerts? Without clear accountability, maintaining a well-structured and efficient AWS environment becomes increasingly difficult.
Multiple AWS Account per team & environment
In my opinion, this is the most effective model an organization can adopt. It not only ensures strict separation between environments but also empowers teams with full control over their own resources.
In this approach, each environment (e.g., dev, stage, prod) consists of multiple AWS accounts—one per team. This eliminates the challenges of the Single AWS Account per Environment model, such as security risks, access control issues, and resource ownership conflicts. However, it does introduce a significant downside: cost.
While AWS accounts themselves are free, the resources deployed within them can become expensive. I’ve seen companies extensively use services like GuardDuty, CloudWatch, AWS Config, and Trusted Advisor in every account, aggregating data into central monitoring accounts. While this approach enhances security and visibility, the accumulated costs for a “standard” account setup can be substantial. Organizations must carefully balance the benefits of isolation with the financial impact of running multiple AWS accounts.
Such AWS Account management allows the teams to create an API (e.g. exposed by AWS Private Link) and treat their AWS account as an internal component.
Exemplary diagram of simple API hosted by different teams
AWS blog: https://aws.amazon.com/blogs/compute/architecture-patterns-for-consuming-private-apis-cross-account/