Skip to content

Staging rollback

Staging's two hostnames don't share a shape today, and one of them is already broken independent of anything to do with this migration.

What each hostname uses today, before any cutover

Hostname Current routing policy Current target(s)
staging.arep.co Simple ALIAS, single record Old staging ALB (alb-apse2-stag-migrationv2)
staging.arep.ink Weighted, two entries 200 → 52.64.21.46 (dead EIP), 0 → 52.62.81.96 (gateway1). Both referenced health checks are deleted. This hostname resolves to the dead address right now, live, confirmed by public DNS resolution, unrelated to migration timing

staging.arep.ink being broken today isn't something rollback needs to preserve, there's no working state on this hostname to protect. Worth fixing on its own, independent of the migration.

Rollback for staging.arep.co

Single record today, straightforward UPSERT back to the original target if something goes wrong after cutover:

aws route53 change-resource-record-sets \
  --hosted-zone-id <staging.arep.co zone id, still the production account's arep.co zone> \
  --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":
    {"Name":"staging.arep.co","Type":"A",
     "AliasTarget":{"HostedZoneId":"<ALB hosted zone>",
                    "DNSName":"dualstack.alb-apse2-stag-migrationv2-...elb.amazonaws.com",
                    "EvaluateTargetHealth":true}}}]}'

In practice this DNS record never changes as part of this migration, staging.arep.co already points at migrationv2 today and continues to. This command is here for completeness, not because a DNS-level rollback is actually expected.

Rollback for staging.arep.ink

This one is already a weighted record, treat it like the apex

Don't UPSERT a single plain A record here either, even though the current weighted pair is already non-functional (both health checks are gone). Overwriting it with a plain record still means rebuilding a weighted structure from scratch later if one is ever wanted again. If cutover introduces a new, working weighted pair for this hostname, roll back the same way as the apex, adjust weights, never replace with a single record.

There isn't really a DNS cutover to roll back

Unlike production, staging's rollout doesn't move traffic anywhere, staging.arep.co/.ink already point at migrationv2 today. What this migration actually changes is the ALB's own configuration (certificate coverage, WAF attachment, alarms) and whether its backends are running. "Rollback" here means reverting whichever Terraform PR caused a problem (removing the new cert attachment, the new WAF association, or the new alarms) and, if needed, stopping the backends again, not a DNS-level swap. See the staging rollout for what actually gets applied.