Skip to content

Issue Resolved

Everything this review found that's already fixed and no longer needs anyone's attention. Kept separate from Questions for the team so that page stays just the things that still need an answer.

  • arep.co's bare root path (/) had no equivalent ALB rule. Live nginx has a location = / exact match ahead of its location / catch-all; ALB has no automatic exact-match priority, so this needed its own rule. Added at priority 9 (ahead of every other arep.co rule), redirecting arep.co + exact path / to https://audiencerepublic.com/. Fixed and pushed.
  • automated.arep.co's live nginx config actually has 4 routes the listener rules didn't replicate, not the 5 first estimated: /privacy and /terms (redirects to audiencerepublic.com, preserving nginx's exact behavior — plain HTTP, 302, literal target path, no query string carried over), /share-analytics/ (forwards to the existing tg_prod_automated_testing_am target group, since nginx proxies it to the same host:port as the /api/v1/am rule), and /maintenance (a fixed-response 503 serving the same static maintenance page nginx does — a 6th route, missed in the first pass, found by reading the actual config instead of estimating from it). The 2 static-asset path patterns turned out not to need a rule at all: they resolve to the same backend the existing default catch-all already forwards to (tg_prod_automated_testing, port 4350), mirroring how tg_prod_static already handles the identical case for the main prod stack. Fixed and pushed.
  • PR3's backend tag lookups were all wrong (all 11 of them). Fixed and pushed, verified two independent ways.
  • The "VPC peering gap" turned out not to be a gap. Staging's real traffic already routes through alb-apse2-stag-migrationv2, an existing ALB in the production account, same VPC as its backends, no peering ever needed. The staging backend instances living in the production account isn't a problem to fix, it's exactly where the ALB that actually serves them also lives. See staging's target state for the full picture.
  • All six PRs are updated and pushed reflecting the above: PR2 (certs), PR3 (target groups), PR4 (WAF), PR5 (listener rules), PR6 (CloudWatch) all corrected. PR1 needed no changes.
  • tg_prod_monitor's backend is confirmed dead, not just unconfirmed. The original plan's premise ("several commented-out proxy_pass lines suggest the monitor service may have been deprecated") doesn't match the actual nginx config — /api/v1/mn/ → monitor-backend is live and uncommented in every copy of the config we have. But a live connectivity test from inside the VPC (via the gateway host) gets Connection refused on port 5000 for both campaign-1 and campaign-2 — the hosts are reachable, nothing is listening on that port on either one. The target group stays provisioned in PR3 as-is (not removed), but its PR6 alarms will fire and sit in ALARM state immediately once applied, since there's genuinely nothing there to ever become healthy.
  • Confirmed exactly 4 listener rules upgrade http:// to https:// versus live nginx: /privacy, /terms, /support, and the Zoom-integration support article (/app and /4IoS9 were already https:// in nginx, not upgrades). Both real destination hosts checked live: audiencerepublic.com serves HTTPS cleanly (200, valid TLS). support.audiencerepublic.com doesn't resolve at all — but that's a pre-existing nginx bug, not something this upgrade introduces (see Questions for the team).
  • All 5 staging target groups originally had zero CloudWatch alarms planned. Resolved: alarms now exist for the 3 real target groups on alb-apse2-stag-migrationv2 (tg-apse2-stag-campaign-am/cc, tg-apse2-stag-collector-sg), added alongside the rest of this review's fixes.