Skip to content

AWS Production Rebuild and Coexistence Plan

Purpose

This document captures the production-side constraint that changes the migration approach:

  • production already exists
  • the goal is to rebuild the application runtime from EC2 to ECS
  • the existing production estate should be treated as the current source of truth for traffic and data

This is not a greenfield production build.

Current Production Reality

Existing Production Components

Production already has:

  • an existing application deployment on EC2
  • a Patroni-based PostgreSQL cluster with TimescaleDB and PostGIS
  • AWS-managed Redis
  • an existing production VPC and network layout
  • at least one existing ECS workload in the production VPC

Existing ECS Workload

There is currently an Anisette ECS workload in the production VPC.

For now, keep that as part of the production network context and avoid moving it unless the migration work requires it later.

Migration Implication

The production migration should be treated as a rebuild of the application runtime, not a rebuild of the whole platform.

That means:

  • keep the existing production database in place
  • keep the existing production Redis in place
  • deploy the new ECS application stack alongside the existing EC2 runtime during transition
  • cut traffic over only after staging and production validation are complete

Database Constraint

Cross-VPC Database Access

The main cross-VPC concern is the database dependency.

If the new ECS services are deployed into a different VPC from the existing database, the network path must be designed explicitly.

Do not assume the ECS services can reach the database without:

  • route design
  • security group rules
  • DNS resolution
  • a clear decision on whether the database remains private to one VPC or is exposed through an internal access pattern

Design Principle

Keep the database connectivity model explicit and narrow.

If peering is used, keep it limited to the ECS VPC and the database VPC for this migration path only.

See 12 AWS Database Connectivity and VPC Peering Plan for the preferred path.

Coexistence Strategy

Run the existing EC2 deployment and the new ECS deployment in parallel during the migration window.

Use that overlap to:

  • validate ECS behavior
  • confirm database connectivity
  • verify service discovery
  • rehearse rollback
  • compare logs and metrics

Cutover Rule

Do not remove the EC2 path until:

  • the ECS deployment has been validated in staging
  • the production ECS deployment is stable
  • the database access pattern is proven
  • rollback has been rehearsed

Anisette Note

If the Anisette ECS workload must remain in the production VPC for now, treat it as an existing neighboring workload.

That means:

  • do not couple this migration to Anisette unless required
  • do not assume its networking or state is part of this project
  • revisit it later if the cleanest long-term layout is to move it elsewhere