From a Single Account to a Governed AWS Platform

A financial institution ran its entire AWS environment inside a single account.

Applications from different areas, production and test environments, critical workloads and experiments — all shared the same space, the same service limits and the same network. What had begun as simplicity had become the operation’s largest source of risk.

The project restructured that environment along AWS Well-Architected Framework patterns, breaking the single account into a governed multi-account structure with network segregation, provisioning as code and granular cost visibility.

A single account concentrates risks that only surface once it is too late:

• A misconfiguration in a test environment could reach production resources.
• There was no network isolation between applications belonging to different business areas.
• AWS service limits were shared, so one application’s consumption could block another.
• Permissions grew by accumulation, with no boundary to contain them.
• The bill arrived aggregated, with no way to attribute cost to a project, area, business unit or team.
• Resources provisioned by hand over the years had neither an owner nor a record.

That last point was the most expensive. There was contracted capacity nobody claimed, and without an inventory it could be neither safely shut down nor justifiably kept.

The restructuring followed four tracks, anchored in the Well-Architected Framework pillars:

• Account structure: design the separation by environment, criticality and business area, with permission boundaries between them.
• Network segregation: isolate workloads so that communication between them became explicit and authorized.
• Infrastructure as code: make provisioning reproducible and auditable — the precondition for operating many accounts without multiplying effort.
• Cost visibility: classify resources so the bill could be read through the lens of the business.

The single account gave way to a multi-account organization separated by environment and by business area. Each account gained its own service limits, its own permissions and its own failure boundary.

The network was segregated along the same logic: workloads from different areas stopped reaching one another by default, and the communication that was genuinely needed became something declared rather than something inherited.

On top of that structure, Terraform became the only path to provisioning. A new account stopped being manual work and became the application of a pattern already described in code — which is what makes a multi-account structure sustainable rather than costly.

Resources were classified by project, area, business unit and team, turning an aggregated bill into a financial view the business could read, and opening the way for a FinOps practice.

The work began with an inventory: mapping what lived inside the single account, which application it belonged to, and who answered for it.

That survey exposed the mass of resources with no declared owner, which became a review and reallocation track of its own.

The account structure was designed next and populated incrementally, starting with lower-criticality workloads so the pattern could be validated before it reached production.

Terraform came in from the start rather than at the end: every account created was described in code from birth, so the new structure would not reproduce the manual-provisioning problem that prompted the project.

Cost classification was applied alongside the migration, so each resource arrived in the new structure already attributed to a project, area, business unit and team.

• AWS Well-Architected Framework
• AWS multi-account structure
• Terraform
• Network segregation by workload and area
• Cost Allocation Tags
• Classification by project, area, business unit and team

The underlying change was replacing implicit trust with an explicit boundary.

Before, isolation between workloads depended on nobody making a mistake. Afterwards, it became a property of the structure: one environment cannot reach another because the account and the network do not allow it, not because someone was careful.

Infrastructure as code changed who could act. Provisioning stopped being craftwork and became a reviewable change, which made the multi-account structure operable by a team of the size that already existed.

And cost visibility changed the conversation between Technology and Finance. With the bill readable by project, area, business unit and team, each area could see its own consumption — the foundation on which the FinOps practice was then built.

30%Savings on unmapped resources

• A single account replaced by a multi-account structure along AWS Well-Architected Framework patterns, with boundaries by environment, criticality and business area.

• Network segregation established, making explicit and authorized the communication that previously existed by omission.

• 100% of provisioning as code in Terraform, the precondition for operating many accounts without multiplying effort.

• 30% savings from reviewing and reallocating resources that had neither an owner nor a record.

• Cost visible by project, area, business unit and team, replacing the aggregated bill with a financial reading of the business.

• A foundation established for FinOps, with cost classification already applied at migration time.