Skip to content

Staging — after the ALB migration

Compare against today's state. Staging's target state turned out to need almost no new infrastructure at all, once we found what already existed.

Traffic flow (target state)

%%{init: {'flowchart': {'nodeSpacing': 70, 'rankSpacing': 110, 'padding': 20, 'curve': 'basis'}}}%%
flowchart TB
    Internet((Public Internet))

    subgraph PRODACCT["Production account — unchanged, this is where the real work already lives"]
        direction TB
        Z1["staging.arep.co / staging.arep.ink<br/>same DNS records as today,<br/>no delegation, no new zones"]
        MIGV2["alb-apse2-stag-migrationv2<br/>same VPC as its backends,<br/>no peering needed"]
        TGS["tg-apse2-stag-campaign-am/cc,<br/>tg-apse2-stag-collector-sg<br/>real, pre-existing target groups"]
        SBACK["staging/campaign, staging/campaign-2,<br/>staging/audience-manager,<br/>staging/deferred-collector"]
        Z1 --> MIGV2 --> TGS --> SBACK
        WAF["WAF Web ACL<br/>same Googlebot rule as prod,<br/>now actually attached here"]
        ALARMS["6 new CloudWatch alarms<br/>on the 3 real target groups"]
        WAF -.-> MIGV2
        ALARMS -.-> TGS
        PORTAL["&lt;promoter&gt;.staging-portal.arep.co<br/>NOT in migration scope"]
    end

    subgraph STAGACCT["Staging account — deliberately untouched"]
        OTHERALB["alb-apse2-stag-server<br/>separate, genuinely staging-owned ALB,<br/>its own empty target groups,<br/>out of scope for this migration"]
    end

    Internet --> Z1
    Internet --> PORTAL

What changes

Today After migration
DNS authority for staging.arep.co/.ink Production account's arep.co/arep.ink zones Unchanged. No delegation, no new zones
Load balancer alb-apse2-stag-migrationv2, in the production account Same ALB. Not moved, not replaced
Target groups 3 real ones already exist (tg-apse2-stag-campaign-am/cc, -collector-sg), registered against the real backends Same 3 target groups. Referenced via read-only Terraform data sources, not recreated
Certificate *.arep.co wildcard already covers staging.arep.co; staging.arep.ink had no coverage at all star_arep_ink (built for prod's own arep.ink) additionally attached to migrationv2's listener
WAF Web ACL existed but was never attached to this ALB Attached, same Googlebot rule, now actually reaches staging.arep.co
Alarms None on any staging target group 6 new alarms (unhealthy + no-healthy pairs) across the 3 real target groups

What this deliberately does not do

  • No VPC peering. The network-connectivity gap that looked like the biggest blocker in this migration turned out to be solvable by not needing new infrastructure at all, migrationv2 was always in the same VPC as its backends.
  • No new hosted zones, no cross-account DNS delegation, no manual one-time NS record for anyone at AR to add.
  • alb-apse2-stag-server, a separate, genuinely staging-account-owned ALB with its own more-complete-but-empty target groups (matching the original plan's naming exactly), is left entirely untouched. Whether that one should become the real target instead of migrationv2 someday is a real, open architectural question, not something this migration resolved, see Questions for the team.
  • Nothing here is imported into Terraform state. The ALB and its 3 target groups are referenced read-only. Taking ownership of them is a separate, later decision.

Known risks, still open

  • The google-site-verification TXT record on staging.arep.co was never touched by any of this, still worth confirming it's the one actually in use.
  • staging.arep.ink is currently resolving to a dead, unassociated EIP through a deleted health check, live, right now, unrelated to this migration. See rollback.
  • Privacy Portal (staging-portal.arep.co) is out of scope here and depends on whatever happens to the production gateways, see the production migration page.