Skip to content
All work

Rayna Tours · 2026

Moving production out of an impaired cloud region

When the AWS region running a travel booking platform was disrupted, production ran on a recovery stack within about a day, and the whole platform moved to a new region within about a month.

to run production on a recovery stack
~1 day
to rebuild the shared services as code
~36 h
to leave the old region completely
~1 month
Diagram of the region moveBefore: production, with about twenty container services and shared services, ran in an impaired AWS region. After: within about a day, production ran on a recovery stack in a new region, with networking and core infrastructure stood up and the production database restored from a snapshot. The shared services were rebuilt as code in six Terraform repositories, each with its own pipeline and documentation, in about 36 hours. The services then moved using the shared modules, and the final databases were restored from cross-region snapshot copies. The old region was decommissioned in a written destroy order within about a month. The same Terraform code, run with new parameters, built the new region.Impaired regionProduction~20 container servicesShared services~1 monthDecommissionedWritten destroy orderNothing left runningNew region1Recovery stackNetworking and core infrastructureProduction database from snapshot~1 day2Shared services as code6 Terraform repositoriesOwn pipeline and documentation~36 h3Services movedUsing the shared modulesDatabases from snapshot copiesTerraform code·Same code, new parameters
The platform was already defined as code, so rebuilding it in a new region meant running the same code with new parameters.

The situation

Rayna Tours runs its booking platform on AWS: about twenty services in containers, with databases, caches, messaging and storage shared between them. In March 2026 the AWS region hosting the platform was disrupted, and access to it became unreliable.

What we did

  • On the first day, stood up networking and core infrastructure in a new region and restored the production database from a snapshot, so production could run on a recovery stack.
  • Rebuilt the shared-services layer (databases, private endpoints, caches, Kafka, DynamoDB tables, and storage with a CDN) as six new Terraform repositories, each with its own pipeline and documentation, in about 36 hours.
  • Moved the team’s services onto the new foundation using the platform’s shared modules, and restored the final production databases from cross-region snapshot copies.
  • Decommissioned the old region with a written, step-by-step destroy order, so nothing was left running or orphaned.

Why it worked

The platform was already defined as code, with one contract between stacks and one module per type of service. Rebuilding in a new region meant running the same code with new parameters, not reconstructing a hand-made environment.

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.