Cijena serverless WebSocketa: minute konekcije rijetko su najveća stavka

Napravio sam WebSocket servis na API Gatewayu i Lambdi, a mapu konekcija držao je Redis. Servis je služio za analitiku uživo, obavještenja pojedinačnim korisnicima, prisilnu odjavu i zaključavanje koje je sprječavalo da dva admina uređuju isti zapis.

Servis je radio. Pogriješio sam u tome koji je dio računa bitan.

WebSocket konekcija ima stanje, a Lambda funkcija nema, pa se veći dio dizajna svodi na pitanje gdje čuvati stanje između poruka.

Socket drži API Gateway. Lambda radi samo onoliko milisekundi koliko joj je potrebno da obradi jednu poruku, a sljedeća poruka može završiti na drugoj instanci. Zato se mapiranje od „ko je ovo“ do „u koju konekciju pišem“ mora čuvati izvan funkcije.

Mapiranje sam držao u Redisu, pod ključem složenim od korisnika, tipa korisnika, statusa i emaila. Na to se nadovezuje šesnaest ruta: subscribe i publish, te rute za pojedine događaje, kao što su odjava, zaključavanje zapisa za uređivanje i slanje obavještenja.

U tom dizajnu nema ničeg neobičnog.

Za WebSocket API, API Gateway naplaćuje dvije stavke:

Minuta konekcije obračunava se za svaku minutu dok je socket otvoren, bez obzira na to šalje li se išta. Većina tekstova o troškovima serverless WebSocketa bavi se upravo ovom stavkom. I ja sam pretpostavio da će ona biti najveća na računu, jer se plaća i dok korisnik ništa ne radi.

Onda sam napravio model, a u većini scenarija više je koštalo nešto drugo.

Model ima osamnaest scenarija: šest različitih brojeva korisnika, svaki pri tri nivoa saobraćaja.

Pretpostavke navodim da biste ih mogli zamijeniti svojim. Cijene su po cjenovniku za US East sa sredine 2026. godine, bez free tiera na API Gatewayu. Korisnici su povezani osam sati dnevno, trideset dana u mjesecu. Poruka u prosjeku ima 2 KB, pa je jedna poruka jedna obračunska jedinica. Polovinu svih poruka čine push poruke sa servera, pa je poziva Lambde upola manje nego poruka. Lambda ima 128 MB i radi 50 ms po pozivu, a uračunat je njen trajni free tier. Svaki poziv upiše jedan kilobajt loga po cijeni od 0,50 $/GB, a izlazni prenos podataka košta 0,09 $/GB.

Većina kalkulatora izostavlja dva fiksna troška, a ispod hiljadu korisnika oni su važniji od svega ostalog.

Prvi je Redis. cache.t4g.micro na Valkeyu košta 9,34 $ mjesečno i radi bez obzira na to povezuje li se iko.

Drugi je VPC endpoint. Lambda koja pristupa ElastiCacheu mora biti u VPC-u, a Lambda u VPC-u ne može pozvati API Gateway Management API i poslati poruku ako nema izlaz iz VPC-a. Interface endpoint košta oko 7,30 $ mjesečno u jednoj zoni dostupnosti. NAT Gateway bi koštao 32 $.

Ukupno je to 16,64 $ fiksnog troška prije prve konekcije.

Slab saobraćaj: 20 poruka po korisniku dnevno

Umjeren saobraćaj: 200 poruka po korisniku dnevno

Jak saobraćaj: 2.000 poruka po korisniku dnevno

1. Ispod hiljadu korisnika fiksni troškovi čine veći dio računa

Pri slabom saobraćaju i deset korisnika račun iznosi 16,69 $, od čega su 16,64 $ Redis i VPC endpoint. Potrošnja iznosi četiri centa.

Na sto korisnika račun je 17,09 $, a na hiljadu 21,11 $. Broj korisnika porastao je stostruko, a račun se pomjerio za otprilike četiri dolara, jer se uglavnom plaća kirija za dvije komponente koje rade bez obzira na saobraćaj.

Ovaj rezultat me iznenadio, jer obrće uobičajeni savjet. Na malom serverless WebSocket servisu nema smisla optimizovati broj poruka: na sto korisnika i pri slabom saobraćaju podešavali biste 3% računa. Taj račun se može smanjiti samo ako uklonite neku fiksnu komponentu, tako što uzmete jeftinije skladište konekcija ili ga se potpuno odreknete.

2. Minute konekcije su najveća stavka u samo tri od osamnaest scenarija

Očekivao sam da će biti najveća stavka, a bile su to samo pri slabom saobraćaju, od pet hiljada korisnika naviše. Pri slabom saobraćaju minute konekcije čine 80% potrošnje, a od pet hiljada korisnika naviše potrošnja je veći dio računa. Pri umjerenom saobraćaju minute konekcije čine 28% potrošnje, a pri jakom 4%.

Razlog je računica koju sam trebao napraviti na početku. Minuta konekcije košta četvrtinu cijene poruke, a korisnik koji je povezan osam sati ima 480 minuta konekcije dnevno, pa se troškovi izjednače tek na 120 poruka dnevno. Iznad otprilike 15 poruka na sat po korisniku poruke su veća stavka na računu.

3. Pri umjerenom saobraćaju obični server je jeftiniji već na hiljadu korisnika

Obje arhitekture trebaju Redis, pa razliku među njima pravi sve ostalo.

Pri umjerenom saobraćaju i hiljadu korisnika serverless već košta više od jedne instance, a na pet hiljada korisnika skuplji je i od pravog redundantnog para servera. Na pedeset hiljada korisnika košta tri do pet puta više.

Kao tačku u kojoj se cijene izjednače viđao sam otprilike hiljadu stalno otvorenih konekcija, a tu sam brojku i sam ranije pogrešno izračunao. Ona nastaje kad se minute konekcije porede s golom instancom. Pritom se zanemaruje da obje strane trebaju skladište konekcija, da serverless treba i izlaz iz VPC-a i da pri realnim količinama poruka poruke koštaju više od konekcija. Kad se sve to uračuna, serverless postaje skuplji od jednog servera i prije hiljadu korisnika.

Kalkulator ispod računa isti model s vašim brojkama. Nudi šest brojeva korisnika iz tabela, jer sam samo za njih birao veličinu Redisa i servera.

Održavanje nije ni na jednom računu. Uz serverless nema zakrpa, skaliranja, planiranja kapaciteta ni dežurstva zbog procesa koji je pao. Jedan server je single point of failure, pa sam izračunao i cijenu redundantnog para, a i par su dvije instance o kojima se neko mora brinuti.

Na sto korisnika lako je platiti 17 $ umjesto 22 $ i ne misliti više o serveru. Na pedeset hiljada korisnika serverless je više od tri puta skuplji od redundantnog para. Plaćati toliko samo da biste izbjegli održavanje dva servera odluka je koju neko treba donijeti svjesno.

I logovi mogu koštati više od minuta konekcije. Pri umjerenom saobraćaju i 10.000 korisnika CloudWatch košta 15 $, naspram 36 $ za minute konekcije, a opširno logovanje na servisu koji razmjenjuje mnogo poruka to obrne. Logovi su stavka na računu koju je najjeftinije popraviti i najlakše zaboraviti.

Dvije brojke izgledaju kao da se moraju slagati: TTL od petnaest minuta na zapisu konekcije i osvježavanje na klijentu svakih deset minuta.

Neko vrijeme sam to smatrao skrivenom spregom: dvije postavke u dva repozitorija, a ispravnost zavisi od odnosa među njima. Bolje je zapitati se ko upravlja konekcijom.

Konekciju otvara klijent, pa klijent upravlja i njenim vijekom trajanja. On je jedina strana koja zna da li socket još postoji, a sve na serveru je sigurnosna mreža za zapise koje klijent nije stigao počistiti.

Tako invarijantu koju morate pamtiti zamjenjuje pravilo od jednog reda: klijent je mjerodavan, a server čisti za njim. Zato i interval osvježavanja na klijentu mora biti kraći od TTL-a zapisa: konekcija pripada klijentu, pa klijent mora obnoviti zapis prije nego što bi ga server počistio.

Dva ograničenja koja se ne mogu podići

Idle timeout je 10 minuta: socket bez saobraćaja se zatvara. Najduže trajanje konekcije je 2 sata: svaka konekcija se zatvara nakon dva sata, koliko god bila aktivna. Nijedno od ta dva ograničenja ne može se podići.

Osvježavanje na klijentu svakih deset minuta pada tačno na idle timeout, pa se socket u praksi ponekad zatvori prije osvježavanja. To je u redu ako klijent osvježava tako što se ponovo poveže, jer se vrati u svakom slučaju i zapis se upiše iznova. Bio bi problem da je tih deset minuta heartbeat koji treba održati socket otvorenim, jer keepalive mora biti dobro ispod granice.

Granica od dva sata znači i da se dashboard otvoren cijeli dan ponovo poveže najmanje dvanaest puta, pa se na dugotrajnu konekciju ne možete osloniti.

Zaostali zapisi konekcija se plaćaju

Zapis konekcije koji nadživi svoj socket prikazuje korisnika kao online iako nije, a server mu zbog tog zapisa i šalje poruke. Poruka ode i API Gateway je naplati, ali je niko ne primi.

Servis koji spisku navodno povezanih korisnika šalje obavještenja i izmjene uživo plaća svaku poruku poslanu nekome ko je otišao, a trošak raste s brojem zaostalih zapisa. To pritom prolazi neprimijećeno, jer poruka poslana mrtvoj konekciji ne izaziva grešku koju iko prati.

Model ovo može izraziti brojkom. Pri umjerenom saobraćaju polovinu poruka čine push poruke sa servera, pa je na 10.000 korisnika to trideset miliona push poruka mjesečno. Ako je 10% zapisa konekcija zaostalo, tri miliona tih poruka bude naplaćeno, a da ih niko ne primi: 3 $ mjesečno. Kad je zaostalo 30% zapisa, to je 9 $, a na pedeset hiljada korisnika i 30% zaostalih zapisa 45 $.

Ti iznosi su mali, ali su čist gubitak. Rastu s brojem zaostalih zapisa, a ne sa saobraćajem, i to je jedina stavka na računu za koju sigurno znate da za taj novac niste dobili ništa.

Kad push ne uspije, API Gateway vraća 410 Gone. Ako handler obriše zapis čim dobije taj odgovor, istim korakom počisti stanje prisutnosti i zaustavi trošak, bez ikakvog usklađivanja s klijentom.

Tako svaki od tri mehanizma pokriva svoj slučaj:

Nijedan od njih ne zavisi od brojke u tuđem repozitoriju.

Jednu odluku s tog servisa donio bih ponovo: prestao sam ručno pisati konfiguraciju za deploy.

Serverless konfiguracija mora deklarisati svaku rutu. Sa šesnaest ruta to je fajl koji pažljivo uređujete i svejedno pogriješite. Ruta koja postoji u kodu, a nema unos u konfiguraciji, za sistem uopšte ne postoji, a ništa vas na to ne upozori. Zato se konfiguracija generiše iz koda. Izvor je samo jedan, pa se kod i konfiguracija ne mogu razići. Šesnaest ruta je već više nego što bi čovjek trebao ručno usklađivati.

Sve brojke su po cjenovniku za US East sa sredine 2026. godine, bez free tiera na API Gatewayu i s trajnim free tierom Lambde. U računicu nisu ušle LCU naknade za load balancer, prenos između zona dostupnosti, backupi i cijene za rezervisane instance, a sve to pomjera kolone sa serverima, uglavnom naviše. Model je računica na osnovu objavljenih cijena i nisam mjerio sistem u radu.