Finding Balance in AWS: When does it make sense to break architectural dogmas and stop optimizing?

Cloud services promised flexibility and cost-efficiency. However, the reality of complex AWS infrastructures often forces engineering teams into regular reviews and a search for savings.
At ASSIST, when designing and maintaining cloud architectures, we constantly move on thin ice between adhering to established "best practices" and sound pragmatism.
‍
We recently opened a rather radical discussion within our internal architectural forum:

‍Do we really always need a strict multi-account structure, or is it time to re-evaluate certain dogmas?

Here are the key technical and process insights we have reached, along with our recommendations for more effective FinOps. The myth of isolated environments and the hidden costs of "Idle Resources."
The golden rule of cloud architecture is clear: Separate production and non-production environments into distinct AWS accounts (e.g., using AWS Organizations). This provides ultimate isolation, security, and prevents service limit interference.

Upon a closer look at operating costs, however, the pitfalls of this approach often emerge. You don't pay for the existence of the AWS account itself, but for the so-called baseline resources and services that must run within it, even when the environment is not being actively used.

Where unnecessary costs arise:

• Active monitoring over empty space:
  APM and log management tools constantly perform polling and query resource states (e.g., container registries, databases), even when there is currently no load in the non-production account.
• Duplication of network infrastructure:
  NAT Gateways, Load Balancers, and VPN endpoints in each isolated account generate fixed hourly charges, which in aggregate form a non-negligible part of the invoice.

Alternative view: In certain scenarios, consolidation makes much more sense. Instead of maintaining dozens of accounts with high operational overhead, it can be more efficient to use one or two primary accounts with logical isolation at the level of large, well-secured VPCs (Virtual Private Clouds) utilizing strict IAM policies.

Aggressive CI/CD as a replacement for cumbersome environments.
In our discussion, we also touched upon a bolder idea. If a development team has top-tier, fine-tuned CI/CD pipelines, extensive automated testing, and deploys in minimal increments, the actual need to maintain robust (and expensive) pre-production environments decreases. With the proper use of feature flags and canary deployments, continuous delivery principles can be applied much more directly. The infrastructure then becomes leaner, and we stop paying for servers that spend most of the month simply waiting for manual QA to take place.

FinOps and the Law of Diminishing Returns. The most critical technical-business clash occurs when we pit cloud expenses against engineering time. Architectural purity and maximum optimization are excellent goals, but they are subject to the relentless law of diminishing returns.
‍
Before every major intervention in the infrastructure (such as migrating to new accounts or refactoring services), it is necessary to ask the question:

Will the future savings on the AWS bill outweigh the cost of the senior DevOps engineer's time spent performing this migration?
At a certain point, it is simply more rational to stop fine-tuning the infrastructure for single-digit percentage gains and instead invest the saved time into developing new features that bring real value to users.

‍

Expert Recommendations from ASSIST

If you are currently addressing AWS cost optimization, we recommend the following approach:

1. Map out your fixed overhead:
   Before you start scaling down instances, look at the services you pay for continuously. Consolidate NAT Gateways, review log retention, and limit the polling of monitoring tools in non-production environments.
2. Critically evaluate your multi-account strategy:
   If your non-production accounts remain mostly empty, consider switching to robust isolation at the VPC and IAM level within a smaller number of accounts.
3. Calculate your engineering ROI:
   Never optimize just for the good feeling of a lower invoice. If saving $100 a month costs you three days of a cloud architect's time, the optimization makes no economic sense.
4. Invest in CI/CD:
   The more you trust your automation and pipelines, the fewer robust static environments you need to maintain.

At ASSIST, we believe that the best architecture is not born from silent compliance with manuals, but from healthy and professional opposition from the entire team.

We would love to hear your thoughts – please share your feedback on the article at LinkedIn