Què és serverless, i quan NO fer-lo servir

Serverless no vol dir que no hi hagi servidors. Vol dir que no en gestiones cap: no hi ha instància per arrencar, ni sistema operatiu per actualitzar, ni grup d'autoescalat per configurar. Tu entregues una funció i el proveïdor decideix on i quan executar-la.

El canvi de fons no és tècnic, és econòmic. Amb un servidor pagues per temps encès. Amb Lambda pagues per invocació i per mil·lisegons d'execució. Si no t'entra cap petició, no pagues res. Si te n'entren mil de cop, se n'executen mil alhora sense que hagis tocat res.

Això és el que et ven AWS. La resta de la lliçó és la lletra petita.

---

El model mental: procés efímer i sense estat

Quan invoques una funció, AWS busca un entorn d'execució lliure. Si no n'hi ha cap, en crea un de nou: descarrega el teu codi, arrenca el runtime de Node i executa tot el que hi ha fora del handler. Això és el cold start. Després executa el handler, congela el procés i el desa uns minuts per si torna una petició. Si no torna, el destrueix.

D'aquí surten quatre conseqüències que has d'interioritzar abans d'escriure res:

• No pots guardar res a memòria i esperar retrobar-ho. Les variables globals sobreviuen entre invocacions del mateix entorn, però no controles quin entorn t'atendrà.
• No hi ha routing enganxós. Dues peticions del mateix usuari poden anar a dos entorns diferents.
• Un entorn atén una petició alhora. No hi ha concurrència dins d'una instància de Lambda: deu peticions simultànies són deu entorns.
• Pagues el temps de rellotge, no el de CPU. Si la teva funció espera 800 ms una resposta d'una API externa, pagues aquests 800 ms sencers.

Un handler mínim en TypeScript:

// src/handler.ts
import type { APIGatewayProxyEventV2, APIGatewayProxyResultV2 } from "aws-lambda";

// Això s'executa UN cop per entorn d'execució, no per petició.
const arrencat = new Date().toISOString();

export const handler = async (
  event: APIGatewayProxyEventV2,
): Promise<APIGatewayProxyResultV2> => {
  return {
    statusCode: 200,
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      ruta: event.rawPath,
      entornArrencatA: arrencat,
    }),
  };
};

Crida'l dos cops seguits i veuràs el mateix entornArrencatA: és el mateix entorn reutilitzat. Espera deu minuts, torna-hi, i haurà canviat.

---

Quan serverless és la resposta

• Càrrega irregular o imprevisible. Un formulari de contacte, un webhook, una API interna que ningú toca de nit. Pagar per un servidor encès 24 h per atendre 3.000 peticions al dia no té sentit.
• Feina per esdeveniments. Un fitxer que arriba a S3, un missatge a una cua, un cron. El model encaixa sol.
• Projectes petits que han de sobreviure a un pic. Si surts a la premsa i et vénen 50.000 visites en una hora, Lambda escala i tu no fas res.
• Equips petits. El temps que no dediques a parchejar servidors el dediques al producte. Això, en un equip d'una persona, val més que la diferència de factura.

---

Quan NO és la resposta

Aquí és on la documentació d'AWS calla.

Càrrega constant i alta

Si tens tràfic sostingut, serverless surt car. Els números de sota són reals (els tens desglossats a l'apartat de costos): un servei amb 100 peticions per segon constants, 256 MB i 200 ms per petició, et surt per uns 270 $ al mes amb Lambda. El mateix servei en dos contenidors petits darrere d'un balancejador te'l fas per uns 50 $.

No és un 10 % de diferència: és cinc vegades. El motiu és el de sempre — pagues temps de rellotge, i un contenidor aprofita els mil·lisegons que passa esperant l'entrada/sortida per atendre altres peticions, mentre que una instància de Lambda els paga aturada.

Processos llargs

Una funció Lambda mor als 15 minuts. No és configurable més enllà. Si has de processar un vídeo, generar un informe pesat o migrar una taula sencera, o bé el parteixes en trossos (Step Functions, cues) o busques una altra eina. I si el que hi ha al davant és API Gateway, el límit real que et menjaràs no són 15 minuts: són 29 segons.

Coses que necessiten estat a memòria

Una cache en memòria, un pool de connexions, una sessió de WebSocket amb estat, un motor que triga a carregar un model i el vol tenir viu. Tot això, a Lambda, o no funciona o es converteix en una peça externa (ElastiCache, DynamoDB, RDS Proxy) que abans no necessitaves. Compta aquest cost abans de decidir.

Latència p99 predictible

Els cold starts en Node ronden els 100–400 ms segons el pes del bundle. Per a una API interna és irrellevant. Per a una pantalla de pagament o un endpoint que es crida dins d'un bucle, no ho és. Es pot mitigar amb provisioned concurrency, però llavors pagues per tenir entorns encesos — és a dir, has reinventat el servidor, però més car.

---

Què costa això

Preus de Lambda (arquitectura x86; amb ARM/Graviton el càlcul és un 20 % més barat):

Concepte	Preu
Nivell gratuït mensual	1.000.000 de peticions + 400.000 GB-segon
Peticions	0,20 $ per milió
Còmput	0,0000166667 $ per GB-segon

El GB-segon és la unitat que costa d'entendre: memòria assignada × segons d'execució. Una funció de 512 MB que triga 200 ms consumeix 0,5 × 0,2 = 0,1 GB-segon.

Tres escenaris reals:

Escenari	Peticions/mes	Cost
Formulari de contacte (500/dia, 128 MB, 100 ms)	15.000	0 € — no surts del nivell gratuït
API interna (1M/mes, 256 MB, 150 ms)	1.000.000	~0,20 € — el còmput encara cau al nivell gratuït
Servei sostingut (100 req/s, 256 MB, 200 ms)	259.000.000	~270 €

Nota honesta: el nivell gratuït de Lambda és de tipus always free, no caduca als dotze mesos. Però AWS va canviar el model de nivell gratuït per als comptes nous a mitjan 2025 (crèdits de benvinguda en comptes de franquícia), així que mira't la pàgina de preus del teu compte abans de donar cap número per bo.

I compta el que Lambda no inclou: API Gateway, CloudWatch Logs, NAT Gateway si poses la funció dins d'una VPC. Aquest últim són 32 $ al mes fixos i és la sorpresa més habitual de la primera factura.

---

Errors habituals

• Posar la funció dins d'una VPC sense necessitat. Ho fa molta gent per costum. Si la funció no ha de parlar amb una RDS privada, no la hi posis: t'afegeixes un NAT Gateway de 32 $/mes i temps d'arrencada extra a canvi de res.
• Deixar el timeout per defecte. Els 3 segons per defecte són pocs per a qualsevol cosa que faci una crida externa. La funció es talla a mitges, i com que el reintent d'una invocació asíncrona és automàtic, acabes executant la feina dues vegades sense adonar-te'n.
• Obrir la connexió a la base de dades dins del handler. Cada invocació obre una connexió nova, i amb 200 peticions concurrents esgotes el límit de la RDS. La connexió va fora del handler, i si tens una base de dades relacional, amb RDS Proxy al davant.
• Desplegar a la regió equivocada. La consola d'AWS recorda l'última regió que vas mirar. Desplegues a us-east-1, ho busques a eu-west-1 i no hi és. Fixa la regió al fitxer de configuració, no al teu cap.