AWS Infrastructure Consolidation

The natural approach — point each domain's A-record (or Cloudflare origin) to the new instance — would have required updating records across Cloudflare (shinobidata, simplideliver, draw, darkhorsestocks subdomains) and a direct A-record provider for the unproxied ones, fanned out over multiple TTLs, with a real outage window per domain. Solved by routing every domain through a single Elastic IP (13.127.181.125) and Nginx hostname-based vhosts on the host: the migration becomes one `aws ec2 disassociate-address` + `associate-address` pair against the new instance ID, taking ~2–5 seconds total across all domains simultaneously, with zero DNS propagation involved. The same EIP that had pointed at the old t3.xlarge now points at the r6a.large; Cloudflare, registrars, and end-users see no change.

First-party Next.js apps benefit from ECS's task lifecycle (CodeBuild → ECR → `ecs update-service --force-new-deployment` for atomic image swap with health-checked rollout), but the 8-container DarkHorse stack is owned by a sister team that ships via GitHub Actions → Docker Hub and needs `docker compose` semantics for selective per-service restart. Running both under ECS would have required wrapping every DarkHorse image in a task definition and rebuilding their CI. Running both under Docker Compose would have meant losing CodeBuild's S3 layer cache and ECS's restart/health/limits guarantees for the first-party apps. The shipped design keeps ECS tasks and Docker Compose containers on the same EC2 host inside the ECS-optimized AMI: ECS owns 5 task definitions including the Nginx proxy task; Docker Compose owns `/ecs-data/{darkhorse,excalidash}/docker-compose.yml` with `restart: unless-stopped`; both write logs to the same CloudWatch account (ECS native for tasks, SSM `docker logs` for compose); both restart automatically on crash; CPU and RAM headroom on the r6a.large (16 GB / 2 vCPU AMD) covers steady-state at ~1 GB RAM and 0.4% CPU across all containers combined.

SQL Server Express on `mutualfunddb-2024-12-v1` (db.t3.medium) was the single most expensive line item across all three accounts ($82/mo) and pinned Account 3 open. A cross-account RDS snapshot copy + restore on Account 1 was the obvious answer but would have required IAM cross-account share, KMS key cross-account access, and a Cloudflare-routed connection-string flip for both `shinobidata.com` and `dashboard.darkhorsestocks.in`. The shipped sequencing — down-size in place first (db.t3.medium → db.t3.small, $73 → $22, safe because SQL Server Express is capped at 1 GB RAM regardless of host class, validated by Account 3's actual 6% avg / 17% peak CPU over a 7-day CloudWatch window) — captured the $51/mo Tier-3 saving immediately, with the cross-account move deferred behind a `Deferred — works cross-account for now` flag in the post-migration reference. The lesson surfaced: in a multi-tier optimization plan, the move that unblocks account closure (cross-account migration) and the move that captures the bulk of the saving (right-sizing) are often *not* the same move, and decoupling them preserved most of the value at a fraction of the risk.