---
title: "Cold starts serverless y límites de concurrencia: checklist de pruebas de carga"
description: "Cold starts y concurrencia serverless: límites estilo Lambda, capacidad provisionada, pruebas k6 con arrival rate—contexto de documentación AWS Lambda."
publishDate: "2026-09-10"
draft: false
keyword: "pruebas carga serverless"
intent: "MOFU"
cta: "Usa Performate para convertir este playbook en escenarios k6 ejecutables, umbrales y reportes compartibles sin perder días en código de integración."
tags: ["k6", "pruebas-de-carga", "rendimiento-api", "serverless"]
translationOf: serverless-cold-starts-load-testing
---

Serverless parece elástico hasta que **cold starts** y **topes de concurrencia** convierten un escalón de tráfico en 503. Los gráficos de latencia media ocultan distribuciones bimodales: invocaciones warm a 80 ms, cold a 2 s, throttled en error. Las pruebas deben incluir patrones idle-then-burst y respetar límites por cuenta ([concurrencia Lambda AWS](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html)).

Este checklist cubre qué probar más allá de RPS plano, una rampa k6 que simula tráfico quiet-then-flash-sale, y cómo distinguir respuestas throttle de latencia cold en reportes. Combínalo con alfabetización [spike vs carga](/es/blog/stress-vs-carga-vs-spike-testing) cuando producto describe "tráfico súbito".

## Qué probar más allá de la latencia media

Serverless difiere de contenedores always-on:

- **Cold start tras ventana idle** — primeras requests tras periodo quieto pagan costo de init (runtime, VPC ENI, fetch de secretos).
- **Saturación de concurrencia por cuenta/región** — pools reservados vs no reservados; límites burst por función.
- **Comportamiento provisioned vs on-demand** — concurrencia provisionada elimina camino cold para N instancias warm; prueba ambos modos si los usas.
- **Timeouts downstream amplificados** por invocaciones lentas — 504 de API Gateway puede ser síntoma, no causa raíz.
- **Firmas 429/503 throttle** distintas de errores 500 de aplicación — etiqueta y umbraliza por separado en análisis.

Piensa en capacidad serverless como **tokens e instancias warm**, no porcentaje CPU en flota fija.

### Advertencias de fidelidad staging

Funciones en staging suelen tener más memoria, sin penalización cold VPC, o reservas de concurrencia distintas. Documenta gaps como cualquier prueba [staging vs prod](/es/blog/pruebas-carga-staging-vs-produccion) — los gaps serverless suelen ser mayores de lo habitual.

## k6: pausa idle y spike

**Ejemplo ilustrativo — no es una prueba lista para producción.** Ajusta stages a tu historia de tráfico; coordina con equipo cloud el max de concurrencia antes de correr 80 req/s contra cuenta staging compartida.

**Qué demuestra este ejemplo:**

- **`ramping-arrival-rate`** con stage inicial bajo simula tráfico idle; rampa aguda simula flash sale o ráfaga de webhooks.
- **Tags `surface:serverless`** segmentan métricas de rutas containerizadas en el mismo gateway.
- **Umbral de error relajado en fase spike** opcional — documenta si la prueba busca prueba SLO o mapeo de límites.
- **Sleep corto** mantiene reutilización de conexión realista sin think time cero ([sanity VUs](/es/blog/usuarios-virtuales-think-time-chequeos-ia)).

```javascript
import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE = __ENV.API_BASE || 'https://staging.example.com';

export const options = {
  scenarios: {
    burst_after_quiet: {
      executor: 'ramping-arrival-rate',
      startRate: 1,
      timeUnit: '1s',
      preAllocatedVUs: 50,
      maxVUs: 200,
      stages: [
        { duration: '3m', target: 2 },
        { duration: '30s', target: 80 },
        { duration: '2m', target: 80 },
        { duration: '1m', target: 2 },
      ],
      tags: { surface: 'serverless' },
    },
  },
  thresholds: {
    'http_req_duration{surface:serverless}': ['p(95)<2000'],
    'http_req_failed{surface:serverless}': ['rate<0.05'],
  },
};

export default function () {
  const res = http.get(`${BASE}/fn/invoke`, { tags: { route: 'invoke', surface: 'serverless' } });
  check(res, {
    ok: (r) => r.status < 500,
    not_throttled: (r) => r.status !== 429 && r.status !== 503,
  });
  sleep(0.1);
}
```

**Patrones que funcionan**

- **Registra cold vs warm** cuando la plataforma expone `x-cold-start`, `X-Amz-Executed-Version` o similar — Trend custom en k6 si el header está presente.
- **Coordina con límites de cuenta** — no VUs ilimitados contra cuenta payer staging compartida.
- **Corre spike durante ventana con personal** — aborta si tasa throttle supera límite de exploración acordado.
- **Compara provisioned on/off** en dos exports — liderazgo ve trade-off costo vs latencia.

**Anti-patrones a evitar**

- Solo `constant-arrival-rate` plano — nunca ejercita camino cold tras idle.
- Tratar todos los 503 como bugs de aplicación — puede ser throttle de concurrencia.
- Stress en Lambda producción sin control de cambios y plan de reserva de concurrencia.
- Ignorar límites de conexión DB downstream cuando funciones escalan rápido.

**Pro tip (comando de ejemplo):** desglosa códigos de estado en resumen para análisis de throttle.

```bash
k6 run serverless-burst.js --summary-trend-stats="p(95),p(99)" --tag surface=serverless
```

**Qué demuestra este comando:** combina con filtro post-run de `http_req_duration` donde `status=503` en tu herramienta de análisis — separa latencia cold de throttle duro.

## Marco de decisión: patrón vs executor

| Patrón | Executor | Pregunta respondida |
|:---|:---|:---|
| Tráfico cálido estable | `constant-arrival-rate` | SLO en tráfico normal |
| Cold start tras idle | Hold bajo + stage spike | Penalización init en primeras ráfagas |
| Mapear límite concurrencia | `ramping-arrival-rate` hasta fallo | Dónde empiezan throttles |
| Recuperación post-escala | Stage ramp down | ¿Latencia se normaliza? |

**Usa rampa con forma spike** antes de eventos de marketing — no otra corrida de carga steady.

**Usa ARR steady** solo tras confirmar pool warm — si no, cold sesga `p95`.

## Observabilidad y checklist pre-corrida

- [ ] Registra cold vs warm si la plataforma expone headers diagnósticos — anota en reporte.
- [ ] Coordina max concurrencia con equipo cloud — documenta límites cuenta/región.
- [ ] Compara tipo de prueba [spike vs carga](/es/blog/stress-vs-carga-vs-spike-testing) con lenguaje de producto.
- [ ] Separa throttle vs 5xx de aplicación en checks o post-procesamiento.
- [ ] Anota conteo de concurrencia provisionada y settings de memoria en pie de reporte.
- [ ] Programa durante ventana donde on-call puede desactivar prueba vía kill switch.

## Cómo Performate simplifica las pruebas de carga serverless

Abajo hay un **ejemplo de flujo concreto** para prueba de burst en URL invoke — adapta stages a tu perfil flash-sale.

**Ejemplo: plantilla spike cold-start**

1. **Importa** URL invoke desde Postman — headers y auth preservados. *Problema resuelto:* sin reescribir paths API Gateway bajo presión de lanzamiento.
2. **Construye** stages de rampa en UI — 3m quiet, 30s spike, 2m hold. *Problema resuelto:* editor visual de stages reduce errores YAML en semanas de alto estrés.
3. **Corre** burst en staging con equipo cloud en Slack. *Problema resuelto:* abort en escritorio más rápido que esperar cancel de job CI.
4. **Filtra** errores por status en reporte — 429/503 vs 500. *Problema resuelto:* ticket de capacidad recibe evidencia throttle, no genérico "subieron errores".
5. **Exporta** para ticket de capacidad con captura de diagrama de stages. *Problema resuelto:* debate concurrencia provisionada/finanzas usa un artefacto.
6. **Guarda** plantilla para próximo lanzamiento — retag solo `surface:serverless`. *Problema resuelto:* repetibilidad sin reconstruir de memoria.

Ese flujo mapea directamente al `cta` de este post: escenarios ejecutables y reportes compartibles sin pánico de código de integración antes del lanzamiento.

## Cierre

Las pruebas de carga serverless son **idle + burst + límites**, no RPS plano. Programa un spike cold-start antes del próximo flash sale; etiqueta throttles por separado; documenta reservas de concurrencia en el mismo ticket que el export k6.

Coordina con tu equipo cloud, corre quiet-then-spike una vez en staging y registra dónde empiezan los 429 — ese número pertenece al runbook de lanzamiento.

[Try Performate free](https://performate.app) | [Book a demo](/demo) | [Executors k6](https://k6.io/docs/using-k6/scenarios/executors/)