Skip to content
All work

Rayna Tours and TechnoHeaven · 2025–2026

From one legacy account to a governed multi-account AWS platform

A multi-account AWS foundation for a travel group's twenty or so services, with guardrails, keyless pipelines and a temporary environment for every pull request, all defined in Terraform.

AWS accounts in one organisation
8
Terraform repositories
40+
services on the platform
~20
Diagram of the multi-account AWS platformBefore: one legacy AWS account ran .NET, Node.js and Next.js services, payments and Kafka consumers side by side, access was hard to review, and every environment was built differently. After: an AWS Organization of 8 accounts, defined in code. Service control policies restrict regions and block long-lived IAM users. Central accounts hold identity (IAM Identity Center, with access through groups), networking (a hub-and-spoke network with Transit Gateways) and shared services. Production and non-production run in their own accounts, with container services and separate subnets for workloads and data. GitHub Actions reaches AWS with OIDC and no stored keys, every change is planned in a pull request, production waits for approval, and each pull request can get a temporary environment.One legacy account.NET · Node.js · Next.jsPayments and Kafka consumersAccess hard to reviewEnvironments built differentlyKeyless deliveryGitHub Actions with OIDCPlan in every pull requestProduction waits for approvalTemporary PR environmentsAWS Organization·8 accountsService control policiesRestrict regions · Block long-lived IAM usersIdentityIAM Identity CenterAccess through groupsNetworkingHub-and-spokeTransit GatewaysShared servicesProductionContainer servicesWorkload and data subnetsNon-productionContainer servicesWorkload and data subnets
One legacy account became an AWS Organization defined in code, with guardrails, a hub-and-spoke network and keyless delivery.

The situation

The platform started in a single legacy AWS account, with .NET, Node.js and Next.js services, payments and Kafka consumers growing side by side. Access was hard to review, and every environment was built a little differently.

What we built

  • An AWS Organization defined in code. Separate accounts for each environment plus central identity, networking and shared services, with service control policies that restrict regions and block long-lived IAM users.
  • Access through IAM Identity Center. Access is granted through groups only, with a clear escalation ladder from developer to administrator.
  • A hub-and-spoke network. Separate Transit Gateways for production and non-production, and tiered subnets for workloads and data.
  • A golden module for services. One Terraform module creates a container service with its IAM, security group, autoscaling and alarms, and denies default internet egress. Fourteen service repositories use it.
  • Keyless delivery. GitHub Actions authenticates to AWS with OIDC, every change is planned in a pull request, and production applies wait for approval. Each pull request can get its own temporary environment.
  • Modernisation. Legacy .NET/IIS applications moved into Windows containers on Amazon ECS with CI/CD.

The result

Onboarding a new service became a configuration change instead of a project, the team ships through one reviewed path, and the same code later made it possible to move the whole platform to a new region quickly.

Services used

Not sure where to start?

Book a free 30-minute call. We learn what you need and tell you honestly whether and how we can help. There is no obligation.