Az eddigi kilenc modul tudásának összefűzése egyetlen, végrehajtható tervvé: milyen sorrendben mozdítsd a Nuxt + Aurora + SQS + S3 + CloudFront + Beanstalk stacket, hol vannak a visszafordulási pontok, mi maradhat örökre AWS-en — és mikor mondj nemet az egésznek.
A csábítás az, hogy a legizgalmasabb résszel kezdj (Workers! D1! Durable Objects!). A helyes sorrend viszont a kockázat és a visszafordíthatóság szerint alakul. Három szabály, ami az egész tervet vezérli:
A domain nameszerverei a Cloudflare-hez kerülnek, a forgalom rajtuk keresztül megy a változatlan AWS-origin felé. Ekkor még egyetlen sor kódot sem írtál át, de már megkapod: a globális CDN-t, a WAF-ot, a rate limitinget, a DDoS-védelmet és a valós forgalmi analitikát (9. modul).
Miért itt kezdd: ez a lépés önmagában értéket ad, a CloudFront kivezethető alóla, és a visszaút egy DNS-váltás. Ráadásul innentől méred a valós forgalmadat — a következő fázisok tervezéséhez ez lesz az alapadat.
Kimenet: Cloudflare a forgalom előtt, CloudFront kivezetve, mérőszámaid vannak.
A tárolás átköltöztetése (6. modul) a leggyorsabban megtérülő lépés, mert az egress-díj eltűnik, a kódváltozás pedig jellemzően endpoint- és credential-csere. Nagy adatmennyiségnél a Sippy inkrementálisan szivárogtatja át az objektumokat, leállás nélkül.
Sorrend a fázison belül: ① új feltöltések már R2-be (dupla írás egy ideig, ha kell) → ② olvasás R2-ből, fallbackkel S3-ra → ③ Sippy/másolás a maradékra → ④ S3 read-only, majd kivezetés.
Kimenet: a fájlforgalom Cloudflare-en, az első látványos számlacsökkenés.
Ez a lényegi lépés (3. + 4. modul): a Nitro cloudflare_module preset, Static Assets, és a DB-elérés Hyperdrive-on át a megmaradó Aurorára. Az adat nem mozdul — pont ettől vállalható a kockázat.
A biztonságos élesítés: előbb staging (8. modul), majd a valódi forgalom fokozatosan. Két bevált technika: (a) Cloudflare-oldali route-alapú bevezetés — először csak a statikus és néhány olvasó útvonal megy a Workerre, a többi az AWS-originre; (b) a teljes app átállítása után gradual deployment a verziók között. Rollback: a route visszairányítása az AWS-originre — percek.
Amire készülj: npm-függőségek szűrése (natív binárisok, 2. modul), a lokális memória-cache-ek kiváltása KV-vel, a háttérmunkák ctx.waitUntil()-be vagy sorba tétele. Az Aurora hálózati elérése Hyperdrive-nak: publikus + IP ACL vagy Cloudflare Tunnel.
Kimenet: a Beanstalk mögötti web-réteg kiürül; a Nuxt SSR és az API az edge-en fut.
A háttérmunkák átemelése (7. modul). A trükk az átmeneti kettősség: az új üzeneteket már a Queues-ba küldöd, miközben a régi SQS-consumer még fut, amíg ki nem ürül a sor. Így nincs „állítsuk le és számoljunk" pillanat.
Sorrend: ① a producer-oldal átírása Queues-ra (az SQS-consumer még él) → ② Queues-consumer élesítése, DLQ-val és riasztással → ③ az SQS kiürülése után a régi consumer leállítása → ④ a cron-jobok átemelése Cron Triggersre, a több lépéses folyamatok Workflows-ba.
Kimenet: az utolsó „mindig futó" AWS-komponensek is elhagyhatók.
A pipeline átkötése (8. modul): Workers Builds vagy Actions + wrangler, PR-preview-k, kanári és rollback; az observability beállítása (9. modul): Workers Logs, traces, Analytics Engine a tenant-meteringhez, error tracker. Végül a Beanstalk-környezetek, ALB-k, NAT gateway-ek leállítása — ez a fázis hozza a második nagy számlacsökkenést.
Kimenet: egyetlen deploy-modell, egyetlen observability-stack; az AWS-en már csak az adatbázis (és ami tudatosan ott maradt).
Itt kell a legőszintébbnek lenni: ezt a fázist lehet, hogy soha nem csinálod meg — és ez rendben van. A Hyperdrive miatt az Aurora + Workers kombó tartósan üzemeltethető, jó teljesítménnyel. A váltás (5. és 5b. modul) csak akkor indokolt, ha van rá termékoldali húzóerő: adatszeparációt kérő ügyfelek, EU-jurisdiction igény, tenantonkénti restore, régió-közeli adat, vagy ha az Aurora-számla a maradék költséged érdemi része.
Ha mégis: ne az egész adatbázist mozgasd. Új, jól izolált feature-ök D1-en indulnak, vagy per-tenant D1-ek jönnek létre az új tenantoknak, és a régiek fokozatosan, tenantonként költöznek — a registry + Workflow-runner mintával (5b. modul).
A migráció nem vallás. Vannak dolgok, amiket értelmes ott hagyni, és a modul egyik célja, hogy ezt előre kimondja — így nem érzed kudarcnak, ha marad AWS-számlád:
| Komponens | Maradhat? | Miért |
|---|---|---|
| Aurora/RDS | igen, akár tartósan | Hyperdrive-val jól működik; a teljes Postgres-tudás (extension-ök, interaktív tranzakciók) megmarad |
| Adattárház, ETL, BI | igen | a Cloudflare nem ezt a piacot célozza; hagyd a Redshift/Athena/Glue vonalat, ahol van |
| Nehéz batch- és ML-munkák | igen | órákig futó, nagy memóriájú vagy GPU-s feladatok nem a Workers profilja |
| Legacy szolgáltatás natív függőségekkel | igen (vagy Containers) | ha ImageMagick/ffmpeg/natív bináris kell, az nem V8-isolate-ba való |
| Belső, VPN mögötti eszközök | igen | Cloudflare Tunnellel elérhetők, nem kell átépíteni |
A cél nem a „zéró AWS", hanem hogy a felhasználói forgalmat kiszolgáló út legyen az edge-en, alacsony latenciával és kiszámítható költséggel. A háttérrendszerek maradhatnak ott, ahol jól vannak.
A Containers a platform válasza a „de nekem tényleg egy igazi Linux-processz kell" esetre: valódi konténer (a te Dockerfile-odból vagy image-edből), amit egy Durable Object vezérel — ez a DO a routing, az életciklus és az állapot gazdája, a konténer pedig a munkát végzi egy Linux VM-ben.
wrangler.jsonc — a minta szerkezete{
"containers": [{
"class_name": "PdfRenderer",
"image": "./Dockerfile",
"instance_type": "basic", // lite | basic | standard-1…4
"max_instances": 10
}],
"durable_objects": { "bindings": [{ "name": "PDF", "class_name": "PdfRenderer" }] },
"migrations": [{ "tag": "v1", "new_sqlite_classes": ["PdfRenderer"] }]
}Jó felhasználás: PDF-generálás fejléc nélküli böngészővel, kép- és videó-feldolgozás (ffmpeg, ImageMagick), régi Node/Python szolgáltatás átmeneti futtatása a migráció alatt, felhasználói kód futtatása sandboxban, tudományos/AI könyvtárak, amiknek natív bináris kell.
sleepAfter), a diszkjük efemer (az instance életciklusához kötött), és a hidegindításuk nem a Workers ezredmásodperces világa. Ezért nem való ide: adatbázis, error tracker vagy bármilyen állapotőrző platform (lásd 9.7), állandóan futó napi ügyeletes szolgáltatás, vagy „a Beanstalk-appom egy az egyben ide másolva" — utóbbi működik ugyan, de akkor a platform előnyeiből (edge, nulla üzemeltetés, per-kérés árazás) semmit nem kapsz meg. A Containers kiegészítő a Workers mellé, nem alternatíva helyette.| Anti-pattern | Miért baj | Helyette |
|---|---|---|
| „Big bang" hétvégi átállás | nincs visszaút, minden hiba egyszerre jön | fázisterv, fázisonként éles rendszerrel |
| Először az adatbázist mozgatni | a legkockázatosabb lépés a legkevesebb tapasztalattal | Hyperdrive: az adat marad, a kód mozog (4. modul) |
| Az Express-app 1:1 lefordítása | globális cache-ek, memória-állapot, hosszú tranzakciók — mind törik | a Worker-modell szerinti újragondolás (2., 7. modul) |
| Mindent D1-be, mert „natív" | SQLite-dialektus, 10 GB, nincs interaktív tranzakció | döntési térkép szerint (5. modul); a fő DB maradhat Postgres |
| KV-t használni számlálóra/állapotra | eventually consistent, ~1 írás/s/kulcs | Durable Objects (6., 7. modul) |
| Breaking migráció egy release-ben | a kanári és a rollback is eltörik tőle | expand–contract, gated prod-migráció (8. modul) |
| Observability-t „majd később" | a kanárit sem tudod értékelni, vakon deployolsz | a 4. fázis része, nem utólagos extra (9. modul) |
Mielőtt az első fázisba kezdesz, ezt a hetet érdemes kipipálni:
package.json-on — melyik csomag használ natív binárist, fájlrendszert, portnyitást? Ez adja meg, mennyi valódi munka lesz a 2. fázis.Mert azonnali értéket ad (CDN, WAF, rate limiting, DDoS-védelem, analitika), a visszaút egyetlen DNS-változtatás, a CloudFront kivezethető alóla — és innentől valós forgalmi adatod van a következő fázisok tervezéséhez.
Hogy az adat nem mozdul: a Hyperdrive-val a megmaradó Aurorához kapcsolódsz, tehát csak a kód költözik — a kód mozgatása pedig route-visszairányítással vagy rollbackkel perceken belül visszafordítható.
Átmeneti kettősséggel: előbb a producer ír már a Queues-ba, miközben a régi SQS-consumer még fut és kiüríti a maradék sort; a Queues-consumer élesítése DLQ-val és riasztással; a régi consumer csak az SQS kiürülése után áll le.
Ha állapotőrző (adatbázis, error tracker) vagy folyamatosan rendelkezésre kell állnia: a konténer elalszik tétlenségnél, a diszkje efemer, a hidegindítás lassabb. Az alapelv: a Containers kiegészítő a Workers mellé konkrét, natív függőségű munkákra — nem a régi szerver-modell visszacsempészése.
Termékoldali húzóerő esetén: adatszeparációt kérő enterprise ügyfelek, EU-jurisdiction igény, tenantonkénti restore, régió-közeli adat több kontinensen, vagy ha az Aurora a maradék költség érdemi része. Technológiai kíváncsiság önmagában nem elég ok.
Hogy nem infrastruktúrát üzemeltetsz, amin kód fut, hanem kódot deployolsz, és az infrastruktúra kérdése megszűnik — cserébe elfogadod a platform szabályait: nincs processz-memória és fájlrendszer, a CPU-idő a mérték, az állapot a kapcsolt szolgáltatásokban él, és minden erőforrás bindingként érkezik.