Context & Pain Points
The insurance ledger ran on on-premises virtualization that had stopped scaling with the business. Capacity arrived on a procurement cycle rather than on demand, several tiers had a single host between them and an outage, and the network had grown into dozens of VPCs and data-centre segments wired together in pairs. Every new connection meant another peering to plan, another route table to hand-edit, and another place a loop could hide. Team boundaries were equally soft: separate business units shared accounts and IAM policies written case by case, so nothing in the platform stopped one team's role from reaching another team's resources. Transaction processing could not stop while any of this was fixed.
What We Had To Solve
- Migrating critical production transaction state machines without halting day-to-day business operations, which ruled out any cutover that needed the ledger to be quiet.
- Interconnecting dozens of legacy VPCs with central security inspection zones cleanly, without the route-table sprawl and loop risk that a full peering mesh brings.
- Establishing strict, identity-based resource policies and role boundaries for separate organizational teams, in an estate where account sharing had made those boundaries advisory.
- Keeping a recovery path for the ledger in a second region, so a regional failure is a documented procedure rather than a rebuild.
How We Built It
- Used AWS Transit Gateway as a centralized network hub, routing traffic between virtual private clouds and on-premises data centers, so each VPC attaches once and inspection sits in one place instead of at every peering edge.
- Cut over with Amazon Route 53, moving traffic per service rather than per data centre, which kept the migration reversible at every step and removed the need for a business-hours outage.
- Orchestrated database replication pipelines using Amazon RDS with automated backup snapshots and read replicas, so reporting load came off the transactional primary as part of the move rather than after it.
- Engineered comprehensive AWS Organizations structures with Service Control Policies to enforce hard boundaries, so a team's maximum permission is set above the account and cannot be widened from inside it.
- Defined the landing zone in AWS CloudFormation, so each migrated account is built from the same reviewed template instead of from console steps repeated by hand.
Outcomes That Mattered
Zero Business Downtime
Performed cutover migrations of legacy transaction systems with absolutely zero service interruptions, moving traffic service by service behind Route 53.
Centralized Transit Routing
Scaled network interconnections to over 30 isolated VPCs with zero routing loops, with every attachment resolving through one Transit Gateway route domain.
40% Operational Savings
Pruned legacy datacenter hosting contracts in favor of right-sized, scalable AWS instances, replacing procurement lead time with capacity that follows demand.
Enforced Team Boundaries
Service Control Policies set each team's ceiling at the organisation level, so an over-permissive IAM policy inside an account cannot grant more than the boundary allows.
Outcome
Core ledger services now run in a multi-account AWS Organizations structure with cross-region disaster recovery, and operational overhead dropped 40% once the legacy hosting contracts were retired. AWS Transit Gateway replaced the peering mesh as a central hub, so VPCs and the remaining on-premises segments attach once and route through a single inspection point. Amazon Route 53 carries the DNS cutover, which is what made a staged migration possible without a maintenance window. Databases moved onto Amazon RDS with automated snapshots and read replicas, and Service Control Policies now enforce team boundaries at the organisation level instead of relying on per-account IAM discipline. The whole landing zone is defined in CloudFormation.