Aurora Serverless v2 după șase luni: pragul de 0,5 ACU și mitul auto-pause

Publicat pe blogul TEN INVENT · Septembrie 2026

Aurora Serverless v2 se vinde cu o singură propoziție: plătești capacitatea de bază de date pe care o folosești, scalată în fracțiuni de secundă. Șase luni de rulat în producție, staging și dev pentru o platformă a unui client din SUA ne-au învățat că propoziția e adevărată și că ascunde două întrebări care decid dacă e baza de date potrivită pentru tine: care e cea mai mică capacitate pe care ai voie s-o folosești și ce se întâmplă când nu folosești deloc.

Versiunea scurtă: e alegerea corectă pentru dev și staging, pentru workload-uri de producție cu vârfuri și pentru oricine preferă să nu se gândească la clase de instanțe. E alegerea greșită pentru o încărcare de producție mică și constantă, unde o instanță RDS plictisitoare e mai ieftină, și pentru una mare și constantă, unde Aurora provisioned e mai ieftină. Am alege-o din nou pentru proiectul ăsta. Iată aritmetica.

Ce e un ACU și ce cumperi cu 0,5 dintr-unul

O Aurora Capacity Unit e cam 2 GiB de memorie cu CPU și rețea proporționale. Setezi un minim și un maxim per cluster, iar clusterul scalează între ele în funcție de încărcare. Prețul e per ACU-oră: $0,12 în us-east-1, deci un ACU care rulează toată luna e cam $88, iar jumătate de ACU e cam $44.

Minimul obișnuia să fie 0,5 ACU, punct. De la sfârșitul lui 2024 îl poți seta la 0, ceea ce activează auto-pause: după o perioadă de inactivitate configurabilă, clusterul încetează să taxeze compute-ul și se reia la următoarea conexiune. Asta e funcția la care se referă marketingul când zice „plătești ce folosești”. Tot aici trăiește și nuanța.

În dev și staging am setat minimul 0. Clusterele se opresc peste noapte și în weekend, iar reluarea durează cam 15 secunde. Primul request după o pauză așteaptă, sau pică și reîncearcă, și e în regulă pentru un mediu în care primul request de dimineață e al unui developer. Două clustere non-producție au trecut de la cam $90 pe lună la 0,5 ACU fiecare la cam $20.

În producție nu putem. O blocare de 15 secunde la primul request după o perioadă liniștită e o pană vizibilă pentru utilizatori pe o aplicație orientată spre consumatori, și ar pica și health check-ul App Runner care lovește baza de date. Așa că producția rulează cu minim 0,5 ACU, non-stop, indiferent dacă o folosește cineva sau nu. Ăsta e pragul: $44 pe lună înainte de primul query. Mare parte din timp clusterul nostru de producție stă între 0,5 și 1,5 ACU, iar factura lunară de compute ajunge pe la $90.

Ce e bine

Scalarea e reală și e rapidă. Un job batch nocturn care atinge mare parte din tabela de comenzi duce clusterul de la 0,5 la 4 ACU în sub un minut și înapoi în următoarele cincisprezece. N-am dimensionat niciodată o instanță pentru el. Pe RDS provisioned am plăti vârful job-ului toată ziua.

E Postgres. Extensii, pg_dump, orice ORM, orice unealtă. Data API și autentificarea IAM sunt acolo dacă le vrei; noi folosim IAM auth din Lambda-uri și sărim peste gestiunea parolelor pentru ele.

Stocarea e separată și plictisitoare. $0,10 per GB-lună, crește singură, niciun volum de redimensionat, niciun IOPS de provizionat. Backup-urile din fereastra de retenție sunt incluse.

Auto-pause în non-producție e o funcție de cost autentică. Două clustere, $70 pe lună economisiți, zero configurare dincolo de un minim de 0 și un timeout de inactivitate. A făcut mediile de preview per PR practice: un cluster comun pe pauză, o bază de date per PR, zero cost de compute per PR.

Ce e rău

Pragul e prețul. Pentru un workload de producție mic, 0,5 ACU non-stop înseamnă $44 plus stocare. O instanță RDS PostgreSQL db.t4g.medium, 2 vCPU și 4 GiB, e cam $47 on-demand și $30 rezervată, nu scalează, dar nici nu are nevoie. Dacă încărcarea ta de producție e constantă și mică, Serverless v2 e modul mai scump de a cumpăra același lucru.

Scalarea în jos e lentă, și scalarea în jos e momentul în care cad conexiunile. Capacitatea urcă în secunde și coboară în minute, intenționat. Când coboară, memoria instanței se micșorează, iar conexiunile care țineau working set-uri mari sunt omorâte. Am văzut erori sporadice de connection reset o săptămână înainte să le corelăm cu evenimentele de scale-in. RDS Proxy în față a rezolvat pentru Lambda-uri; pentru App Runner am setat timeout-ul de inactivitate al pool-ului sub intervalul de scale-in.

ACU maxim e o limită de memorie pe care o poți lovi în momentul nepotrivit. Am setat max 4 ca să plafonăm costul. Un query de raportare care avea nevoie de mai multă memorie decât dau 4 ACU n-a devenit mai lent, a picat. Pe RDS provisioned același query ar fi făcut swap și s-ar fi târât, ceea ce e, poate, mai rău, dar s-ar fi terminat.

Reluarea după auto-pause nu e 15 secunde pentru toată lumea. E 15 secunde pentru cluster. Adaugă cold start-ul Lambda din față și pool-ul de conexiuni al instanței App Runner care se restabilește, și primul request de dimineață în dev poate lua 30 de secunde. Acceptabil acolo. Nu e o funcție de producție, orice ar sugera pagina de prețuri.

Costul, sincer

Comparația pe care o vrea lumea e Serverless v2 față de alternative la o încărcare medie dată. La preț de listă în us-east-1, doar compute:

Punctul de încrucișare e clar. Sub cam 1 ACU medie, o instanță RDS mică e mai ieftină sau egală. Peste cam 2 ACU constant, Aurora provisioned e mai ieftină. Serverless v2 câștigă la mijloc, și câștigă decisiv când vârful e de câteva ori media, adică ultimul rând, cel care descrie majoritatea aplicațiilor reale cu utilizatori într-un singur fus orar.

Setări pe care le-am copia în orice cluster nou

• Producție: min 0,5, max dimensionat după cel mai mare query pe care l-ai văzut plus unu, nu după buget. Deletion protection pornit. RDS Proxy pentru orice are formă de Lambda.
• Non-producție: min 0, auto-pause după 10 minute, max 2. Accepți blocajul de dimineață.
• Ambele: timeout de inactivitate al pool-ului de conexiuni sub 5 minute, ca evenimentele de scale-in să nu te surprindă. Stocare I/O-Optimized doar dacă taxele de I/O depășesc cam 25 % din factură, ceea ce la noi nu se întâmplă.
• Urmărește ServerlessDatabaseCapacity și ACUUtilization în CloudWatch. A doua la 100 % mai mult de câteva minute înseamnă că ACU maxim e prea mic și ceva urmează să pice, nu să încetinească.

Verdict

Pagina de prețuri zice că plătești ce folosești. Versiunea exactă e: plătești cel puțin jumătate de ACU în producție, nu plătești nimic când e pe pauză în altă parte, și plătești o primă per ACU în schimbul faptului că nu dimensionezi nimic. Dacă prima merită depinde în întregime de forma încărcării tale, și acum ai tabelul.

Alegi între Serverless v2, RDS și Aurora provisioned pentru ceva real? Facem aritmetica împreună.