Röviden: A Graviton5-ös C9g és M9g akár 25%-kal erősebb a Graviton4-nél, Frankfurtban is elérhető. A magyar kérdés nem a bench, hanem a migráció költsége és az, ami nem fordul ARM-ra.
Júniusban megérkezett a Graviton5 a C9g/C9gd compute- és az M9g/M9gd általános célú instance-okra. A vendor szerint ez a valaha volt legerősebb és energiahatékonyabb saját CPU-juk: a Graviton4-hez képest akár 25% jobb compute, ötszörös L3 cache, DDR5-8800, PCIe Gen6. A M9g Frankfurtban is GA. Magyar csapatnak ez a mondat a lényeg: az ARM már nem „majd ha a US-East-en kimegy a kísérlet”. Itt van, EU-s régióban, általános célú méretben.
Amit a számok mondanak — és amit nem
A publikus referenciák látványosak. A Honeycomb hat hónapos A/B tesztben 36% jobb per-core throughputot mért Graviton4-hez képest megfigyelési workloadon. A HubSpot MySQL-en akár 60%-kal rövidebb query durationről beszélt M9g-n. Ezek vendor által közölt, valós ügyfél-számok — nem a te számaid. A Graviton-migráció egyetlen tisztes módja, hogy a saját p95-ödet méred, ugyanazon a kódon, ugyanazzal a terheléssel, legalább egy hétig, nem egy péntek délutáni wrk-vel.
A C9g a CPU-intenzív oldal: analytics, HPC-jelleg, AI-orchestration, ahol a CPU még mindig a gerinc, nem a GPU. Tizenegy méret, mediumtól 48xlarge-ig, bare-metal opcióval; a nagyoknál 100 Gbps hálózat és magas EBS-sávszélesség. Az M9g a „sima” webes, API-s, adatbázisos közép. Ha ma M6i vagy M7g a magszolgáltatásod, az M9g a természetes következő kérdés — nem a C9g.
A migráció, ami nem a CPU
Az ARM-váltás három rétege. Az első a nyelv: a modern Node, JVM, Go, Python hivatalos ARM-buildje 2026-ban már nem kaland. A második a natív függőség: image-könyvtárak, regex-gyorsítók, régi native addon, egyetlen vendor SDK, ami csak x86 wheel-t ad. A harmadik a üzemeltetés: AMI, bakancs-script, monitoring agent, sidecar. A bukás szinte soha nem a „Graviton lassú”, hanem az, hogy a tizenkettedik függőség x86-only, és ezt stagingben deríted ki, nem a RFC-ben.
A Graviton akkor olcsó, ha a build-pipeline-od ARM-on is zöld. Addig csak egy újabb instance-család a konzolon.
Gyakorlati sorrend, ami magyar kettes-hármas csapatnál működik. Először a stateless API, ahol a image-t te építed. Aztán a worker, ahol a CPU a számla. Végül az adatbázis — és ott lassan, read-replika vagy árnyékterhelés nélkül ne. A HubSpot-szerű MySQL-nyereség csábító, de az adatbázis-családváltás a rollback szempontjából más műfaj, mint egy API-deploy.
Mikor maradj x86-on
Három őszinte ok. Vendor lock a binary szinten: van olyan zárt komponensed, amiből nincs aarch64 build, és a cseréje negyedéves projekt. Speciális instruction set: ha a kódod AVX-re hangolt, és a teljesítményed ebből jön, az ARM más profil, nem drop-in. És a csapatidő: ha a következő két sprinted egy incidensből és egy auditból áll, a CPU-családváltás várhat. A Graviton5 nem szalad el Frankfurtból jövő héten.
A Nitro Isolation Engine — Rust-alapú közvetítés memóriához, CPU-regiszterhez, I/O-hoz — a platformrész, nem a te kódod. Ne vedd „miért váltsunk” érvnek. Vedd annak, ami: a hypervisor oldala vastagodott. A te oldalon a least privilege, az AMI-higiénia és a mérés marad.
Költségben a Graviton akkor nyer, ha a kihasználtságod megvan, és a szoftver nem fizet taxit a kompatibilitásért. Ha a gép 15%-on pörög, a 25% gyorsabb CPU 15% üresjáratot visz gyorsabban. Előbb right-size, aztán családváltás. Ez unalmas, és ezért működik.
A magyar migrációs checklist
Egy hét, ami nem heroikus, csak rendes. Nap 1: az image multi-arch, a CI ARM-jobja zöld, a natív addonok listája egy oldalon. Nap 2: stagingen egy M9g vagy C9g, ugyanaz a kód, ugyanaz a feature flag. Nap 3–5: éleshez közeli forgalom, p95, hibaarány, CPU-kredit ha burstable-ről jössz. Nap 6: Cost Explorer, ugyanaz a tagging, dollár és forint, usage versus FX külön. Nap 7: döntés. Marad, bővül, vagy vissza. A vissza nem kudarc. A bench nélküli maradás a kudarc.
Node-on a npm native addon a tipikus akná. JVM-en a GC-flag és a heap, amit x86-ra hangoltál, ARM-on más profilt ad — ne vidd át vakon a -Xmx rituálét. Pythonon a wheel: ha a pip x86 kereket cache-el, az instance elindul, a worker pedig importnál hal meg. Go-n ez a legritkább fájdalom, ha GOARCH=arm64 a pipeline része, nem utólagos meglepetés. A checklist nyelve ez legyen, ne a „Graviton gyors”.
Frankfurt versus Ireland: a M9g GA-listáján Frankfurt benne volt. Ha az adatod EU-ban marad, ne US-East-re menj „mert ott van a legnagyobb kvóta”. A kvóta kérhető. Az adatlokáció a szerződésed. A C9gd helyi NVMe-je akkor érdekes, ha a workloadod tényleg a lokális SSD-t eszi — cache, scratch, bizonyos adatbázis-szerű terhelés. Ha EBS-re írsz mindent, a d a névben nem ajándék, csak másik SKU.
A Bare-metal 48xl a brosúra teteje, nem a magyar kettes csapat első lépése. Kezdd a mérettel, amin ma is futsz, egy generációval odébb. A 25% akkor a tied, ha a szoftver ugyanazt a munkát kevesebb vCPU-n vagy rövidebb idő alatt végzi. Ha ugyanannyi gépet tartasz „biztonságból”, a Graviton5 a status-symbol, nem a számla. Ugyanez igaz a GPU-mellékszálra: a C9g CPU-s AI-orchestrationre van kihegyezve, nem arra, hogy a p4d-t kiváltsa. Ha a modell a GPU-n él, az ARM ott a kísérőzenekar. Ne keverd a két számlát egyetlen „migráljunk Gravitonra” epicbe — a kísérőzenekar cseréje nem a szólista cseréje, és a rollback is más. Ha egy hét mérés után a p95 rosszabb, ne „hangolj tovább két sprintet”. Vidd vissza, írd meg, melyik függőség volt a fék, és akkor gyere vissza, amikor az a függőség ARM-on is unalmas.
Mit jelent ez neked?
Ha Frankfurtban futtatsz általános API-t vagy workert, az M9g/C9g 2026-ban nem kísérlet, hanem következő capacity-terv. Mérj egy hétig, ARM-on is fordítsd a pipeline-t, és a natív függőségeket írd össze, mielőtt a finance-nek ígérsz százalékot. Ha van x86-only binaryd, ne hazudj ARM-ot köré — ütemezd a cserét, vagy maradj. A Graviton5 a jó ár/teljesítmény, nem a vallás. A vallás ott kezdődik, amikor bench nélkül migrálsz, mert a blogposzt szép volt.