Voir en français
Menu

Governance

Bringing several hundred AWS accounts back under governance

The context

An international software vendor had accumulated several hundred AWS accounts spread across dozens of delivery teams. Every team had done its best, which produced as many conventions as there were teams: firewall rules that disagreed from one account to the next, backups present here and absent there, security boundaries impossible to demonstrate to an auditor, and a bill nobody could fully explain.

The goal was not to regain control by forbidding everything. Governance that blocks delivery teams gets worked around within the month, and the result is worse than the starting point, because the workarounds are undocumented.

What we did

We took the estate over and centralised what had to be uniform, leaving the delivery teams what is genuinely theirs.

Guardrails written once in the organisation and enforced in every accountSeveral hundred accounts sit under a single AWS Organizations root. Three sets of guardrails are written centrally: service control policies, firewall and WAF rules managed through Firewall Manager, and AWS Backup retention plans. They are enforced in every member account without being renegotiated team by team. Each account keeps its own delivery team, and the findings produced across the whole estate converge into a single Security Hub view where every finding is attached to an owning team.Guardrails defined once, applied everywhereAWS Organizations — several hundred accounts under one rootService control policieshard guardrailsFirewall ManagerWAF and firewall rulesAWS Backupretention, self-serviceEnforced in every account — not renegotiated team by teamTeam account Adelivery teamTeam account Bdelivery teamTeam account Cdelivery team…several hundredSecurity Hub — every finding attached to an owning team
The guardrails are written in one place and land in every account, which is what stops governance from becoming a negotiation. The bottom row is the part that decides whether it works: thousands of findings are worth nothing until each one has an owner.
  • Centralised security policy: AWS Organizations, service control policies, and centrally managed firewall rules through Firewall Manager, applied uniformly instead of negotiated account by account.
  • Consistent networking and edge protection: Transit Gateway to replace a VPC peering mesh that had become unreadable, and centralised WAF policies in front of internet-facing applications, managed the same way through Firewall Manager instead of account by account.
  • Backup as a service built on AWS Backup, which dozens of delivery teams consume by declaring their retention requirement, without each having to become a specialist.
  • One security view through Security Hub, aggregating findings from every account instead of leaving them to sit in each one. At this size the problem is not producing alerts — there are thousands — but making them actionable: attaching each finding to an owning team, and tracking what actually gets fixed.
  • Audit compliance: traceability, environment isolation, retention policies, and automatic production of the evidence auditors expect.
  • Cost reduction and remediation of existing infrastructure, starting with the heaviest line items rather than the easiest ones.
  • Performance work: sizing containerised workloads on ECS to absorb traffic spikes without over-provisioning all year, and a rework of the managed Aurora database configuration.
Inter-account connectivity through a single Transit Gateway hubEach delivery team owns its own VPC in its own account, and there are several hundred of them. Instead of peering them with each other, every VPC attaches to a single Transit Gateway. From that hub, traffic reaches shared services and central egress, on-premise networks over VPN or Direct Connect, and internet-facing applications sitting behind centrally managed WAF policies. Adding an account means one attachment rather than a new peering for every existing VPC.Inter-account connectivity through one hubAccount VPC Adelivery teamAccount VPC Bdelivery teamAccount VPC Cdelivery team…several hundredTransit Gateway — one hub instead of a peering meshShared servicesand central egressOn-premise networksVPN or Direct ConnectInternet-facing appsbehind centralised WAF
A peering mesh grows as the square of the account count, which is why nobody could read the old one. A hub grows linearly: one attachment per account, and the routing decisions live in one place instead of being spread across hundreds of route tables.

The outcome

Security is steered from one place instead of being renegotiated team by team, backups exist everywhere and are tested, and audits rest on evidence produced automatically rather than reconstructed under pressure.

The bill went down. The more durable change is elsewhere: it can be explained again, which is what makes trade-offs possible.

All case studies

Talk to us directly

Write to us directly. No salesperson, no qualification call. One of us two replies, within 24 hours.

contact@onescale.io

We reply within 24 hours, and it is one of us who replies.

Based in Lyon, working with clients in France, across Europe and internationally.