Nu e pe factură. Nu ca „NAT Gateway”, în orice caz. E sub EC2-Other, un tip de utilizare numit NatGateway-Hours, lângă altul numit NatGateway-Bytes, iar în vederea implicită din Cost Explorer e pliat în linia EC2, motiv pentru care o echipă care nu rulează nicio instanță EC2 se poate uita la o taxă EC2 de $100 și poate presupune că e o greșeală.
Nu e o greșeală. E $0,045 pe oră, fiecare oră, pentru fiecare NAT gateway pe care îl ai, înainte ca un singur octet să treacă prin el, plus $0,045 pentru fiecare gigabyte care trece. Pe factura cu trei conturi pe care am publicat-o era 13 % din total, mai mult decât Lambda, DynamoDB și WAF la un loc, pentru o componentă care nu face nimic altceva decât să lase lucrurile private să ajungă la internet. Articolul ăsta e despre de ce îl ai și cum am trecut de la trei la unul.
De ce ai un NAT gateway
Pentru că ceva e într-un subnet privat. Subneturile private n-au rută spre internet gateway, intenționat: nimic de pe internet nu le poate atinge. Prețul e că nici ele nu pot atinge internetul, iar „internetul” include endpoint-urile API AWS, deci o Lambda dintr-un subnet privat nu poate apela S3, Secrets Manager sau SQS fără o cale de ieșire. Calea de ieșire e un NAT gateway într-un subnet public, cu o rută de la subneturile private spre el.
Motivul nostru a fost Aurora. Baza de date e într-un subnet privat, corect. Lambda-urile care vorbesc cu ea trebuie să fie în VPC ca s-o atingă. Odată în VPC, au nevoie de NAT pentru orice altceva fac: să ia un secret, să pună un mesaj într-o coadă, să apeleze un API terț. O singură cerință, accesul la baza de date, a tras o duzină de funcții în VPC și un NAT în fiecare cont.
Cât ne-a costat de fapt
Trei conturi, câte un NAT fiecare, câte o availability zone fiecare (evitaserăm intenționat unul per AZ, ceea ce ar fi triplat costul):
| Ore | Octeți | Lunar | |
|---|---|---|---|
| prod | $33 | ~60 GB × $0,045 = $3 | $36 |
| staging | $33 | ~5 GB | $33 |
| dev | $33 | ~10 GB | $33 |
| Total | $102 |
Observă forma. E aproape în întregime taxa orară. Octeții sunt nimic, pentru că mare parte din ce trece prin NAT sunt apeluri API mici. Așa că sfatul obișnuit, „redu procesarea de date a NAT-ului”, ne-ar fi economisit trei dolari. Pârghia e numărul.
Cinci moduri de a avea nevoie de mai puține
1. Gateway endpoint-uri pentru S3 și DynamoDB. Gratuit. Un gateway endpoint e o intrare în tabela de rutare care trimite traficul pentru S3 sau DynamoDB prin rețeaua AWS în loc de afară și înapoi. Nu costă nimic, e două linii de CDK și ar trebui să fie în fiecare VPC din prima zi, indiferent de NAT. A eliminat cam jumătate din octeții noștri de NAT, adică $1,50. Fă-o oricum; motivul e latența și faptul că nu plătești egress pentru traficul S3, nu NAT-ul.
vpc.addGatewayEndpoint('S3', { service: ec2.GatewayVpcEndpointAwsService.S3 });
vpc.addGatewayEndpoint('DynamoDB', { service: ec2.GatewayVpcEndpointAwsService.DYNAMODB });
2. Interface endpoint-uri pentru serviciile pe care chiar le apelezi. $7,30 pe lună fiecare. Un interface endpoint e o interfață de rețea în subnetul tău, cu un IP privat pentru un serviciu AWS: Secrets Manager, SQS, ECR, CloudWatch Logs, STS. Fiecare costă cam $7,30 pe lună plus $0,01 per gigabyte. Aritmetica: un endpoint se amortizează doar dacă îți permite să elimini un NAT, sau dacă împingi mai mult de vreo 700 GB pe lună prin el. Cinci endpoint-uri ca să acoperim tot ce apelează Lambda-urile noastre înseamnă $37, mai mult decât NAT-ul pe care l-ar înlocui. Așa că le folosim exact într-un singur loc, mai jos.
3. Ieși din VPC. Ăsta e cel mare. O Lambda trebuie să fie în VPC doar dacă vorbește cu ceva ce e accesibil doar acolo. Am auditat cele douăsprezece funcții: șapte vorbeau cu Aurora, cinci nu. Cele cinci erau în VPC pentru că construct-ul CDK avea vpc: setat implicit în fabrica noastră de funcții. Scoaterea lor din VPC a luat un flag și le-a scos complet din lista de clienți ai NAT-ului. O Lambda din afara VPC-ului ajunge la API-urile AWS direct, gratuit, și pornește mai repede.
Pentru cele șapte care au nevoie de Aurora există o opțiune în plus pe care o evaluăm: RDS Data API, care lasă o funcție din afara VPC-ului să interogheze un cluster Aurora peste HTTPS. Schimbă driverul, deci nu e un flag, dar ar goli complet VPC-ul de Lambda-uri.
4. Nu pune unul în dev. NAT-ul din mediul de dev exista ca Lambda-urile de dev să poată ajunge la internet. După pasul 3, singurele lucruri din subneturile private de dev care aveau nevoie de internet erau cele șapte funcții de bază de date care iau secrete și postează în cozi. Două interface endpoint-uri, Secrets Manager și SQS, la $15 pe lună, au înlocuit un NAT de $33, iar apelurile către API-uri terțe din dev (nu există; sunt stub-uite) n-au mai avut nevoie de nicio cale. Staging-ul a primit același tratament.
5. O instanță NAT unde chiar ai nevoie de egress ieftin. Dacă dev ar fi avut nevoie de acces general la internet, răspunsul e o instanță NAT, nu un NAT gateway: un t4g.nano care rulează imaginea open-source fck-nat costă cam $3 pe lună, duce câteva sute de megabiți și e un compromis bun pentru un mediu non-producție unde un single point of failure e acceptabil. N-am avut nevoie, dar e unealta potrivită pentru cazul „am nevoie de un NAT, dar nu de unul de $33”. Niciodată în producție.
Există și un al șaselea, care se aplică doar dacă poți trece pe IPv6-only: un egress-only internet gateway e gratuit și face pentru IPv6 ce face un NAT pentru IPv4. Majoritatea API-urilor terțe nu sunt încă accesibile peste IPv6, deci n-a fost o opțiune pentru noi.
Unde am ajuns
| Înainte | După | Lunar | |
|---|---|---|---|
| prod | 1 NAT gateway | 1 NAT gateway + gateway endpoint-uri S3/DynamoDB | $36 → $36 |
| staging | 1 NAT gateway | interface endpoint-uri Secrets Manager + SQS, fără NAT | $33 → $15 |
| dev | 1 NAT gateway | interface endpoint-uri Secrets Manager + SQS, fără NAT | $33 → $15 |
| Lambda-uri în VPC | 12 | 7 | |
| Total | $102 | $66 |
Producția își păstrează NAT-ul: apelează API-uri terțe, are nevoie de o cale reală, iar $36 pentru o componentă managed, capabilă de multi-AZ, fără mentenanță, e corect. Economia e $36 pe lună, ceea ce sună puțin până observi că e 5 % din toată factura, a luat o după-amiază, iar aceeași după-amiază a făcut cinci Lambda-uri să pornească mai repede.
Regula pentru lucrurile noi
Înainte ca o funcție sau un serviciu nou să intre într-un subnet privat, trebuie să răspundă la o întrebare în pull request: cu ce din subnetul privat vorbește? Dacă răspunsul e „cu nimic”, nu intră. Dacă răspunsul e „cu baza de date”, intră și primește lista de endpoint-uri de care are nevoie. Dacă răspunsul e „are nevoie de internet”, atunci ori e producție, ori e o discuție de design.
NAT gateway-ul nu e un produs prost. E un produs de care e ușor să ai trei fără să fi decis asta. Numără-le pe ale tale.
Dacă linia ta EC2-Other e mai mare decât linia EC2, îți putem spune de ce într-o după-amiază.