Cutover- en rollbackrunbook van AWS naar STACKIT

Zo gebruikt u dit runbook

De volgorde komt uit het uitvoeringsplan van de run, de eigenaren en rollbackregels uit de handmatige stappen die de run schrijft (execution/manual/actions.md). Rijen met de markering (praktijk) zijn algemene best practices die de run niet schrijft.

• Bron van de volgorde

  Afhankelijkheden bepalen de golven; de cutoverstappen hebben "after"-koppelingen, dus gereedheid volgt op de laatste datareconcile, de omschakelingen volgen op gereedheid en het rollbackbesluit volgt op elke controle.

• Niets draait vanzelf

  StackToIT maakt, wijzigt en verwijdert niets. Elke stap wordt uitgevoerd door een persoon, door OpenTofu of door een script dat uw team uitvoert.

• Geen tijdsduren

  Het plan noemt geen onderhoudsvenster en verzint er geen. Neem de duur uit uw proefrun, niet uit een tabel.

De bouwvolgorde: drie golven

Uit migration/technical-sequencing.md van de demorun: negen eenheden in drie golven. Eenheden van één golf kunnen parallel verhuizen; het bestand noemt dit een startpunt voor uw golfplan, geen planning.

## Wave 1 — 4 unit(s)

| Unit | Class | Target |
|---|---|---|
| `aws_route53_zone.main` | DIRECT / MEDIUM | STACKIT DNS |
| `aws_s3_bucket.uploads` | RECONFIGURE / MEDIUM | STACKIT Object Storage |
| `aws_secretsmanager_secret.api_key` | RECONFIGURE / MEDIUM | STACKIT Secrets Manager |
| `aws_vpc.app` | RECONFIGURE / MEDIUM | STACKIT project networking / Network Area (SNA) |

## Wave 2 — 3 unit(s)

| Unit | Class | Target |
|---|---|---|
| `aws_security_group.db` | RECONFIGURE / MEDIUM | STACKIT security group |
| `aws_subnet.app_a` | RECONFIGURE / MEDIUM | STACKIT network |
| `aws_subnet.app_b` | RECONFIGURE / MEDIUM | STACKIT network |

## Wave 3 — 2 unit(s)

| Unit | Class | Target |
|---|---|---|
| `aws_db_instance.orders` | REPLATFORM / MEDIUM | STACKIT PostgreSQL Flex |
| `aws_instance.app` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |

Fase 1 · Vóór het venster

Fase 2 · Schrijfstop en laatste kopie

Fase 3 · De omschakeling

De twee stappen die de rollback dragen

Letterlijke regelbereiken uit execution/manual/actions.md van de demorun: het risico en de rollback van de delegatiewijziging, daarna de kop en de rollback van de stap voor het rollbackbesluit. De lange afhankelijkheids- en statusregels ertussen zijn weggelaten.

- Risk: while resolvers hold the old delegation (one parent NS TTL) some answer from Route 53 and some from STACKIT: a record changed in one zone and not in the other is seen by part of the clients only, so both zones hold the same records until the TTL has passed
- Rollback (manual): set the NS records at the registrar (or the parent zone) back to the Route 53 name servers; resolvers that hold the STACKIT delegation keep it for one parent NS TTL, so the STACKIT zone stays in service for at least that long after the rollback, and the Route 53 zone is retired only after the GO recorded at the rollback decision step

#### The rollback decision step (`MAN/verify/rollback-decision`)

- Phase: Verification
- What: Decide GO or ROLLBACK for the migration once every check of the verification is done: GO lets the source resources be retired, ROLLBACK reverts the cutover and keeps AWS serving
- Why: reverting the cutover is a change of addresses only while the AWS resources exist; after the first decommission step the way back is a rebuild from backups
- Who: Migration Owner
- When: after every check of the verification

- Risk: the decision point follows every check of the verification (each is also an action-complete precondition); the retirement steps depend on it, and through it on the checks
- Rollback (manual): on ROLLBACK, revert each cutover step as its rollback says (the traffic switch of aws_instance.app, the delegation change of the hosted zone of aws_route53_zone.main, the switch of the applications that use aws_s3_bucket.uploads, the switch of the applications that use aws_db_instance.orders) and start no decommission step; on GO nothing is reverted

Fase 4 en 5 · Controleren, beslissen, uitfaseren

Het DNS-concept achter de delegatiestap

De STACKIT DNS-zone en recordset die de demorun schreef (terraform/dns.tf, zonder commentaar). Het record houdt de TTL van 300 s van de bron aan.

resource "stackit_dns_zone" "main" {
  project_id = var.project_id
  name       = "orders.example.com"
  dns_name   = "orders.example.com"
}

resource "stackit_dns_record_set" "app" {
  project_id = var.project_id
  zone_id    = stackit_dns_zone.main.zone_id
  name       = "www.orders.example.com"
  type       = "A"
  records    = ["203.0.113.10"]
  ttl        = 300
}

Regels voor de rollback

Waar de weg terug eindigt en wat u onderweg opgeeft.

• Houd de bron intact tot de GO

  Het plan maakt de bron na de schrijfstop nooit alleen-lezen en wijzigt die niet, dus een rollback is slechts configuratie die wordt teruggezet. Verwijder niets in AWS voordat het rollbackbesluit GO is.

• Schrijfacties na de omschakeling

  Wat de applicaties na de omschakeling naar STACKIT schreven, staat niet in AWS. Kopieer het terug met een apart geoefende methode of accepteer het verlies, en beslis vóór het venster.

• DNS vraagt geduld

  Resolvers houden de oude delegatie na een wijziging één NS-TTL van de bovenliggende zone vast, dus beide zones moeten zo lang dezelfde records bevatten. De TTL van de delegatie bij de registrar staat niet in de bron.

• DNSSEC (praktijk)

  AWS documenteert voor de omgekeerde richting dat een domein niet door twee providers tegelijk kan worden ondertekend en dat het DS-record eerst moet worden verwijderd. Is uw zone ondertekend, plan het DS-record dan in beide richtingen.

• Het punt zonder terugkeer

  Na de eerste uitfaseringsstap is de weg terug een herbouw vanuit back-ups. Daarom staat de beslisstap apart en draagt die een datum en het resultaat van elke controle.

Vragen van teams

Bronnen

• Making Route 53 the DNS service for a domain that is in use (AWS-documentatie, de omgekeerde richting)
• STACKIT PostgreSQL Flex (STACKIT-documentatie)
• STACKIT Object Storage (STACKIT-documentatie)
• Backup and clone of PostgreSQL Flex (STACKIT-documentatie)
• STACKIT DNS: manage DNS zones (zone delegation)