In the early days of cloud computing, everything was centralized. Teams operated in a single AWS account or Google Cloud project, similar to traditional datacenters. As cloud usage scaled, multi-account models (AWS) and folder/project structures (Google Cloud) emerged to manage growing complexity. While this allowed rapid innovation, it also led to significant operational and organizational challenges.

The Downside of Account/Project Proliferation

As companies gave development teams their own accounts or projects, freedom came at a cost:

• Operational Inconsistencies

  Each team manages its infrastructure, deployments, alerting, and monitoring. Skilled teams may thrive, but inexperienced ones create chaotic environments with poor operational standards.

• Cost Inefficiency

  Fragmented usage makes cost-saving tools like savings plans or reserved instances difficult to leverage. Resource choices vary widely, with little optimization across accounts or projects.

• Documentation Overload

  Keeping runbooks and processes updated across accounts/projects is time-consuming. Tasks like backups and monitoring are often duplicated unnecessarily across teams.

• Knowledge Silos

  When teams disband or external contractors leave, undocumented processes and silent knowledge become risks. This creates operational gaps and slows future efforts.

These issues make scaling operations or driving meaningful cost reductions nearly impossible, especially for smaller services that don’t need dedicated accounts or projects.

Focus on Simplicity

Before spinning up a dedicated account or project, ask yourself: What are we building, and what does it really need?

• Leverage Existing Platforms

  Use tools like Cloud Run or Heroku that provide opinionated, constrained environments. These platforms are lightweight and handle most use cases without the complexity of managing ECS/EKS/GKE.

• Avoid Over-Engineering

  Services shouldn’t always be treated as long-term assets. They might come and go, rendered unnecessary by new ones or combined with others. Many teams overcomplicate their setups, duplicating effort to build custom infrastructure for simple needs.

• Adopt Shared Practices

  Instead of every team writing its own IaC, centralize common operations like backups, monitoring, and security. This reduces complexity and increases efficiency.

When a Dedicated Account/Project is justified

Only use a dedicated account or project if there’s a valid reason, such as:

• Security: Reducing the blast radius of potential failures or breaches.

  Compliance: Meeting regulatory requirements for isolation in industries like finance or healthcare.

Reasons like “we always do it this way” or “it feels cool” are not valid.

Invest in Platforms

Rather than giving each team its own account or project, focus on building a shared platform to handle common needs. This doesn’t need to be a complex Internal Developer Platform. Something as simple as a CLI tool can work as a starting point for your internal platform efforts.

Most applications don’t need custom, complex infrastructure. A standardized, well-maintained platform simplifies operations, reduces costs, and allows teams to focus on building great products.