Röviden: A NAT Gateway óradíja jelentéktelennek tűnik, az adatfeldolgozási díja viszont csendben nő. A megoldás ritkán a "kapcsoljuk ki", sokkal inkább az architektúra és a VPC endpointok.
A NAT Gateway az a tétel, ami hónapokig szinte láthatatlan a számlán, aztán egyszer csak valaki rákérdez, hogy miért fizetünk érte annyit, mint néhány közepes adatbázis-példányért. Nem azért nő, mert drágult, hanem azért, mert a forgalom nő — és a NAT Gateway árazásának a lényege nem az óradíj, hanem az átfolyó adat mennyisége.
Ez a cikk független magyar kommentár a témában sokat idézett angol nyelvű FinOps-forrásokra reagálva. A tanulság nem új, de makacsul ismétlődik: a NAT Gateway ritkán a probléma gyökere, csak a hely, ahol a rosszul megtervezett adatútvonalak számlája megjelenik.
Miért nő a NAT Gateway számlája?
A NAT Gateway két dolgot számláz: azt, hogy létezik (óradíj), és azt, hogy mennyi adat folyik rajta keresztül (feldolgozási díj gigabájtonként). Az óradíj kiszámítható és jellemzően jelentéktelen. A feldolgozási díj az, ami elszalad, mert minden egyes gigabájt, ami a privát subnetből a külvilág felé (vagy azon keresztül más AWS-szolgáltatás felé) megy, díjköteles.
A csapda az, hogy sok forgalomról a mérnök nem is gondolja, hogy a NAT-on megy át. Konténerregisztertől lehúzott image-ek, csomagfrissítések, logok és metrikák külső gyűjtőbe, S3-ba írt mentések egy rosszul konfigurált útválasztásnál — mind ott landolhat.
A gyakori tévhit
A leggyakoribb tévhit, hogy az S3 vagy a DynamoDB felé menő forgalom "belső", tehát ingyenes. Alapértelmezetten viszont, ha nincs megfelelő VPC endpoint, ez a forgalom is a NAT Gatewayen keresztül, a publikus végponton át megy — és fizetsz érte, kétszer is: a NAT-feldolgozásért és potenciálisan a régión kívüli átvitelért.
Hová folyik el a pénz?
A tapasztalat szerint néhány visszatérő forrás adja a NAT-számla nagy részét:
- Konténerképek húzása build és deploy során, különösen ha minden pipeline-futás friss node-on történik.
- Csomag- és függőségletöltés (nyelvi package managerek) minden egyes futásnál cache nélkül.
- Megfigyelhetőségi adat: logok, metrikák, trace-ek külső SaaS-be küldve.
- Objektumtár-forgalom VPC endpoint nélkül.
A megoldás: endpoint és architektúra, nem kikapcsolás
A NAT Gatewayt ritkán lehet egyszerűen "kikapcsolni", mert a privát erőforrásoknak legtöbbször tényleg kell kimenő elérés. A helyes irány az, hogy a nagy, ismétlődő adatutakat leveszed róla.
| Forgalom típusa | NAT Gatewayen át | Alternatíva |
|---|---|---|
| S3 / DynamoDB elérés | Fizetsz a feldolgozásért | Gateway VPC endpoint (díjmentes útvonal) |
| Egyéb AWS API-k | Fizetsz | Interface (PrivateLink) endpoint |
| Image- és csomaghúzás | Ismétlődő nagy forgalom | Cache, tükrözés, közelebbi registry |
| Külső internet | Indokolt esetben marad | Megmarad, de mérd |
A gateway endpoint az S3 és DynamoDB felé az egyik legnagyobb megtérülésű beavatkozás, mert az érte fizetendő díj más nagyságrend, mint a NAT-feldolgozás, és sok csapatnál épp ez a forgalom dominál.
Hogyan derítsd ki a sajátodét?
A számla önmagában nem mondja meg, mi folyik a NAT-on. Ehhez a VPC flow logokra és a költségbontásra van szükség. A gyakorlati sorrend:
- Kapcsold be a VPC flow logokat a NAT-ot használó subneteken.
- Aggregáld a kimenő forgalmat cél és port szerint — mi a legnagyobb tétel?
- Azonosítsd, mi lehetne belső útvonalon (S3, más AWS-szolgáltatás).
- Vezess be endpointokat a legnagyobb tételekre, és mérd újra.
- A maradék valódi internetforgalmat áraz be, és döntsd el, indokolt-e.
A több AZ csapdája
Egy gyakran figyelmen kívül hagyott részlet: a magas rendelkezésre állás kedvéért több elérhetőségi zónában is szokás NAT Gatewayt telepíteni. Ez helyes reflex, de ha a forgalom keresztbe megy a zónák között (az egyik zóna erőforrása a másik zóna NAT-ját használja), akkor a zónák közti adatátvitel díja is rárakódik. Érdemes zónánként a helyi NAT-ra irányítani a kimenő forgalmat.
Az architektúra átgondolása
A NAT Gateway költségének mélyebb kezelése nem beállítás, hanem tervezés kérdése. A kérdés, amit fel kell tenni: miért kell egyáltalán a privát erőforrásaidnak ennyit kifelé kommunikálniuk? Sok esetben a kimenő forgalom nagy része AWS-en belüli célokhoz tart, amiket endpointtal ki lehet váltani. Ami valóban az internetre megy (külső API-k, csomagfrissítés), azt érdemes csoportosítani és tudatosan kezelni.
Egy gyakori minta, hogy a build- és telepítési folyamatok minden futásnál nagy csomagokat töltenek le az internetről a NAT Gatewayen át. Ezt egy belső csomagtükör vagy gyorsítótár drasztikusan csökkentheti: a csomag egyszer jön be, utána belülről szolgálódik ki.
A megfigyelés, ami láthatóvá teszi
A NAT Gateway költségének kezeléséhez először látnod kell, mi folyik rajta. A forgalmi naplók (flow logs) megmutatják, honnan hová megy a forgalom, és így azonosíthatók a legnagyobb tételek. E nélkül csak tippelsz, melyik endpoint éri meg.
- Kapcsold be a hálózati forgalmi naplózást a NAT Gateway-t használó alhálózaton.
- Azonosítsd a legnagyobb forgalmú célokat és protokollokat.
- Ahol AWS-en belüli a cél, mérlegeld a megfelelő endpointot.
- Ahol internetre megy, nézd meg, csökkenthető-e (cache, tükör, ütemezés).
Mit jelent ez neked?
A NAT Gateway számlája nem a kapcsoló hibája, hanem a mögötte lévő adatutaké — ezért a "kapcsoljuk ki" ritkán a jó válasz. Kezdd azzal, hogy flow logokból megnézed, mi folyik rajta keresztül, tedd fel az S3/DynamoDB gateway endpointokat, és rendezd zónahelyesen a kimenő útvonalakat. Ez a három lépés a legtöbb környezetben érdemben csökkenti a számlát anélkül, hogy a rendelkezésre állást feláldoznád.