DEV Community: Franchesco Romero

Lambda Web Functions cobra la memoria mientras el entorno viva: el punto de equilibrio contra Lambda clásica

Franchesco Romero — Sun, 25 Oct 2026 22:13:32 +0000

AWS lanzó Lambda Web Functions el 12 de octubre de 2026. Corre un servidor HTTP normal, atiende hasta 128 peticiones a la vez por entorno y cobra CPU activa en vez de tiempo de reloj. Suena a un descuento directo sobre AWS Lambda clásica. No lo es: el costo pasa de "el tiempo que corre una petición" a "la memoria que ocupa un entorno mientras existe". Este post calcula dónde se cruzan las dos líneas y lo prueba con una API real.

Qué cambia en la factura

Lambda clásica (us-east-1, Arm) cobra cada petición mientras corre:

$0.0000133334 por GB-segundo de memoria configurada, en tiempo de reloj, incluido el tiempo que pasa esperando a la base de datos
$0.20 por millón de peticiones

Web Functions cobra tres cosas:

$0.0000276944 por vCPU-segundo de CPU activa. Esperar I/O casi no cuesta.
$0.0000036667 por GB-segundo de memoria, mientras el entorno exista, incluido el tiempo ocioso entre peticiones
$0.30 por millón de peticiones

Dos consecuencias:

La memoria se vuelve un piso mensual. Si llega tráfico cada pocos minutos, el entorno nunca se apaga. Con 1 GB son unos $9.50 al mes antes de cobrar una sola petición.
La CPU cuesta casi el doble por segundo, pero sólo cuenta la CPU. Una petición que tarda 200 ms y calcula durante 50 ms paga 50 ms.

Así que Web Functions gana por petición sólo cuando las peticiones esperan mucho más de lo que calculan, y necesita suficientes peticiones para pagar el piso.

El punto de equilibrio

Los dos modelos pagan por petición; Web Functions además paga el piso. El cruce está en:

break-even requests/month = floor / (classic cost per request - Web Functions cost per request)

classic per request        = latency_s * classic_GB * 0.0000133334 + 0.0000002
Web Functions per request  = cpu_s * 0.0000276944 + 0.0000003
floor                      = env_GB * 2,592,000 * 0.0000036667

La página de precios de AWS trae un ejemplo de "API backend con mucho I/O": 200 ms por petición, 50 ms de CPU, unos 0.29 GB por entorno. Contra una función clásica de 1 GB:

Web Functions memory floor   $2.76/month
classic, per million         $2.87
Web Functions, per million   $1.68
break-even                   2,331,877 requests/month

Arriba de 2.3 millones de peticiones al mes, Web Functions sale más económica. Ahora la misma carga contra una función clásica de 512 MB:

Web Functions memory floor   $2.76/month
classic, per million         $1.53
Web Functions, per million   $1.68
Web Functions never pays off: per request it costs as much or more than classic.

La respuesta se voltea según cuánta memoria necesitaría la función clásica. La comparación sólo tiene sentido contra la configuración clásica que de verdad usarías. Una advertencia: Lambda clásica asigna CPU en proporción a la memoria, así que 50 ms de CPU a 1 GB tardan más a 512 MB, y la latencia sube con ellos. Mide antes de confiar en la línea más económica.

Una API real

Una API pequeña en producción: FastAPI en una tarea de AWS Fargate (0.25 vCPU, 1 GB, Arm), detrás de un Application Load Balancer, con PostgreSQL en Amazon RDS. Catorce días de métricas de Amazon CloudWatch:

RequestCount                 101865.0
latency_s avg=0.075 max=33.25 p50=0.0085 p99=1.096
minutes with >=1 request: 20159 of 20160
p50 requests/min: 1
peak requests/min: 283 (4.72 rps)
MemoryUtilization  68.65622133758562

Unas 218,000 peticiones al mes, con tráfico en casi todos los minutos y una petición por minuto en la mediana. Como hay tráfico en cada minuto, un entorno se quedaría vivo todo el mes y el piso se paga completo.

El punto de equilibrio en el caso más favorable para Web Functions, cero CPU por petición:

Web Functions memory floor   $6.56/month
classic, per million         $1.20
Web Functions, per million   $0.30
break-even                   7,286,426 requests/month
your traffic                 218,282 requests/month (3.0% of break-even)

Esta API necesitaría 33 veces su tráfico para que Web Functions le gane a Lambda clásica, aunque sus peticiones no usaran nada de CPU.

La factura mensual completa:

	Fargate + ALB (hoy)	Web Functions	Lambda clásica
Cómputo	$8.39	$7.03	$0.26
Puerta de entrada	ALB, 2 IPv4 públicas, AWS WAF regional: $32.50	CloudFront + WAF: ~$9.22	CloudFront + WAF: ~$9.22
Total	$40.89	~$16.25	~$9.48

El hallazgo más grande está en la segunda fila. A este tamaño, el dinero no se va en el cómputo. El balanceador, sus dos direcciones IPv4 públicas y el WAF regional cuestan cuatro veces lo que cuesta el contenedor que tienen detrás. Cualquiera de las dos opciones de Lambda ahorra sobre todo porque quita el ALB, no porque calcule de forma más eficiente. Un dominio propio o un WAF delante de Lambda siguen necesitando Amazon CloudFront, así que el costo del WAF se muda en vez de desaparecer.

Para esta API la pregunta es teórica de todos modos: en el lanzamiento, Web Functions sólo corre Node.js, y esta API es Python.

Cuándo conviene

Usa Web Functions cuando el tráfico sea constante y alto, las peticiones pasen casi todo su tiempo esperando I/O, el código sea Node.js y la función clásica que reemplazas necesite mucha memoria.
Quédate en Lambda clásica cuando el tráfico sea bajo o a ráfagas. Si un entorno atiende unas cuantas peticiones por minuto, el piso de memoria es puro gasto extra.
Si estás en contenedores, revisa la puerta de entrada antes que el cómputo. Un servicio pequeño detrás de un ALB puede pagar más por el balanceador que por la tarea.

Endurecer servidores mcp stdio

Franchesco Romero — Sat, 24 Oct 2026 19:50:20 +0000

Un servidor de MCP que usa el transporte stdio es una línea de comandos que tu
agente corre como tú. En octubre de 2026 eso dejó de ser abstracto: el
CVE-2026-105740 (CVSS 9.9) de Langflow dejó que cualquier usuario con sesión
registrara un servidor stdio cuyo comando iba directo a bash -c. Este post
recorre el bug, el arreglo que de verdad aguanta, y una auditoría de una máquina
de desarrollo corriendo Claude Code, que sacó una línea de npx apuntando a un
scope de npm que nadie tiene.

El punto de partida: qué hizo Langflow

El advisory (GHSA-7w94-79vh-5mr2) nombra las líneas. La API acepta un
MCPServerConfig con command, args, env, url y headers de cualquier
usuario autenticado. No hay "ninguna allowlist de comandos permitidos, ninguna
blocklist de comandos peligrosos". Después, el comando se arranca así:

args=["-c", f"exec {command_str} || echo 'Command failed...'"]

El dict de env del usuario se mergea en el entorno del hijo. El trigger no es
"corre este servidor": es GET /api/v2/mcp/servers?action_count=true, la petición
que lista los servidores. Afectado: 1.8.3 según el advisory, parchado en 1.9.0;
una nota de triaje también lista 1.10.3, así que 1.10.3 o posterior cubre las dos
lecturas. Los reportes de intentos de explotación desde honeypots están en los
miles bajos; el que tiene una nota de metodología cuenta 2,023 desde el 19 de
septiembre desde un solo sensor.

elchesco / blog-mcp-stdio-hardening-code

Code companion - an MCP stdio server is a shell command: hardening after the Langflow CVE

Code companion: an MCP stdio server is a shell command

Folder	Post section	What it is
`00-the-bug/`	Round 0: the bug	`vulnerable_spawn.py`: the CVE-2026-105740 pattern reduced to its two lines, with harmless payloads. Kept as a DEAD END on purpose.
`01-safe-spawn/`	Round 1: the fix	`safe_spawn.py`: server IDs mapped to pinned argv, no shell, env from an allowlist.
`02-audit-your-machine/`	Round 2: measure	`mcp_audit.py`: every MCP server your agents will start, flagged STDIO / UNPINNED / AUTO-YES / NOT-FOUND / ENV / PLAIN-HTTP.
`03-managed-policy/`	Round 3: fleet policy	Claude Code managed settings: exact `serverCommand` allowlist, locked to managed scope.
`04-aws-tool-role/`	Round 4: identity	IAM role for a tool that runs on AWS: one log group, explicit denies, confused-deputy-safe trust policy.
`05-checklist/`	Round 5	What to check on your machine today, and what a platform must enforce.

Ronda 0: el bug, reducido

00-the-bug/vulnerable_spawn.py guarda solo las dos líneas que importan y corre
payloads inofensivos:

1: mcp-server-started
2: mcp-server-started
3: mcp-server-started substitution-ran-before-exec
4: not node: PATH from the env field won

Tres detalles no obvios:

La línea 2 parece una mitigación y no lo es. exec reemplaza el shell con el primer programa, así que el ; echo chained nunca corre. La sustitución de comandos sí, porque el shell expande $(...) antes de exec (línea 3).
El campo env es su propia inyección. La línea 4 pide node --version y obtiene un binario distinto, porque PATH vino de la petición. LD_PRELOAD hace lo mismo para cualquier programa enlazado dinámicamente en Linux.
Nada de eso importa mucho. El campo command acepta cualquier programa. Un parser perfecto que rechace $(...) de todos modos corre curl ... | sh si el usuario lo tecleó como el comando. El bug es que un usuario define qué corre, no cómo se parsea el string.

Ronda 1: el arreglo que aguanta

01-safe-spawn/safe_spawn.py:

REGISTRY: dict[str, ServerSpec] = {
    "playwright": ServerSpec(argv=("/usr/local/bin/playwright-mcp", "--headless")),
    "echo-demo": ServerSpec(argv=("/bin/echo", "mcp-server-started")),
}

def start_stdio_server(server_id: str, user_args: list[str] | None = None) -> str:
    spec = REGISTRY.get(server_id)
    if spec is None:
        raise NotAllowed(f"unknown MCP server id: {server_id!r}")
    if user_args:
        raise NotAllowed("arguments are part of the reviewed spec, not the request")
    ...
    out = subprocess.run(list(spec.argv), env=child_env(spec), shell=False, ...)

1: mcp-server-started
refused: unknown MCP server id: "bash -c 'echo pwned'"
refused: arguments are part of the reviewed spec, not the request
refused: binary not installed: /usr/local/bin/playwright-mcp

Las reglas, en orden de cuánto compran:

Los usuarios escogen un ID. Nunca mandan un comando.
Cada ID mapea a un argv exacto que se revisa como una dependencia, con una versión fijada instalada en tiempo de build de la imagen. Nada se jala al arrancar.
Sin shell.
El entorno del hijo se construye desde una allowlist (HOME, LANG, TZ, un PATH fijo) más los valores que un admin puso. El entorno del que llama nunca se mergea con datos de la petición.
Agregar un ID es un cambio de admin con un registro de auditoría. En Langflow, la config persistía en los settings del proyecto que las revisiones de flow no miraban.

Ronda 2: mide tu propia máquina

El mismo riesgo existe sin un servidor vulnerable. Un agente de código lee las
definiciones de servidor stdio de los archivos de config y las arranca como tú.
02-audit-your-machine/mcp_audit.py lista cada servidor de las ubicaciones
usuales (los scopes user y local de ~/.claude.json, el .mcp.json del proyecto,
Kiro, Cursor, Claude Desktop) y marca lo que encuentra. Lee nada más, más una
petición HEAD por paquete al registry de npm o PyPI.

En la máquina que usé para escribir este post:

~/.claude.json (local scope: ~/projects)
  playright            npx @playwrigth/mcp@latest                                   STDIO UNPINNED NOT-FOUND(npm:@playwrigth/mcp)
~/.claude.json (local scope: ~/projects/myapp)
  playright            npx @playwrigth/mcp@latest                                   STDIO UNPINNED NOT-FOUND(npm:@playwrigth/mcp)

2 servers, 2 stdio, 2 with a finding beyond STDIO

playwrigth es un typo, y el scope de npm no existe.

$ curl -s -o /dev/null -w '%{http_code}\n' https://registry.npmjs.org/@playwrigth/mcp
404
$ curl -s https://registry.npmjs.org/-/org/playwrigth/package
{"error":"Scope not found"}

Cualquiera puede crear la org playwrigth en npm y publicar @playwrigth/mcp. Los
servidores de scope local se cargan cuando una sesión arranca en ese directorio, y
@latest significa que el siguiente arranque resuelve lo que sea que se haya
publicado al último. El servidor nunca funcionó, así que nadie lo notó: una conexión
de MCP fallida es una línea en /mcp, no un error que detenga el trabajo.

Dos detalles no obvios:

El lookup del registry es lo que lo encontró. Sin él, la línea se lee como un servidor de Playwright normal. El flag NOT-FOUND de la auditoría existe para este caso: un typo, un scope sin reclamar, o un paquete que se despublicó.
La aprobación del .mcp.json del proyecto no es una respuesta completa. Claude Code pregunta antes de usar servidores de scope de proyecto en sesiones interactivas, e ignora las aprobaciones que un repositorio clonado se commitea a sí mismo. En claude -p, las sesiones del Agent SDK y algunas sesiones de nube, "carga los servidores de scope de proyecto sin preguntar". El scope local, donde vivía este typo, es la propia config del usuario, así que no hay paso de aprobación en absoluto.

El arreglo es un comando por directorio afectado:

claude mcp remove playright
claude mcp add playwright -- npx -y @playwright/mcp@0.0.83

Ronda 3: política para una flota

Un desarrollador puede arreglar un typo. Un equipo necesita la política para hacer
el typo inerte. Claude Code lee allowedMcpServers y deniedMcpServers de los
managed settings (03-managed-policy/managed-settings.json):

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverUrl": "https://mcp.example.com/*" },
    { "serverCommand": ["npx", "-y", "@playwright/mcp@0.0.83"] }
  ],
  "deniedMcpServers": [
    { "serverCommand": ["npx", "@playwright/mcp@latest"] },
    { "serverUrl": "http://*" }
  ]
}

Con una entrada de serverCommand presente, cada servidor stdio debe empatar un
comando listado exactamente, cada argumento en orden. La línea con el typo no
empata, así que no se carga.

Tres detalles no obvios de los docs:

serverName no es un control de seguridad. Es la etiqueta tecleada en claude mcp add. Cualquiera puede nombrar cualquier servidor github. Usa serverCommand y serverUrl.
serverCommand no compara env. Los docs lo dicen directo: "Algunas variables de entorno cambian lo que node carga al arrancar". Ese es el problema de LD_PRELOAD de Langflow en otro producto. Si el env importa, define el servidor en managed-mcp.json, donde el admin también pone su env.
Sin allowManagedMcpServersOnly, los usuarios ensanchan la lista. Las allowlists se mergean de cada scope, incluyendo ~/.claude/settings.json. Las denylists siempre se mergean, y un deny siempre gana.

Ronda 4: la identidad como la que corre una herramienta

En una laptop, un servidor stdio hereda todo lo que el desarrollador tiene:
~/.aws, el keychain, el SSH agent, el historial de shell. En una plataforma, el
mismo servidor debería ser un servicio remoto con su propia identidad. Ese es el
argumento más fuerte para los transportes remotos: un servidor HTTP corre en su
propio proceso, como su propio rol, detrás de una auth que se puede revocar sin
tocar la laptop de nadie.

04-aws-tool-role/ es la forma de AWS de eso:

Leer un log group, leer métricas, nada más.
Deny explícito sobre iam:*, sts:AssumeRole, secretsmanager:GetSecretValue, ssm:GetParameter* y kms:Decrypt, para que un Allow amplio agregado después no lo pueda ensanchar.
Una trust policy que solo deja a las tareas de ECS en esta cuenta asumir el rol (aws:SourceAccount + aws:SourceArn).

Detalle no obvio: cloudwatch:GetMetricData no tiene scoping a nivel de recurso. Si
los nombres de las métricas son sensibles, la respuesta es una cuenta separada, no
un statement más listo.

Lo que el rol no resuelve es el egreso. Una herramienta de solo-lectura que puede
llamar a cualquier URL puede mandar lo que leyó a cualquier lado. Córrela donde las
únicas rutas sean los endpoints de AWS que necesita.

Cómo se ven los buenos defaults

Azure MCP Server 3.0 pasó a estable la misma semana. Es una referencia útil para
defaults, independiente de la nube:

Modo --read-only, que también excluye las herramientas de envío de email y SMS.
Filtrado con --tool que "empata los nombres expuestos exactamente, ignorando mayúsculas".
Validación de endpoint anti-SSRF extendida a más endpoints de data-plane y de control-plane.
Sus herramientas de query de PostgreSQL y MySQL ahora están marcadas como "destructivas, no-idempotentes, y no-de-solo-lectura", y el filtrado por verbo de SQL se quitó. La guía es permisos de base de datos de menor privilegio en lugar de tratar de filtrar el texto de SQL.

El último punto es la misma lección que la Ronda 0 desde el otro lado: no trates de
hacer segura una primitiva poderosa parseando su input. Dale una identidad que no
pueda hacer la cosa peligrosa.

Lecciones

Mide tu propia config antes de leer sobre el CVE de alguien más. La auditoría encontró un paquete reclamable en la máquina que escribió este post.
La definición de un servidor stdio es código. Revísala, fíjala, y decide quién la puede escribir, de la manera en que lo harías para un workflow de CI.
No te parsees para salir de la ejecución de comandos. Quita la capacidad del usuario de escoger el comando.
Las variables de entorno son inputs. PATH, LD_PRELOAD y NODE_OPTIONS deciden qué corre tanto como el comando lo hace.
La falla silenciosa es una superficie de ataque. Un servidor que nunca conectó por meses es un nombre que nadie está vigilando.
La identidad y el egreso son la frontera real. Los flags de solo-lectura y los filtros de herramientas ayudan; un rol que no puede hacer la cosa peligrosa es lo que aguanta.

Auditar un pipeline de IaC después del provider de Terraform troyanizado

Franchesco Romero — Sat, 24 Oct 2026 01:29:50 +0000

El 8 de octubre, Zscaler ThreatLabz describió un provider de Terraform que se
comporta exactamente como un provider normal de AWS y también, en el momento en
que Terraform lo carga, jala un loader de un dominio parecido e instala un robador
de credenciales (reporte).

Este stack no usa Terraform. Usa AWS CDK, desplegado desde GitHub Actions sobre
runners ARM autoalojados. La pregunta de todos modos aplica: si un paquete en el
toolchain de infraestructura se volviera hostil mañana, ¿qué obtendría? Este post
es la auditoría que respondió esa pregunta, con los comandos, su salida, y los
arreglos rankeados por palanca. La mayoría todavía no están hechos.

Qué es un provider troyanizado, en términos de CDK

Un provider de Terraform es un binario que corre con las credenciales de nube que
sean que estén en su entorno. En CDK el equivalente es cada paquete en
infra/node_modules: cdk synth ejecuta tu app, tu app importa aws-cdk-lib y
cualquier otra cosa que instalaste, y todo eso corre como un solo proceso de Node.
El provider de Zscaler se disparaba al cargar. Un paquete de npm malicioso se puede
disparar al instalar (lifecycle scripts) o al importar (código de nivel superior).
Al importar basta aquí, porque el synth importa todo.

Así que la pregunta de la auditoría es: ¿qué credenciales y acceso de red existen
en el proceso que corre npm ci y cdk synth?

El punto de partida

El job de deploy:

- name: AWS credentials (OIDC)
  if: env.DEPLOY_ROLE_ARN != ''
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ env.DEPLOY_ROLE_ARN }}
    aws-region: ${{ env.AWS_REGION }}

- name: AWS credentials (legacy static keys)
  if: env.DEPLOY_ROLE_ARN == ''
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: ${{ env.AWS_REGION }}

# ... setup-node ...

- name: Deploy infra
  run: |
    cd infra
    npm ci
    npx cdk deploy MyApp-Backend --require-approval never --progress events

El orden importa: las credenciales se ponen primero, luego npm ci y luego el
synth corren dentro del mismo entorno.

Hallazgo 1: el rol de OIDC que nadie asume

El repo tiene un rol de OIDC, con alcance a main y al entorno production, con
una sesión de una hora. El workflow lo prefiere. Luego:

gh secret list

AWS_ACCESS_KEY_ID   2026-04-06
AWS_SECRET_ACCESS_KEY   2026-04-06
...

No hay un AWS_DEPLOY_ROLE_ARN, así que el if: siempre toma la rama de llaves
estáticas.

aws iam list-access-keys --user-name myapp-ci
aws iam get-access-key-last-used --access-key-id "$KEY_ID"

{ "Status": "Active", "CreateDate": "2026-04-06T04:03:15+00:00" }
{ "LastUsedDate": "2026-10-15T22:46:00+00:00", "ServiceName": "autoscaling" }

El camino seguro se escribió, se mergeó y se desplegó, y nada lo usa. Es fácil
ver cómo pasa eso. La migración estaba bloqueada por una restricción real: el rol
de OIDC todavía no cargaba cada permiso que los workflows de frontend, intelligence
y security-scan necesitan. Mientras tanto, cada grant nuevo fue a las dos
identidades hasta que el usuario pegó contra un techo fácil de pasar por alto:

Maximum policy size of 2048 bytes exceeded for user myapp-ci

Ese límite de 2048 bytes aplica a la suma de todas las inline policies de un
usuario, no a cada una. El usuario de CI estaba en 1943 bytes (95%) cuando falló.
El workaround fue una managed policy. El arreglo es terminar la migración, que quita
al usuario y su límite juntos.

Una llave estática así de vieja es lo que un robador de credenciales está buscando.
El payload en el reporte de Zscaler es un backdoor multiplataforma con robadores de
datos. En un runner, la llave se sienta en el entorno de cada proceso que el job de
deploy arranca.

Hallazgo 2: el install y el synth corren con credenciales de deploy

Las credenciales tienen alcance, pero solo en el papel. El grant de CDK de la
identidad de CI es nada más sts:AssumeRole sobre los roles de bootstrap:

actions: ["sts:AssumeRole", "sts:TagSession"],
resources: [`arn:aws:iam::${account}:role/cdk-hnb659fds-*-${account}-${region}`],

Uno de esos roles es el deploy role, que le entrega a CloudFormation el execution
role:

aws iam list-attached-role-policies \
  --role-name cdk-hnb659fds-cfn-exec-role-ACCOUNT-us-east-1 --output text

ATTACHEDPOLICIES    arn:aws:iam::aws:policy/AdministratorAccess AdministratorAccess

Ese es el default de cdk bootstrap. Cualquier código que corra en el paso de
deploy puede desplegar un stack de CloudFormation, y ese stack puede crear un
usuario de IAM con derechos de admin. La cadena es: npm ci o cdk synth →
credenciales del entorno → sts:AssumeRole sobre cdk-*-deploy-role →
CloudFormation → AdministratorAccess.

Lo que limita el radio de impacto hoy:

python3 -c "
import json; p = json.load(open('package-lock.json'))['packages']
print('packages', len(p) - 1)
print('install scripts', [k for k, v in p.items() if v.get('hasInstallScript')])
print('bundled', sum(1 for v in p.values() if v.get('inBundle')))
print('integrity missing', sum(1 for k, v in p.items() if k and not v.get('integrity') and not v.get('inBundle')))"

packages 49
install scripts []
bundled 20
integrity missing 0

49 paquetes, ninguno con install scripts, todos fijados por hash de integridad. Esa
es una superficie chica y verificable. Es suerte más que política, sin embargo:
nada detiene que el paquete 50 agregue un postinstall, y nada detendría que
código de nivel superior en cualquiera de los 49 corra en el synth.

El arreglo es dividir el job. El synth no necesita credenciales cuando los lookups
de contexto están cacheados en el cdk.context.json commiteado (este repo ya hace
eso para sus llamadas de HostedZone.fromLookup y Vpc.fromLookup). Así que:

Job synth: sin credenciales de AWS, npm ci --ignore-scripts, cdk synth, sube cdk.out.
Job deploy: descarga cdk.out, asume el rol de OIDC, corre cdk deploy --app cdk.out. Sin npm ci y sin código de app.

El job de deploy todavía corre la CLI de CDK, que es un paquete. Esa es la misma
confianza que le pones a terraform mismo, y mucho menos que "cada paquete en el
lockfile". El workflow está en la carpeta de código.

Hallazgo 3: un lockfile prueba igualdad, no seguridad

Tres alertas de Dependabot sobre brace-expansion en infra/ no las puede
arreglar este repo. La copia vulnerable viene dentro del tarball de aws-cdk-lib
como una de sus 20 dependencias bundleadas:

node_modules/aws-cdk-lib/node_modules/brace-expansion   "inBundle": true

Una entrada de overrides la deja sin cambios, y npm audit fix reporta un
arreglo que nunca aplica. El hash de integridad del lockfile cubre el tarball de
aws-cdk-lib, lo que significa que cubre la copia bundleada también, byte por
byte. Esa es la misma garantía que .terraform.lock.hcl da para un provider:
obtienes los bytes que obtuviste la vez pasada. El hash checa que los bytes no
cambiaron. No dice nada sobre si eran seguros. Si la primera descarga estuvo mal, el
lockfile fija los bytes malos.

Los controles de Terraform del escrito de Zscaler (checksums, lockfiles) son
necesarios, y solo llegan hasta ahí. Lo que de verdad reduce la exposición es una
allowlist corta de fuentes (un registry privado o un network mirror para los
providers, onlyBuiltDependencies para los build scripts de npm) más los hallazgos
2 y 4: limitar qué puede alcanzar el código una vez que corre.

Hallazgo 4: un runner de larga vida con derechos de deploy, corriendo código de PR

Los runners son autoalojados, de larga vida, y su instance profile espeja el deploy
role:

// Espeja los permisos de deploy del rol de OIDC para que los jobs se comporten
// idénticos en el runner nuevo.
instanceRole.addToPolicy(new iam.PolicyStatement({ sid: "ECRPushPull", /* ... */ }));
instanceRole.addToPolicy(new iam.PolicyStatement({ sid: "ECSDeploy", /* ... */ }));
instanceRole.addToPolicy(new iam.PolicyStatement({ sid: "PassECSRoles", /* ... */ }));
instanceRole.addToPolicy(new iam.PolicyStatement({ sid: "S3SyncSpaAndMarketing", /* ... */ }));

Los jobs corren directo en el host, así que cualquier proceso en cualquier job
puede obtener esas credenciales del instance metadata service. Un hop limit de 1 no
ayuda, porque el job no está en un contenedor. El CI de pull request corre en el
mismo pool:

gh api repos/acme/myapp/actions/runs/$CI_RUN/jobs \
  --jq '.jobs[]|[.name,.runner_name,.conclusion]|@tsv'

changes myapp-runner-eded276f1-1    success
frontend    myapp-runner-eded276f1-1    success
frontend-time-travel    myapp-runner-eded276f1-2    success

Esa corrida era un PR de Dependabot subiendo katex. El job frontend corrió
pnpm install --frozen-lockfile con el paquete subido, en una caja con push a ECR,
deploy a ECS y escritura a S3 sobre el bucket de la SPA de producción, a una
petición de metadata de distancia.

GitHub retiene los secretos del repositorio de las corridas disparadas por
Dependabot. Eso se puede ver en el mismo PR, donde el job que despierta el pool de
runners falló porque no tenía credenciales:

{"conclusion":"failure","labels":["ubuntu-latest"],"name":"wake"}

Los jobs de CI corrieron de todos modos, porque otro workflow ya había despertado
el pool. GitHub retuvo los secretos correctamente. El instance profile no es un
secreto, así que nunca se retuvo. La subida de katex era benigna. El camino
estaba abierto.

Dos mitigaciones ya ayudan. pnpm 10 no corre ningún build script de dependencia a
menos que estén en allowlist, y la allowlist tiene tres entradas:

"pnpm": { "onlyBuiltDependencies": ["esbuild", "protobufjs", "@sentry/cli"] }

El pool también escala a cero entre workflows, así que un compromiso no persiste por
mucho. Ninguno de los dos cambios afecta lo que el código puede hacer al importar
durante la corrida de pruebas.

El arreglo: quítale los permisos de deploy al instance profile, para que solo pueda
leer el token de registro del runner, y deja que los jobs de deploy obtengan
credenciales a través de OIDC por job. Entonces un job de PR en la misma caja no
obtiene nada del metadata service que importe. Por separado, los runners
--ephemeral se aseguran de que las sobras de un job no puedan alcanzar las
credenciales del siguiente job.

Hallazgo 5: nadie lo vería

aws guardduty list-detectors

{ "DetectorIds": [] }

Para la detección, el reporte de Zscaler recomienda vigilar actividad de proceso
inesperada en las estaciones de trabajo de los desarrolladores y los sistemas de
CI/CD. En esta cuenta, nada vigila los runners ni las llamadas de API que vienen de
ellos. Una llave de CI robada usada desde otra IP se vería como la llave de CI.

La señal más barata sin servicios nuevos: la llave estática solo se usa desde las
IPs públicas del pool de runners. Una query de CloudTrail Lake o un script de
lookup-events que marque cualquier llamada de myapp-ci desde una dirección fuera
del pool atrapa el caso de la llave robada. Script en la carpeta de código. Los
hallazgos de EC2 e IAM de GuardDuty cubren más terreno. Ponle precio para tu cuenta
antes de habilitarlo.

Para lectores de Terraform y OpenTofu

No probado en este stack, porque no tiene Terraform. Estos son los equivalentes de
los controles de arriba.

Restringe de dónde pueden venir los providers, en la config de la CLI
(~/.terraformrc, o TF_CLI_CONFIG_FILE en CI):

provider_installation {
  network_mirror {
    url     = "https://terraform-mirror.example.com/providers/"
    include = ["registry.terraform.io/hashicorp/*"]
  }
  direct {
    exclude = ["registry.terraform.io/*/*"]
  }
}

Commitea el lockfile con hashes para cada plataforma que corre init, y falla el CI
si init lo cambiaría:

terraform providers lock -platform=linux_arm64 -platform=linux_amd64 -platform=darwin_arm64
terraform init -lockfile=readonly

Corre plan con credenciales que pueden leer pero no escribir, y corre apply en
un job separado con el rol de OIDC, como en el hallazgo 2. Un provider llamado
awsbeta debería fallar una revisión de required_providers de inmediato. La
config del mirror de arriba hace que falle al instalar.

Lecciones

Audita el proceso, no el paquete. "¿Este paquete es malicioso?" no se puede responder. "¿Qué credenciales existen en el proceso que lo corre?" sí, y la respuesta decide el radio de impacto.
Un camino seguro que nadie toma no es un control. El rol de OIDC pasó la revisión, se desplegó limpio, y no autenticó nada por meses. Checa qué corrió de verdad: get-access-key-last-used y gh secret list.
Los lockfiles prueban igualdad, no seguridad. Son la herramienta correcta para "¿cambiaron los bytes?". Usa otra cosa para "¿deberían correr estos bytes?".
El instance metadata es un secreto que ningún almacén de secretos retiene. Cualquier cosa que retiene secretos de las corridas no confiables (Dependabot, forks) se salta el instance profile.
El default del bootstrap es admin. Los pipelines de CDK y de Terraform los dos tienden a terminar en un rol que puede hacer cualquier cosa. Saber dónde termina el tuyo antes de decidir cuánto importan los eslabones anteriores.

Auditar agentes como identidades

Franchesco Romero — Sat, 24 Oct 2026 01:13:15 +0000

Los agentes de IA son identidades no humanas. Algunos los despliegas tú mismo, y otros llegan con herramientas que ya usas.

Dos tipos de agente

Los agentes elegidos son los que están en tus diagramas: tú creaste el rol,
así que en principio le pusiste alcance. Los agentes heredados llegaron con
una funcionalidad de un proveedor. GitHub trae Dependabot, tu issue tracker trae
un summarizer, tu buzón recibe un asistente que conectaste en treinta segundos.
Nadie escribió un rol para ellos, porque su acceso es un grant de OAuth o una
instalación de GitHub App, no una policy de IAM.

Los dos tipos tienen una identidad, un conjunto de permisos, un camino de red
hacia las cosas, y actividad que podrías o no loguear. La revisión es la misma de
cualquier forma. Los agentes heredados nada más son más fáciles de olvidar,
porque ningún código de infraestructura los menciona.

Este post lo propuso un agente programado que lee un buzón a través de un conector
OAuth. Ese conector tiene más alcance hacia datos personales que cualquier cosa en
la cuenta de producción. Pertenece al mismo inventario.

La pregunta cara: qué pueden alcanzar los agentes

Los agentes de modelo: con alcance a propósito

El rol del intelligence service lista los ARNs de modelo exactos que puede
invocar:

// Restringir a los ARNs de modelo que de verdad usamos para que una tarea
// comprometida no pueda invocar modelos caros de escala Sonnet.
const bedrockModelArns = [
  `arn:aws:bedrock:${region}::foundation-model/amazon.nova-micro-v1:0`,
  `arn:aws:bedrock:${region}::foundation-model/amazon.nova-lite-v1:0`,
  `arn:aws:bedrock:${region}::foundation-model/amazon.nova-pro-v1:0`,
  `arn:aws:bedrock:${region}::foundation-model/amazon.titan-embed-text-v2:0`,
  "arn:aws:bedrock:us-west-2::foundation-model/stability.stable-image-core-v1:1",
  "arn:aws:bedrock:us-west-2::foundation-model/stability.stable-image-ultra-v1:1",
];

El backend, que también genera imágenes, no:

actions: ["bedrock:InvokeModel"],
resources: ["arn:aws:bedrock:*::foundation-model/stability.*"],

El wildcard fue deliberado: los modelos de imagen de Bedrock pasaron a Legacy tres
veces seguidas (Nova Canvas, Titan v2, SDXL), y cada una significó perseguir un
ARN nuevo. Sigue siendo cada modelo de Stability en cada región. Eso es una
exposición de costo, no una exposición de datos, y una alarma de budget sobre el
atributo de modelo es el control correcto para ello. En este caso la nueva
funcionalidad de Cost Explorer sí ayuda.

Los controles a nivel de prompt para estos agentes (agencia excesiva, inyección,
manejo de output).
Este post es sobre la identidad debajo de ellos.

El agente de código: con alcance en el papel

El grant de secretos dice:

// Solo credenciales de bootstrap. NO los secretos de la app (rds, stripe, jwt...).
new iam.PolicyStatement({
  sid: "ReadBootstrapSecrets",
  actions: ["secretsmanager:GetSecretValue"],
  resources: [
    `arn:aws:secretsmanager:${region}:${account}:secret:/myapp/agent-box-github-token-*`,
    `arn:aws:secretsmanager:${region}:${account}:secret:/myapp/agent-box-claude-credentials-*`,
  ],
}),

La escritura de vuelta es todavía más estrecha: PutSecretValue solo sobre las
credenciales, para que "una sesión desbocada no deba poder sobreescribir"
el token de GitHub. Cada statement es correcto. Más abajo, para depurar prod:

new iam.PolicyStatement({
  sid: "EcsExecAndRead",
  actions: ["ecs:ExecuteCommand", "ecs:DescribeServices", "ecs:DescribeTasks", /* ... */],
  resources: ["*"],
}),
new iam.PolicyStatement({
  sid: "EcsDeploy",
  actions: ["ecs:RegisterTaskDefinition", "ecs:UpdateService", "ecs:RunTask", "ecs:StopTask", "ecs:TagResource"],
  resources: ["*"],
}),

Pregúntale a IAM qué puede hacer el rol, en lugar de leer los statements uno por
uno:

aws iam simulate-principal-policy \
  --policy-source-arn "$AGENT_ROLE_ARN" \
  --action-names ecs:ExecuteCommand ecs:UpdateService ecs:RegisterTaskDefinition \
                 secretsmanager:GetSecretValue iam:PassRole \
  --resource-arns "*" \
  --query 'EvaluationResults[].[EvalActionName,EvalDecision]' --output text

ecs:ExecuteCommand  allowed
ecs:UpdateService   allowed
ecs:RegisterTaskDefinition  allowed
secretsmanager:GetSecretValue   implicitDeny
iam:PassRole    implicitDeny

GetSecretValue sobre * está denegado, que es lo que el comentario prometía.
ExecuteCommand sobre * está permitido, y el contenedor del backend de
producción recibe DB_USER/DB_PASSWORD, JWT_PRIVATE_KEY y STRIPE_SECRET_KEY
inyectados desde Secrets Manager como variables de entorno al arrancar. Un shell en
ese contenedor está a un env de distancia de cada secreto que el comentario dice
que el agente no puede leer. Ese camino se usa a propósito: las queries ad-hoc de
producción corren a través de ECS Exec a la tarea del backend. Es un manual de
operaciones documentado, no un hipotético.

iam:PassRole muestra implicitDeny solo porque la simulación no pasó ningún
contexto de iam:PassedToService. El statement real permite pasar cualquier rol
myapp-* a tareas de ECS, y junto con RegisterTaskDefinition y UpdateService
eso significa: correr cualquier imagen, bajo cualquier task role de app, como un
servicio de producción.

Los secretos tenían alcance. El alcance del agente no. El grant de secretos
responde "cuáles secretos puede leer a través de la API de secretos". El alcance es
la unión de cada camino hacia los datos, y aquí el camino más corto pasó por el
contenedor.

El agente que agregarías al pipeline

AWS Continuum for Penetration Testing (antes AWS Security Agent) entró a public
preview el 5 de octubre como un paso en tiempo de deploy: hallazgos en la salida
del pipeline, re-test automático después de un arreglo
(anuncio).
El anuncio no lista los permisos que necesita. Lee
la guía de CI/CD antes de implementarlo.

Lo que el anuncio sí deja claro es la colocación: el paso de deploy. En este stack,
la identidad del job de deploy puede desplegar infraestructura a través de la
cadena de bootstrap de CDK, que termina en AdministratorAccess. Pega un snippet de un proveedor en ese job
y el agente nuevo lo hereda todo, a través del entorno, sin que nadie escriba una
policy. Dale su propio job, su propio rol, y nada en su entorno que el snippet no
necesite. Un pentester necesita alcanzar la URL objetivo. No necesita tus
credenciales de deploy.

Una revisión para cada agente

Cuatro preguntas, en el mismo orden para agentes elegidos y heredados:

Identidad. ¿Cuál principal es? ¿Un rol de IAM, un grant de OAuth, una GitHub App, un PAT? ¿Quién lo tiene, y cuándo expira su credencial? Un refresh token de OAuth que se muere del lado del servidor se lleva al agente con él, y solo un login humano lo puede traer de vuelta. El post de la parte 2 sobre la caja cubre cómo se ve eso.
Permisos. Corre simulate-principal-policy contra las acciones que importan, en lugar de leer statements. Los comentarios describen la intención. El simulador describe la policy.
Alcance. Para cada activo sensible, lista cada camino hacia él, no solo la API obvia. Los secretos alcanzan un proceso a través de la API de secretos, las variables de entorno, un shell en un contenedor que los contiene, el instance metadata service, un paso de CI que los imprime.
Actividad. ¿Puedes distinguir sus llamadas de las de un humano? CloudTrail muestra el nombre de la sesión del rol. Nombra las sesiones, y para los conectores de OAuth checa qué loguea el proveedor. El conector del buzón de arriba no deja un rastro que el dueño del buzón pueda consultar.

El costo es la quinta pregunta, y la más barata. Respóndela al final.

Qué ayudaría después

Divide el rol del agente de código por riesgo, no por servicio. Mantén la observabilidad de solo-lectura sobre *. Mueve ecs:ExecuteCommand y las acciones de deploy a un segundo rol que la caja asume bajo demanda con una sesión respaldada por MFA de un humano, o ponle alcance a ExecuteCommand con una condición ecs:cluster a un clúster que no sea de prod. Esto cuesta fricción en cada sesión de debug de prod. Esa fricción es el punto.
Agrega un permission boundary a cada rol de agente. Un boundary no puede otorgar nada, así que es seguro escribirlo de forma amplia: niega iam:* excepto PassRole, niega secretsmanager:* fuera del prefijo del agente, niega ecs:ExecuteCommand sobre prod salvo que un session tag diga que un humano aprobó. Ejemplo en la carpeta de código.
Inventaría los agentes heredados. Lista los grants de OAuth y las apps instaladas por herramienta (GitHub, Google Workspace, el issue tracker, el chat). Esto es una hoja de cálculo, no infraestructura. También es el único paso aquí sin código, que es por lo que sigue sin hacerse.
Fija el ARN del modelo de imagen en el backend, o quédate con el wildcard y ponle un budget al atributo de modelo. Escoge uno y escribe la razón en el comentario.
Corre la simulación de alcance en CI. Una prueba de contrato que falla si cualquier rol de agente nuevamente obtiene ecs:ExecuteCommand, iam:PassRole o secretsmanager:GetSecretValue sobre * atrapa las regresiones que la revisión se pierde.

Checklist

[ ] Cada agente, elegido o heredado, está listado con dueño, tipo de credencial y expiración.
[ ] Cada rol de agente se checó con simulate-principal-policy, no leyendo el JSON.
[ ] Ningún rol de agente tiene ecs:ExecuteCommand, ssm:StartSession o lambda:UpdateFunctionCode sobre producción sin un paso humano.
[ ] Cada rol de agente tiene un permission boundary.
[ ] Las sesiones de los roles de agente están nombradas, para que CloudTrail distinga agente de humano.
[ ] Los agentes de pipeline corren en su propio job, con su propio rol, sin credenciales de deploy en su entorno.
[ ] El gasto de agente se filtra sobre cada valor de SERVICE que vende modelos, no solo Amazon Bedrock.
[ ] Los grants de OAuth a funcionalidades de IA en herramientas SaaS se revisan en agenda.

De $32 a $0.90 al mes: un pool de CI que solo existe cuando hace falta

Franchesco Romero — Sat, 10 Oct 2026 21:31:11 +0000

Un recorrido por el pipeline de CI/CD detrás de un proyecto chico de SPA + API + workers de IA: siete workflows de GitHub Actions, una caja spot ARM64
autoalojada que ahora duerme en cero y se despierta por corrida, un listener que
re-corre los jobs que un reclamo de spot mató, y una segunda pasada de la suite
de frontend con el reloj movido 400 días hacia adelante. Con los números de los
primeros tres días de scale-to-zero, y dos cosas que los logs mostraron y las
pruebas no.

Stack: GitHub Actions, un Auto Scaling Group de EC2 de instancias spot Graviton,
AWS CDK, ECS Fargate (arm64), S3 + CloudFront, pytest, Vitest.

TL;DR

	Pool siempre encendido	Pool scale-to-zero
Horas que la caja está arriba	24/7	2.7% (2h12m de 81h)
Costo del pool (spot + EBS + IPv4)	$32.34/mes	~$0.90/mes (mismas tarifas, escaladas por uptime)
Push al primer job autoalojado	~2 s	1m44s a 3m56s (5 cold starts)
Jobs matados por un reclamo de spot	rojos hasta que alguien re-corre	se re-corren automáticamente, máximo 3 intentos
Bombas de tiempo de pruebas con compuerta de fecha	encontradas el día que explotan	encontradas en el PR que las escribe

La forma

                      pull_request / push a main / cron / dispatch
                                         |
          +------------------------------+-------------------------------+
          |                                                              |
   runner-pool.yml  (ubuntu-latest)                     CI / Deploy * / Security Scan
   despierta: DesiredCapacity=1                          runs-on: self-hosted
          |                                             (los jobs se quedan "queued" hasta
          v                                              que un runner se registra, ~2-4 min)
   ASG lanza 1 caja spot Graviton  -------------------------->  los jobs corren
   el user-data registra 2 runners                                    |
                                                                      v
                                                         workflow_run: completed
                                                                      |
                              +---------------------------------------+------------------+
                              |                                                          |
                runner-pool.yml duerme (ubuntu-latest)              rerun-on-runner-loss.yml (ubuntu-latest)
                DesiredCapacity=0 salvo que otro                    ¿falló + el log dice "shutdown signal"?
                workflow de pool esté queued/en progreso            -> rerun-failed-jobs (máx 3)

Siete workflows. Todo lo que buildea o prueba corre en el pool autoalojado; todo
lo que administra el pool corre en runners hospedados por GitHub:

Workflow	Trigger	Corre en	Qué hace
`ci.yml`	PR hacia `main`	self-hosted	Filtro de rutas, luego los jobs de frontend, frontend-time-travel, backend, intelligence, infra, ci-scripts en paralelo
`deploy-backend.yml`	push a `main` (`backend/`, `infra/`)	self-hosted	lint, 2 shards de pruebas, compuerta de cobertura mergeada, `cdk deploy`, imagen arm64, migraciones, ECS
`deploy-frontend.yml`	push a `main` (`frontend/**`)	self-hosted	Vitest, esperar el deploy de backend del mismo commit, audit, build, S3, invalidar
`deploy-intelligence.yml`	push a `main` (`intelligence/**`)	self-hosted	pruebas, imagen arm64, migraciones, ECS
`security-scan.yml`	domingo 03:00 UTC	self-hosted	Trivy sobre las imágenes más recientes
`runner-pool.yml`	todo lo de arriba, más cron	ubuntu-latest	despertar antes, dormir después
`rerun-on-runner-loss.yml`	`workflow_run: completed`	ubuntu-latest	re-correr los jobs que un reclamo de spot mató

El lado del pool tiene que estar en runners hospedados por GitHub. Un job
self-hosted no puede arrancar el pool que necesita para correr, y no puede
detener el pool en el que está corriendo.

El pool

Un Auto Scaling Group, solo spot, diez tipos de instancia Graviton de 2 vCPU a lo
largo de dos AZs, PRICE_CAPACITY_OPTIMIZED. Cada caja registra dos procesos de
runner, así que una caja corre dos jobs a la vez. MaxSize es 2 para que Capacity
Rebalance pueda lanzar el reemplazo antes de que AWS se lleve la caja vieja de
vuelta.

Hasta la semana pasada era MinSize: 1, DesiredCapacity: 1, sin política de
escalado. Medido a lo largo de las 120 horas previas: 3 horas con CPU por
encima de 10%, media de 1.08%. Una caja inactiva el 97.5% del tiempo, costando
$23.94 de spot, $4.80 de EBS y $3.60 de IPv4 público al mes.

El cambio de CDK son dos líneas y una eliminación:

const asg = new autoscaling.AutoScalingGroup(this, "RunnerAsg", {
  vpc,
  mixedInstancesPolicy: { /* diez tipos Graviton, solo spot */ },
  minCapacity: 0,
  maxCapacity: 2,
  // desiredCapacity deliberadamente NO declarado.
  capacityRebalance: true,
  groupMetrics: [autoscaling.GroupMetrics.all()],
});

Dos detalles no obvios:

desiredCapacity se tiene que ir. CDK advierte que declararlo reinicia el tamaño del grupo en cada deploy (aws/aws-cdk#5215). Con el tamaño ahora manejado desde fuera de CDK, un cdk deploy corriendo dentro del deploy de backend le arrancaría la caja de debajo al job que está corriendo ese mismísimo deploy. Omitido, CloudFormation lo pone en la creación y lo deja en paz después.
El volumen de EBS es deleteOnTermination. Dormir el pool termina la instancia, lo que se lleva las horas de spot, el volumen y el IPv4 público con ella. Detener en lugar de terminar seguiría pagando por el volumen.

Despertar y dormir sin tocar los otros workflows

El diseño obvio es un job wake arriba de cada workflow y una arista needs: wake
en cada job autoalojado. Eso son ocho archivos y docenas de aristas needs:, y una
arista equivocada rompe un deploy. En su lugar, un workflow separado dispara con
los mismos eventos:

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]
  workflow_dispatch:
  schedule:
    - cron: "50 2 * * 0"     # 10 min antes del security scan del domingo
    - cron: "*/30 * * * *"   # barredor
  workflow_run:
    workflows: [CI, Deploy Backend, Deploy Frontend, Deploy Intelligence, Deploy Marketing, Security Scan]
    types: [completed]

concurrency:
  group: runner-pool
  cancel-in-progress: false

Corre en paralelo con el workflow real. Los jobs autoalojados empiezan queued, y
GitHub retiene un job en cola hasta que un runner con labels que empatan se
registra. La cola es la sincronización. Ningún archivo de workflow fuera de este
sabe que el pool puede dormir.

El trigger de push a propósito no tiene filtros de ruta. Un push de solo-docs
despierta la caja para nada; el lado de dormir limpia eso.

wake pone DesiredCapacity=1. sleep lo pone en 0, pero solo si nada más
necesita la caja:

def cmd_sleep(asg, repo, run_id, *, dry_run):
    if any_runner_busy(repo):
        print("A runner is still busy; leaving the pool up.")
        return 0

    others = other_active_runs(repo, run_id)
    if others:
        print("Other runs still need the pool, leaving it up:")
        for name in others:
            print(f"  - {name}")
        return 0

    set_desired(asg, 0, dry_run=dry_run)
    return 0

La asimetría es deliberada. Un scale-down perdido cuesta centavos y el dormir de
la siguiente corrida lo recoge. Un scale-down equivocado mata un deploy a media
migración, que es la falla exacta que el pool ya sufre por los reclamos de spot.

El mismo razonamiento para los errores: cada camino en runner_pool.py regresa 0.
Un despertar que no puede alcanzar AWS deja los jobs en cola, lo cual es visible y
recuperable. Un workflow de pool en rojo en cada PR no es ninguna de las dos.

Esa regla se aprendió en el PR que la introdujo. El paso que resuelve el nombre del
ASG corría bajo bash -e, y el grant de IAM que necesitaba estaba en el mismo PR,
así que DescribeAutoScalingGroups regresó AccessDenied y el PR se puso en rojo. El
arreglo es un if ! alrededor de la llamada:

if ! name=$(aws autoscaling describe-auto-scaling-groups \
  --query "AutoScalingGroups[?Tags[?Key=='Name' && Value=='${RUNNER_ASG_TAG}']].AutoScalingGroupName | [0]" \
  --output text 2>&1); then
  echo "::warning::could not resolve the runner ASG, leaving the pool alone: ${name}"
  name=""
fi

El nombre del ASG se resuelve por tag, no hardcodeado. CloudFormation lo genera y
cambia si el construct alguna vez se reemplaza.

Cómo se ve en el log de escalado

2026-10-10T21:04:51  Successful  Launching a new EC2 instance: i-058255690229cf59c
2026-10-10T00:47:25  Successful  Terminating EC2 instance: i-0327f991f9094b5b1
2026-10-10T00:16:22  Successful  Launching a new EC2 instance: i-0327f991f9094b5b1
2026-10-07T20:32:53  Successful  Terminating EC2 instance: i-0d799f051fa663669
2026-10-07T20:12:34  Successful  Launching a new EC2 instance: i-0d799f051fa663669
2026-10-07T14:19:47  Successful  Terminating EC2 instance: i-0d92076be33dcc045
2026-10-07T14:01:02  Successful  Launching a new EC2 instance: i-0d92076be33dcc045

Siete sesiones en 81 horas, de 3 a 31 minutos cada una, 2h12m en total. El script
que las suma está en la carpeta de código (04-measure/pool_uptime.py). Lee
describe-scaling-activities, empareja cada lanzamiento con su terminación, y
cuenta una sesión todavía abierta hasta ahora.

El precio es el cold start. Antes, el primer job autoalojado arrancaba como 2
segundos después de que la corrida se creaba. Ahora:

Corrida	Creada	Primer job autoalojado	Espera
Deploy Backend	14:00:40	14:04:16	3m36s
Deploy Backend	20:12:13	20:15:51	3m38s
Deploy Frontend	00:16:53	00:18:37	1m44s
Deploy Backend	00:16:53	00:19:43	2m50s
CI	21:04:21	21:08:17	3m56s

Tres minutos por corrida en frío, contra un deploy de backend que toma mucho más
que eso. Las corridas pegadas una tras otra aterrizan en la caja caliente y no
pagan nada.

CI en un pull request

ci.yml es solo chequeos: sin credenciales de AWS, sin deploy. Un job de
dorny/paths-filter decide qué áreas cambiaron, y cada job de área tiene compuerta
en su propio output, así que un PR de solo-frontend nunca arranca el servicio de
PostgreSQL del backend. Las corridas de PR se cancelan en vuelo cuando el autor
empuja de nuevo; las corridas de deploy nunca lo hacen, porque un deploy a medias
es peor que uno lento.

El job ci-scripts es el que la mayoría de los pipelines no tienen. Los scripts
que reparan el propio CI (rerun_on_runner_loss.py, runner_pool.py) tienen
pruebas de contrato que stubbean gh y aws en el PATH, y corren cuando esos
scripts o sus workflows cambian. El filtro de rutas incluye el propio
runner-pool.yml, porque la lista de workflow_run ahí tiene que empatar con
POOL_WORKFLOWS en el script, y editar solo el YAML es justo el drift que la
prueba existe para atrapar.

El reloj 400 días adelante

Cuatro veces en unas semanas, main se puso en rojo en un commit que no tocaba
nada relacionado. Cada vez era una prueba con un fixture como
closes_at: "2026-10-01" afirmando la rama de "todavía abierto". Pasaba en el PR
que lo escribía, luego fallaba en cada corrida desde la mañana en que esa fecha
llegaba en la vida real.

El arreglo a nivel de prueba es fijar el reloj (vi.spyOn(Date, "now").mockReturnValue(...))
a un instante entre las dos ramas. El arreglo a nivel de pipeline es hacer que la
siguiente falle ahora, no en un año. src/test/setup.ts:

const timeTravelMs = Number(process.env.TIME_TRAVEL_DAYS || 0) * 86_400_000
if (timeTravelMs) {
  const RealDate = Date
  const realNow = RealDate.now.bind(RealDate)
  class ShiftedDate extends RealDate {
    constructor(...args: ConstructorParameters<typeof Date> | []) {
      if (args.length === 0) super(realNow() + timeTravelMs)
      else super(...(args as ConstructorParameters<typeof Date>))
    }
    static now() {
      return realNow() + timeTravelMs
    }
  }
  globalThis.Date = ShiftedDate as DateConstructor
}

Y un segundo job de CI, corriendo en paralelo con la suite normal:

frontend-time-travel:
  needs: changes
  if: needs.changes.outputs.frontend == 'true'
  runs-on: self-hosted
  steps:
    # checkout, pnpm, node, install
    - name: Vitest (clock 400 days ahead)
      env:
        TIME_TRAVEL_DAYS: "400"
      run: cd frontend && pnpm exec vitest run

Dos detalles no obvios:

Solo el new Date() sin argumentos y Date.now() se mueven. new Date("2026-10-01") sigue parseando a ese instante. Así que las fechas de fixture se quedan fijas y "ahora" se mueve más allá de ellas, que es la situación exacta que rompe una prueba con compuerta de fecha.
Una prueba que fija su propio reloj anula el movimiento y es inmune. Esa es la presión buscada: la única manera de poner en verde el job de time-travel en una prueba con compuerta de fecha es escribirla de la manera permanente.

Jobs separados en lugar de un paso secuencial, para que una palomita en rojo diga
de qué tipo de falla se trata: una regresión, o una bomba de fecha. En local:
TIME_TRAVEL_DAYS=400 pnpm test:run, y 1095 para un horizonte más largo.

Deploys en push a main

Cada workflow de deploy tiene un filtro de rutas, un grupo de concurrency con
cancel-in-progress: false, y un input runner que cae por default en
self-hosted.

Backend: ruff, basedpyright y pip-audit primero, luego dos shards de pytest divididos por duraciones registradas, luego un job que mergea los dos archivos .coverage y exige 60% sobre la unión (las compuertas por shard dejan pasar módulos que un shard nunca importa). Luego cdk deploy del stack de backend, un build de imagen arm64 nativo, las migraciones corridas como una tarea de ECS de una sola vez con la imagen nueva, y solo entonces la actualización del servicio.
Frontend: Vitest, luego una compuerta que espera el deploy de backend del mismo commit cuando el commit tocó backend/ o infra/.
Intelligence: pruebas con un chequeo de drift de modelo-a-schema, imagen arm64, migraciones, ECS.

El input runner: ubuntu-latest es la salida de emergencia cuando spot no tiene
capacidad en absoluto. Para el frontend es un build estático y funciona tal cual.
Para los servicios arm64 tiene que buildear a través de QEMU, ya que un build
amd64 nativo produce una imagen que la tarea de Fargate no puede jalar.

Cuando spot se lleva la caja a media corrida

Un reclamo aparece como una X roja en cualquier paso que estuviera corriendo,
indistinguible de una prueba que falla hasta que se abre el log crudo.
rerun-on-runner-loss.yml lee los logs de los jobs fallidos, busca líneas que solo
el host del runner produce (The runner has received a shutdown signal,
lost communication with the server), y re-corre los jobs fallidos. Se niega
cuando existe una corrida más nueva, cuando el intento ya es el tercero, o cuando
el log no se pudo leer.

El scale-to-zero y el listener de re-corrida se componen sin saber el uno del otro.
La re-corrida crea un intento nuevo, el intento se forma en cola, la corrida en
cola evita que sleep escale hacia abajo, y si el pool ya se durmió, el siguiente
despertar lo dispara... nada. Una re-corrida no es un evento push ni
pull_request. El barredor de cada media hora solo duerme. En la práctica la caja
reclamada la reemplaza Capacity Rebalance antes de que sleep vea siquiera un pool
inactivo, pero es la única costura en el diseño que vale la pena conocer.

Qué mostraron los logs

Cada prueba unitaria de runner_pool.py pasa. Leer los logs reales de despertar y
dormir de los primeros tres días sacó dos cosas que las pruebas no pudieron.

1. El listado de runners es un 403 en producción.

Wake the pool  2026-10-10T21:14:30Z  gh api /repos/acme/myapp/actions/runners failed (1): gh: Resource not accessible by integration (HTTP 403)
Wake the pool  2026-10-10T21:14:41Z  gh api /repos/acme/myapp/actions/runners failed (1): gh: Resource not accessible by integration (HTTP 403)
Wake the pool  2026-10-10T21:15:11Z  No runner came online within 300s. The self-hosted jobs will queue. If spot has no capacity at all, re-run with the `runner: ubuntu-latest` input.

Listar runners autoalojados necesita el permiso de Administration del repositorio,
y GITHUB_TOKEN no se le puede otorgar. permissions: actions: read no es
suficiente. El script trata cualquier error de API como "sin datos", así que:

wake nunca ve a un runner ponerse en línea, y hace poll por los 300 segundos completos cada vez. El pool de todos modos despierta, porque set-desired-capacity pasa antes del poll. El costo son de 5 a 7 minutos facturados de runner hospedado por evento en un repo privado.
El chequeo de sleep de "¿algún runner está ocupado?" siempre responde no. Ha sido seguro solo porque el segundo chequeo, "¿algún workflow de pool está en cola o en progreso?", usa la API de runs, que actions: read sí cubre:

Sleep the pool if nothing else needs it  gh api /repos/acme/myapp/actions/runners failed (1): gh: Resource not accessible by integration (HTTP 403)
Sleep the pool if nothing else needs it  Other runs still need the pool, leaving it up:
Sleep the pool if nothing else needs it    - Deploy Backend#38086462352 (queued)
Sleep the pool if nothing else needs it    - Deploy Frontend#38086462341 (in_progress)

La prueba de contrato stubbea gh y sirve un runners.json enlatado para esa
ruta. Verificaba la tabla de decisión contra un permiso que el token real no tiene.

2. */30 no significa cada 30 minutos. El barredor disparó 12 veces entre el
2026-10-08 y el 2026-10-10:

03:29  10:50  17:38  22:38  02:39  09:47  16:42  21:23  01:02  07:21  13:53  18:06

Huecos de 4 a 7 horas. GitHub documenta que los workflows agendados se pueden
demorar o tirar bajo carga; en este repo, una agenda de 30 minutos se porta como
una de 5 horas. El comentario en el workflow dice que el peor caso de un despertar
perdido es "~30 min de spot inactivo, como 3 centavos". El peor caso real son
varias horas: siguen siendo centavos, pero no el número del comentario.

2 GB de RAM y nada de laptop: cómo se ve de verdad desarrollar en iPad en 2026

Franchesco Romero — Mon, 28 Sep 2026 01:41:24 +0000

Qué cambió en 2026

Cuatro cosas, y ninguna es la tableta.

Los CLI agénticos se volvieron remotos primero. Claude Code registra una sesión desde un host tuyo y la abres en una pestaña del navegador. Lo que hace el trabajo nunca fue el editor, así que el editor dejó de necesitar ser local.
Los túneles de VS Code movieron el extension host a la máquina remota. Sobre un túnel, una pestaña del navegador recibe el set completo de extensiones de escritorio. Sobre SFTP recibe nada más el subconjunto de web extensions. La misma barra de direcciones, otro producto.
Las VPN de malla hicieron alcanzable una caja de solo egreso. Sin regla de entrada, sin bastión, y aun así una sesión de SSH, porque la caja marcó hacia afuera primero.
La capacidad spot chica de ARM se volvió lo bastante accesible para sostener el trabajo pesado. Así que la caja siempre encendida se queda chica a propósito.

La pregunta dejó de ser "¿puedo desarrollar en un iPad?". Ahora es "¿puedo reparar la máquina donde está mi agente, desde aquí?".

Qué necesitas

Cosa	Por qué	Costo
Magic Keyboard Folio, o un Logitech Combo Touch	El trackpad es el requisito. Una terminal sin teclado físico es una demostración	Unos 250 USD de lista, más económico de terceros
Blink Shell	La terminal. Trae `mosh`, guarda las llaves en el Secure Enclave, tiene un comando `code`	Blink+ son 19.99 USD al año, con prueba de 14 días
La caja de la parte 1	Donde viven Claude Code y el repo	Unos 12 USD al mes en `t4g.small`
VPN de malla	Alcanzarla sin abrir un puerto	El plan gratuito alcanza
Monitor externo	Nada. Los iPads sin chip M solo espejan	No compres uno

Empieza sin configurar nada

Abre claude.ai/code en Safari, escoge la máquina, trabaja. Agrégalo a la pantalla de inicio para que se comporte como app y no como pestaña. Si la caja de la parte 1 está corriendo, esto funciona ahora mismo sin instalar nada.

Hazlo antes de construir cualquier otra cosa. Te dice si la ergonomía te acomoda antes de gastar un fin de semana en el resto.

Luego fíjate en lo que no puede hacer: en esa pestaña no hay shell. Y ahí está todo el problema.

Si todavía no tienes caja

La versión durable es la parte 1. La versión corta, suficiente para seguir este post: una t4g.small sobre Ubuntu arm64, un instance profile con AmazonSSMManagedInstanceCore, y un security group sin ninguna regla de entrada.

AMI=$(aws ssm get-parameter --output text --query Parameter.Value \
  --name /aws/service/canonical/ubuntu/server/24.04/stable/current/arm64/hvm/ebs-gp3/ami-id)

aws ec2 run-instances \
  --image-id "$AMI" --instance-type t4g.small \
  --iam-instance-profile Name=agent-box \
  --security-group-ids "$SG" \
  --block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=30,VolumeType=gp3,Encrypted=true}' \
  --metadata-options HttpTokens=required \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=agent-box}]'

Luego, en la caja, los dos paquetes de los que depende este post y un archivo de swap, porque 2 GB con un proceso de Node encima se quedan sin memoria:

sudo apt-get install -y tmux mosh
sudo fallocate -l 4G /swapfile && sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Pon todo eso en el script de bootstrap de la parte 1 en lugar de teclearlo una vez. Una instancia cuyo AMI viene de un parámetro de SSM se reemplaza con el tiempo, y el disco se va con ella.

Configura la tableta

Cuatro instalaciones, una sola vez.

1. El teclado. Magic Keyboard Folio para iPad (A16) si quieres el de Apple, Logitech Combo Touch si no. El requisito es el trackpad, no la marca. Seleccionar texto en una terminal con la yema del dedo es tan incómodo que dejas de hacerlo, y entonces dejas de leer bien la salida.

2. Blink Shell, del App Store. Blink+ son 19.99 USD al año con prueba de 14 días, y es la única pieza que cuesta dinero directo. Se lo gana porque trae mosh, guarda las llaves en el Secure Enclave y tiene un comando code. Termius y Secure ShellFish son alternativas razonables; Secure ShellFish monta el host remoto en la app Archivos, que es otro juego de concesiones.

Genera la llave dentro de Blink en lugar de copiar una llave privada al dispositivo:

config → Keys → + → Secure Enclave

Con Tailscale SSH no vas a necesitar instalar esa llave pública en ningún lado, porque la tailnet negocia la identidad. Genérala de todos modos: es a lo que recurres el día que apagues la VPN.

Luego agrega el host:

config → Hosts → +
  Host:     agent-box
  HostName: agent-box     (el nombre en la tailnet)
  User:     appuser

3. Tailscale, del App Store, con sesión en la misma cuenta que la caja.

4. claude.ai/code en la pantalla de inicio. Safari, Compartir, Agregar a inicio. Pierde la barra del navegador y se comporta como app. Instala también la app de Claude, para que el teléfono sirva de segunda pantalla cuando quieras ver cómo va una corrida larga.

Luego corre la prueba que de verdad te dice si esto funciona:

mosh appuser@agent-box
tmux new -A -s main

Arranca algo largo. Bloquea la tableta, espera un minuto, desbloquea, reconéctate con mosh appuser@agent-box y tmux new -A -s main. La sesión debe estar ahí con el trabajo todavía corriendo. Si está, la configuración quedó y todo lo de abajo es preferencia.

Las tres maneras de entrar

Esta es la parte que solo importa cuando la laptop está apagada.

1. La sesión del navegador

claude.ai/code en Safari. Cero configuración, sobrevive que cierres la pestaña, y aquí pasa la mayor parte del trabajo.

No tiene terminal. Así que cuando la caja necesita un humano, este camino no lo puede dar. Todo lo de abajo existe por esa frase.

2. Una terminal de verdad sobre la VPN de malla

En la caja:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --reset --ssh --hostname=agent-box

La caja marca hacia afuera, así que el security group se queda de solo egreso y nada escucha en internet. --ssh deja que la tailnet negocie la identidad de SSH, así que no hay llave pública que copiar a la tableta.

Tres detalles en ese solo comando:

Sin --advertise-tags, a propósito. Un tag cuesta dos ediciones de política, no una. Hay que declararlo en tagOwners o el comando muere de entrada con requested tags [tag:agentbox] are invalid or not permitted, y además taguear el nodo lo saca de autogroup:self, así que la regla ssh por defecto deja de aplicarle y necesitas una segunda con dst apuntando al tag. Sin tag, el nodo es tuyo y las dos cosas salen gratis. La concesión es la expiración de llave: los nodos sin tag expiran, así que apágale la expiración a ese dispositivo en la consola. Los nodos tagueados no expiran, y ese es el argumento real para hacerlo por el camino largo más adelante.
--reset porque tailscale up se niega a cambiar ajustes sin que vuelvas a mencionar todas las banderas no-default. Cualquier intento anterior deja banderas guardadas.
--hostname porque el default es el hostname de EC2, que cambia en cada reemplazo y te deja un nombre inservible en la tailnet.

Aun así necesitas una sección ssh en la política. Sin tag, apunta a tus propios dispositivos:

"ssh": [
  {
    "action": "accept",
    "src": ["autogroup:member"],
    "dst": ["autogroup:self"],
    "users": ["appuser", "autogroup:nonroot"]
  }
]

Usa accept, no check. El check pide re-autenticar en el navegador cada cierto tiempo, que es incómodo desde una tableta.

Desde la tableta:

mosh appuser@agent-box
tmux new -A -s main

Todo vive dentro de tmux. iPadOS mata una app en segundo plano sin preguntar, y lo va a hacer a media tarea. mosh más tmux new -A -s main te devuelve la sesión exactamente como estaba, a través de la suspensión, un cambio de Wi-Fi y un traspaso de hotspot. El SSH pelón te devuelve un socket muerto y trabajo perdido. Esa sola regla es la mayor parte de la diferencia entre que esto se sienta profesional o se sienta como una concesión.

La -A importa más de lo que parece: entra si la sesión existe y la crea si no, así un solo comando sirve para conectar y para reconectar. Con tmux new -s main pelado el reconectar falla y acabas con main, main-1, main-2.

Y una trampa que va a parecer un bug de tmux y no lo es. Blink invoca ~/.local/blink/mosh-server antes del del sistema, y si no está, ese intento sale 127, Blink reintenta, y la sesión que acaba de morir se lleva tu servidor de tmux recién creado. El cliente entonces reporta:

error connecting to /tmp/tmux-1000/default (No such file or directory)

que te manda a depurar tmux, los permisos de /tmp y los locales, y ninguno es el problema. Un symlink elimina el intento fallido:

mkdir -p ~/.local/blink
ln -sf "$(command -v mosh-server)" ~/.local/blink/mosh-server

3. Session Manager en el navegador, como rompe-cristal

La consola de AWS da un shell en la instancia desde Safari, sin nada instalado en la tableta y sin VPN en el camino. Solo necesita el agente de SSM y el instance profile que ya creaste.

Es el camino que sigue funcionando cuando la configuración de la VPN está mal, y en la ventana justo después de que un reemplazo borró lo que hayas configurado a mano.

Verifícalo desde la tableta antes de necesitarlo, incluyendo el paso de MFA. Si el segundo factor vive nada más en la laptop que ahora está apagada en casa, este camino es decorativo. Son cinco minutos que no sirven de nada si los dejas para después.

Por qué las tres

Camino	Configuración	Da un TTY	Sobrevive un reemplazo
`claude.ai/code`	Ninguna	No	Sí
VPN de malla más `mosh`	Los dos lados, una vez	Sí	Solo si la instalación de la VPN está en el bootstrap
Session Manager	Nada más allá del instance profile	Sí	Sí

La parte 2 terminó en una caja que estaba active y sin registrar. Recuperar una sesión de Claude Code en ese estado necesita una terminal interactiva, así que el camino cómodo es justo el que no puede. Dos de estos tres no son opcionales.

El editor

En la caja:

curl -Lk 'https://code.visualstudio.com/sha/download?build=stable&os=cli-alpine-arm64' \
  --output vscode_cli.tar.gz
tar -xf vscode_cli.tar.gz
./code --version
./code tunnel --accept-server-license-terms

El primer arranque imprime un código y una URL que abres en la tableta. Después de eso tienes VS Code con tus extensiones reales, la de Claude Code entre ellas, porque el extension host corre en la caja.

Corre la descarga como el usuario de la caja, no como root. Hecha desde un shell de root, el binario queda en el home de ese usuario con dueño root y todo lo de después falla de formas que nunca mencionan los permisos.

Luego déjalo como servicio, en este orden:

sudo loginctl enable-linger appuser
./code tunnel service install --accept-server-license-terms
systemctl --user is-active code-tunnel

El enable-linger no es opcional y va primero. service install crea un servicio de usuario, y un servicio de usuario muere con el último login si el usuario no tiene linger. El síntoma sin eso es "el túnel desaparece cuando me desconecto", que no apunta a systemd.

Cuando el servicio esté arriba, mata el ./code tunnel que dejaste en primer plano en el paso anterior. Si lo dejas, quedan dos procesos peleando por el mismo nombre de túnel, y el que sobrevive una desconexión es el del servicio, no el tuyo.

Cuatro cosas que si no, te van a costar tiempo:

La carpeta tiene que ir en la URL. https://vscode.dev/tunnel/<nombre> abre un editor sin archivos y parece roto. Lo que quieres es https://vscode.dev/tunnel/<nombre>/home/appuser/myapp. La forma relativa, /tunnel/<nombre>/myapp, funciona en unas versiones y en otras no; la de ruta completa falla menos. O abre la URL pelada y usa File, Open Folder una vez, y queda en Recent.
code status siempre va a decir No installation of Visual Studio Code stable was found. Ese comando busca un VS Code de escritorio en la máquina, que no es lo que un túnel necesita ni algo que deba estar ahí. No es un error. Para revisar el túnel usa code tunnel service log o systemctl --user is-active code-tunnel.
Diez túneles por cuenta. Pasando eso, el CLI borra uno sin usar al azar, así que limpia con code tunnel unregister.
El build de ARM es cli-alpine-arm64 y corre en Ubuntu. Verificado sobre glibc, code 1.140.0; no hace falta un userland musl ni una variante linux-arm64. Aun así corre ./code --version justo después de extraer, porque una arquitectura equivocada falla ahí y no después, dentro de algo que parece un problema de túnel.

Desde Blink en lugar de Safari. El comando code de Blink abre el mismo editor sin salir de la app de terminal:

code <tunnel_url>

También tiene un modo SFTP que no necesita túnel, usando la extensión de filesystem de Blink:

code appuser@agent-box:~/myapp

Práctico para una edición rápida, con una cosa que conviene saber: en modo SFTP el extension host corre en el navegador, así que recibes solo web extensions y la de Claude Code no está entre ellas. El túnel es la ruta que te da el editor real.

Lo único que no se puede automatizar es la autenticación por dispositivo del túnel. El binario se instala desde un script, el token no, así que un reemplazo de instancia significa volver a registrarlo a mano. Al menos es un paso que sí se puede hacer desde la tableta.

Un servidor de VS Code más su extension host más Claude Code en 2 GB va apretado incluso con swap. Si el editor del navegador va a ser la interfaz principal y no algo ocasional, dimensiona la instancia un escalón arriba.

El trabajo pesado va en otro lado

La caja es chica a propósito. Las suites de pruebas que necesitan base de datos, los builds de contenedor y las pruebas de navegador van en CI, así que un push es la forma de correrlas. Si el proyecto ya se despliega por pipeline y no con builds locales, nada cambia cuando viajas, salvo quién levanta el contenedor.

Lo que no funciona

Contenedores, una base de datos local, una suite de pruebas contra un Postgres real. iPadOS no da virtualización. No es un problema de permisos ni de encontrarle la vuelta.
Una segunda pantalla. El escritorio extendido necesita M1 o posterior; todos los demás iPads espejan, así que un monitor te da una copia con barras negras de la tableta.
Tres pestañas del navegador haciendo todo esto a la vez. Con 6 GB de RAM las pestañas se desalojan. Escoge un cliente principal y deja el trabajo real en tmux del otro lado.

La configuración está terminada cuando puedes reparar la caja desde la tableta, no cuando puedes programar en ella.

Github Actions: Re-intentar automáticamente los jobs de CI que un reclamo de spot instance mató

Franchesco Romero — Wed, 16 Sep 2026 20:42:58 +0000

Mi CI corre en un runner spot ARM64 autoalojado. Cuando AWS se lleva la instancia de vuelta a media corrida, GitHub muestra una X roja en cualquier paso que estuviera corriendo, y se ve idéntico a una prueba que falla.
Esto es un workflow que lee el log del job, reconoce esa falla específica, y re-corre los jobs fallidos por su cuenta. Las fallas de prueba reales se quedan en rojo.

Stack: GitHub Actions, una instancia spot EC2 en un Auto Scaling Group, CDK.

Qué pasó

Un deploy de backend se puso en rojo en Tests (shard 1/2). El log crudo:

2026-09-16T19:31:20Z ........................................................................ [ 75%]
2026-09-16T19:31:31Z ##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.
2026-09-16T19:31:44Z ##[error]The operation was canceled.
2026-09-16T19:31:44Z Terminate orphan process: pid (18652) (pytest)

Puntos ininterrumpidos hasta 75%, luego la máquina se fue. Cero pruebas fallaron. El otro shard se murió 13 segundos después, mismo host. El deploy de frontend entonces abortó a propósito, porque se niega a publicar cuando el deploy de backend para ese commit no tuvo éxito.

Un detalle que vale la pena saber: gh run view <id> --log-failed imprime nada para esta clase de falla. La salida vacía se ve como una herramienta rota, así que el log real casi nunca se abre. Hay que jalarlo por job:

gh api repos/myorg/myapp/actions/jobs/<job-id>/logs | tail -20

Qué hace

Un listener de workflow_run dispara después de que cualquier corrida de CI o de deploy termina. Para una corrida fallida jala los logs de los jobs fallidos y busca líneas que solo el host del runner puede producir:

RUNNER_LOSS_MARKERS = (
    "The runner has received a shutdown signal",
    "lost communication with the server",
    "The runner has received a cancellation signal from the server",
    "The operation was canceled by the runner service",
)

Si una hace match, llama a rerun-failed-jobs. Si ninguna hace match, no hace nada y la corrida se queda en rojo.

También se niega a actuar en tres casos:

Existe una corrida más nueva del mismo workflow y branch. Re-correr un intento más viejo nada más pelea con el concurrency group.
Intento 3 o posterior. Si un tercer intento todavía muestra una señal de shutdown, el pool está caído, no inestable, y un humano debería mirar el ASG.
El log no se pudo leer. Un log expirado o que todavía se está subiendo no es evidencia de nada.

Cómo usarlo

Dos archivos, sin dependencias más allá del CLI de gh que los runners hospedados por GitHub ya tienen.

Copia rerun_on_runner_loss.py y rerun-on-runner-loss.yml a .github/scripts/ y .github/workflows/.
Lista tus workflows por nombre en el trigger:

on:
  workflow_run:
    workflows: [CI, Deploy Backend, Deploy Frontend]
    types: [completed]

permissions:
  actions: write        # rerun-failed-jobs, nada más
  contents: read

jobs:
  maybe-rerun:
    if: >-
      github.event.workflow_run.conclusion == 'failure' ||
      github.event.workflow_run.conclusion == 'cancelled'
    runs-on: ubuntu-latest      # no self-hosted, ve abajo
    steps:
      - uses: actions/checkout@v5
      - run: python3 .github/scripts/rerun_on_runner_loss.py
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          REPO: ${{ github.repository }}
          RUN_ID: ${{ github.event.workflow_run.id }}
          RUN_ATTEMPT: ${{ github.event.workflow_run.run_attempt }}

runs-on: ubuntu-latest no es un detalle. En self-hosted este job se formaría detrás del mismísimo outage que existe para reparar.

workflow_run solo dispara para la copia del workflow que está en la rama por default, así que no hace nada hasta que se mergea. Pruébalo re-corriendo el script a mano contra un run id conocido.

La mitad de infraestructura

Re-correr solo ayuda si un runner regresa. Capacity Rebalance suscribe el ASG al aviso de interrupción de spot de dos minutos para que un reemplazo arranque antes de que se coseche la instancia, y llevaba meses habilitado aquí sin hacer nada:

capacityRebalance: true,
minCapacity: 1,
maxCapacity: 1,     // sin holgura, así que tiene que terminar primero
desiredCapacity: 1,

Un ASG no puede exceder MaxSize. Con MaxSize: 1 no hay dónde poner el reemplazo, así que la funcionalidad se degrada en silencio a terminar primero, que es el apagón que se suponía prevenía. maxCapacity: 2 con desiredCapacity: 1 lo arregla, y el costo en estado estable no cambia: la segunda caja solo existe durante el traslape.

Ese cambio tiene una precondición. Cada instancia registraba sus runners bajo nombres fijos con --replace:

./config.sh --name myapp-runner-$i --unattended --replace

Con dos cajas vivas, el reemplazo le roba el registro a la caja vieja
mientras todavía está corriendo un job, convirtiendo un rebalanceo elegante en una versión más rápida del kill que estaba evitando. Los nombres tienen que cargar el id de la instancia:

INSTANCE_ID=$(curl -fsS --retry 5 -H "X-aws-ec2-metadata-token: $IMDS_TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id || true)
RUNNER_SUFFIX=$(printf "%s" "${INSTANCE_ID##*-}" | tail -c 9)
[ -n "$RUNNER_SUFFIX" ] || RUNNER_SUFFIX=$(date +%s)

./config.sh --name myapp-runner-$RUNNER_SUFFIX-$i --unattended --replace

Cada || true ahí importa: ese user-data corre bajo set -euo pipefail, y un solo curl sin guardar fallando al arrancar una vez produjo una instancia sana con cero runners registrados, lo que forma cada job para siempre.

Los archivos completos están en blog-ci-spot-reclaim-code/runner-asg.ts y runner-user-data.sh.
omatización lo deja en paz.

El lado de infraestructura afirma contra la plantilla de CloudFormation
sintetizada, no contra el TypeScript, porque todo este post es evidencia de que
una propiedad puede leerse bien y no hacer nada:

print("ok" if int(asg["MaxSize"]) > int(asg["DesiredCapacity"]) else "no")

Qué no arregla

Si el mercado de spot de ARM está apretado y el ASG se queda en cero instancias
por horas, lo que ha pasado, el retry tampoco encuentra runner. La única cura
para eso es onDemandBaseCapacity: 1, un cambio deliberado de precio de como $9
al mes a como $25 al mes.

elchesco / rerun-on-runner-loss

Tell a spot reclaim apart from a failing test, and re-run only the jobs AWS killed.

Auto-rerun CI jobs that a spot reclaim killed

CI on a self-hosted spot runner goes red for two very different reasons: your code broke, or AWS took the instance back mid-job. GitHub presents both the same way, as a red X on whatever step was running.

This repo is a small workflow_run listener that tells them apart. It reads the logs of the failed jobs, and only when they carry the runner-loss fingerprint does it re-run them. Real test failures stay red.

Full write-up: blog-post.md.

Layout

Files sit where they are meant to be installed, so the .github/ directory can be copied wholesale.

.github/
  scripts/rerun_on_runner_loss.py        the decision, and the re-run call
  scripts/test/rerun_on_runner_loss.test.sh   contract test, stubs the gh CLI
  workflows/rerun-on-runner-loss.yml     the listener (must stay ubuntu-latest)
  workflows/test.yml                     runs the contract test in this repo
infra/
  runner-asg.ts                          ASG capacity block (CDK)
  runner-user-data.sh                    runner registration + offline sweep
  scripts/test/github-runner.test.sh     contract test on the

…

View on GitHub

Tres capas de contexto para un agente de código, ordenadas por garantía

Franchesco Romero — Sun, 30 Aug 2026 18:09:58 +0000

Tres capas de contexto para un agente de código, ordenadas por garantía

Una migración tiró una columna. Las pruebas estaban en verde, la revisión estaba hecha, el deploy era de rutina. Setenta y ocho segundos después el panel de admin estaba regresando 500s. El agente que revisó esa migración no tenía forma de saber que el deploy rota dos tasks una a la vez, porque nada en el repo lo dice.

Cómo evité que Claude repitiera mis errores. - Speaker Deck

speakerdeck.com

TL;DR

Capa	Qué va en ella	Presente cuando	Obedecida
`CLAUDE.md`	Lo que el modelo no puede deducir leyendo el repo	Cada sesión, siempre	Casi siempre
Archivos de memoria	Un archivo por error cometido, con la razón	Cuando la recuperación lo juzga relevante	Casi siempre
Hooks de git y de herramientas	Reglas que no te puedes dar el lujo de que se salten	Cada corrida	No negociable

El orden es el punto. Cada capa cuesta más de configurar y da una garantía más fuerte. La mayoría de la gente trata de resolver todo en la capa uno, que es por lo que su CLAUDE.md tiene 600 líneas y va empeorando.

Dos números de los cinco meses, los dos medidos, los dos en:

CLAUDE.md fue de 180 líneas, llegó a su pico en 249, se podó a 129, y se queda en 145.
Los archivos de memoria fueron 12, 26, 36, 76, 91.

Los dos medidos el 21 de agosto de 2026. Corre los scripts en tu propio repo hoy y el conteo de memoria será más alto que el mío, porque esa capa nunca deja de crecer. Ese es el punto de ella.

La capa que escribo a mano se encogió. La capa que sale de los errores creció. Si las dos tuyas están creciendo, estás poniendo todo en la capa uno.

El incidente

21 de julio, 21:14. CloudWatch:

UndefinedColumnError: column listings.public_visibility does not exist
GET /api/v1/admin/marketplace
500 · 500 · 500 · 500 · 500 ...

La migración era correcta. El timing no. El backend corre dos tasks de Fargate y el rollout las reemplaza una a la vez, mientras que la migración corre antes de que las tasks nuevas estén sanas. Por setenta y ocho segundos el código viejo seleccionaba una columna que ya no existía.

El arreglo es el expand y contract de manual: deja de referenciar la columna en un deploy, tírala en uno posterior. Esa no es la parte interesante. La parte interesante es que pedí una revisión de esa migración y nunca le dije a nadie, humano o de otro tipo, cómo se despliega este proyecto. La topología de deploy no está en el código. No hay ningún archivo que diga "esto rota dos a la vez, con traslape".

El reflejo después de un incidente así es escribir un mejor prompt la próxima vez. Eso falla por una razón aburrida: un prompt se muere con la sesión.

Capa 1: lo que el modelo no puede deducir

La prueba de si una línea pertenece a CLAUDE.md es una oración.

Si el modelo lo puede deducir leyendo el repo, córtalo.

Claude lee tu manifiesto. No necesita que le expliques que usas React. El CLAUDE.md típico que encuentras en línea es en su mayoría una descripción del repo, que el agente deriva en dos tool calls y deriva mejor de lo que tú la escribiste, porque el repo es la verdad y tu descripción tiene cuatro meses de vieja.

Lo que sobrevive la prueba cae en cuatro formas, y todas son o una prohibición o una excepción:

## Base de datos

Nunca edites el schema a mano, siempre a través de migraciones.

Las migraciones que crean enums deben usar `op.execute()` crudo, no
`op.create_table` con un Enum nombrado: el paso de autogenerate se rompe.

`score_total` es una columna generada de Postgres. Nunca le asignes.

Las pruebas necesitan un Postgres real y el password no es el que está en el
README, que está viejo. Jálalo del secret manager del equipo.

Nota la última línea. Carga el puntero, no el secreto. Un CLAUDE.md se commitea, así que una credencial nunca va dentro de uno. Nombrar dónde vive el valor es todo el valor de la línea, y no cuesta nada.

Podar es una mejora medible

La parte contraintuitiva: un CLAUDE.md de 600 líneas rinde peor que uno de 100 líneas. Estos no son hechos que se acumulan, son instrucciones compitiendo por la atención. Cada línea irrelevante diluye las que importan.

El mío creció a 249 líneas en once días, que es lo que pasa cuando tratas el archivo como documentación de onboarding. El 5 de abril lo corté a 129. A lo largo de los cuatro meses siguientes se fue de vuelta a 145 y nada se rompió.

El truco práctico es hacer que el agente audite su propio contexto. Abre el archivo y pregunta:

¿Qué en este archivo puedes deducir leyendo el repo?

Luego borra eso. Vas a borrar más de lo que esperas.

Capa 2: un error, un archivo, con la razón

CLAUDE.md es lo que sabías de antemano. La memoria es lo que aprendiste crasheando. Si tu CLAUDE.md crece cada vez que algo se rompe, estás usando la capa equivocada.

Aquí está el archivo que salió de los 78 segundos, textual excepto por el
frontmatter:

Una migración que hace DROP o RENAME de una columna sale en el mismo deploy que el código que deja de usarla, pero el backend corre 2 tasks de Fargate y las rota una a la vez, y la migración corre antes de que las tasks nuevas estén sanas.

**Por qué:** el rolling deploy significa que el código viejo y el nuevo sirven simultáneamente. Cualquier cambio de schema que no sea compatible hacia atrás con la imagen anterior rompe ese traslape. Pegó el 2026-07-21: `/admin/marketplace` tronó por ~78 segundos.

**Cómo aplicar:** los cambios aditivos (ADD COLUMN con un default, CREATE INDEX) son seguros de un jalón. Los destructivos necesitan expand/contract: el deploy A deja de referenciar la columna, el deploy B la tira. Un RENAME es un DROP más un ADD.

Tres partes, todas obligatorias: qué pasa, por qué pasa, qué hacer. Sin la tercera es una queja, no una regla.

La razón no es opcional

Esta es la parte que la gente se salta, y saltársela es lo que hace que estos archivos se vuelvan superstición.

"Nunca hagas DROP COLUMN en una migración."

Esa regla nunca tira una columna. Ni en un proyecto de una sola instancia, ni en desarrollo. No tiene idea de dónde aplica, así que aplica en todos lados y se te atraviesa.

"Nunca hagas DROP COLUMN en un solo deploy, porque el rolling
 deploy tiene dos versiones del código sirviendo a la vez."

Esa sabe que un job de una sola instancia está bien, y se da cuenta por su cuenta de que un RENAME es un DROP disfrazado. La razón convierte una prohibición en un modelo mental, y un modelo mental generaliza a casos que nunca escribiste.

La otra cosa que vale la pena decir: yo no escribí ese archivo. Dije "esto acaba de pasar, guárdalo para que no se repita" y el agente lo escribió. Escribir la memoria es trabajo del modelo. Decidir que algo merece una es tuyo, y la prueba es si te va a morder otra vez. Un typo no. Una propiedad del sistema que no está escrita en ningún lado, sí.

Capa 3: cuando casi siempre no es suficiente

Las capas uno y dos funcionan bien. Pero son instrucciones a un modelo, y un modelo tiene una tasa de olvido distinta de cero. Para la mayoría de las reglas esa tasa es irrelevante. Para unas cuantas no lo es.

Tenía una regla de que cada funcionalidad visible al usuario se documenta en una guía que lee el lado no técnico del equipo. Vivió en CLAUDE.md por seis meses y se seguía casi siempre. Casi siempre resultó significar que la guía iba tres funcionalidades atrasada y nadie lo notó hasta que alguien la necesitó.

USER_VISIBLE_PATHS=(
    '^backend/app/api/v1/admin/'
    '^backend/app/services/billing/'
    '^frontend/src/pages/admin/'
)

# ¿tocó algo visible pero no la guía?
if ! echo "$STAGED" | grep -qx 'docs/team-guide.md'; then
    echo "✗ commit bloqueado" >&2
    # e imprime la salida de emergencia:
    #   git commit --no-verify
    exit 1
fi

El bash no es la parte interesante. Dos decisiones de diseño lo son.

El mensaje de error documenta la salida. Un hook del que no te puedes salir obstruye el primer caso legítimo, y alguien lo desinstala esa semana. El mensaje está escrito para la persona que va a estar aquí a las once de la noche sin paciencia para acordarse de una bandera.

La lista de rutas es deliberadamente conservadora. Los falsos positivos se descartan con una bandera. Una funcionalidad visible saliendo en silencio no se descarta, se descubre meses después.

Elegir la capa

No "cuál es la mejor". Cuánto cuesta la falla.

Si la regla	Ponla en	Porque
Es una preferencia de estilo	`CLAUDE.md`	Un fallo ocasional no le hace daño a nadie
Vino de un incidente específico	Memoria	Necesita la razón y el alcance
Se descubre semanas después	Hook	Nadie va a revisar. Se acumula
Cuesta dinero o uptime	Hook	El fallo ocasional deja de ser aceptable

No tengo una tasa de falla medida para ninguna capa y no la voy a inventar. El argumento es costo esperado, no frecuencia. Es el mismo cálculo que ya usas para decidir si algo se lleva una prueba automatizada.

Una nota sobre los subagentes

Adyacente, y muy malentendido: un subagente cuesta más tokens totales, no menos. Paga por su propio system prompt, su propia copia de CLAUDE.md y sus propios schemas de herramientas, y luego su resumen te regresa como input.

Lo que ahorras es ventana de contexto principal, que es un recurso distinto y a veces el que de verdad te falta. Vale la pena cuando la exploración abarca módulos que no conoces, o cuando las investigaciones pueden correr en paralelo.
No vale la pena para una tarea que toca tres archivos que ya identificaste.

Qué hacer el lunes

Tres cosas, menos de una hora en total.

Abre tu CLAUDE.md y pregúntale al agente qué es redundante. "¿Qué en este archivo puedes deducir leyendo el repo?" Borra eso.
La próxima vez que algo se rompa, archívalo mientras está caliente. Antes de arreglarlo, con la razón. Es cuando lo tienes fresco y cuando menos ganas tienes de escribirlo.
Escoge una regla y conviértela en un hook. La que duele si se resbala. Una. Con su salida documentada en el mensaje de error.

El modelo no recuerda. Tu repositorio sí.

Construyendo un recomendador de emparejamiento de expertos

Franchesco Romero — Mon, 24 Aug 2026 00:03:34 +0000

La forma del problema

Un directorio es una superficie: el miembro lo abre y adivina.
Un recomendador es una superficie de empujar: el sistema propone y tiene que justificarse. La justificación es la parte difícil, y es donde vive la estadística.

Tres restricciones hicieron esto distinto de un recomendador de contenido:

El item es una persona con capacidad finita. Un hilo se le puede recomendar a diez mil personas. Un experto no.
Una mala recomendación es cara de los dos lados. Quien pide desperdicia una petición, el experto desperdicia una hora, y los dos aprenden a ignorar la superficie.
La afirmación tiene que ser checable. "Quizá te guste este hilo" no necesita evidencia. "Esta persona está un nivel adelante de ti en diseño de sistemas" sí.

Recuperación: híbrida, fusionada con RRF

Tres recuperadores independientes sobre el conjunto de expertos elegibles, fusionados con Reciprocal Rank Fusion:

def rrf_fuse(*ranked_lists, k=60):
    """Fusiona listas de ids rankeadas. El score depende solo del rank, nunca
    de la escala propia del recuperador, que es el punto: la similitud coseno y
    un conteo de hilos resueltos no son números comparables."""
    fused = {}
    for lst in ranked_lists:
        for rank, key in enumerate(lst):
            fused[key] = fused.get(key, 0.0) + 1.0 / (k + rank)
    return fused

RRF es la primitiva correcta aquí por una razón que vale la pena decir: los recuperadores emiten cantidades incomparables. Uno regresa un coseno en [-1, 1], uno regresa un conteo entero de hilos resueltos, uno regresa un delta de nivel de escalera. Normalizarlos a una escala común requiere supuestos sobre sus distribuciones que nadie tiene a este volumen de datos.
RRF descarta las magnitudes y se queda solo con el orden, que es exactamente la información que sobrevive a una muestra chica.

k = 60 es la constante estándar de la formulación original de Cormack et al.
Aplana la cabeza: la diferencia entre el rank 1 y el rank 2 es
1/61 - 1/62 ≈ 0.00026, así que un recuperador no puede dominar por estar confiado, solo por estar consistentemente temprano a lo largo de las listas.

Scoring: un compuesto ponderado, con los pesos como datos

SCORE_WEIGHTS = {
    "compass_gap_fit": 0.30,   # explícito y direccional
    "semantic_fit":    0.20,   # coseno del embedding de perfil
    "skill_overlap":   0.15,   # tecnologías compartidas, ponderadas por rareza
    "capacity_fit":    0.15,   # también una compuerta dura
    "expert_quality":  0.12,   # rating, aceptación, experiencia que satura
    "specialty_match": 0.05,   # burda, pero muy poblada
    "fairness":        0.03,   # penalización de exposición amortiguada por log
}

Dos componentes valen la pena desempacar.

expert_quality satura. Un experto sin historial puntúa 0.5, no 0:

def expert_quality(*, avg_rating, completed, accepted, proposed):
    if completed == 0 and proposed == 0:
        return 0.5                      # prior neutral, no cero
    rating_part = ((avg_rating or 4.0) - 1.0) / 4.0
    acceptance  = accepted / proposed if proposed else 0.6
    experience  = 1.0 - math.exp(-completed / 5.0)
    return 0.5 * rating_part + 0.3 * acceptance + 0.2 * experience

La saturación exponencial sobre experience codifica que la diferencia entre 0 y 5 sesiones completadas es grande y la diferencia entre 40 y 45 es ruido.
Un término lineal habría hecho inalcanzables a los veteranos. El prior de 0.5 para los no probados es la decisión de cold start que deja crecer el pool de expertos más allá de quien haya ido primero; sin él, el sistema es un loop de rico se hace más rico por construcción.

fairness es exposición amortiguada por log.

def fairness_factor(times_recommended):
    return 1.0 / math.log(math.e + max(0, times_recommended))

ln(e + n) da exactamente 1.0 en n = 0 y decae lento. Una penalización lineal habría hecho irrecomendable a un buen experto después de un puñado de ciclos.

La parte que importa: esto es un problema de asignación

El instinto es computar un top-N por cada quien pide. Ese instinto está mal, y el modo de falla no es sutil.

Si cada quien pide escoge de forma independiente a su mejor experto, las mismas tres personas más fuertes juntan todas las peticiones. Son las que tienen los mejores ratings y el historial más profundo, así que ganan cada ranking, y dejan de contestar en un mes. El recomendador entonces destruye el recurso que existe para asignar.

Así que los pares se puntúan, y luego se asignan de forma global bajo una restricción de capacidad por experto:

def allocate(pairs, *, capacity, per_requester):
    """Asignación global greedy. Ordenada por score, cada par consume una unidad
    de la capacidad de su experto."""
    assigned = defaultdict(int)
    out = []
    for pair in sorted(pairs, key=lambda p: p["score"], reverse=True):
        if capacity.get(pair["expert_id"], 0) <= 0:
            continue
        if assigned[pair["requester_id"]] >= per_requester:
            continue
        capacity[pair["expert_id"]] -= 1
        assigned[pair["requester_id"]] += 1
        out.append(pair)
    return out

Esta es la aproximación greedy a un matching bipartito con restricción de grado. A esta escala (cientos de pares) la solución óptima vía scipy.optimize.linear_sum_assignment y la greedy difieren por ruido, y la versión greedy tiene una propiedad que la óptima no: es inspeccionable en un dry run, línea por línea, en orden de score. Cuando un operador pregunta "¿por qué esta persona obtuvo ese experto?", la respuesta es una sola pasada hacia abajo por una lista ordenada.

A quienes piden que la asignación no puede colocar no se les tira. Por construcción son aquellos cuyos mejores expertos están llenos, lo que los hace el insumo exacto para el clustering uno-a-muchos: agrúpalos por celda de escalera y propón una sola sesión.

La capa de datos, y la estadística que la hace defendible

La segunda capa responde "qué debería aprender después, y cuánto vale".
Compara la mediana de datos ponderada por fuente de los puntos de datos que reportan una habilidad contra los que no.

Esa oración contiene tres maneras de engañar a alguien. Las tres necesitaron una compuerta.

1. Ponderación por fuente con decaimiento exponencial por recencia

No todos los puntos de datos merecen voto igual. Cada fuente carga un peso de confianza y una corrección de sesgo, y cada punto decae con la edad:

COALESCE(cs.base_weight, 0.50)
  * (1 + COALESCE(cs.bias_correction_pct, 0) / 100.0)
  * POWER(0.5, EXTRACT(EPOCH FROM (now() - sdp.scraped_at)) / (:halflife * 86400.0))

Una vida media de 365 días significa que una publicación de dos años todavía cuenta, a un cuarto del peso de una fresca. El LEFT JOIN sobre la tabla de fuentes es deliberado: un punto de datos cuya fila de fuente nunca se registró cuenta en el default neutral de 0.50 en lugar de desvanecerse, porque tirar datos en silencio es peor que ponderarlos de forma conservadora.

El agregado es una mediana ponderada, no una media ponderada. Las
distribuciones de datos están sesgadas a la derecha y la cola es donde viven los errores de scraping; una sola cifra mal parseada mueve una media y no mueve una mediana.

def weighted_median(values, weights):
    pairs = sorted(zip(values, weights), key=lambda p: p[0])
    total = sum(max(0.0, w) for _, w in pairs)
    if total <= 0:                       # todos los pesos en cero: degrada a mediana simple
        mid = len(pairs) // 2
        return (float(pairs[mid][0]) if len(pairs) % 2
                else (float(pairs[mid - 1][0]) + float(pairs[mid][0])) / 2.0)
    half, acc = total / 2.0, 0.0
    for value, weight in pairs:
        acc += max(0.0, weight)
        if acc >= half:
            return float(value)
    return float(pairs[-1][0])

2. Estratificación, porque el número ingenuo mide antigüedad

Este es el confusor que hace inútiles a la mayoría de las afirmaciones de "la habilidad X paga Y% más". La gente senior sabe más herramientas. Compara a todos los que reportan Kubernetes contra todos los que no, y una parte grande del delta es nada más antigüedad filtrándose por la comparación.

Cada comparación por lo tanto pasa dentro de un estrato (rol, seniority, país, bucket de experiencia). Los buckets son burdos a propósito (0-2, 3-5, 6-9, 10+): estratos más finos matan de hambre a la muestra y el intervalo explota. Una habilidad cuyo efecto desaparece una vez estratificada se tira, no se reporta.

3. Un intervalo por bootstrap, no un estimado puntual

Un estimado puntual se lee como una promesa. El bootstrap por percentil re muestrea las dos cohortes con reemplazo, recomputa las medianas ponderadas, y toma los percentiles 5/95 de la distribución de deltas resultante:

def bootstrap_ci(with_vals, with_w, without_vals, without_w, n=1000, alpha=0.10):
    rng = random.Random(SEED)            # determinista: los mismos insumos deben
    deltas = []                          # producir el mismo intervalo en cada corrida
    for _ in range(n):
        a = [rng.choice(range(len(with_vals))) for _ in with_vals]
        b = [rng.choice(range(len(without_vals))) for _ in without_vals]
        med_a = weighted_median([with_vals[i] for i in a], [with_w[i] for i in a])
        med_b = weighted_median([without_vals[i] for i in b], [without_w[i] for i in b])
        if med_b > 0:
            deltas.append((med_a - med_b) / med_b * 100.0)
    deltas.sort()
    lo = deltas[int(math.floor((alpha / 2) * len(deltas)))]
    hi = deltas[min(len(deltas) - 1, int(math.ceil((1 - alpha / 2) * len(deltas))) - 1)]
    return round(lo, 2), round(hi, 2)

El bootstrap es la herramienta correcta porque la distribución muestral de una mediana ponderada de una distribución sesgada no tiene una forma cerrada limpia. El re muestreo esquiva la derivación por completo.

El RNG sembrado importa más de lo que parece. Un operador refrescando un dry run de admin no debe ver el número bambolearse; un intervalo de confianza que cambia al recargar es indistinguible de un bug.

Una fila se surge solo si las tres se cumplen:

significant = (ci_low > 0.0                  # el intervalo se queda de un lado del cero
               and premium >= min_pct        # bastante grande para valer el tiempo de una persona
               and premium <= claim_cap_pct) # no un outlier absurdo

Las filas no significativas de todos modos se computan y se guardan. La tabla de admin muestra qué se rechazó y por qué, porque un número que el sistema se negó a usar es tan interesante como uno que usó.

La medición que reencuadró el proyecto

Todo lo de arriba estaba en verde en CI. Luego la primera dry run contra producción:

requesters=82  experts=1  scored_pairs=82  affinity=3  office_hours=0

1 experto de 51. La causa:

requester_ids = {m.user_id for m in requesters}
eligible_experts = [
    m for m in experts
    if m.open_load < cap and m.user_id not in requester_ids   # <-- esto
]

La intención era "no emparejes a alguien consigo mismo". La implementación era "excluye a cualquier experto que sea también un candidato a pedir", y casi todos los expertos lo son, porque no tienen ninguna petición abierta propia.

Medido:

Roles activos elegibles como experto:                51
...que se apuntaron:                                 51
...bajo el tope de carga:                            51
...excluidos por ser también quienes piden:             50

El único sobreviviente era la única persona que resultó estar a media
interacción, y las tres propuestas apuntaban a ella. El sistema había
encontrado el modo de falla de burnout por su cuenta, en la primera corrida, a través de una línea pensada para prevenir un problema completamente distinto.

La guarda de auto emparejamiento ya existía por par, que es donde va.

Dos hallazgos más de la misma corrida:

Las cards podían salir sin razón. Solo 4 miembros tenían una colocación de escalera de competencias, así que el componente más pesado casi siempre era 0 y la señal sobreviviente era un coseno de embedding que nadie puede leer. Una propuesta tenía una lista de razones vacía. Una card que no puede decir por qué es peor que ninguna card.

El badge de tendencia disparaba con todo. La ingesta era reciente, así que casi cada publicación caía en la ventana de 30 días y la línea base de 90 días era una o dos filas:

golang   229 publicaciones  trend=2.00
go       155 publicaciones  trend=462.00
python   109 publicaciones  trend=62.40
aws       43 publicaciones  trend=61.50

Una razón necesita un denominador que valga la pena dividir. El arreglo es un conteo mínimo de línea base antes de que se afirme una tendencia siquiera, y una cota sobre la razón.

La lección de frecuencia inversa, aprendida tres veces

Esta es la parte con el mayor valor de transferencia, porque la misma idea estadística tuvo que aplicarse en tres niveles distintos y cada nivel se veía bien hasta que se inspeccionó.

Nivel 1: lift, en el minero de adyacencia

La adyacencia de habilidades es minería clásica de reglas de asociación sobre habilidades co-ocurrentes en publicaciones de vacantes. Para una regla
A -> B:

soporte = conteo de transacciones que contienen las dos
confianza = P(B | A) = soporte / conteo(A)
lift = confianza / P(B)

La confianza sola es inútil, y la razón es instructiva. Linux co-ocurre con todo, así que P(Linux | lo que sea) es alta y cada regla apunta a Linux. El lift divide por la tasa base: si saber A no sube la probabilidad de B por encima del azar, el lift es 1 y la regla no carga información.

lift = confidence / (singles[consequent] / total)
if lift < min_lift:      # 1.15
    continue

Reglas que sobrevivieron sobre datos reales, ordenadas por confianza * lift:

laravel        -> php            conf=0.73  lift=11.33  support=8
terraform      -> kubernetes     conf=0.75  lift=9.25   support=9
rails          -> ruby           conf=0.78  lift=7.94   support=7
react native   -> react          conf=1.00  lift=5.48   support=7
gcp            -> aws            conf=0.73  lift=6.15   support=16

Esas se leen bien para un humano, que es la única validación disponible a este tamaño de muestra.

Una trampa que vale la pena registrar: las primeras pruebas unitarias de esto eran degeneradas. Un corpus donde el antecedente aparece en cada transacción tiene lift 1.0 por construcción, así que nada puede ser significativo jamás.

Los fixtures tuvieron que reescribirse para incluir publicaciones que no contuvieran ningún lado de la regla. Un corpus de mercado es diverso; un corpus de prueba tiene que serlo también, o no prueba nada.

Nivel 2: frecuencia de documento, en la señal de tema

El riel salió y casi cada card decía:

Comparten temas: introduccion-plataforma.

La distribución de frecuencia de tags lo explica:

talento-tecnologico        27 hilos   50.0%
introduccion-profesional   17 hilos   31.5%
introduccion-plataforma    14 hilos   25.9%
espacio-relajacion          4 hilos    7.4%
servidores-caseros          4 hilos    7.4%
ai-local-vs-nube            2 hilos    3.7%

Tres tags cubren la mitad de un corpus de 54 hilos, luego un acantilado a 7%.

Este es el problema de Linux otra vez, un nivel arriba: un tag sobre la mitad del corpus no carga información sobre un par. Los tags por encima de 20% de frecuencia de documento se tiraron del scoring y del copy.

Ese arreglo hizo el copy menos vergonzoso sin hacerlo significar nada, lo que lleva al tercer nivel.

Nivel 3: el vocabulario era la ontología equivocada

Existían nueve tags en total. Ninguno de ellos era una tecnología.
Eran secciones del foro: un tablero de anuncios, dos áreas de introducción, un espacio fuera de tema. Ningún umbral de frecuencia puede rescatar una señal que está midiendo lo equivocado. Compartir "introducciones" significa que las dos personas se presentaron.

La señal técnica que sí existía era el tech_stack del perfil:

python 11 · aws 8 · docker 7 · node.js 7 · typescript 7
git 6 · react 6 · fastapi 5 · kubernetes 3 · terraform 3

Flaca (20 de 83 miembros) pero real, y nombra cosas que un experto puede enseñar. El componente de tema se reemplazó por completo, normalizado por el menor de los dos stacks para que un stack de 30 items no pueda diluir un buen match de 3-de-4, y extendido a través de las reglas de adyacencia minadas para que quien pide sobre Python conecte con un experto sobre FastAPI con la regla como la justificación declarada.

Y luego, predeciblemente, el nivel 3 tuvo su propio nivel:

También trabaja con python.

Python está en 11 de 20 stacks. El mismo problema, tercera recursión. La resolución esta vez no fue un filtro duro, porque a diferencia de una sección de foro, Python es una habilidad enseñable real y ponerla en cero descarta traslape genuino.

Las habilidades ubicuas se bajan de peso a un quinto en lugar de tirarse, el copy nombra las habilidades más raras
primero, y un stack compartido solo justifica una card cuando al menos una habilidad compartida es poco común:

weight_of = lambda sk: 0.2 if sk in common_skills else 1.0

Una habilidad compartida rara ahora le gana a una ubicua 1.0 a 0.2, que es lo que pone a Terraform encima de Python en el ranking en lugar de debajo por accidente de quién lista más tecnologías.

La generalización: cada vez que una señal es un traslape de conjuntos, pregúntate cuál es la tasa base de cada elemento antes de dejar hablar al traslape. El lift, el IDF, y este bajado de peso de habilidades son la misma corrección con tres nombres distintos.

Afinado de pesos como learning to rank offline

Los pesos compuestos se guardan en config, no en código, y hay una dry run que propone un rebalanceo a partir de los resultados calificados de los propios miembros:

correlations = {k: safe_corr(np.asarray(per_key[k]), y) for k in keys}

Tres decisiones deliberadas alrededor de ella:

La clase positiva es una sesión agendada, no un click. Un click en un hilo es barato; convertir una propuesta en una sesión de verdad agendada no.

Optimizar por clicks afinaría el ranking hacia la curiosidad en lugar de hacia sesiones que pasan.

La propuesta es una mezcla conservadora, nunca el vector crudo derivado de la correlación:

blended = {k: BLEND * corr_w.get(k, 0.0) + (1.0 - BLEND) * current.get(k, 0.0)
           for k in current}

Con BLEND = 0.5 y un piso de 30 muestras, una semana flaca no puede mover el ranking.

Nada se aplica automáticamente. Un operador previsualiza y aplica de forma explícita. Auto aplicar una correlación computada sobre decenas de muestras es como un ranker oscila.

Trampas

Trampa 1: la restricción de unicidad que creó duplicados. Las filas son únicas por (requester, expert, cycle_key), lo cual es correcto por ciclo y mal a través de ellos. El cron semanal escribió un segundo ciclo encima del primero y el riel de inmediato se dobló:

riel para <miembro>:
   <experto-a>  0.3997
   <experto-a>  0.3871   <--
   <experto-b>  0.3589
   <experto-b>  0.3462   <--

Arreglado en dos lugares, porque cualquiera solo deja un hoyo: la lectura se colapsa con DISTINCT ON (expert_id) quedándose con la mejor fila, y un ciclo nuevo reemplaza las propuestas sin tocar de los viejos para que la tabla no pueda crecer una card por persona por semana para siempre. Solo se tiran las filas no mostradas; cualquier cosa que un miembro vio es historial de embudo.

Trampa 2: el CTA que no hacía nada. El riel se renderizaba dentro de la misma página a la que enlazaba su botón, así que el click actualizaba el query string y la página se quedaba ahí. Peor, el enlace no cargaba id de match, así que una petición enviada nunca podía reportar de vuelta y la máquina de estados nunca podía avanzar más allá de CLICKED. La tasa de aceptación, la única métrica sobre la que se juzga el rollout y la que está cableada a la alarma, se habría leído como cero para siempre. El botón muerto se habría
reportado en un día; la métrica muerta se habría creído por semanas.

Trampa 3: una auto-recomendación latente. Cero filas en producción tenían requester_id = expert_id, pero el clustering uno-a-muchos escogía su experto del pool completo sin excluir el cluster, y esas filas cargan al primer miembro del grupo como quien pide. Podía apuntarse a sí mismo. Simplemente nunca había
disparado porque ningún cluster había alcanzado el umbral.

Lecciones

Mide contra datos de producción antes de confiar en un diseño. La primera dry run contra filas reales invalidó más del diseño que todas las pruebas juntas. Córrela antes de que se emita nada, no después.
Un recomendador para un recurso finito es un problema de asignación. El top-N por usuario es la forma equivocada y su modo de falla es destruir el lado de la oferta. La restricción de capacidad va en la asignación, no en un post filtro.
Chequea la tasa base de cualquier señal de traslape de conjuntos. El lift, la frecuencia de documento y la rareza de habilidad son la misma corrección. Una señal compartida por la mitad de la población no carga información sobre un par, no importa qué tan cierta sea.
Antes de afinar un umbral, verifica el vocabulario. Se gastaron dos rondas en cortes de frecuencia para un conjunto de tags que no contenía ninguna tecnología en absoluto. Pregúntate qué son las etiquetas antes de preguntar qué tan comunes son.
Un intervalo de confianza es una decisión de producto, no un detalle de estadística. El intervalo, el piso de muestra y la cota de efecto son lo que se para entre una correlación y una promesa que los datos no pueden cumplir. Muestra el rango, declara la muestra, y niégate a imprimir el número cuando las compuertas fallan.
Siembra el bootstrap. Un número que cambia al recargar es indistinguible de un bug, y destruye la confianza del operador más rápido que estar mal una vez.
Instrumenta la conversión antes de publicar la superficie. Un botón muerto se reporta en un día. Una métrica muerta se cree por un mes.
Publica el motor a oscuras. Emisión apagada por default y una dry run como la acción de admin por default significaron que cuatro bugs significativos se encontraron con datos reales y cero notificaciones enviadas.

Cómo mantener siempre disponibles las sesiones de tu agente de código remoto (parte 2)

Franchesco Romero — Wed, 19 Aug 2026 00:53:33 +0000

La Parte 1 construyó una caja siempre encendida para una sesión de remote-control de Claude Code y terminó con una alarma que convierte seis días de silencio en quince minutos. Esa alarma atrapa una caja muerta. Esta es la secuela, y la caja de aquí nunca estuvo muerta. Estaba active, su token estaba fresco, y en cada reinicio imprimía:

Take this session with you and pick up right where you left off on any device.
Open the Code tab in the Claude mobile app, or visit claude.ai/code in a browser.

y la sesión no estaba en claude.ai/code. Nunca se había registrado. El banner de arriba se imprime al arrancar, antes de que haya pasado lo que anuncia, así que le mintió al monitoreo, me mintió a mí cuando lo "arreglé", y casi se mintió hasta meterse en este blog post como el arreglo. Este post es sobre la diferencia entre un proceso que dice que está listo y una sesión que de verdad lo está.

TL;DR

	Lo que creía	Lo que era cierto
Causa raíz	el registro se puso viejo a lo largo de ~6 días de uptime	nunca se registró, el CLI se colgó en un prompt interactivo sin TTY
El "arreglo"	reinicia el servicio; el banner regresa; el heartbeat en verde	el reinicio imprimió el banner otra vez y aun así no se registró
La señal de salud que construí	grep del journal por `claude.ai/code`	ese string es el banner de pre-registro, verde para un proceso colgado
La señal real		la URL registrada (`claude.ai/code/session_…`), que solo se imprime después del registro

Placeholders, como en la parte 1: myapp, appuser, acme/myapp.

El síntoma

La sesión simplemente no estaba en la lista de claude.ai/code, mientras que todo en la caja decía que debería estar:

$ systemctl is-active claude-remote-control
active
$ stat -c %y ~/.claude/.credentials.json
2026-07-28 02:54:11          # token refrescado hace horas, la auth está bien
$ aws cloudwatch describe-alarms --alarm-names myapp-agent-box-down \
    --query 'MetricAlarms[].StateValue' --output text
OK

Así que hice lo obvio: reinicié el servicio. Imprimió el banner, el proceso subió, el heartbeat se puso verde, y la sesión seguía sin estar ahí. Ese es el momento en el que vale la pena detenerse. Cada señal que tenía decía sano, y el producto real (una sesión que puedo abrir desde un navegador) no existía.
Un reinicio que produce un banner no es un reinicio que produce una
sesión.

Conseguir una señal que no puede mentir

systemctl is-active reporta que el proceso existe. El banner reporta que el proceso arrancó. Ninguno reporta que la caja se registró con el punto de encuentro hospedado, lo único que mete la sesión en la lista. Para ver eso, pídele al CLI que escriba su propio log de debug y lee lo que de verdad pasa:

claude remote-control --name myapp-cloud --continue --debug-file /tmp/rc.log --verbose

Dos fallas cayeron de inmediato, y ninguna era "vieja":

Take this session with you and pick up right where you left off on any device.
Open the Code tab in the Claude mobile app, or visit claude.ai/code in a browser.
The session keeps running on this machine. ... Press Ctrl+C to stop.

Enable Remote Control? (y/n)

El proceso imprime el banner y luego se bloquea en un prompt interactivo.
Bajo systemd no hay TTY que lo conteste, así que espera ahí para siempre: active, banner emitido, registro ni siquiera intentado. Los CLI recientes agregaron esta confirmación; la caja de la parte 1 es anterior a ella.

Y cuando le di una y, la segunda falla:

Error: No recent session found in this directory or its worktrees.
Run `claude remote-control` to start a new one.

--continue, la bandera de la parte 1 que mantiene el marcador estable reanudando la misma sesión, da error duro cuando no hay sesión que reanudar. En una caja cuyo historial de sesión local se había borrado en una reconstrucción, --continue no era una optimización; era un arranque que solo podía fallar.

El arreglo real: contesta el prompt, y no dependas de que una sesión exista

Las dos fallas viven en una línea, así que el arreglo es una línea, un wrapper en ExecStart:

ExecStart=/bin/bash -c 'cd /home/appuser/myapp; \
  echo y | /home/appuser/.local/bin/claude remote-control --name myapp-cloud --continue || \
  echo y | /home/appuser/.local/bin/claude remote-control --name myapp-cloud'

Tres cosas se ganan su lugar:

echo y contesta el prompt. Importa que el proceso siga corriendo después de que su stdin se cierra (verificado, sí lo hace), así que un echo de una sola vez basta; sin yes inundando el pipe, sin sleep infinity manteniéndolo abierto.
--continue || <nuevo> trata de reanudar (marcador estable) y cae de vuelta a una sesión nueva cuando no hay nada que reanudar. Como echo y cierra limpio, un --continue fallido de verdad regresa y corre el fallback; un sleep infinity aquí colgaría el pipeline en el camino de falla y reintroduciría el atoro silencioso exacto.
Sin $@ ni $VAR en ExecStart. systemd expande ${} y $VAR pelón él mismo, y mutila $@; la jugada segura es repetir la ruta en lugar de factorizarla en una variable.

Ahora el log de debug muestra lo que el banner solo fingía:

[bridge:init] Resuming session session_01Pp8… on environment env_01Vp…
[bridge:init] Registered, server environmentId=env_01Vp…
[bridge:title] server title: myapp-cloud

Registered. Ese es el recibo. El banner era el menú.

Defensa en profundidad, todavía vale la pena conservarla

El wrapper arregla el outage. Dos guardas del primer borrador de este trabajo se quedan, porque endurecen la caja contra otras maneras en que la sesión puede caducar:

Reciclado diario. RuntimeMaxSec=86400 rebota la unidad cada 24h; Restart=always la trae de vuelta y --continue reanuda la misma sesión, así que el marcador aguanta. Si un registro alguna vez se pone viejo en un uptime largo, esto le pone tope al radio de impacto en un día en lugar de confiar en
que viva para siempre. TimeoutStopSec=20 mantiene cada reciclado rápido, ya que el CLI ignora SIGTERM por ~90s.

Escritura de vuelta de credenciales. La parte 1 señaló que el CLI rota su refresh token y la captura del secreto se pudre. Un helper chico empuja el token vivo de vuelta a Secrets Manager en cada corrida del watchdog, protegiendo con fuerza contra escribir un archivo local malformado encima de un secreto bueno, para que una instancia reemplazada ya no arranque sin autenticar.

El health check al que engañó el mismo banner

Aquí está la parte que arde. La primera versión del chequeo de readiness, la que se suponía atrapaba justo este estado de "arriba pero sin registrar", hacía esto:

# MAL: hace match al banner de pre-registro, así que está verde para un proceso colgado
journalctl -u claude-remote-control --since "${AGE}s ago" | grep -q "claude.ai/code"

claude.ai/code está en el banner que se imprime antes del prompt en el que el proceso estaba colgado. El chequeo que construí para detectar la falla quedaba satisfecho por la falla. Es el bug original vestido con el disfraz de su propio arreglo.

La sesión registrada imprime una línea distinta, una URL con un id de sesión o de environment:

Continue coding in the Claude mobile app or https://claude.ai/code/session_01Pp8…

El discriminador entre "anunciada" y "registrada" es un solo carácter: lo que sigue a code. El banner dice code in a browser; la cosa real dice code/session_… o code?environment=…. Así que haz match a eso:

# solo una sesión REGISTRADA imprime una URL con '/' o '?' después de 'code'
journalctl -u claude-remote-control --since "${AGE}s ago" | grep -qE 'claude\.ai/code[/?]'

Con el chequeo corregido el heartbeat significa lo que dice: active, lo bastante joven para haberse registrado, y una URL de registro en su propio log.
Cualquier otra cosa degrada el latido a DEGRADED y reinicia, y DEGRADED no hace match al filtro OK de la parte 1, así que un estado que no se va a auto-sanar de todos modos le suena a la alarma existente.

Callejones sin salida (los dos el mismo error)

Checar por una conexión de red abierta. La sonda de readiness intuitiva: seguramente una sesión registrada sostiene un socket al punto de encuentro. Medido en la caja sana: cero sockets establecidos. Una sesión registrada inactiva no mantiene ninguno. El chequeo reiniciaría una caja funcionando en cada tick.
Grep del banner de arranque. Cubierto arriba. Verde antes de que el trabajo esté hecho.

Los dos fallan de la misma manera: afirman sobre algo que es cierto antes de
que pase la cosa real. Un socket que quizá todavía no esté ahí; un banner que
está ahí demasiado pronto. El arreglo en los dos casos es afirmar sobre el
artefacto que existe solo después del éxito: la línea Registered, la URL
con un id.

Lecciones

Un banner es un menú, no un recibo. Cualquier mensaje de "ya puedes hacer X" impreso al arrancar es una intención, no una confirmación. Los health checks tienen que indexarse en el artefacto que existe solo una vez que X de verdad pasó.
Reiniciar hasta que reaparezca el mensaje feliz no es verificación. Vi el banner, vi el heartbeat ponerse verde, y seguí adelante, dos veces. El mensaje era el mismo las dos veces porque nunca dependió del éxito.
Los prompts interactivos son minas en cajas sin atender. Una sola compuerta (y/n) nueva, incontestable sin un TTY, convierte en silencio un servicio que funciona en uno colgado. Dale la respuesta explícitamente; no asumas que un servicio hereda la de tu terminal.
Las banderas de conveniencia tienen modos de falla. --continue mantiene un marcador estable y falla duro cuando no hay nada que continuar. En una caja que se puede reconstruir desde nada, "reanudar" necesita un "o arranca de nuevo" al lado.
Cuando no hay API de estado, afirma sobre el log de éxito, el específico. No el banner optimista. La línea que solo el camino exitoso puede producir.

Arquitectura de 10 agentes, 1k users, presupuesto: dos pizzas al mes

Franchesco Romero — Sun, 16 Aug 2026 23:36:58 +0000

Arquitectura de 10 agentes, 1k users, presupuesto: dos pizzas al mes - Speaker Deck

Construir sistemas multi-agente no tiene que ser caro. En esta sesión comparto cómo diseñé una arquitectura con 10 agentes de IA sirviendo a más de 1,00…

speakerdeck.com

Este post es el acompañamiento de mi charla en el AWS Summit CDMX 2026 (DEV302). No es un truco de free tier ni una demo de juguete: son 8 o 9 decisiones de ingeniería, cada una medida, que convierten el camino default (unos 250 dólares al mes) en algo que cabe en dos pizzas. Voy a mostrarte los números y el código.

Para que sea concreto uso un caso ficticio llamado Aula, una plataforma de cursos en línea con unos 1,000 estudiantes. El conocimiento ya existe: dudas resueltas, material de cada lección, ejercicios. Diez agentes convierten ese conocimiento en respuestas fundamentadas en el historial. Aula no es un producto real, pero los números sí salen de un sistema real.

El caso: qué hacen los diez agentes

Cinco flujos que ve el estudiante:

Una duda ("no entiendo los closures"), que devuelve una explicación fundamentada en el historial.
Una entrega (sube un ejercicio), que devuelve feedback editable, no la respuesta.
Qué sigue ("¿qué estudio después?"), que devuelve la siguiente lección más un plan de 3 pasos.
Buscar ("¿ya lo preguntaron?"), que devuelve dudas similares ya resueltas.
Resumen de un hilo largo, que devuelve los puntos clave.

Diez agentes en total: classifier, extractor, retriever, enricher, synthesizer, drafter, summarizer, recommender, action_plan y quality_judge. Cada uno es una clase, no un framework. Ahí empieza la historia de costo.

El camino default cuesta 22 pizzas

Si sigues el tutorial que la mayoría encuentra, armas esto: Amazon Bedrock Agents, AgentCore, Amazon OpenSearch Serverless, un NAT Gateway, un Application Load Balancer, Amazon RDS Proxy y AWS X-Ray. Suma unos 250 dólares al mes. Diecisiete pizzas solo de piso fijo, antes de la primera petición.

El reto no es recortar. Recortar es fácil. El reto es sostener el mismo sistema, en producción, seguro, manejable y escalable, gastando lo que dos pizzas. Voy a cotizar cada decisión en pizzas que se comería de tu factura. Una rebanada son unos 1.75 dólares (unos 30 pesos). Una pizza son 8 rebanadas, unos 14 dólares. El tope: dos pizzas, 16 rebanadas, unos 28 dólares al mes.

Decisión 1: un modelo por tarea (el 90/10)

La palanca más grande, y la que no te vende nadie, es el tier por agente. No todos los pasos necesitan el modelo premium.

7 agentes en Amazon Nova Lite (clasificar, extraer, condensar, recomendar, evaluar).
2 agentes en Amazon Nova Pro, solo los que producen lo que LEE el estudiante (synthesizer y drafter).
1 agente con Amazon Titan Embeddings (el retriever, que no es un LLM de chat).

El resultado medido: el 90% de las llamadas al modelo van al tier económico, y el costo baja a unos 0.004 dólares por duda. Si todo corriera en Nova Pro, sería cerca de 10 veces más.

¿Y la calidad? No es fe. Un shadow run midió que Nova Lite clasifica con un 98.5% de acuerdo contra Nova Pro en esa tarea. El tier se elige por dificultad, no por default.

# El tier lo fija el agente, no el framework.
MODEL_LITE = "amazon.nova-lite-v1:0"   # 7 agentes
MODEL_PRO  = "amazon.nova-pro-v1:0"    # 2 agentes: lo que LEE el estudiante
MODEL_EMB  = "amazon.titan-embed-text-v2:0"  # 1 agente: retrieval

class DrafterAgent(BaseAgent):
    name, default_model = "drafter", MODEL_PRO

Ver code/base_agent.py y code/tier_routing.py.

Decisión 2: mata el piso fijo (ingreso y red)

Dos ausencias que casi nadie cuestiona, y que juntas valen casi 5 pizzas que no pago.

Amazon API Gateway, no Application Load Balancer. El ALB cuesta unos 16 dólares al mes fijos, pizza y media, llegue 1 persona o un millón. Amazon API Gateway HTTP API cobra por request: a 1,000 usuarios con tráfico modesto, cerca de 1.5 dólares al mes. Llega al contenedor por VPC Link y service discovery, sin ALB de por medio. ¿Cuándo sí ALB? Routing L7 sofisticado, WebSockets, o miles de peticiones por segundo.

AWS Fargate en subnet pública, no NAT Gateway. El NAT cuesta unos 33 dólares al mes fijos (3 pizzas) aunque el tráfico sea cero. Lo mío: subnet pública con IP pública y un security group que solo deja entrar al VPC Link. La IP es pública pero funcionalmente inalcanzable. Cuidado con el consejo de "usa VPC endpoints": 4 o 5 endpoints a 7 dólares cada uno salen más caros que el NAT. Valen por compliance, no por ahorro.

Decisión 3: usa lo que ya pagas

pgvector, no Amazon OpenSearch Service. A escala de miles de embeddings, pgvector basta y sobra. El menú arranca en OpenSearch a 174 dólares o más, entre 8 y 15 veces mi presupuesto, en una sola línea. Lo mío: CREATE EXTENSION vector en la misma Amazon RDS que ya pago. La pregunta correcta no es si pgvector es tan bueno, es si necesito lo que OpenSearch hace de más. A 3,000 vectores, no.

-- El retriever: distancia coseno con índice HNSW, prefiltrando por curso.
SELECT contenido, resolucion
FROM dudas_embedding
WHERE curso_id = :curso
ORDER BY embedding <=> :q
LIMIT :k;

Tus filas ya son la memoria. AgentCore Memory ofrece memoria semántica gestionada. Pero la memoria de Aula, qué respuestas sirvieron por tema, ya está en filas de Postgres. Leer 20 filas, agruparlas y meterlas al prompt como un bloque de historial son unas 120 líneas y 50 milisegundos. No gana por económico, gana por simplicidad y por no necesitar código nuevo.

Workers asyncio, no AWS Lambda por tarea. Los trabajos programados (reindex, resumen semanal, barrido de evaluaciones, recordatorios) corren como tareas asyncio dentro del contenedor de AWS Fargate que ya está prendido para la API. El break point honesto: con más de una réplica, un cron in process dispara doble, y ahí sí subes a Amazon EventBridge Scheduler apuntando a ECS RunTask (cerca de 0 dólares). Managed cuando el patrón lo justifica, no por default.

Decisión 4: observabilidad por log, no por traza

Latencia, tokens y costo por agente salen de una línea de log en formato EMF (Embedded Metric Format), que Amazon CloudWatch convierte en métrica sin ninguna llamada a la API en el hot path. AWS X-Ray a bajo volumen es casi gratis (unos 0.40 dólares), así que aquí el argumento no es el costo, es el acoplamiento: EMF no necesita SDK ni escala por traza, y tú decides qué métricas existen.

La trampa que sí cuesta dinero: meter un ID de alta cardinalidad (como student_id) como dimensión son miles de métricas custom, cientos de dólares al mes. Los IDs van al cuerpo del log, nunca a la dimensión.

# 1 línea EMF -> métrica en CloudWatch, sin PutMetricData.
def emit_emf(agent: str, model: str, latency_ms: float, cost_usd: float):
    print(json.dumps({
        "_aws": {"CloudWatchMetrics": [{
            "Namespace": "aula/Agents",
            "Dimensions": [["AgentName", "ModelUsed"]],
            "Metrics": [{"Name": "LatencyMs"}, {"Name": "CostUsd"}],
        }]},
        "AgentName": agent, "ModelUsed": model,
        "LatencyMs": latency_ms, "CostUsd": cost_usd,
    }))

Ver code/emf.py.

Decisión 5: seguridad y resiliencia sin inflar la factura

Seguridad. El input del usuario entra a un LLM, así que va como dato delimitado, no como instrucción. Salida estructurada más el juez como respaldo. IAM al mínimo: bedrock:InvokeModel solo sobre los ARNs de mis 2 modelos, no un comodín. Guardrails gestionados solo a escala (PII, toxicidad) o por compliance.

Resiliencia. El estudiante espera unos 2 segundos. Amazon Bedrock puede responder 429 en picos. La respuesta: retry con backoff acotado por el presupuesto de latencia (2 intentos máximo) y fallback de tier. Si Nova Pro está throttled, degrada a Nova Lite con la confianza más baja. Degrada, no revienta. Provisioned Throughput solo si el 429 es crónico, no para un pico.

async def invoke_resilient(prompt, primary=MODEL_PRO, fallback=MODEL_LITE, budget_ms=2500):
    for attempt in range(2):
        try:
            return await invoke(prompt, model=primary, timeout_ms=budget_ms)
        except ThrottlingException:
            await asyncio.sleep(min(0.2 * 2 ** attempt + jitter(), 0.6))
    # sigue throttled: degrada, no revienta
    return await invoke(prompt, model=fallback, confidence_penalty=0.15)

Ver code/resilience.py.

Dónde se va el costo, de verdad

Aquí está lo bonito de medir con EMF: puedes ver dónde vive cada dólar sin instrumentar nada extra.

Concepto	Rebanadas	Costo aprox
AWS Fargate ×2, 24/7	12	22 dólares
Amazon Bedrock (10 agentes)	2	3 dólares
EMF (métricas por log)	1	2 dólares
Amazon API Gateway	1	1 dólar
Total	16	~28 dólares

El 72% de la factura son los dos contenedores de AWS Fargate prendidos todo el tiempo. Todo lo demás junto son 5 rebanadas. La lección: el costo fijo que no usas es tu mayor fuga, y aquí ya está exprimido.

La parte honesta

Redondeo a 2 pizzas, pero son unos 2 y cuarto. El redondeo lo absorbe.
Las cifras del core (AWS Fargate, Amazon Bedrock, EMF) son medidas. Las de tool use en Aula son estimadas.
El costo real de este sistema no es dinero, es tiempo de ingeniería y seguridad. Medir cada decisión toma más trabajo que aceptar el default.

Lo contraintuitivo: baja al crecer

Costo por estudiante al mes, a 1,000 estudiantes: unos 2 centavos.

Como la factura es costo fijo (los contenedores no escalan con el uso), se reparte. Más estudiantes, menos por cabeza. Es lo opuesto a una arquitectura lineal por request. A 10 usuarios sale carísimo por cabeza; a 1,000 sale a 2 centavos, y sigue bajando.

Para llevar

El piso fijo que no usas es tu mayor fuga: NAT, ALB, OCU.
Usa lo que ya pagas: pgvector, asyncio, filas como memoria.
Haz coincidir el tier del modelo con la dificultad de la tarea (el 90/10).
El patrón de uso elige la herramienta, no el default.
La pregunta correcta no es "¿uso managed?", es "¿qué NO quiero mantener?".

Las slides, el código y las notas están en el repositorio. Si vas a construir agentes sobre Amazon Bedrock y el presupuesto importa, empieza por medir dónde se va cada dólar. Casi siempre es una sola cosa.

Demo: https://awssummitcdmx2026.elches.co/

elchesco / diez-agentes-dos-pizzas

Diez agentes en producción sobre Amazon Bedrock por el costo de dos pizzas al mes. Código de acompañamiento (AWS Summit CDMX 2026, DEV302).

Diez agentes en producción por el costo de dos pizzas al mes

Código de acompañamiento de la charla AWS Summit CDMX 2026 (DEV302): un sistema multi agente en producción sobre Amazon Bedrock, con Q&A, feedback de ejercicios, recomendaciones, búsqueda y resumen, para unos 1,000 usuarios, por unos 28 dólares al mes.

Post: Arquitectura de 10 agentes, 1k users, presupuesto: dos pizzas al mes
Slides: Speaker Deck

El caso es ficticio: Aula, una plataforma de cursos en línea con ~1,000 estudiantes. No es un producto real. Los números (latencia, costo por duda, picos de conexiones) salen de un sistema real. Los snippets son ilustrativos: muestran cada decisión de costo, no son un proyecto ejecutable completo.

Las decisiones, en código

Cada archivo es una decisión de la charla. Los marcados con 🔒 estaban en slides que oculté por tiempo, pero el código va aquí completo.

Archivo	Decisión

…

View on GitHub

Gracias por leer. Preguntas y correcciones son bienvenidas.

¿Cómo revertir una migración promovida a Aurora sin perder los datos nuevos?

Franchesco Romero — Sat, 25 Jul 2026 22:56:24 +0000

Migraste una base de datos MySQL de Amazon RDS a Amazon Aurora. La read replica de Aurora se puso al día, la promoviste, cambiaste el endpoint de la app, y ahora los writes aterrizan en Aurora.

Diez minutos después, o quizá tres horas después, algo anda mal y quieres regresar a la vieja instancia de RDS.

Aquí está la trampa. La vieja instancia de RDS está congelada en el momento en que hiciste el corte. Cada pedido, registro y edición que pegó en Aurora desde entonces no existe en RDS. "Revertir" de forma ingenua significa "tirar a la basura todo lo que pasó en la base de datos nueva". Y el arreglo de siempre, tomar una ventana de mantenimiento y recargar RDS desde Aurora, no escala: a 100 TB una recarga se mide en días, no en minutos.

Esta es la historia de construir una reversión que conserva los datos
nuevos, probarla en AWS real hasta que se rompió de maneras interesantes, y reducirla a un manual de operaciones que una persona cansada pueda seguir a las 3 de la mañana. Todo lo de abajo lo corrí en instancias desechables en una región aislada y las borré después.

TL;DR

La vieja instancia de RDS no debería ser un backup congelado. Hazla una réplica inversa viva de Aurora: después de promover Aurora, apunta RDS de vuelta a Aurora sobre replicación por binary-log para que siga tragándose cada write nuevo. La reversión es entonces "déjala terminar, luego cambia el endpoint".
Con la réplica inversa mantenida caliente, el tiempo de reversión es constante e independiente del tamaño de la base de datos: como 1 a 5 minutos a 1 GB y a 100 TB, porque haces el corte del delta, no de la base de datos.
La única compuerta que importa es Seconds_Behind_Source = 0. Llegar ahí significa que RDS tiene el 100% de los writes de la era Aurora. Hacer el corte antes pierde datos.
Dos rutas funcionan: replicación nativa por binlog (recomendada, barata, replica DDL) y AWS DMS (más manejada por consola, pero ignora en silencio DROP TABLE y unos cuantos ALTER). Las dos las validé en vivo.
Un "standby frío vacío" (una instancia lista pero sin datos) cuesta lo mismo por hora que una réplica caliente y te da la velocidad de reversión de no tener nada. Si pagas por mantener una caja corriendo, mantenla caliente.
Los filos que costaron tiempo real de debug: una regla de security group que falla en silencio, una edición de parameter group que es todo-o-nada, un stored procedure cuyo conteo de argumentos no es lo que los docs implican, y una regla de compatibilidad de versión que bloquea la migración de plano.

La forma del problema

La migración hacia adelante de RDS a Aurora es una cosa resuelta de un solo botón: creas una read replica de Aurora desde la instancia de RDS, esperas, promueves. AWS hace el snapshot y convierte por ti. Esa parte la tomo como dada.

La dirección interesante es hacia atrás. Una vez que Aurora es primaria y toma writes, la vieja instancia de RDS se va quedando más desactualizada cada segundo. Una reversión que importa tiene que responder una pregunta: ¿a dónde van los writes de la era Aurora? Si la respuesta es "a ningún lado, los perdemos", no es una reversión, es un desastre con pasos extra.

La respuesta que escala es invertir la replicación. Cuando RDS era la fuente y Aurora la réplica, los datos fluían de RDS a Aurora. Después de la promoción lo configuras al revés: Aurora es la fuente, RDS es la réplica.
Ahora RDS jala de forma continua todo lo que Aurora escribe. La vieja
instancia no está congelada, es un espejo caliente que siempre va un segundo o dos atrás de Aurora. Revertir se vuelve: detén Aurora, deja que RDS termine el último segundo, cambia el endpoint.

La parte elegante es el costo de la sincronización inicial. En el instante de la promoción, RDS ya es byte por byte igual a Aurora, porque era la fuente. Así que el enlace inverso no re-copia la base de datos. La siembras en la coordenada de la promoción y de ahí en adelante solo carga el delta.
Por eso el tamaño de la base de datos deja de importar.

Construyéndolo, y viéndolo romperse

Levanté el mundo post corte en instancias desechables: un clúster de Aurora MySQL como "prod nuevo", una instancia de RDS for MySQL como el objetivo de reversión, en una región aislada. Luego cableé la replicación inversa y la empujé por el camino feliz y por los caminos de falla.

Callejón sin salida 1: el security group que falla en silencio

Primer intento de arrancar la replicación, la réplica nada más se quedó ahí sentada:

Replica_IO_Running: Connecting
Source_Server_Id: 0
Last_IO_Errno: 0
Last_IO_Error:

Connecting, para siempre. Sin número de error, sin texto de error. El hilo de IO estaba tratando de alcanzar Aurora y no recibía nada, pero nada se reportaba. La causa: las dos bases de datos eran públicamente accesibles (para que mi cliente de SQL las alcanzara), lo que significaba que la réplica resolvía el endpoint de Aurora a su IP pública. La conexión de replicación entonces llegaba a Aurora desde la IP pública de la réplica, que el security group no permitía. Un drop silencioso, presentado como un esperanzado Connecting.

La lección no es "abre la IP pública". Es lo contrario. En producción, mantén las dos bases de datos privadas. Entonces el tráfico de réplica a fuente fluye sobre IPs privadas dentro de la VPC, y una sola regla de autorreferencia del security group lo cubre. La accesibilidad pública fue lo que creó el problema.

El camino feliz

Con la red arreglada, la mecánica funcionó exactamente como se anunciaba.
Escribe dos filas a Aurora, y en unos segundos aparecen en RDS. Detén el enlace, drena a cero lag, corre los dos procedimientos de reversión, y RDS se vuelve una primaria independiente que acepta writes mientras Aurora queda desacoplada. Cero datos perdidos. La secuencia completa está en el manual de operaciones al final.

Callejón sin salida 2: revertir demasiado pronto pierde exactamente lo que crees

Todo el diseño descansa en una sola disciplina, así que me obligué a verla fallar. Detuve la réplica, escribí dos filas más a Aurora, y luego "reverti" sin esperar a que la réplica se pusiera al día.

Aurora: 7 filas.
RDS después de revertir: 5 filas.

Las dos filas escritas durante la ventana se fueron. Esta es toda la razón por la que Seconds_Behind_Source = 0 es una compuerta dura y no una sugerencia. La reversión es sin pérdidas solo si congelas los writes en la fuente y dejas que la réplica drene a cero antes de hacer el corte.

Callejón sin salida 3: qué rompe de verdad la réplica

Esperaba que los writes divergentes en el objetivo rompieran la replicación ruidosamente. No lo hicieron. Las read replicas de RDS traen por default slave_exec_mode = IDEMPOTENT, que en silencio hace que la fuente gane un conflicto de primary key en lugar de dar error. Así que un write perdido en el objetivo de reversión se sobreescribe calladito, no se marca.

Lo que sí la rompe es el schema drift. Tiré una columna en el objetivo, luego escribí una fila en la fuente que usaba esa columna. El aplicador de SQL se detuvo en seco:

Last_SQL_Errno: 13146
Replica_SQL_Running: No

La réplica se congeló y se quedó atrás en silencio, todavía reportando un hilo de IO sano. La conclusión operativa: alarma sobre que Replica_SQL_Running voltee a No, no solo sobre el lag. Y durante la ventana de standby caliente, trata el objetivo como estrictamente solo lectura y congela el DDL en la fuente.

Callejón sin salida 4: el conteo de argumentos que los docs implican está mal

La variante GTID es la que quieres en producción, porque sobrevive a un failover de Aurora. Al configurarla, el stored procedure rechazó mi llamada:

ERROR 1318 (42000): Incorrect number of arguments for PROCEDURE
mysql.rds_set_external_master_with_auto_position; expected 6, got 5

El procedimiento toma seis argumentos: host, port, user, password,
ssl_encryption, y delay. Leyendo ejemplos que omiten el delay final, es fácil pasar cinco. Trampa relacionada: el tunable se llama gtid-mode con guion en el parameter group, mientras que gtid_mode con guion bajo es una vista de runtime de solo-lectura que rechaza modificaciones.

Callejón sin salida 5: la edición del parameter group que se aplicó a medias

Esta costó el más tiempo y produjo el síntoma más confuso. Después de
habilitar GTID, la replicación no arrancaba:

Got fatal error 1236 from source when reading data from binary log:
'Binary log is not open'

En Aurora, @@gtid_mode era ON, pero @@log_bin era 0. El binary logging estaba apagado, así que no había nada que replicar. La causa: había puesto binlog_format=ROW y dos parámetros de GTID en una sola edición del parameter group, y uno de los nombres de parámetro estaba mal. Un modify de parameter group es todo o nada. Toda la edición se rechazó, lo que en silencio dejó binlog_format en su default OFF. Los parámetros de GTID, puestos en una llamada posterior exitosa, estaban bien, que es por lo que el
estado se veía a medio arreglar.

El arreglo: pon binlog_format=ROW, reinicia el writer de Aurora, y
verifica @@log_bin = 1 y un SHOW MASTER STATUS no vacío antes de cablear la réplica. Aurora necesita el reinicio para de verdad abrir el binary log.

Una vez que eso quedó bien, el auto-posicionamiento de GTID funcionó de principio a fin:

Auto_Position: 1
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 0
Retrieved_Gtid_Set: <aurora-uuid>:1-3

La segunda ruta: AWS DMS

El binlog nativo es la ruta recomendada, pero AWS DMS vale la pena conocerlo porque es casi por completo manejado por consola. Corrí una tarea de full load más CDC de Aurora a una segunda instancia de RDS. Funcionó, y es rápido:

Métrica	Resultado
Full load, 2 tablas, 274 MB	20.2 s (como 48 GB/h en la instancia más chica)
CDC, un solo insert	propagado en menos de 12 s

Pero DMS tiene un hueco que el binlog no. Creé una tabla en Aurora (se replicó bien), luego la tiré:

Aurora: tabla ida.
Objetivo de DMS: tabla todavía ahí.

El CDC de DMS no replica DROP TABLE ni RENAME TABLE, e ignora unos cuantos ALTER. Sobre una ventana de reversión larga eso es schema drift silencioso. Usa DMS si quieres el flujo de consola y puedes vivir con la restricción; usa binlog si quieres que el DDL venga incluido.

Los números, y por qué el tamaño deja de importar

El punto de todo el ejercicio es que el tiempo de reversión se desacopla del tamaño de la base de datos. Dos tablas cuentan la historia. La primera es la ejecución de la reversión cuando la réplica caliente se mantiene corriendo:

Tamaño de la BD	Tiempo de reversión (réplica caliente)
1 GB	~1 a 2 min
100 GB	~1 a 3 min
1 TB	~1 a 5 min
100 TB	~1 a 5 min

Constante. La única variable es cuánto delta se apiló durante el incidente, y una instancia de clase producción drena eso a como 1 a 2 GB por minuto, así que hasta un backlog gordo de 10 GB se limpia en minutos de un solo dígito.

La segunda tabla es lo que pasa si no mantuviste la réplica caliente y tienes que reconstruir el fallback desde cero. Este es el camino a evitar:

Tamaño de la BD	Reconstruir vía DMS paralelo (~0.9 TB/h)	Reconstruir vía dump + restore (~60 GB/h)
100 GB	~7 min	~1.7 h
1 TB	~1.1 h	~17 h
100 TB	~4 a 5 días	inviable

A 100 TB la diferencia es minutos contra días. Ese es todo el argumento para mantener la vieja instancia caliente.

Un ancla medida para los números de reconstrucción: en una instancia de clase producción (32 vCPU, 256 GB) un insert lógico de un solo hilo corrió a como 1.2 GB por minuto, o 72 GB/h. El apply de binlog basado en filas y el restore lógico son del mismo orden de magnitud, que es sobre lo que están construidos los estimados de arriba. Las mediciones de instancia chica (un par de MB/s de apply de binlog, como 48 GB/h de full load de DMS) son pisos conservadores que escalan hacia arriba con el tamaño de la instancia.

La trampa del standby frío vacío

Un punto medio tentador es mantener una instancia de RDS aprovisionada y corriendo pero vacía, lista para llenarse bajo demanda. Suena ahorrador. Es lo peor de los dos mundos.

Una instancia vacía e inactiva cuesta lo mismo por hora que una réplica caliente, porque pagas por el cómputo, no por los datos. Pero una instancia vacía no tiene línea base, así que revertir significa cargar la base de datos entera en ella primero. Ese es el camino de reconstrucción lineal con el tamaño: minutos a 100 GB, días a 100 TB. Pagas precio completo de standby por la velocidad de reversión de no tener nada. Peor, estarías recargando desde Aurora, la base de datos de la que estás tratando de escapar, así que si el gatillo fue corrupción la copias fielmente.

Si estás pagando por mantener una caja corriendo como objetivo de reversión, mantenla caliente. Si de plano no puedes, la opción honesta es ningún standby y una reversión aceptada de varios días con pérdida alta, no una caja vacía que cuesta lo mismo que la buena opción.

El manual de operaciones

Todo el asunto en una oración: la vieja instancia de RDS es una copia viva que ha estado tragándose cada write de Aurora desde el corte, así que revertir es detener Aurora, dejar que RDS termine los últimos writes, cambiar el endpoint.

Configúralo una vez, cuando promuevas Aurora:

Agarra la coordenada de binlog de Aurora en el instante en que la app empieza a escribirle (SHOW MASTER STATUS).
Apunta RDS a Aurora desde esa coordenada (mysql.rds_set_external_master o la variante de auto-posición de GTID) y arranca la replicación.
Confirma Replica_IO_Running: Yes y Replica_SQL_Running: Yes. Déjala corriendo. Alarma sobre que el hilo de SQL se detenga. No le escribas a RDS y no cambies el schema en Aurora mientras corre.

Revierte, cuando lo decidas:

Detén que la app le escriba a Aurora.
SET GLOBAL read_only = ON en Aurora, para que nada se cuele.
Observa RDS hasta Seconds_Behind_Source = 0 con los dos hilos en Yes. Esta es la compuerta. Significa que RDS ahora tiene cada write de la era Aurora. Si un hilo dice No, párate y escala, no hagas el corte.
mysql.rds_stop_replication y luego mysql.rds_reset_external_master en RDS.
SET GLOBAL read_only = OFF en RDS.
Apunta el endpoint de la app a RDS. Vuélvela a levantar.

No hay deshacer después del paso 4. Una vez que el enlace se corta y RDS es escribible, las dos bases de datos son independientes. Que es exactamente por lo que el paso 3 no es opcional: es la garantía de que te estás llevando todos los datos de vuelta contigo.

DEV Community: Franchesco Romero

Lambda Web Functions cobra la memoria mientras el entorno viva: el punto de equilibrio contra Lambda clásica

Qué cambia en la factura

El punto de equilibrio

Una API real

Cuándo conviene

Endurecer servidores mcp stdio

El punto de partida: qué hizo Langflow

elchesco / blog-mcp-stdio-hardening-code

Code companion - an MCP stdio server is a shell command: hardening after the Langflow CVE

Code companion: an MCP stdio server is a shell command

Suggested reading order

Ronda 0: el bug, reducido

Ronda 1: el arreglo que aguanta

Ronda 2: mide tu propia máquina

Ronda 3: política para una flota

Ronda 4: la identidad como la que corre una herramienta

Cómo se ven los buenos defaults

Lecciones

Auditar un pipeline de IaC después del provider de Terraform troyanizado

Qué es un provider troyanizado, en términos de CDK

El punto de partida

Hallazgo 1: el rol de OIDC que nadie asume

Hallazgo 2: el install y el synth corren con credenciales de deploy

Hallazgo 3: un lockfile prueba igualdad, no seguridad

Hallazgo 4: un runner de larga vida con derechos de deploy, corriendo código de PR

Hallazgo 5: nadie lo vería

Para lectores de Terraform y OpenTofu

Lecciones

Auditar agentes como identidades

Dos tipos de agente

La pregunta cara: qué pueden alcanzar los agentes

Los agentes de modelo: con alcance a propósito

El agente de código: con alcance en el papel

El agente que agregarías al pipeline

Una revisión para cada agente

Qué ayudaría después

Checklist

De $32 a $0.90 al mes: un pool de CI que solo existe cuando hace falta

TL;DR

La forma

El pool

Despertar y dormir sin tocar los otros workflows

Cómo se ve en el log de escalado

CI en un pull request

El reloj 400 días adelante

Deploys en push a main

Cuando spot se lleva la caja a media corrida

Qué mostraron los logs

2 GB de RAM y nada de laptop: cómo se ve de verdad desarrollar en iPad en 2026

Qué cambió en 2026

Qué necesitas

Empieza sin configurar nada

Si todavía no tienes caja

Configura la tableta

Las tres maneras de entrar

1. La sesión del navegador

2. Una terminal de verdad sobre la VPN de malla

3. Session Manager en el navegador, como rompe-cristal

Por qué las tres

El editor

El trabajo pesado va en otro lado

Lo que no funciona

Github Actions: Re-intentar automáticamente los jobs de CI que un reclamo de spot instance mató

Qué pasó

Qué hace

Cómo usarlo

La mitad de infraestructura

Qué no arregla

elchesco / rerun-on-runner-loss

Tell a spot reclaim apart from a failing test, and re-run only the jobs AWS killed.

Auto-rerun CI jobs that a spot reclaim killed

Layout

Tres capas de contexto para un agente de código, ordenadas por garantía

Tres capas de contexto para un agente de código, ordenadas por garantía

Cómo evité que Claude repitiera mis errores. - Speaker Deck

TL;DR

El incidente

Capa 1: lo que el modelo no puede deducir

Podar es una mejora medible