AWS Blocks: backend en AWS sin aprender infraestructura
AWS lanzó en preview AWS Blocks, un framework open-source en TypeScript que te da backend sobre AWS sin tener que aprender herramientas de infraestructura. Corre todo en local sin cuenta de AWS y, cuando estás listo, deployás el mismo código a la nube sin cambiar un solo import. El dev advocate Salih Güler lo mostró el 18 de junio de 2026 armando un predictor de llaves del Mundial.
AWS Blocks es un framework TypeScript de código abierto que abstrae servicios de AWS (bases de datos, autenticación, tiempo real, agentes de IA, tareas programadas) detrás de primitivas tipadas llamadas “blocks”. Si buscás un tutorial de AWS Blocks para arrancar tu desarrollo backend, la gracia es que escribís lógica de aplicación normal y el framework genera la infraestructura por vos.
En 30 segundos
- Es gratis el framework: AWS Blocks no cobra licencia. Pagás solo los servicios de AWS que consumas en producción.
- Cero cuenta de AWS para empezar: todo corre en local. La cuenta recién hace falta para deployar.
- Mismo código en local y en la nube: el deploy no pide reescribir imports ni adaptar configuraciones.
- Trae bloques listos: tiempo real (WebSocket), auth con JWT, tablas NoSQL, agentes de IA (Ollama) y tareas con cron.
- Demo real: un predictor de llaves del Mundial con chat IA, leaderboard y sync horario de resultados.
¿Qué es AWS Blocks y cómo funciona como framework?
Ponele que querés un backend con base de datos, login y WebSockets, pero no tenés ganas de pelearte con CDK, CloudFormation ni el IAM de turno. Esa es la fricción que AWS Blocks intenta sacar del medio.
Según el posteo oficial en dev.to del equipo de AWS, el framework te da “capacidades de backend sobre AWS sin aprender herramientas de infraestructura”. En la práctica, cada funcionalidad es un block que importás y usás como código TypeScript común. El framework se encarga de mapear ese block al servicio de AWS que corresponde.
La diferencia con el CDK tradicional es de altura. Con CDK definís infraestructura. Con Blocks escribís la app, y la infra sale como subproducto. Y como todo está tipado, el frontend sabe qué forma tienen tus datos sin que vos copies y pegues interfaces a mano. Complementá con cómo integrar modelos de IA en tu aplicación.
| Aspecto | AWS Blocks | CDK tradicional |
|---|---|---|
| Qué escribís | Lógica de app en TypeScript | Definiciones de infraestructura |
| Cuenta de AWS para desarrollar | No (corre local) | Recomendable para probar servicios reales |
| Type-safety frontend/backend | Automático | Manual |
| Costo del framework | Gratis (pagás servicios AWS) | Gratis (pagás servicios AWS) |
| Personalización avanzada | Cae a CDK cuando lo necesitás | Control total desde el arranque |
Tutorial de AWS Blocks: requisitos y configuración del desarrollo inicial
Para seguir el ejemplo del Mundial necesitás Node.js instalado y, opcional, Ollama si querés correr el agente de IA en tu máquina sin pegarle a la nube.
El arranque es así: clonás el repo, hacés checkout de la branch que trae solo el frontend (un React 19 con Vite y Tailwind, con toda la UI ya armada pero sin backend), y levantás el server. En http://localhost:3000 vas a ver la cáscara de la app. No funciona nada todavía porque no hay backend. Lógico.
Después agregás Blocks con un comando:
- Instalación:
npm create @aws-blocks/blocks-app@latestgenera una carpeta con dev server, config de deploy en CDK y una app de ejemplo (un todo) que vas a reemplazar. - Dos puertos: al levantar el proyecto corren el frontend Vite en el 3000 y el backend Blocks en el 3001.
- Punto de entrada dual: el archivo
aws-blocks/index.tsmezcla código de runtime con la definición de infraestructura. Ahí vive todo.
¿Cómo construir funcionalidades en tiempo real con WebSocket?
Acá viene lo bueno: el block de Realtime. En la demo del Mundial, cuando un usuario carga su predicción, los demás la ven aparecer al toque. Eso es pub/sub bidireccional sin que tengas que parar un servidor de WebSockets a mano.
El leaderboard usa la misma idea. A medida que entran resultados reales, los puntajes se actualizan en vivo para todos los que están mirando. El mismo bloque que en local te sincroniza entre pestañas, en producción te lo resuelve la infra de AWS, sin que cambies el código. Esto se conecta con lo que analizamos en automatizar el despliegue con CI/CD.
Autenticación, autorización y persistencia de datos
El framework ofrece varias opciones de autenticación. La más directa es AuthBasic con JWT: definís usuarios, manejás sesiones y listo.
Para los datos hay dos caminos. DistributedTable es una tabla NoSQL para lo que escala (las predicciones de cada usuario, por ejemplo). KVStore es un almacén clave-valor para cosas más simples. Definís el esquema en TypeScript una vez, y ese tipado viaja al frontend automáticamente. Si cambiás un campo en la tabla, el frontend te marca el error de compilación antes de que rompas nada en runtime.
Integración de inteligencia artificial y agentes IA
El predictor tiene un chat con un agente que conoce los rosters de cada selección y su ranking FIFA. Eso sale del block de Agent.
Para el modelo, la fuente muestra Ollama corriendo local (gratis, ideal para desarrollar sin gastar). La idea es la misma de siempre con Blocks: probás con Ollama en tu máquina y, al deployar, el agente queda enchufado a la infra de AWS sin que reescribas la lógica del chat. Lo explicamos a fondo en almacenar datos en bases de datos en la nube.
Eso sí: el agente es tan bueno como el contexto que le pasás. Si los datos de rankings están desactualizados, el “experto” en fútbol te va a contestar con información vieja. Ojo con eso.
Automatización con tareas programadas y eventos
¿Cómo entran los resultados reales de los partidos? Con una tarea programada. El block de CronJob corre cada hora, pega a una API de resultados deportivos y actualiza la base. Después el leaderboard se recalcula solo.
Es el patrón clásico de batch horario: traés datos externos, los guardás, disparás el recálculo. Si la API externa falla, conviene que pienses el manejo de reintentos, porque un cron que falla en silencio te deja el leaderboard congelado y nadie se entera hasta que reclama.
De código local a producción en AWS sin cambios
Esta es la promesa central. Deployás y el mismo código que corría en tu máquina se va a AWS. Blocks genera el CDK por debajo, así que no tocás un import. En elegir la herramienta de automatización correcta profundizamos sobre esto.
Si necesitás algo muy específico que el framework no cubre, tenés la puerta de salida: usás CDK directamente para personalizar. No quedás encerrado. El monitoreo y los logs van a CloudWatch como en cualquier app de AWS.
Para el frontend de un proyecto así, si tu público es de Argentina o LATAM, alojarlo cerca importa para la latencia. Podés servir el front desde donweb.com y dejar el backend en AWS, o usar el hosting que mejor te cierre. El backend serverless de Blocks no te ata a una sola arquitectura de frontend.
Errores comunes al empezar con AWS Blocks
- Usar Node viejo: conviene tener una versión reciente de Node.js. Con una versión vieja el
npm createpuede fallar o tirar errores raros. Verificá connode -vantes de arrancar. - Olvidarse del puerto 3001: si solo levantás el 3000, ves la UI pero “no funciona nada”. El backend vive en el 3001. Los dos tienen que estar corriendo.
- Asumir que el framework cuesta plata: AWS Blocks es gratis. Lo que pagás son los servicios de AWS en producción (las tablas, el scheduler). En local no gastás nada.
- Saltearse Ollama en desarrollo: si no configurás Ollama, el agente IA no responde en local. No es un bug, es que falta el modelo.
Preguntas Frecuentes
¿Qué es AWS Blocks y para qué sirve?
AWS Blocks es un framework open-source en TypeScript que da capacidades de backend sobre AWS sin necesidad de aprender herramientas de infraestructura. Sirve para construir apps full-stack con base de datos, autenticación, tiempo real y agentes de IA escribiendo solo lógica de aplicación. Está en preview desde junio de 2026.
¿Se puede usar AWS Blocks sin una cuenta de AWS?
Sí. Todo el desarrollo corre en local sin cuenta de AWS. La cuenta recién hace falta cuando querés deployar la aplicación a producción, momento en el que se generan los recursos reales en la nube.
¿Cuánto cuesta usar AWS Blocks?
El framework es gratuito y open-source. El costo aparece solo por los servicios de AWS que consumas en producción, como los agentes de IA, las tablas NoSQL o el scheduler de tareas. En local no hay cobro.
¿Cuáles son los requisitos técnicos para empezar?
Necesitás Node.js instalado y, de forma opcional, Ollama si querés correr el agente de IA local. El proyecto se crea con npm create @aws-blocks/blocks-app@latest y levanta el frontend en el puerto 3000 y el backend en el 3001.
¿Cómo se pasa de desarrollo local a producción sin cambiar código?
Al deployar, AWS Blocks genera la infraestructura en CDK automáticamente y el mismo código que corría en local se ejecuta en AWS, sin modificar imports ni configuraciones. Si necesitás personalización avanzada, podés bajar a CDK directamente.
Conclusión
AWS Blocks ataca un dolor concreto: la distancia entre saber escribir una app y saber pararle la infraestructura en AWS. Que corra todo en local sin cuenta y que el deploy no pida reescribir código es lo más interesante de la propuesta.
Está en preview, así que tomalo con pinzas para producción seria todavía. Pero si querés prototipar un backend con tiempo real, auth y un agente de IA sin perder días en CDK, vale la pena clonar el repo del predictor del Mundial y armarlo siguiendo el tutorial oficial. El mejor modo de saber si te sirve es escribir el primer block.
