Introducción

Este es el segundo año que puedo asistir al AWS Ambassador Summit en Seattle gracias a Logicalis Spain.

El AWS Ambassador Summit es un evento de 3 días en el que todos los AWS Ambassador podemos ir a aprender y hacer comunidad.

En estos 3 días AWS nos cuenta muchas cosas que están bajo NDA y que no puedo contar, pero hay otras que sí.

El evento tiene diferentes tipos de charlas, desde charlas más estratégicas para Partners (recordad que esto me lo sponsoriza mi empresa), charlas sobre nuevos servicios o novedades (NDA), charlas estratégicas sobre AWS (hacia dónde vamos), mesas redondas con los Service Teams de AWS (muchas preguntas y roadmap), un workshop de agentes (basado en la FIFA World Cup 2026) y varios eventos para socializar.

Además, durante este evento podemos disfrutar del conocimiento de mucha gente importante de AWS que participa en las diferentes charlas como Rahul Pathak, Rudy Chetty, Jigar Thakkar, Laura Grit, e incluso este año tuvimos la suerte de que se pasara a saludar Swami Sivasubramanian.

Pero qué es lo más importante del evento, no son ni las charlas ni los roadmaps, ni estar en las oficinas de AWS en Seattle, ni conocer a Jeff Barr en persona (aunque esto último mola mucho).

Lo más importante es que nos juntamos más de 120 Ambassadors de 40 países diferentes y podemos compartir nuestros puntos de vista, nuestros problemas (que se parecen mucho) y cómo vemos las cosas a futuro.

Esto último puede parecer hasta contraproducente para nuestras empresas, pero realmente es todo lo contrario, porque en casi el 95% de los casos no compartimos región de negocio e incluso si lo compartimos no solemos competir directamente, además de que obviamente no nos contamos las estrategias de nuestras empresas, pero sí discutimos sobre lo que vemos.

Os puedo decir que no hay otro sitio en el que sienta un síndrome del impostor tan grande como aquí y esto no es falsa humildad, sé que soy excepcional en mi trabajo, pero es que dentro de este programa está lo mejor de lo mejor, el ser un crack es el mínimo necesario.

Agentes, Agentes y más Agentes.

No creo que os sorprenda si os digo que todo ha girado en torno a los agentes y todas las nuevas capacidades que se van a desbloquear próximamente.

Aquí hay algo que sospechaba: los roadmaps a un año se han terminado. Con toda la revolución Agentic la industria ha llegado a velocidades absurdas. Tanto que ahora mismo pensar en lo que puede venir dentro de un año ha dejado de tener sentido, podemos hacer esbozos de hacia dónde queremos ir, pero no podemos plantearnos revoluciones a un año cuando dentro de unos meses todo puede cambiar.

Pero aquí han surgido varias cosas que me gustaría comentar con más detalle.

La importancia del dato.

Es verdad que la industria se mueve muy rápido, pero a veces nos tenemos que parar a reflexionar. Por mucho que hagamos agentes muy inteligentes que estén coordinados entre sí, que tengan unos prompts increíbles con integraciones vía MCP conectadas a tus APIs, bases de datos y herramientas internas, si el dato que consumen es malo o está desactualizado, no sirven de nada y sus respuestas van a ser malas.

Por poner un ejemplo, un sistema agéntico para automatizar las operaciones, si está tirando de procedimientos desfasados o solapados o incluso a los que les faltan pasos (porque el operador los conoce), va a fallar o realizar cosas que no queremos.

Y hablando entre nosotros, es algo bastante habitual, en muchos casos nos estamos encontrando que el paso de mejorar, gobernar y basarse en datos no se ha realizado, pero queremos implantar sistemas agénticos ya.

Muchas arquitecturas son deficientes.

Cuando dos arquitectos se juntan, siempre van a salir las miserias, así que imaginaros si nos juntamos más de 100.

Por eso salió el caso de PocketSO, es verdad que es un caso muy límite y que el problema no era el agente en sí, ni siquiera que tuviese muchos permisos (aunque parte del problema era).

El problema principal es que la arquitectura de la solución no seguía las buenas prácticas mínimas, los entornos no estaban separados, los backups estaban en los mismos volúmenes y se podían modificar, etc.

Es verdad que dar permisos root a un agente, sin definir límites es un problema, pero hay muy malas arquitecturas en producción, es algo que todos sabemos, que todos sufrimos y que no es algo local, pasa en todo el mundo.

Y esto es algo que vamos a ver mucho por desgracia, de hecho en ocasiones lo vemos sin necesidad de que esté la IA involucrada.

Alguien no sabía que tenía que hacer un ritual arcano antes de una subida a producción y el entorno entero se ha caído durante horas. Suena a broma pero muchas veces hacemos cosas mal hechas simplemente porque ya las tenemos automatizadas y en nuestro contexto, cuando alguien sin ese contexto lo ejecuta, se produce una caída a producción de 20 horas (nunca me ha pasado…).

Esto es algo que en general preocupaba mucho, dar las llaves del calabozo a un agente sin ese contexto y sin solucionar estos problemas puede ser muy problemático.

El Gap entre C-Level y la capa Técnica.

Esto es algo que también ha salido mucho en nuestras conversaciones: hay una presión en los C-Level por usar sistemas agénticos que es desmesurada y en muchas ocasiones absurda.

No me malinterpretéis, probablemente muchos de nosotros llevemos usando agentes, asistentes y GenAI desde el inicio de esta revolución, pero también gracias a esto sabemos de sus limitaciones.

Sabemos cómo usar los prompts, añadir contexto a las steering files, añadir Skills, revisar por qué el prompt se está saltando una instrucción importante, saber que un contexto gigante es casi peor que uno pequeño, aprender a estructurar los contextos para facilitar su uso, etc. Si os habéis pegado con agentes sabéis de qué hablo.

El problema es que todos estamos sufriendo en muchas ocasiones que alguien con un prompt mínimo (y probablemente malo) intenta decirte cómo hacer tu trabajo, cómo montar una arquitectura, incluso retando tus decisiones sin poder defender lo que la IA le ha dicho (la frase de “me lo ha dicho Claude o ChatGPT” se usa demasiado). Esto está produciendo un gap gigante en la implantación agéntica.

En muchos casos la visión ejecutiva es muy sencilla, cuando esta implementación tiene muchas más aristas de las que creemos.

Algo que me ha pasado últimamente es que me llega una arquitectura hecha con IA para validarla porque hay que implementarla ya y resulta que no hay por donde cogerla, no se ha tenido en cuenta nada del contexto de lo que existe actualmente, si preguntas cosas por un modelo de datos o como has pensado la seguridad te miran raro.

El problema no es que use IA para explorar ideas (eso está genial), el problema es confundir un mal output de un LLM con un plan validado (OjO que un agente bien montado lo puede hacer). Y nosotros nos quedamos entre la espada y la pared: o lo rechazamos y parecemos resistentes al cambio, o lo aceptamos y firmamos una deuda técnica que vamos a pagar durante años.

Qué es un Agente.

Los agentes son el futuro, pero todo es un agente.

Esto puede parecer absurdo, pero todos estamos viendo que en muchas ocasiones se habla de agentes, cuando se está usando un automatismo de toda la vida o incluso peor, gente que está convirtiendo en agentes automatizaciones de toda la vida, haciendo llamadas a un LLM solamente para justificar que están usando agentes.

He visto cosas que no creería nadie: un “agente” que llama a un LLM para parsear un JSON que tiene un esquema fijo, otro que usa Claude para decidir si un número es mayor que otro, y mi favorito personal, uno que invoca un modelo de lenguaje para hacer un grep en un fichero de log. Eso no es un agente, eso es quemar dinero con estilo.

Los agentes son fundamentales cuando hay ambigüedad, cuando necesitas razonamiento, cuando el camino no es determinista. Ahí es donde el stack tiene sentido: un modelo en Bedrock que razona, Agent Core que le da identidad y gobernanza, Strands SDK para orquestar el loop, y MCP para conectar con el mundo exterior. Eso es un agente. Pero si tu flujo es “si A entonces B”, eso es un if de toda la vida y no necesita un LLM por detrás.

Creo que todos hemos visto a gente usar agentes y llamadas a un LLM para hacer algo que hace un script o tool que ya existe o que es sencillo de implantar. Y el problema no es solo el coste (que también), sino que estás añadiendo complejidad, indeterminación y latencia a algo que antes era simple, instantáneo y predecible.

El uso de asistentes a nivel de proyecto.

Este fue uno de los últimos temas, además de porque fue algo que vimos el último día con Laura Grit y cómo AWS había usado un approach nuevo para el Proyecto Mantle usando equipos integrados con agentes.

Esto me pareció bastante interesante, porque a día de hoy en la mayoría de proyectos se utilizan los asistentes y agentes de forma masiva, pero en muchas ocasiones sin un control.

Así que me parece interesante abrir este debate y empezar a gestionar los equipos con un enfoque agéntico, sabiendo cómo podemos mejorar y acelerar los proyectos con una calidad adecuada.

Algo interesante era que todo el equipo tiene un steering compartido y por otro lado que hay que revisar el código para conocerlo, entenderlo y poder defenderlo. Si no eres capaz de hacer estas 3 cosas, la calidad de tus proyectos se va a resentir.

Ojo, esto no significa hacerlo todo a mano, sino poder defender las cosas que vas a implantar y no utilizar el comodín de “es que esto me lo pasó mal mi agente de IA”.

Nadie va a pensar en los Juniors.

Esto es algo que me preocupa bastante. Ahora mismo no me gustaría ser alguien que está estudiando con un panorama que puede ser desolador, muchas de las tareas que hacían los perfiles Junior están siendo sustituidas por agentes y estamos perdiendo ese conocimiento.

Si no hay Juniors ahora, no vamos a tener Seniors en el futuro y parece que en muchos casos estamos olvidándonos de esto.

Antes un Junior aprendía a prueba y error, peleándose con su código, entendiendo por qué algo no funcionaba. Esos fallos eran parte del camino para convertirse en Senior. Si no permitimos que los Juniors crezcan, tenemos un problema muy grande.

No tengo una solución. Quizás el rol del Junior evolucione hacia saber dirigir agentes, validar outputs y entender qué está haciendo el agente. Pero eso no es sencillo y creo que estamos muy lejos de estar preparados, además de que estamos obviándolos de esta ecuación.

Conclusión.

Me vuelvo de Seattle con una sensación de que todo se está moviendo muy rápido, quizás demasiado y a lo mejor no todo el mundo está preparado.

Por un lado, la velocidad a la que se mueve todo es emocionante. Los agentes ya no son una promesa, son una realidad en producción que está generando valor medible. Y estar rodeado de 120 personas que viven esto en primera persona, en contextos tan diferentes como Japón, India, Noruega o Brasil, te da una perspectiva que no consigues en ningún otro sitio.

Por otro lado, hay una desconexión preocupante entre lo que la tecnología puede hacer y lo que las organizaciones están preparadas para absorber. Los datos siguen sin gobernarse, las arquitecturas siguen sin seguir buenas prácticas y el gap entre lo que pide la dirección y lo que puede ejecutar la capa técnica sigue creciendo.

Y esto no es solo nuestra impresión. Los datos de 2026 son demoledores: según MIT, el 95% de los pilotos de IA generativa no producen impacto medible en la cuenta de resultados. Forrester confirma que el 88% de los pilotos de agentes nunca llegan a producción. Y el 54% de los C-suite admiten que adoptar IA “está destrozando su empresa” (Writer.com, 2026). El patrón de fracaso no es técnico — es operacional: datos frágiles, gobernanza inexistente y cero feedback loop tras el lanzamiento.

Lo llevamos diciendo años con la migración a cloud, con el modelo de empresas basadas en datos, con los inicios de Machine Learning y parece que con los agentes vamos a repetir los mismos errores (correr antes de saber andar).

Mi takeaway principal: no importa lo inteligente que sea tu agente si le das basura como entrada. Y no importa cuántos agentes despliegues si tu arquitectura es un castillo de naipes.

La revolución agéntica no es solo un problema tecnológico. Es un problema de datos, de arquitectura, de cultura y de personas. Y eso, por mucho que avance la IA, sigue siendo responsabilidad nuestra.

Ahora toca aplicar lo aprendido. Pero no todo fue darle vueltas a la cabeza en Seattle, también hay que desconectar y recordar por qué merece la pena cruzar el charco. Os dejo con el Monte Rainier como prueba de que no todo fueron salas de reuniones.

Ahora es momento de ver esas maravillas, que en el caso de AWS se han materializado en: Amazon Q Developer CLI y Kiro.

En este Post vamos a ver:

• Amazon Q Developer CLI: La evolución natural del desarrollo asistido por IA
• Kiro: El agente de IA que está redefiniendo la automatización
• Casos de uso revolucionarios que antes eran imposibles
• El futuro de la colaboración humano-agente
• Por qué esta revolución es diferente a todo lo anterior

Amazon Q Developer CLI

Más Allá de un Asistente de Código o un Chat conversacional.

Hace ya un tiempo, en el re:Invent de 2023 AWS lanzó Amazon Q. En ese momento me pareció el mejor lanzamiento de AWS, pero con el tiempo el globo se fue desinchando y la verdad aunque era útil para algunas cosas, me resultaba poco útil, incluso dándome recomendaciones que no me gustaban.

En marzo de 2024 AWS lanzó AWS Q Developer CLI y aquí sí que teníamos una herramienta que es un Game Changer.

Y vamos a ver qué es AWS Q Developer CLI y qué se diferencia de lo que teníamos antes.

Q Developer CLI, Un Asistente de IA Agentic en tu CLI.

A diferencia de otros asistentes, incluido el propio Q Developer (sin CLI), este se integra en tu propio CLI, de forma que te permite interactuar con tu propio PC y utilizar sus herramientas para ayudarte.

Q Developer te proponía mejoras en tu código o te permitía generar código en base a interacciones con él, pero Q Developer CLI, es capaz de leerse un directorio entero de código, documentación, archivos excel y en base a ellos generar código o incluso ejecutar acciones.

Una mejora clara es que es un asistente dentro de mi propio PC, con mi propio contexto, es más puede leer ficheros (a los que yo le dé acceso) y ejecutar acciones de SO (las que yo permita), de forma que puede ser autónomo en múltiples tareas.

Un ejemplo que suelo comentar, es algo que habitualmente me pasa, algún problema con alguna SCP que he puesto yo. Descubro que tengo alguna SCP (que la mayoría de las veces he creado yo) que me está bloqueando una acción, pero como soy un despistado, no me acuerdo de qué SCP es y tengo que investigarlo, es algo que es sencillo, pero requiere tiempo.

Con Q Developer CLI puedo darle acceso en modo lectura a mi cuenta master, a mi cuenta problemática e incluso a mi cuenta de Logs, explicarle mi problema y que me ayude a identificarlo.

No es una tarea compleja pero es muy tediosa, además requiere leer muy bien las políticas.

Q es capaz de revisar qué acción se me está denegando, relacionarla con mis SCPs y proponerme una solución, e incluso, si le dejo, ejecutarla él de forma autónoma.

Esto es un ejemplo, pero hay muchos como pedirle que me ayude a identificar problemas de costes o incluso que me simule el coste de una arquitectura.

Por otro lado me centro mucho en AWS, pero también puede revisar documentos que tengo en mi PC y generar nuevos, ayudarme con problemas HTML en una web, o incluso ayudarme con problemas de rendimiento.

Kiro

¿Qué es Kiro?

En julio de 2025 AWS anunció Kiro que es un IDE nativo en IA Agentic. Es una clara evolución de Q Developer CLI pero más orientado a un entorno para desarrolladores.

A diferencia de los editores tradicionales con plugins de IA, está diseñado desde cero como un agente inteligente que puede:

• Entender el contexto completo del proyecto y sus dependencias.
• Ejecutar tareas complejas de forma autónoma con supervisión humana.
• Mantener un contexto persistente de decisiones y patrones del proyecto.
• Integrar herramientas a través de MCP (Model Context Protocol).
• Generar código de forma autónoma.

Más allá del Vibe Coding habitual.

Una diferencia de Kiro es su método de funcionamiento, en vez de hacer Vibe Coding, Kiro es capaz de definir un Spec para un proyecto de forma que haga los siguientes pasos:

Toma de Requisitos: Generando unos requisitos legibles del proyecto en base a nuestro contexto. Generación de Diseño: Una vez que los requisitos estén definidos, Kiro va a generar un diseño en base a estos. Generación de Tareas: Cuando ya tengamos un diseño cerrado, Kiro generará una serie de tareas para ejecutar el proyecto en base a los requisitos y el diseño acordado.

Cada uno de estos puntos requiere una validación manual, en esta validación podemos aceptar lo que Kiro propone (No lo recomiendo) o revisar cuidadosamente los requisitos, diseño y tareas para que el proyecto sea exitoso.

Ejecución Autónoma

Una vez definido el plan, Kiro puede ejecutar las tareas de forma independiente, desde la generación de código hasta la configuración de infraestructura, pasando por la gestión de dependencias.

Gestión de Contexto Avanzada

Una de las ventajas de este modelo, es que Kiro tiene un contexto de todo el proyecto y no solo de secciones separadas, además cada interacción de cada tarea va alimentando el contexto, de forma que la ejecución es muy completa.

Además al usar las Specs que yo he validado, Kiro va a seguir las instrucciones sin salirse del camino.

Esto además se potencia en una funcionalidad de Kiro llamada Agent Steering que nos va a permitir realizar una estandarización de convenciones en Kiro, que además podemos compartir no solamente a nivel de todas nuestras interacciones con Kiro en este proyecto, sino las de todo el equipo.

Permitiendo que todo el desarrollo siga las mismas reglas que nosotros imponemos (Naming, Uso de Librerias, Alineamiento del proyecto, etc)

El Impacto de Kiro en el Desarrollo

Antes de Kiro

Desarrollador/Ingeniero → Planifica → Codifica → Prueba → Despliega → Mantiene

Con Kiro

Desarrollador/Ingeniero → Define objetivos → Kiro asiste en todo el ciclo → Desarrollador supervisa y ajusta.

Esta transformación permite a los desarrolladores centrarse más en la estrategia y la creatividad, mientras Kiro maneja gran parte de la ejecución táctica bajo supervisión.

Obviamente el modelo no es perfecto y Kiro va a cometer errores, de ahí que requiera supervisión, pero va a dar superpoderes a nuestros desarrolladores/ingenieros para ser más eficientes.

MCP para AWS Q Developer CLI y Kiro

Cómo MCP Potencia Estas Herramientas

Tanto Kiro como Amazon Q Developer CLI se aprovechan de MCP (Model Context Protocol) para extender sus capacidades de forma nativa

De esta forma pueden ejecutar herramientas, desde leer o modificar ficheros en local, a conectarse a herramientas externas, como puede ser la propia AWS, también pueden leer documentación oficial, mejores prácticas e incluso problemas conocidos.

Esto hace que si como herramientas individuales son ya muy potentes, el poder interaccionar con otras herramientas los potencia todavía más.

Por ejemplo en muchas ocasiones podéis pedir que instalen una herramienta para ejecutar una acción, como leerse un CSV gigantesco para hacer una correlación de datos.

El Poder de la Estandarización

Ya hablamos en el anterior artículo que MCP es muy interesante porque es un estándar abierto y permite la integración con muchos servicios, que cada día crecen más.

Esta integración MCP significa que:

• Cualquier herramienta que implemente MCP funciona automáticamente.
• Podemos crear nuestros propios MCP servers para mejorar nuestros contextos.
• El ecosistema de MCP está creciendo de forma orgánica y colaborativa.
• No hay vendor lock-in en las integraciones.

Os recomiendo volver a echar un vistazo a los MCP que tiene la propia AWS. Con ellos vais a poder tener una potencia increíble.

Por Qué Esta Revolución es Diferente

Hasta ahora, el post es un resumen de capacidades, pero en qué me ayuda Kiro o Amazon Q Developer CLI y por qué es mejor que otras herramientas de IA que usaba hasta ahora.

Vale ya he dicho esto mucho, pero qué significa este cambio.

Hasta ahora yo podía preguntar a cualquier IA y esta me ayudaba, pero no ejecutaba acciones por mí, es verdad que me podía generar mis propios agentes y podría llamarlos, pero es complejo.

En este caso puedo ayudarme de estas herramientas para ejecutar mi día a día, de forma sencilla.

No es Solo Otra Mejora Incremental

Cambio Cualitativo, No Cuantitativo

No voy a usar un LLM revolucionario, es más tanto Kiro como Amazon Q Developer CLI utilizan los modelos de Anthropic, pudiendo elegir entre las versiones de Claude Sonnet mas recientes.

Como veis ni siquiera son los modelos más potentes de Anthropic, pero cómo los usamos tiene más sentido, el Loop de Agentic va a dividir las tareas en multiples tareas que ejecutara secuencialmente, permitiendo solucionar problemas y mejorar en la respuesta.

Transformación del Rol

En vez de ejecutar o escribir código nuestro rol cambia a definir la estrategia, es decir puedo pedir a Amazon Q Developer CLI que me ayude a encontrar un problema y él ejecutará el diagnóstico por mí y puedo ir guiándole hasta encontrar la solución más adecuada e incluso me ayudará a implementarla.

O en Kiro puedo definir un nuevo proyecto y definir los requisitos y guiar el desarrollo.

Además estas herramientas van a ser proactivas y pueden avisarnos de problemas o malas implementaciones.

Mejora de los promts

Ya no necesito ser un ingeniero de Prompts para tener una respuesta coherente, una de las grandes ventajas de este modelo, es que el contexto va creciendo según las interacciones y aprendiendo de los errores. Si el propio modelo detecta un error va a solucionarlo, pero además guarda el contexto de ese error, además va a poder ejecutar herramientas para ganar contexto, como leer un archivo con requerimientos, leer un ejemplo de lo que espero, consultar documentación o ejecutar acciones remotas en una cuenta de AWS u otro proveedor.

El Efecto Multiplicador

Productividad Exponencial

Una de las mejoras de estas herramientas es que nos permiten avanzar más rápido, en vez de realizar tareas tediosas, como leernos un YAML (No me ha pasado nunca 🤦) para encontrar que hemos puesto mal un espacio y roto todo el fichero, ellas pueden hacerlo por nosotros de forma rápida.

Además permiten ir optimizando lo que hacemos al vuelo y nos permiten implementarlo a nuestro stack completo.

Imaginad que en mitad del desarrollo descubrimos una forma de mejorar el rendimiento de nuestra APP y que es aplicable a otras áreas, hasta ahora teníamos que tener identificadas estas áreas y aplicar la mejora, ahora estas herramientas lo pueden hacer por nosotros.

Democratización del Desarrollo

Estas herramientas además ayudan a que capacidades avanzadas estén más accesibles para todo el mundo, aunque dejadme que aquí puntualice que necesitan supervisión humana.

No os recomiendo confiar al 100% en lo que nos proponen, porque no siempre aciertan, si no tenéis experiencia en un área, es recomendable que alguien con experiencia lo revise antes de ponerlo en producción, pero sí es cierto que pueden ayudarnos en áreas en las que tenemos dudas o quizás no entendemos del todo.

AWS Q Developer CLI, Kiro y Yo

Vale pero cómo podemos utilizarlo en nuestro día a día.

Yo utilizo las 2 herramientas, pero para casos de usos diferentes.

AWS Q Developer CLI me ayuda mucho en mi día a día cuando necesito ejecutar acciones, es decir solucionar un problema, ejecutar algo, mientras que Kiro lo utilizo más para el end-to-end de un proyecto, definiendo las especificaciones y requerimientos de este.

Para ayudaros os voy a contar algunos ejemplos de mi día a día.

AWS Q Developer CLI

Cuando tengo que ejecutar alguna acción, resolver problemas, comparar cosas, hacer un assessment, hacer test, hacer documentaciones AWS Q Developer CLI es mi campeón.

Por ejemplo, tengo que hacer un Assessment de una cuenta, es algo que realmente puedo hacer con los ojos cerrados, pero que me consume bastante tiempo, por eso puedo lanzar una interacción con Q:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# Ejemplo de Assessment

     █████╗ ███╗   ███╗ █████╗ ███████╗ ██████╗ ███╗   ██╗     ██████╗ 
    ██╔══██╗████╗ ████║██╔══██╗╚══███╔╝██╔═══██╗████╗  ██║    ██╔═══██╗
    ███████║██╔████╔██║███████║  ███╔╝ ██║   ██║██╔██╗ ██║    ██║   ██║
    ██╔══██║██║╚██╔╝██║██╔══██║ ███╔╝  ██║   ██║██║╚██╗██║    ██║▄▄ ██║
    ██║  ██║██║ ╚═╝ ██║██║  ██║███████╗╚██████╔╝██║ ╚████║    ╚██████╔╝
    ╚═╝  ╚═╝╚═╝     ╚═╝╚═╝  ╚═╝╚══════╝ ╚═════╝ ╚═╝  ╚═══╝     ╚══▀▀═╝  

Necesito hacer un assessment de varias cuentas de AWS, te paso los perfiles para que ejecutes acciones de solo lectura.

Necesito tener un inventario de assets desplegados, revisar problemas de seguridad, compliance y ver si se siguen las mejores prácticas, además necesito que me ayudes a hacer una propuesta de mejoras.

Tienes documento de ejemplo en la carpeta /Assessment llamado ejemplo_assessment.doc, utilizalo como base

Los perfiles a utilizar son:
Perfil A
Perfil B
Perfil C 

Este ejemplo es muy sencillo, pero me permite pasando un ejemplo que Q me ejecute una serie de tareas siguiendo un estandar generado por mi.

En este caso necesita leer un doc, y por tanto usar una herramienta externa para leerlo, puedo hacerlo con un MD, pero quiero que me genere un doc en base a mi formato.

Otro ejemplo es cuando me toca realizar un cálculo de Costes en AWS y estoy utilizando servidores con licenciamiento, una pregunta habitual es el coste de este licenciamiento, es algo sencillo de sacar pero muy tedioso porque requiere sacar el coste de las instancias sin licenciamiento y restarlas, pero con Q es sencillo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Ejemplo de Calculo de Coste de Licenciamiento

     █████╗ ███╗   ███╗ █████╗ ███████╗ ██████╗ ███╗   ██╗     ██████╗ 
    ██╔══██╗████╗ ████║██╔══██╗╚══███╔╝██╔═══██╗████╗  ██║    ██╔═══██╗
    ███████║██╔████╔██║███████║  ███╔╝ ██║   ██║██╔██╗ ██║    ██║   ██║
    ██╔══██║██║╚██╔╝██║██╔══██║ ███╔╝  ██║   ██║██║╚██╗██║    ██║▄▄ ██║
    ██║  ██║██║ ╚═╝ ██║██║  ██║███████╗╚██████╔╝██║ ╚████║    ╚██████╔╝
    ╚═╝  ╚═╝╚═╝     ╚═╝╚═╝  ╚═╝╚══════╝ ╚═════╝ ╚═╝  ╚═══╝     ╚══▀▀═╝  

En el archivo ec2instances.xlsx tengo una tabla con el coste de cómputo por instancia, quiero calcular el coste para las instancias que tienen licenciamiento, así que quiero que saques 2 columnas adicionales calculando el coste puro de cómputo y el de licenciamiento.
Para calcular el coste de cómputo saca el coste de las mismas instancias pero en Linux y ese es el coste de cómputo puro, el coste de licenciamiento es la diferencia entre ese coste y el coste total de la instancia.
Utiliza la región eu-west-1 

Este ejemplo me hizo un script que es la base que utilizo ahora cuando necesito hacer estos cálculos.

También podemos pedirle muchas más cosas, por ejemplo revisar SCP, implementar cambios, revisar problemas, etc.

Son cosas que realmente yo puedo hacer, pero que me van a llevar mucho más tiempo.

Kiro

A diferencia de Q Developer CLI, Kiro lo utilizo en proyectos a largo plazo, cuando quiero mantener un contexto durante mucho tiempo y además necesito crear código complejo, que necesita muchas iteraciones.

En este tipo de proyectos Kiro es mejor (Lo puedo hacer con Q Developer CLI, pero Kiro es mejor).

Por ejemplo si le pido a Kiro lo siguiente:

"Crea una aplicación de e-commerce con:

- Frontend en Next.js
- Backend en FastAPI
- Base de datos PostgreSQL
- Pagos con Stripe
- Autenticación con Auth0
- Deploy en AWS"

Primero me generara un fichero de Requisitos:

Segundo me generara un Diseño:

Y por ultimo una lista de tareas:

Una vez tengamos los 3 ficheros, podemos empezar a lanzar tareas y crear nuestra implementación.

De hecho lo he probado en varias implementaciones (Que por motivos contractuales no puedo mostrar) y funciona bastante bien.

Modelos de Pricing

También tenemos que comparar su modelo de precios.

Amazon Q Developer CLI

Amazon Q Developer CLI ofrece un modelo de pricing sencillo y orientado a equipos:

• Free Tier: 50 solicitudes de agente por mes, ideal para probar la herramienta
• Pro Tier: $19/mes por usuario, con límites aumentados y funcionalidades empresariales como:
  • Límites aumentados de solicitudes de agente
  • Capacidades de transformación de código (4000 líneas de código por mes)

Kiro

Kiro presenta un modelo más flexible con múltiples niveles:

• Free: 50 créditos perpetuos (no se renuevan mensualmente)
• Pro: $20/mes con capacidad aumentada
• Pro+: $40/mes para usuarios con necesidades intermedias
• Power: $200/mes para uso intensivo

Los planes de pago incluyen uso adicional flexible a $0.04 por crédito adicional, lo que permite escalabilidad según el uso real.

Comparativa: ¿Cuándo usar cada herramienta?

¿Pero es todo tan Bonito?

La respuesta corta es que no. Ni Kiro, ni Q Developer CLI son infalibles, en muchas ocasiones, sobre todo al principio no van a cumplir nuestras espectativas, hace falta tener algunas cosas en cuenta:

Revisar las Specs con mucho cuidado

Este quizas suele ser el primer problema, tenemos que ser muy claro en lo que pedimos. En el caso de Kiro, hay que ser muy cuidadoso a la hora de generar un SPEC nuevo, tenemos que revisar cada punto, con sumo cuidado. Muchas veces nosotros suponemos requerimientos porque nos parecen basicos, pero tanto para Kiro como Q Developer CLI no lo son tanto, por lo que nos puede tocar rehacer nuestro trabajo desde el principio.

Por eso mi recomendación con Kiro es gastar tiempo en revisar los requerimientos, el diseño y las tareas, ya que todo el tiempo que gastemos, será beneficioso en nuestras implementaciones. En el caso de Q Developer CLI, es algo similar, tenemos que ser específicos en los límites que ponemos a nuestras interacciones, así como definir bien el contexto. No hace falta hacer un prompt gigante, pero sí ajustarlo y entender qué contexto tiene Q de lo que queremos hacer

Estas herramientas requieren supervision

No se trata de dejar a estas herramientas hacer un desarrollo de forma autónoma, si lo hacemos el resultado será bastante malo.

Aquí siempre pongo la analogía de un Junior, a un Junior le puedes delegar trabajo, pero tienes que auditarlo para que no se desvíe y no cometa errores. Si un Junior comete un error es nuestra culpa como Seniors, ya que no le hemos supervisado bien, pues pasa lo mismo con Kiro y Q Developer, tenemos que auditar qué hacen y si se equivocan alimentar el prompt para que no vuelva a pasar.

Esto al principio puede ser frustrante, pero con el tiempo vas entendiendo cómo trabajan y cómo puedes mejorar tus prompts.

Siempre escogen el camino fácil

Esto no tiene por qué ser algo malo siempre, en muchas ocasiones tendemos a complicarnos y estas herramientas están diseñadas para usar el camino fácil.

El problema es que en otras ocasiones su camino fácil, es deshabilitar una feature, hacer un análisis simple o saltarse un paso. Esto es algo que tenemos que tener en cuenta y ser capaces de detectar.

Un bucle puede ser un problema muy grande

En ciertas ocasiones puedes entrar en un bucle, que te recomienden una solucion, esta no funcione, tengas varias iteracciones fallidas y que vuelvan al inicio a proponer la misma solucion inicial.

Esto no es habitual, pero puede pasar, pero además incluso podemos retroalimentarlo nosotros diciéndole que no haga algo específico y que nos lo proponga como mejor opción si otras fallan…

Curiosamente tiene una explicación simple. Por un lado hay que tener en cuenta que los modelos se entrenan en un momento dado y luego se alimentan vía RAG (retrieval-augmented generation) lo que puede suponer que la solución no la busca fuera (En un MCP), pero también puede pasar que nosotros mismos alimentemos el modelo diciéndole que no haga algo, esa acción entra al contexto y aunque la entiendo como no válido, va a proponérnosla porque le hemos dicho que es una opción…

Al final siempre va a buscar el camino fácil, aunque podemos forzarle a no hacerlo.

Se puede inventar features

Estas herramientas suelen darnos ideas increibles, pero a veces son tan increibles como imposibles.

Esto me ha pasado alguna vez con Control Tower y terraform, en ocasiones me han recomendado usar resources de terraform que no existen (Aunque tendría sentido que sí), en esos casos te puedes dar cuenta tú y preguntar si existe o en otras ocasiones te darás cuenta al implementar.

Tener cuidado con lo que os proponga y si no os cuadra, pedirle que os lo razone.

A veces pueden ser peligrosas

En alguna ocasión (Más Q Developer CLI que Kiro) ha decidido que es buena idea borrar algo o parar algo sin mi permiso. En una ocasión me borró el fichero de Credentials de AWS CLI porque no sabía usar un perfil…

Son herramientas muy potentes, pero que a su vez requieren que estemos atentos, esto podemos limitarlo en el Prompt, pero os recomiendo que estéis atentos a las acciones que ejecutan.

¿Entonces mejor no usarlas?

Precisamente el punto es el contrario usarlas pero con cabeza.

Son herramientas muy potentes pero que requieren control.

A mí realmente me han solucionado muchas cosas, además de ayudarme mucho.

• He reducido el tiempo de ejecución de muchas tareas, con la ayuda de Kiro y Q Developer CLI.
• Algunas ideas geniales que no se me habían ocurrido o que no tenía tiempo de implementar, ahora están implementadas.
• Odio documentar y el tiempo que dedico a documentar se ha reducido muchísimo y además la mayoría de las veces explican las cosas mejor que yo.
• Me obligan a hacer testing, pero haciendolo ellas.

Reflexión Final

La era de los agentes de IA ha comenzado. ¿Estás listo para ser parte de esta revolución?

No se trata de reemplazar a los desarrolladores/Ingenieros, sino de potenciar nuestras capacidades de formas que nunca antes habíamos imaginado. Estas herramientas nos ayudan a ejecutar ciertas tareas que nos llevan mucho tiempo o son repetitivas y nos permiten centrarnos en lo que realmente importa: crear, innovar y resolver problemas complejos.

Por poner una curiosidad, a mí me han ayudado a realizar tareas mientras atiendo a una reunión, cosa que antes no podía hacer, porque al final ni atendía a la reunión, ni estaba pendiente de lo que hacía.

Esto sigue igual, pero desde hace unos meses empecé a usar Amazon Q Developer CLI y más recientemente Kiro, y la verdad es que me apetece hablar de estas herramientas.

Aunque he usado muchas herramientas de IA y modelos para mejorar mi día a día. Para mí tanto Amazon Q Developer CLI como Kiro son un Game Changer en la industria y esto es debido a la revolución de los Agentes de IA.

Ya sé que está muy utilizado lo de revolución de la IA y que muchos estamos cansados de escucharlo cada 5 minutos, pero sin ese gancho es difícil que leáis el artículo, aun así voy a intentar explicaros un poco en qué consiste esto de los agentes y por qué, en mi opinión, es algo que está cambiando nuestro día a día.

Este artículo va a estar dividido en 2 partes, en esta primera vamos a hablar un poco más de qué es esto de los Agentes y en la segunda nos centraremos sobre Q Developer CLI y Kiro.

En este Post vamos a ver:

• Qué son los agentes de IA y cómo difieren de los modelos tradicionales
• El paradigma del “Agentic Loop” y su impacto revolucionario
• Model Context Protocol (MCP): La clave de la integración
• Strand Agents: Framework para agentes individuales potentes
• Por qué esta evolución cambia fundamentalmente la IA.

De Modelos a Agentes

Pregunta-Respuesta

Si habéis usado en este tiempo ChatGPT, Claude, Gemini, Copilot, Perplexity, DeepSeek, el modelo de funcionamiento tenía un patrón simple: le pedías algo y contestaba directamente.

1. Usuario hacía una pregunta
2. El Modelo procesaba la pregunta y respondía
3. Fin de la interacción

Este modelo, aunque útil, tenía limitaciones fundamentales:

• Pasividad: La IA sólo respondía cuando se le preguntaba
• Contexto limitado: Cada interacción era independiente, podíamos darle un contexto, pero no era tan completo
• Sin persistencia: En cada nueva sesión teníamos que cargar nuestro contexto
• Sin acción: Solo proporcionaban información, no ejecutaban nada en nuestros equipos

Es verdad que en los últimos años estos modelos han ido evolucionando y han ido ganando profundidad, haciendo pequeños loops, que han mejorado su respuesta.

Los Agentes de IA

Los agentes de IA representan una evolución increíble:

1. Proactividad: Pueden iniciar acciones sin necesidad de que lo pidamos explícitamente (también los podemos limitar, para que no ejecuten cosas que no queremos)
2. Persistencia: Mantienen contexto y memoria a largo plazo
3. Autonomía: Pueden tomar decisiones y ejecutar tareas complejas
4. Integración: Se conectan con sistemas externos y herramientas
5. Aprendizaje continuo: Mejoran con cada interacción

Además de esto, podemos utilizar agentes especializados, de forma que sean mucho más óptimos a la hora de ejecutar ciertas tareas. Incluso es algo muy bueno a la hora de reducir los modelos: en vez de utilizar modelos gigantescos, podemos usar modelos destilados, más pequeños pero mucho más optimizados para las tareas del agente.

Por ejemplo, un agente de optimización de recursos solo tiene que saber de ese contexto, no requiere un conocimiento profundo en otras materias, algo que es común en un LLM.

También es posible utilizar diferentes modelos por cada agente, lo que permite usar el mejor modelo para cada propósito.

Esto nos permite tener múltiples agentes coordinados que ejecuten pequeñas tareas y un orquestador que junte todo y ejecute tareas sumamente complejas.

¿Qué es un Agentic Loop?

El Agentic Loop es el concepto fundamental de lo que estamos hablando y es la mayor diferencia con el modelo tradicional.

Es un ciclo continuo y autónomo que permite a la IA operar de forma independiente, tomar decisiones y ejecutar acciones sin intervención humana constante.

Es decir, en base a algo que le pedimos, los agentes van interaccionando para llegar a una respuesta correcta, incluso son capaces de remediar errores que se produzcan a mitad de loop.

Ejemplo de Arquitectura de Agentic Loop

No existe un solo tipo de Agentic Loop, de hecho hay muchos, pero vamos a poner un ejemplo bastante habitual:

Percepción → Planificación → Acción → Evaluación → Aprendizaje → Percepción…

1. Percepción (Perception)

• Análisis del entorno: El agente examina el contexto actual, incluyendo datos que carguemos, estado del entorno y objetivos pendientes
• Identificación de cambios: Detecta modificaciones en el entorno que requieren atención
• Procesamiento multimodal: Integra información de múltiples fuentes (aquí podemos llamar a herramientas externas y otros agentes)

2. Planificación (Planning)

• Definición de objetivos: Establece metas específicas basadas en el contexto detectado
• Descomposición de tareas: Divide una tarea compleja en múltiples tareas sencillas
• Optimización de recursos: Planifica el uso eficiente de las herramientas a su disposición
• Gestión de dependencias: Identifica prerrequisitos y secuencias necesarias

3. Acción (Action)

• Ejecución de tareas: Realiza las tareas planificadas
• Interacción con herramientas: Utiliza APIs, ejecuta comandos, modifica archivos, etc.
• Comunicación: Interactúa con otros sistemas o agentes (MCP o Strands)
• Monitorización: Supervisa el progreso durante la ejecución

4. Evaluación (Evaluation)

• Análisis de resultados: Compara los resultados obtenidos con los objetivos esperados
• Detección de errores: Identifica fallos o desviaciones del plan de tareas
• Medición de eficiencia: Evalúa el rendimiento y uso de recursos
• Validación de calidad: Verifica que los resultados cumplan los requisitos definidos

5. Aprendizaje (Learning)

• Actualización de conocimientos: Incorpora nuevos aprendizajes al contexto
• Refinamiento de estrategias: Mejora los enfoques basándose en los resultados
• Adaptación de patrones: Ajusta comportamientos para situaciones similares futuras
• Memoria persistente: Almacena experiencias para referencias futuras

Este modelo es infinito, es decir, le pedimos una tarea y va a repetir el loop tantas veces como sea necesario. Es verdad que si tiene algún bloqueo, los loops están diseñados para que, si no se avanza, romperlo y devolvernos el error.

La gran ventaja de este modelo es que es iterativo, es decir, va iterando acciones hasta que encuentra la respuesta correcta.

Ejemplo Práctico del Agentic Loop

Vamos a ver un ejemplo real de Amazon Q Developer CLI que utiliza este modelo.

Tengo un Problema, he levantado una máquina en AWS en la cuenta xxx y necesito acceder a ella por SSM, pero no consigo que funcione, haz todo lo necesario para solucionarlo

Ciclo 1:

• Percepción: Analiza la configuración de AWS e identifica problemas de configuración.
• Planificación: Decide revisar que tiene acceso a AWS.
• Acción: Lista los perfiles configurados en local.
• Evaluación: Revisa que tiene acceso a AWS.
• Aprendizaje: Conoce el perfil del AWS CLI para ejecutar las acciones.

Ciclo 2:

• Percepción: Analiza si SSM está configurado.
• Planificación: Decide revisar si el rol de SSM está configurado en la máquina.
• Acción: Ejecuta un describe-instance para revisar la configuración.
• Evaluación: La máquina tiene el Rol de SSM configurado.
• Aprendizaje: El problema no es del rol de la instancia, debe ser de comunicaciones.

Ciclo 3:

• Percepción: Puede existir un problema de comunicaciones con los endpoints de SSM.
• Planificación: Decide revisar la configuración de la subnet donde está desplegada la instancia.
• Acción: Ejecuta un describe-route-tables de la tabla de rutas de la subnet.
• Evaluación: La instancia está en una subnet privada.
• Aprendizaje: El problema está aquí, la instancia no tiene forma de llegar a los endpoints de SSM.

Ciclo 4:

• Percepción: Es necesario desplegar los endpoints de SSM.
• Planificación: Decide crear los endpoints de SSM en la subnet donde está la instancia.
• Acción: Ejecuta un create-vpc-endpoint por cada endpoint de SSM, desplegándose en la subnet indicada.
• Evaluación: Los endpoints son necesarios para que SSM funcione.
• Aprendizaje: El problema debería estar resuelto; hemos permitido la comunicación con los endpoints.

Ciclo 5:

• Percepción: Hay que revisar que SSM esté operativo.
• Planificación: Decide revisar el estado de SSM.
• Acción: Ejecuta un describe-instance-information para ver el estado de SSM.
• Evaluación: El agente está operativo y reporta.
• Aprendizaje: El problema ya está resuelto, la instancia es accesible por SSM.

Este es un ejemplo pequeño y simplificado, realmente hay más pasos y en algunos casos es necesaria nuestra intervención. Lo normal (si no hubiésemos dicho que hiciese todo lo necesario para resolverlo) es que cuando detectase el problema nos diese varias alternativas para solucionarlo.

Por qué es algo que cambia la IA

1. Autonomía Real: Los agentes pueden trabajar independientemente durante horas o días
2. Mejora Continua: Cada ciclo hace al agente más eficiente
3. Adaptabilidad: Se ajusta dinámicamente a cambios en el entorno
4. Escalabilidad: Puede manejar múltiples tareas simultáneamente
5. Persistencia: Mantiene el contexto y progreso a largo plazo

Diferencias Clave con el Modelo Anterior

Model Context Protocol (MCP)

Hasta ahora hemos hablado de agentes, pero muchas veces necesitamos cosas más concretas o incluso conectarnos con herramientas de terceros; aquí es donde entra MCP.

¿Qué es MCP?

El Model Context Protocol (MCP) es el estándar abierto desarrollado por Anthropic que hace posible la revolución Agentic. Es el protocolo que permite a los agentes de IA integrarse de forma nativa con cualquier herramienta, API, servicio o sistema. Es un estándar abierto que permite que cualquiera genere sus propios MCP y permita la integración con otros sistemas.

A mí este modelo me encanta, porque en vez de una apuesta por un modelo propietario, en este caso se ha ido directo a un modelo Open Source que permite la integración de cualquier agente independientemente del LLM que use, quien lo desarrolle o quién sea su consumidor objetivo.

Esto es algo que no ha sido habitual en la industria, lo normal es que cada compañía diseñe su propia integración propietaria y que fuerce al resto a usarla.

Arquitectura de MCP

Componentes Principales

1. MCP Servers

• Proporcionan herramientas específicas a los agentes
• Pueden ser servicios AWS, otro Cloud, APIs de terceros o herramientas locales, etc.
• Exponen capacidades de forma estandarizada

2. MCP Clients

• Los agentes de IA que consumen las herramientas
• Amazon Q Developer CLI y Kiro son ejemplos de clientes MCP

3. Protocol Layer

• Capa de comunicación estandarizada
• Garantiza interoperabilidad entre diferentes sistemas
• Maneja autenticación, autorización y gestión de errores

MCP en la Práctica

Qué podemos hacer con un MCP

Básicamente cualquier cosa, para que os hagáis una idea, yo uso múltiples MCPs en mi día a día.

Uso MCPs que me permiten acceder a ficheros locales de mi PC, por otro lado, uso MCPs que leen la documentación de AWS, otros que me ayudan con el diseño de ciertos servicios e incluso algunos específicos de Terraform, pero las posibilidades son infinitas.

Además, desarrollar un MCP no es excesivamente complejo y nos permite que nosotros mismos podamos generar MCPs; asimismo, podemos ir iterando y mejorando nuestros propios MCPs con el tiempo.

Ejemplo Práctico: Configuración de MCP Server

Un ejemplo de cómo configurar un MCP server básico para acceder a la documentación de AWS:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": ["search_documentation", "read_documentation"]
    },
    "filesystem": {
      "command": "uvx",
      "args": ["mcp-server-filesystem", "--path", "/workspace"],
      "disabled": false,
      "autoApprove": ["read_file", "list_directory"]
    }
  }
}

Este archivo de configuración permite a cualquier agente MCP acceder tanto a la documentación de AWS como al sistema de archivos local de forma estandarizada.

Además, está configurando que estas herramientas de lectura estén preaprobadas.

Ventajas de MCP

1. Interoperabilidad: Cualquier agente puede usar cualquier MCP server
2. Extensibilidad: Fácil agregar nuevas capacidades sin modificar el agente
3. Reutilización: Los MCP servers se pueden compartir entre diferentes proyectos
4. Estandarización: Protocolo común que facilita el desarrollo y mantenimiento

Strand Agents

Además de los MCP, existe otro framework muy interesante que es Strand Agents. Mientras que MCP se centra en la integración de herramientas individuales, Strand Agents se centra más en la propia creación de los agentes, así como en su orquestación, en integrar múltiples agentes, en permitir la persistencia de estados y contextos, etc.

¿Qué es Strand Agents?

Strand Agents es un SDK simple pero potente desarrollado por Amazon que adopta un enfoque basado en modelos para construir y ejecutar agentes de IA. Desde asistentes conversacionales más habituales (lo típico en IA) hasta flujos de trabajo autónomos complejos, permite orquestar desde un desarrollo en local hasta el despliegue en producción de la aplicación.

Características Principales del Framework

• Ligero pero muy flexible: Permite desde un bucle de agente muy sencillo, pero que es completamente personalizable
• Agnóstico: Tiene soporte para utilizar Amazon Bedrock y también modelos propios de Anthropic, LiteLLM, Llama, Ollama, OpenAI, Writer y proveedores personalizados
• Capacidades Avanzadas: Permite implementar sistemas multiagente, agentes autónomos y soporte de streaming
• MCP Integrado: Tiene soporte nativo para servidores Model Context Protocol (MCP), permitiendo acceso a miles de herramientas preconstruidas

Arquitectura de Strand Agents

Componentes Principales

1. Agent Core

• Motor de razonamiento basado en LLM que procesa las peticiones del usuario
• Gestión automática del ciclo de vida del agente (inicialización, ejecución, finalización)
• Soporte para múltiples proveedores de modelos de forma intercambiable

2. Tool System

• Sistema de herramientas nativo usando decoradores Python
• Hot reloading automático desde directorios de herramientas
• Integración nativa con servidores MCP para acceso a herramientas externas

3. Session Management

• Persistencia automática de conversaciones y estado del agente
• Soporte para almacenamiento local (FileSessionManager) y en la nube (S3SessionManager)
• Gestión inteligente de contexto con estrategias configurables

4. Multi-Agent Orchestration

• Coordinación de múltiples agentes especializados trabajando juntos
• Comunicación entre agentes para resolver tareas complejas
• Distribución automática de tareas según las capacidades de cada agente

El Poder de Strand Agents en la Práctica

Capacidades Avanzadas

Structured Output

• Obtención de respuestas estructuradas usando modelos Pydantic
• Validación automática de tipos y esquemas
• Integración perfecta con sistemas de datos existentes

Sistema de Hooks Extensible

• Callbacks configurables en diferentes puntos del ciclo de vida del agente
• Modificación de comportamiento sin cambiar el código core
• Monitorización y logging avanzado de las operaciones

Observabilidad Completa

• Métricas detalladas de cada ejecución del agente
• Trazas completas del proceso de razonamiento
• Información sobre tokens usados, tiempo de ejecución y herramientas utilizadas

Ventajas de Strand Agents

Ventajas del Ecosistema Strand Agents

1. Simplicidad: API basada en Python que permite desarrollar agentes de forma simple
2. Flexibilidad: Soporte para múltiples proveedores de modelos y herramientas personalizadas
3. Escalabilidad: Desde agentes simples hasta sistemas multiagente complejos
4. Observabilidad: Métricas y trazas completas para debugging y optimización
5. Persistencia: Gestión automática de estado y sesiones a largo plazo
6. Integración: Soporte nativo para MCP y ecosistema de herramientas extenso

Combinando MCP con Strand Agents

Una de las cosas más interesantes de este enfoque es que podemos utilizar Strand Agents con MCP de forma que tengamos una orquestación de agentes y herramientas brutal.

• MCP proporciona la integración estándar con herramientas
• Strand Agents proporciona el framework robusto para crear agentes potentes
• Combinándolos nos permiten crear un ecosistema completo para agentes empresariales.

Esta combinación permite crear agentes mucho más complejos, pero además orquestar estos Strand Agents y MCPs de forma que tengamos una solución mucho más optimizada, además de poder gestionar estados, contextos, etc.

Recursos Adicionales

Si queréis profundizar en estos conceptos, aquí tenéis algunos enlaces útiles:

MCP (Model Context Protocol)

• Documentación oficial de MCP - Guía completa del protocolo
• Repositorio de MCP Servers - Colección de servidores MCP oficiales
• AWS Labs MCP Servers - MCPs específicos de AWS desarrollados por AWS Labs
• MCP SDK - SDK de Python para desarrollar MCPs

Strand Agents

• Web oficial de Strand Agents - Sitio oficial del framework
• SDK de Python - Repositorio oficial del SDK
• MCP Server - Servidor MCP para Strand Agents
• Ejemplos y samples - Repositorio con ejemplos prácticos
• Documentación - Guías y tutoriales completos

Herramientas Mencionadas

• Amazon Q Developer CLI - Documentación oficial
• Kiro - IDE con agentes integrados

Conclusión de la Primera Parte

Al principio del artículo comentaba que otras veces no me apetecía escribir sobre IA, no porque no me pareciese interesante, sino porque había demasiado hype y creo que nos saturaba mucho.

Pero este cambio con el modelo Agentic no es solo una mejora incremental en el modelo de IA.

Estamos en un momento muy importante porque estas dos tecnologías juntas nos han dado dos herramientas en AWS que no hay palabras para describirlas como son Amazon Q Developer CLI y Kiro, que han venido a cambiar cómo trabajamos hasta ahora.

En la segunda parte explicaremos cómo Amazon Q Developer CLI y Kiro están aplicando estos conceptos para revolucionar el desarrollo de software, y qué significa esto para el futuro de nuestra industria.

👉 Próximo: “Kiro y Amazon Q Developer CLI: La revolución Agentic en nuestro día a día”

Este es mi cuarto año yendo al AWS re:Invent y la verdad es que me apetecía un montón hacer una guía sobre el propio evento, sobre cómo planificar y cómo aprovechar al máximo esta experiencia única.

Es un evento que es muy interesante, pero a la vez creo que es difícil de planificar. Por eso he decidido compartir todos los consejos y trucos que he aprendido a lo largo de estos años para que puedas sobrevivir y disfrutar al máximo del re:Invent.

En este post vamos a ver:

• ☁️ Qué es el AWS re:Invent y por qué es especial
• 🌵 Las particularidades de Las Vegas que debes conocer
• 🏨 Dónde alojarse: los mejores hoteles según tu presupuesto
• 🎒 Qué llevar en la maleta (y qué es imprescindible)
• 📚 Cómo navegar por las sesiones y keynotes
• 🎁 La Expo y el swag
• 🎉 Las fiestas y eventos sociales
• 💡 Mis tips finales para sobrevivir

¿Qué es el AWS re:Invent? ☁️

El re:Invent es el evento anual de AWS que se celebra en Las Vegas. Siempre se celebra en Las Vegas desde que se inició, hace 12 años.

El evento siempre es más o menos en las mismas fechas: justo después de Acción de Gracias en Estados Unidos.

Este año (2025) es del 1 de diciembre al 5 de diciembre. Acción de Gracias es el cuarto jueves de noviembre, por lo que el evento empieza el siguiente lunes. Es decir, finales de noviembre o primeros de diciembre.

Es el evento más importante de AWS, donde se anuncian las principales novedades, se imparten miles de sesiones técnicas y se reúnen decenas de miles de profesionales de todo el mundo (más de 65.000 asistentes los últimos años).

Las Vegas: Lo que Necesitas Saber 🌵

Un Desierto con Particularidades

Las Vegas es una ciudad bastante peculiar dentro de Estados Unidos, conocida obviamente por el juego y por ser el patio de recreo de Estados Unidos, pero que tiene algunas cosas importantes que hay que saber.

El Clima del Desierto

Lo primero es que es un desierto, y esto es crucial. La temperatura no es muy baja en general, pero es verdad que hace frío.

Es un desierto: por las noches hace frío, por el día hace bastante calor. No un calor excesivo (es en diciembre), pero sí que hay una diferencia de temperatura muy grande.

Por otro lado, el ambiente es muy, muy seco. Eso se nota mucho, sobre todo por las noches. Al despertarte vas a notar que tienes la garganta muy seca y en el día a día los labios se resecan mucho.

El Strip: Más Grande de lo que Parece

No es la ciudad más grande de Estados Unidos, pero es una ciudad grande, sobre todo la parte del Strip.

El Strip es la calle principal donde están todos los hoteles principales que hemos visto mil veces en las películas con sus grandes hoteles y luces de neón. Sin embargo, es más grande de lo que aparenta en las películas.

Parece que los hoteles están muy cerca unos de otros, y efectivamente lo están, pero son gigantescos. Moverte de un hotel a otro toma tiempo. Es más, salir de un hotel a veces es complicado, ya que básicamente están diseñados para que no salgas de ellos.

El Gran Premio de Fórmula 1

Es importante saber que justo antes del re:Invent se produce el Gran Premio de Fórmula 1. Por ello, vais a ver la ciudad un poco diferente a lo habitual, ya que tendrá los muros de la Fórmula 1. El circuito pasa precisamente por el Strip y por casi todos los casinos donde se celebra el re:Invent.

Como ejemplo, la típica imagen de las fuentes del Bellagio es bastante diferente, no vais a ver esta foto porque las gradas están justamente delante de la fuente (aunque el espectáculo se puede ver y mola bastante).

Los Centros de Conferencias 🏢

El evento se realiza en diferentes centros de conferencias. Los centros de conferencias normalmente están asociados a un hotel y están en el Strip.

En total son seis centros de conferencias, aunque es verdad que el Encore y el Wynn se pueden considerar uno. Los principales son:

• Venetian y Caesar Forum, que son los más importantes
• MGM Grand
• Mandalay Bay
• Wynn/Encore

Moverse de un centro de conferencias a otro no es sencillo y lleva bastante tiempo.

Existen autobuses del propio evento (y gratuitos) que permiten moverte entre ellos, pero con las obras de la Fórmula 1 son bastante lentos y puede llevar bastante tiempo moverse de uno a otro.

Entre el Venetian y Caesar Forum es sencillo ya que habilitan un puente peatonal que los conecta, por lo que se tarda poco (10-15 minutos).

Entre el Caesar Forum y el MGM Grand hay un monorail que es bastante rápido. Yo para moverme entre estos dos hoteles lo recomiendo porque es lo más rápido y es gratuito (solo en ese tramo, del MGM al Caesar o del Caesar al MGM).

El Wynn y el Encore están también conectados, por lo que ir de uno a otro no es problema.

Dónde Alojarse: Guía de Hoteles 🏨

El Mejor: Venetian (Pero…)

Obviamente el mejor hotel es el Venetian, porque es donde está toda la acción: donde está la Expo, las keynotes y hay un montón de sesiones, además está muy cerca del Caesar Forum, y por último es el hotel donde van a estar todos los eventos de partners.

Pero también es el más caro, excesivamente caro. Es un hotel de cinco estrellas, además está prácticamente reservado entero por AWS y por los partners, con lo cual es muy complicado tener una habitación, además de que es carísimo.

Las Mejores Alternativas

Hoteles Recomendados

Nota: El orden no es necesariamente por orden de preferencia.

• Harrah’s: Es uno de los mejores hoteles, está pegado al Venetian y tiene acceso directo al Caesar Forum. Por lo que vas a estar muy cerca de las sessiones y de la expo.
• The LINQ: Esta pegado al Harrah’s es tambien un muy buen hotel y comparte el acceso al Harrah’s, el acceso esta entre los 2 hoteles.
• Flamingo: Es el hotel donde estaré yo este año. Está muy cerca del Caesar Forum. Es el siguiente hotel del strip en esa acera. Es un hotel que no esta tan cerca del Venetian pero si del Caesar Forum.
• Treasure Island: Es un hotel muy recomendado, bastante barato en comparacion con otros. El hotel esta enfrente del Vennetian, aunque esta cerca se tarda un poco en llegar a la expo ya que esta en la otra punta del hotel. Es un hotel que se agota rapidamente en la web del re:Invent.
• Horseshoe: Es el hotel donde estuve yo el año pasado, esta algo mas apartado, pero se puede llegar en 10 minutos al Caesar Forum. Para llegar al strip tambien tienes que cruzar una zona comercial.
• Holiday Inn Club Vacations at Desert Club Resort: No esta en el strip pero tiene una acceso al Caesar Forum muy cerca, aunque no es el acceso principal.
• Westin Tambien esta cerca del strip y del Horseshoe, no esta en el strip pero es sencillo llegar al Caesar Forum.

Como veis priorizo mucho la parte del Caesar Forum, basicamente porque el Centro de Conferencias con mas salas y que esta conectado directamente a la expo del Venetian.

Hay más hoteles, pero realmente cuanto más te alejes del Venetian más lejos estarás de toda la acción.

Yo otros años me alojé en el Excalibur, no es mal hotel, pero está muy lejos del Venetian y llegar al MGM Grand es complicado. Además, con las obras de la F1 se pierde mucho tiempo yendo en autobús.

Qué Llevar: Lista Esencial 🎒

Ropa Adecuada

Para el Día a Día

• Ropa cómoda

  Se camina bastante, por lo que os recomiendo vaqueros y camiseta o ropa ciertamente cómoda.

• Capas

  Debido a la diferencia de temperatura entre día y noche recomiendo llevar sudaderas o chaquetas ligeras, en la calle puede hacer frío (sobre todo de noche), pero andando puedes pasar bastante calor.

• Zapatos cómodos

  Se anda mucho, varios kilómetros al día, por lo que si no quieres sufrir mucho, lleva unas zapatillas cómodas para andar.

Para Las Fiestas Nocturnas

Si vais a algún evento de partners por la noche, algunos de ellos se realizan en discotecas de Las Vegas, si queréis entrar en alguna discoteca necesitaréis algo más formal.

Por eso, si vais a ir a fiestas, os recomiendo llevaros un atuendo más formal.

Ojo, esto solo aplica a las fiestas nocturnas y en discotecas, en general no es necesario, pero si queréis entrar al OMNIA o al Hakkasan, necesitáis ir más formal.

Yo por principios no suelo ir.

Elementos Imprescindibles

1. Protector Labial

Llevar lápiz labial, vaselina o un protector labial es crucial. Uno de los problemas en Las Vegas es que el ambiente es muy, muy seco. Normalmente se te secan un montón los labios y se te pueden cortar, con lo cual es muy recomendable llevarlo.

2. Botella de Agua

Una botellita de agua es crucial. En el re:Invent nos suelen dar una botella de agua para rellenar. Estamos en un desierto, puedes sufrir una deshidratación fácilmente. Se anda un montón y es recomendable estar bien hidratado y beber un montón de agua.

3. Mochila

Para moverte por el re:Invent, yo solo recomiendo llevar una mochila. No hace falta que esté llena, pero es verdad que si vas a la Expo y coges algo de swag, puedes meterlo en la mochila y no tienes que llevar múltiples bolsas y peso. Incluso puedes colgar bolsas en la mochila.

4. Maleta de Mano Extra

Si viajáis y habéis facturado una maleta, llevar también una maleta de mano. Aunque la llevéis vacía a la ida, a la vuelta con todo el swag probablemente la necesitéis.

5. Portátil (Opcional)

Llevar un laptop o no depende un poco de cada uno. Yo lo suelo llevar. Es verdad que hay sesiones en las que es interesante o incluso obligatorio llevar portátil. Yo suelo recomendar que el portátil por lo menos te lo lleves a Las Vegas y luego ya, dependiendo de si vas a ir a este tipo de sesiones o no, lo metas en la mochila.

Las Sesiones: Navegando por el Catálogo 📚

Principalmente el re:Invent es un evento técnico y formativo. Aquí tenemos un montón de sesiones y es verdad que es muy difícil elegirlas, el catálogo de sesiones es infinito.

Aunque la herramienta oficial está bien, para la planificación os recomiendo el Planner no oficial de Raphael Manke.

Es mucho mejor que la herramienta oficial y permite hacer listas, aquí está la mía provisional.

Las Keynotes: Imprescindibles

Primero tenemos las keynotes, que son las sesiones principales donde van a hablar los VPs de AWS y el CEO de AWS. Cada día hay una, de lunes a jueves:

Programa de Keynotes

Lunes por la noche: Dave Brown - Infraestructura y servicios core

Martes por la mañana: Matt Garman - El CEO de AWS, la keynote más importante.

Miércoles por la mañana: Swami Sivasubramanian - IA, ML y Data

Jueves por la mañana: Werner Vogels y Peter DeSantis - La más recomendable técnicamente, es una sesión a la que hay que ir.

Jueves por la tarde: Ruba Borno - partners (si no sois partner no suele ser muy interesante)

Consejos para las Keynotes

Las keynotes obviamente se graban y se emiten en directo en YouTube, no es necesario ir, pero la verdad es que el ambiente de la propia keynote, estar allí, ver las novedades de AWS en directo, suele ser bastante chulo.

Truco importante: Yo recomiendo estar una hora antes, incluso a veces algo más, en la cola de la keynote para poder entrar y conseguir un buen sitio.

Es curioso porque hay bastantes asientos reservados y si entras justo 5 o 10 minutos antes de que empiece la keynote puedes sentarte en un muy buen sitio, pero también es verdad que puedes quedarte fuera, sobre todo en las más demandadas.

Otros Tipos de Sesiones

Además de las keynotes, tenemos diferentes tipos de sesiones:

• Breakout Sessions - Las sesiones técnicas principales, que se graban y son las que vemos en YouTube.
• BootCamps - Existe la posibilidad de enrolarte en un BootCamp. (Requiere portátil).
• Builders’ Sessions - Sesiones de 1 hora hands on con una breve introducción teórica. (Requiere portátil).
• Chalk Talks - Sesiones más interactivas y técnicas que no se graban y muy interesantes.
• Code Talks - Sesiones parecidas a las Chalk Talks centradas en código que tampoco se graban.
• Exam Prep - Sesiones para preparar exámenes de AWS.
• Gamified Learning - GameDays, AWS Jams, Escape Rooms y otras sesiones interactivas que te permiten competir y aprender de forma amena. (Requiere portátil)
• Interactive Training - Sesiones de training interactivos parecidos a Skill Builder, pero con expertos in situ.
• Lightning Talks - Sesiones cortas de 15-20 minutos centradas en casos de uso y muy interesantes (aquí están las sesiones de la comunidad de AWS que son auténticas joyas escondidas en el catálogo)
• Workshops - Laboratorios prácticos donde tienes un laboratorio y puedes ir jugando con él, son bastante interesantes, además tienes un entorno AWS preparado y expertos para preguntar. (Requiere portátil).

Planificación y Reserva de Sesiones

El Desafío del Catálogo

El catálogo de sesiones puede ser horrible, es muy grande. Estamos hablando de más de 2000 sesiones diferentes y requiere una planificación.

Lo primero que tenéis que hacer es planificaros y por eso el planner no oficial es importantísimo.

¿Por qué es Importante Planificar?

Porque los centros de conferencias están muy separados unos de otros. Te puede interesar mucho una sesión en el Mandalay, pero la siguiente sesión la tienes en el MGM o la tienes en el Venetian en 10 minutos y no vas a llegar.

Además, tienes que tener en cuenta que las sesiones hay que reservarlas, es posible entrar sin reserva pero solamente el 15% del aforo no se reserva, además dependes de que la gente con reserva no se presente y vas a tener que estar mucho antes de la sesión.

Mi Estrategia de Planificación

Yo normalmente lo que suelo hacer es ver qué sesiones son las más importantes para mí y sobre eso voy haciéndome la agenda, luego marco en qué centros de conferencia voy a estar más tiempo. Intento pasar casi todo el día en un solo centro de conferencias, prefiero no moverme mucho porque se pierde mucho tiempo.

Pero si hay una sesión muy interesante en otro centro de conferencias, voy a ir. Esto os lo digo que es bastante importante y suelo hacerme la planificación y dejármelo todo preparado.

Cuándo se Abren las Reservas

A primeros de octubre (aproximadamente primera o segunda semana de octubre) se abre la reserva de sesiones. Hay sesiones con un aforo muy pequeño y muy demandadas (Chalk Talks y Code Talks).

Algunas sesiones, por ejemplo Lightning Talks, no se pueden reservar, las keynotes tampoco, pero las sesiones que se pueden reservar es importante reservarlas con tiempo.

Mi Estrategia de Reserva

Es más, yo las reservo el mismo día que se abre la agenda. Me pongo una alarma en el calendario, estoy 10 minutos antes con todo preparado para reservar las sesiones.

Aquí es importante planificaros bien, saber qué sesiones vas a reservar.

Gestión de la Carga de Sesiones

No Te Sobrecargues

Os recomiendo que os relajéis, que tengáis en cuenta que si vais a muchas sesiones vais a estar muy cansados. Yo el primer año, por ejemplo, creo que uno de los días hice siete u ocho sesiones, lo cual es una auténtica barbaridad.

Además, el primer año, el primer día se me olvidó incluso que tenía que comer - la hora de la comida se me pasó por completo y fue un desastre. Tuve que comer a todo prisa, horrible.

Planifica las Comidas y Descansos

Yo os recomiendo que os planifiquéis los descansos para poder parar siempre un rato. También os recomiendo que os paréis a comer en una mesa, existe la opción de comida para llevar, puedes cogerte una bolsa y la comes por el camino o la comes fuera de manera muy rápida, pero yo recomiendo sentaros porque al final os va a estresar muchísimo.

La agenda va a saltar por los aires

Todo esto es muy bonito, pero que sepáis que por mucho que os planifiquéis tenéis que tener en cuenta que vuestra agenda va a explotar, por un lado al final puede pasar que no llegues a una sesión o incluso que encuentres algo más interesante que hacer durante ese tiempo.

También os puede pasar que os pongan una reunión a la vez que una sesión en otro Centro de Conferencias (me ha pasado) y tienes que replanificar la agenda.

O que os apuntéis dos veces a la misma sesión en dos días diferentes (hay sesiones que se repiten). He conocido gente que le ha pasado.

Por último, hay unas sesiones que no están en la agenda todavía y que aparecen durante el evento, si aparece un nuevo servicio, normalmente este tiene sesiones asociadas, pero no se liberan hasta que no se publican en la keynote, así que estaros atentos a estas sesiones sobre servicios o features nuevas.

Por cierto, puede pasar que la sesión sobre un servicio nuevo sea en otro centro de conferencias al que tenías pensado ir…

La Expo y el Swag 🎁

Qué Esperar en la Expo

En la Expo hay un montón de swag (merchandising gratuito). Hay mogollón de peluches, camisetas, gadgets tecnológicos y todo tipo de regalos de los diferentes partners y proveedores.

Yo os recomiendo pasaros todos los días, para ir viéndola. Es gigantesca y el swag va cambiando, pero además es interesante conocer las novedades que traen los partners.

Estrategia para el Swag

Último día: En general no es difícil conseguir swag, pero el último día es muy sencillo ya que el último día tienen que gastarlo porque si no se lo tienen que volver a llevar. Entonces suele ser el día más fácil de conseguir swag.

Eso sí, puede ser que ese día queden tallas raras o cosas que nadie quiere. (Ojo, yo he conseguido muchos peluches a última hora)

Las Fiestas y Eventos Sociales 🎉

Importancia del Networking

Las fiestas también son muy importantes en el re:Invent. Hay un montón de fiestas, un montón de maneras de socializar con gente. Aquí ya depende de cada uno, obviamente.

Yo no soy muy fan de las fiestas y no me suelo prodigar en ellas, pero son un buen sitio para pasárselo bien y conocer gente.

Dress Code para Fiestas

En muchas de ellas hay un dress code, pero principalmente en las que se realizan por la noche en una discoteca.

Si vas a un restaurante a cenar por la tarde/noche (hay un montón de eventos así), no suelen pedirte un dress code, pero es verdad que si vas a algún club por la noche, ahí sí que piden un dress code.

Siempre tienes que reservar estas fiestas antes de ir, suele ser por invitación pero hay maneras de conseguirlas.

Conference Parties

Tenéis una web increíble que es Conference Party donde están todas las fiestas. La web tiene todas las fiestas que se van planificando en el re:Invent, con los enlaces para reservarlas y dónde se realizan.

Tenéis que rellenar vuestros datos y siempre os van a hacer preguntas. Luego son muy pesados los meses posteriores para intentar vender su producto (obviamente es para lo que hacen este tipo de fiestas).

re:Play

Hay una fiesta a la que sí tienes que ir (al menos una vez), que es el re:Play, es la fiesta oficial del evento el jueves por la noche.

La fiesta se realiza en el recinto de festivales de Las Vegas y es una auténtica pasada. Tenéis de todo: música, DodgeBall, yincanas, juegos variados, comida.

La verdad es que es como un festival nerd, con un poco de todo.

Suele tocar algún grupo conocido (Weezer en 2024 y Portugal The Man en 2023) y cierra algún DJ importante (Zedd 2024, Major Lazer 2023 y Martin Garrix 2022).

Mi Recomendación sobre Fiestas

Si queréis ir, tenéis que ir - son bastante chulas y os lo vais a pasar bastante bien, pero también que descanséis. Es imposible ir a todas.

Es verdad que hay gente que dice: “Oye, yo esta semana voy a ir a todas las sesiones, voy a ir a todas las fiestas, no duermo y ya cuando vuelva a casa dormiré.” Se puede hacer, pero es muy complicado.

Mi recomendación es que os lo toméis con calma los primeros días es una semana - el re:Invent dura desde el lunes hasta el jueves, y necesitáis energía para aprovechar realmente el evento.

Mis Tips Finales 💡

• Recordar comer - No seáis como yo y recordar comer. Cada día en cada venue hay un menú diferente de algún país (os recomiendo no ir al Venetian a comer, el comedor es gigante y se tarda en llegar a la mesa)
• Hidratarse - Beber agua constantemente.
• Aprender - El re:Invent es un evento formativo y se puede aprender mucho.
• Relacionarse - Hay mucha gente con un background diferente de la que se puede aprender mucho.
• Manejar el hype - Los lanzamientos siempre son impresionantes, pero hay que intentar bajar un poco el hype y ver si lo que presentan es interesante o simplemente humo (sobre todo esperar a ver el pricing)
• Conoce a las caras de AWS - Ver a los Advocates o a Jeff Barr no es imposible, y son gente bastante abierta, les puedes pedir un selfie.

El re:Invent puede ser abrumador la primera vez, pero con estos consejos estarás preparado para aprovechar al máximo estos días intensos en Las Vegas.

¡Nos vemos en Las Vegas! 🎲☁️

La respuesta está en algo que parece imposible: controlar el tiempo.

En este artículo vamos a explorar cómo AWS ha conseguido que Aurora DSQL consiga algo que parecía imposible o al menos muy complejo y es que una BBDD Postgres admita la escritura en múltiples regiones con consistencia.

En este artículo vamos a ver:

• El problema fundamental del tiempo en bases de datos distribuidas
• La solución de AWS: Sincronización de tiempo a escala global
• Aurora DSQL: Arquitectura real de sincronización distribuida
• Comparativa con Aurora PostgreSQL
• Limitaciones y consideraciones

El Problema Fundamental: El Tiempo en Bases de Datos Distribuidas

Antes de entender cómo Aurora DSQL resuelve el problema, necesitamos comprender por qué el tiempo es tan complejo en sistemas distribuidos.

El Teorema CAP o Teorema Brewer

En 2000, Eric Brewer formuló el Teorema CAP que establece que en un sistema distribuido solo puedes garantizar dos de estas tres propiedades:

• Consistency (Consistencia): Todos los nodos ven los mismos datos al mismo tiempo
• Availability (Disponibilidad): El sistema sigue funcionando aunque fallen algunos nodos
• Partition tolerance (Tolerancia a particiones): El sistema continúa operando aunque se pierda comunicación entre nodos

Cualquier base de datos como Aurora PostgreSQL o Aurora MySQL elige Consistencia y Disponibilidad, sacrificando la tolerancia a particiones. Por eso para escritura en Aurora PostgreSQL tenemos un nodo primario y el resto de nodos son réplicas secundarias, tanto en la misma región como en múltiples regiones. Pero Aurora DSQL requiere que las tres propiedades estén garantizadas, lo que requiere un enfoque completamente diferente.

El Problema de la Ordenación Temporal

Imagina esta secuencia de eventos:

Región us-east-1  (10:00:00.020123): UPDATE users SET balance = 900 WHERE id = 123
Región us-west-2  (10:00:00.019548): UPDATE users SET balance = 200 WHERE id = 123
Región eu-west-1  (10:00:00.022020): UPDATE users SET balance = 500 WHERE id = 123
Región eu-south-2 (10:00:00.019386): UPDATE users SET balance = 300 WHERE id = 123

¿Cuál de estas transacciones debería ejecutarse primero?

Son ejecuciones en 4 regiones diferentes en el mismo segundo, sobre el mismo dato y con valores diferentes.

Si utilizamos un sistema como Aurora PostgreSQL con un nodo en la región us-east-1 primario, el dato correcto sería el dato de esta región, ya que el resto de ejecuciones tendríamos que sumar la latencia, lo que produciría inconsistencias.

Además de este problema estamos suponiendo que los sistemas están completamente sincronizados al milisegundo, pero esto no es siempre así. Una sincronización de tiempo no es sencilla.

Por último estamos viendo un ejemplo de una acción, mientras que una transacción conlleva varias acciones anidadas, lo que puede suponer un problema mayor.

Este es el problema que Aurora DSQL debe resolverCrear un orden temporal global y consistente para todas las transacciones, independientemente de dónde se originen y tener un tiempo real y sincronizado entre regiones.

La Solución de AWS: Sincronización de Tiempo a Escala Global

Tradicionalmente, cualquier centro de datos ha utilizado NTP (Network Time Protocol) para sincronizar con relojes atómicos que tienen una precisión a nivel del nanosegundo. Sin embargo, NTP presenta limitaciones críticas para sistemas que requieren precisión extrema, ya que tiene dependencias con una red conectada y por tanto sufre de latencia de red y por tanto puede llegar a una precisión de milisegundos.

AWS necesitaba una sincronización entre regiones mucho mayor, si quería tener un sistema como Aurora DSQL.

Amazon Time Sync Service

AWS ha invertido mucho en que sus infraestructuras estén sincronizadas, para ello creó Amazon Time Sync Service.

Este servicio utiliza una flota de satélites con relojes atómicos que se conectan con todas las regiones de AWS proporcionando el mismo tiempo a todas ellas. Los relojes atómicos son muy caros, pero son necesarios en cualquier sistema de posicionamiento satélite como GPS. Además tienen una ventaja adicional, cuando envían los datos de tiempo sabemos con exactitud a qué distancia está el satélite y por tanto la latencia de la señal con un nivel de precisión muy alto. A diferencia de un servicio tipo de NTP contra relojes atómicos en tierra esta latencia es estable y por tanto nos da una precisión mucho mayor.

La precisión alcanzada es del orden de nanosegundos entre regiones, algo impensable hace pocos años.

ClockBound: Midiendo la Precisión del Tiempo

Complementando Time Sync Service, AWS ha desarrollado ClockBound, un demonio y librería open source que mide la precisión del reloj de las instancias EC2 y permite determinar el orden temporal real de los eventos.

Aunque el Amazon Time Sync Service proporciona tiempo muy preciso, siempre existe una pequeña desviación en la sincronización. ClockBound cuantifica esta desviación, y añade ciertas funcionalidades fundamentales para Amazon DSQL:

Funcionalidades principales:

• Intervalos de tiempo con incertidumbre: En lugar de un timestamp exacto como 10:00:00.123456789, ClockBound proporciona un rango [10:00:00.123456785, 10:00:00.123456793] qué garantiza que el tiempo real está dentro de ese intervalo.
• Comparación temporal definitiva: Puede determinar si un evento A ocurre definitivamente antes que un evento B, o si son potencialmente concurrentes.
• Detección de concurrencia: Identifica cuándo dos eventos pueden haber ocurrido al mismo tiempo, lo que es crucial para resolver conflictos de transacciones en DSQL
• Optimización de esperas: Calcula el tiempo mínimo que debe esperar una aplicación para garantizar que un timestamp sea globalmente único.

Con ClockBound podemos comparar nuestra secuencia de tiempos de forma más exacta:

Evento us-east-1: [10:00:00.020120, 10:00:00.020126] 
Evento us-west-2: [10:00:00.019545, 10:00:00.019551]
Resultado: us-west-2 ocurrió definitivamente antes que us-east-1

Evento eu-west-1: [10:00:00.022018, 10:00:00.022022]
Evento eu-south-2: [10:00:00.019384, 10:00:00.019388] 
Resultado: eu-south-2 ocurrió definitivamente antes que eu-west-1

Evento us-east-1: [10:00:00.020120, 10:00:00.020126]
Evento us-west-2: [10:00:00.019545, 10:00:00.019551]
Evento con conflicto: [10:00:00.019550, 10:00:00.020125]
Resultado: El evento conflictivo se solapa con ambos

Como podéis suponer sin ClockBound Aurora DSQL probablemente no existiría.

Por cierto aunque ClockBound ha sido desarrollado por AWS es un proyecto de código abierto que cualquiera puede usar.

Aurora DSQL: Arquitectura Real de Sincronización Distribuida

Bueno ya va siendo hora de empezar a hablar de cómo funciona Aurora DSQL y qué componentes lo conforman.

Ahora que entendemos cómo AWS ha resuelto el problema del tiempo, podemos explorar cómo Aurora DSQL utiliza esta tecnología para crear una base de datos verdaderamente distribuida que mantiene las propiedades ACID a escala global.

¿Cómo Funciona DSQL?

Aurora DSQL no es simplemente un Aurora PostgreSQL mejorado. Es una arquitectura completamente nueva que reimagina cómo debe funcionar una base de datos para permitir la consistencia en multi-región.

Componentes principales:

Es importante entender que cada capa escala de forma horizontal, independientemente del resto de capas y dinámicamente, todo ello dependiendo de la carga que demandemos a nuestro Aurora DSQL.

Esto hace que sea un servicio totalmente serverless.

Adjudicators:

Aunque la primera capa es Query Processor, vamos a hablar primero de la capa de Adjudicator.

La capa de Adjudicator es probablemente el componente más innovador de Aurora DSQL. Son procesos distribuidos que implementan algoritmos de consenso para garantizar que todas las regiones estén de acuerdo sobre el orden de las transacciones.

Cuando una transacción necesita ejecutarse, la capa de adjudicator revisa si existe conflicto con alguna otra transacción reciente. Para esto utilizan un algoritmo de consenso optimizado y distribuido, que permite detectar posibles conflictos.

Además esta capa escala horizontalmente pudiendo tener múltiples adjudicators para diferentes particiones de nuestra BBDD, cada adjudicator se ocupa de un espacio diferente de nuestra BBDD.

En Aurora DSQL todas las capas están desacopladas, esto implica que podemos definir sistemas de particiones diferentes para cada capa, de forma que los adjudicator no se particionan en función de cómo vamos a almacenar nuestros datos, sino de cómo vamos a analizar los conflictos entre transacciones, mejorando el rendimiento de esta tarea.

Los adjudicators no están replicados en cada región, sino que están distribuidos por espacios de la BBDD, en cualquier momento un adjudicator puede cambiar de región.

Journal Layer:

El Journal es donde se registran todas las transacciones aprobadas por los Adjudicators. Es similar al WAL (Write-Ahead Log) de Aurora PostgreSQL, pero distribuido en varias regiones.

Esto permite que cada transacción aprobada por un adjudicator se escriba directamente en los Journal. Esta capa es la responsable de la durabilidad de los datos, ya que los registros del Journal son inmutables, están distribuidos y replicados en las regiones que elijamos, de forma que podemos tener una trazabilidad de todas las transacciones en este log de forma confiable y con respaldo.

Storage:

La capa de almacenamiento de Aurora DSQL extiende el concepto de Aurora Storage pero añadiendo capacidades de distribución global y consistencia temporal.

Una de las ventajas principales del Storage de Aurora DSQL, es que no es necesario que se ocupe de los conflictos (adjudicator) ni de la durabilidad (journal), esto da más flexibilidad a esta capa permitiendo una optimización mayor.

En vez de basar esta capa en una replicación de datos síncrona, lo que hace esta capa es basar la distribución del storage en particiones de datos, pero añadiendo capacidades de sharding no solo basados en particiones por claves, sino también por tiempo de acceso y regiones, de esta forma los datos están distribuidos de una forma más óptima aunque también estén replicados en las diferentes regiones.

Esto no es posible en una base de datos tradicional.

Query Processor:

Ya que hemos entendido cómo funcionan el resto de capas podemos hablar de Query Processor.

Query Processor es la capa donde se recibe cualquier Query y es donde Aurora DSQL recibe las peticiones SQL y las convierte en operaciones distribuidas. A diferencia de Aurora PostgreSQL, aquí no hay un nodo “primario” único.

Como hemos visto antes nuestro storage no está particionado de una forma estándar, los datos no están replicados en el mismo storage, sino que están distribuidos en diferentes particiones de storage para mejorar el rendimiento.

Esto provoca que cualquier operación de lectura sea menos eficiente porque tenemos que saber dónde está el dato. También pasa con las operaciones de escritura ya que estas van a ser analizadas por la capa de adjudicator antes de escribirse en el Journal y posteriormente a la capa de Storage.

Además hemos visto que todas estas capas están distribuidas en diferentes particiones y que no tienen por qué ser iguales, es decir la capa de adjudicator no está particionada igual que la capa de storage.

Por este motivo Query Processor es una capa fundamental, ya que es la capa que orquesta todas nuestras querys, de forma que es capaz de saber en qué partición está un dato en storage para consultarlo o a qué adjudicator tiene que asignar la tarea de escritura de cualquier dato.

De esta forma esta capa minimiza la latencia reduciendo las tareas y loops que se pueden generar en cualquier transacción.

Otra ventaja para mantener la consistencia es que hace una ordenación temporal de las lecturas y elige el dato versionado más óptimo, por eso si realizamos una consulta de lectura de un dato que ha sido modificado después de nuestra lectura, pero por latencia nuestra escritura ha sido más rápida, en vez de devolvernos el dato modificado nos va a dar la versión del dato en el momento de la ejecución de la query.

Ejemplo de Diagrama Completo:

¿Pero en qué mejora esta arquitectura a una arquitectura tradicional?

La verdad es que la arquitectura está bien, pero realmente funciona ¿?

Strong Snapshot Isolation

Aurora DSQL utiliza una variación del protocolo Optimistic Concurrency Control en lugar de un modelo tradicional. Esto es crucial para el rendimiento en un entorno distribuido.

Básicamente el protocolo de Optimistic Concurrency Control define que si estamos ejecutando una transacción que pueden concurrir con otra, el commit de esta transacción solamente puede ejecutarse en el caso que cumpla con las reglas de aislamiento definidas.

Por eso DSQL usa Strong Snapshot Isolation, este modo de trabajo permite que varias transacciones puedan ejecutarse en paralelo cumpliendo una serie de reglas:

1. Todas las lecturas de la transacción se hacen utilizando el timestamp del inicio de la transacción (Tstart).
2. En el momento de realizar el commit de los datos se establece el timestamp de commit (Tcommit).
3. La transacción puede ejecutar el commit única y exclusivamente si ninguna otra transacción ha realizado un commit en la misma clave durante el tiempo de inicio de la transacción (Tstart) y el tiempo de commit (Tcommit)
4. Se ejecutan las escrituras utilizando el timestamp de Commit (Tcommit)

Esto tiene varias ventajas:

1. Nunca vamos a ver datos que no vengan después de un commit.
2. Las lecturas son repetibles y por tanto cacheables.
3. Las lecturas vienen desde un solo punto de tiempo (lógico).
4. Las escrituras conflictivas son rechazadas, no se pierden escrituras.

Por este motivo es tan importante la capa de Query Processor y Adjudicator, ya que es la encargada de hacer magia y que esto funcione.

Optimización Multi-Región

Hasta ahora lo que hemos visto parece que no es muy multi-región, además que seguiríamos teniendo un problema con las latencias, pero hemos visto un punto importante DSQL separa las lecturas de las escrituras y además tiene un componente fundamental como Query Processor que es donde se encolan las escrituras antes de realizarse el Commit.

De esta forma toda la transacción se puede llegar a ejecutar localmente aunque los datos estén distribuidos ya que únicamente a la hora de realizar el Commit es cuando necesitamos que la capa de Adjudicator valide y es posible que este adjudicator esté en otra región, pero solamente lo necesitamos para ejecutar el commit, no para escribir el dato.

Esto mejora increíblemente el rendimiento, evitando saltos entre regiones innecesarios, por lo que la latencia real de DSQL es mucho más baja de lo que esperaríamos.

Optimización de FailOver

Otra ventaja es que la capa de Adjudicator es una capa que no guarda todos los datos, solamente las transacciones recientes, para estudiar si hay conflicto por lo que es fácilmente replicable en caso de caída de una región.

Por otro lado la capa de Journal sí está distribuida y replicada, por lo que en caso de caída los datos están replicados en multi-región.

Por último la capa de storage, que siempre es algo más lenta a la hora de replicar, tiene la capacidad de rehacer todas las escrituras pendientes utilizando la capa de Journal.

Comparativa con Aurora PostgreSQL o bases de datos tradicionales

Eliminación del Concepto de “Primario”

En Aurora PostgreSQL, hay un nodo primario que maneja todas las escrituras.

En Aurora DSQL, podemos iniciar una escritura desde cualquier región, minimizando las latencias en multi-región.

Escalabilidad Horizontal Real

Aurora DSQL puede escalar añadiendo más regiones sin que tengamos una degradación de rendimiento.

FailOver más rápido

En Aurora PostgreSQL, si la región primaria falla, es necesario que una de las réplicas en otra región pase a ser primario (proceso de 1-2 minutos).

En Aurora DSQL el proceso es mucho más rápido porque no existe un primario y la carga está distribuida.

Escalado Horizontal

Aurora DSQL es una BBDD con capas totalmente desacopladas, lo que hace que sea posible realizar un escalado horizontal y desescalado horizontal, cosa que en Aurora PostgreSQL o en una BBDD tradicional no es posible

Además es una BBDD totalmente serverless.

Limitaciones y Consideraciones

Aurora DSQL es una maravilla, pero no es una base de datos para todos los públicos, por lo que personalmente no la recomiendo para todo el mundo.

Es una base de datos increíble si tu caso de uso es el adecuado, pero si tienes un caso de uso tradicional, probablemente no sea tu base de datos, incluso puede llegar a ser muchísimo peor que Aurora PostgreSQL.

Es importante remarcar que Aurora DSQL prioriza consistencia sobre latencia extrema:

• Transacciones simples: 10-50ms adicionales vs Aurora PostgreSQL.
• Transacciones complejas: Puede ser 2-5x más lento que Aurora PostgreSQL.
• Lecturas: No hay mucha variación ya que se utilizan réplicas locales.

Comparativa de Latencia en la misma región

Si nuestras cargas están en una única región, Aurora DSQL va a tener una latencia mucho mayor.

Modelo de Precios de Aurora DSQL

Aurora DSQL utiliza un modelo de precios serverless que cobra por:

Compute (Procesamiento):

• Se factura por Aurora Compute Units (ACUs) consumidas.
• Escalado automático basado en la carga de trabajo.
• No es necesario provisionar

Storage (Almacenamiento):

• Cobro por GB almacenado por mes
• Replicación automática incluida en el precio
• Backup automático incluido

I/O (Entrada/Salida):

• Cobro por millones de requests de I/O
• Incluye tanto lecturas como escrituras

Comparación de Costes: Aurora DSQL vs Aurora PostgreSQL

Escenario ejemplo - Aplicación mediana:

Aurora PostgreSQL (Provisioned):

- Instancia db.r6g.large: ~$200/mes
- Almacenamiento (100GB): ~$10/mes
- I/O (10M requests): ~$2/mes
- Total aproximado: ~$212/mes (región única)

Aurora DSQL (Serverless):

- Compute (equivalente): ~$300-400/mes
- Almacenamiento (100GB): ~$15-20/mes
- I/O (10M requests): ~$3-5/mes
- Multi-región incluida: Sin costo adicional
- Total aproximado: ~$320-425/mes (multi-región)

Factores que afectan el costo:

• Patrón de tráfico: Aurora DSQL es más eficiente para cargas variables
• Requisitos multi-región: Aurora DSQL incluye replicación en múltiples regiones sin costo adicional.
• Complejidad de transacciones: Transacciones distribuidas complejas pueden incrementar el costo
• Escalado automático: Puede resultar más económico para aplicaciones con picos de tráfico

¿Cuándo Aurora DSQL es más rentable?

• Aplicaciones con tráfico muy variable (serverless se adapta automáticamente) Siempre que la Latencia lo permita
• Necesidad de multi-región.

Casos de Uso No Recomendados

Aurora DSQL no es ideal para:

• Aplicaciones que requieren latencia ultra-baja (<1ms)
• Cargas de trabajo principalmente de lectura
• Sistemas con presupuesto muy limitado
• Aplicaciones que pueden tolerar eventual consistency

Aurora DSQL es una nueva categoría de base de datos que da una vuelta a las bases de datos distribuidas y multi-región. Con esta nueva base de datos, AWS ha abierto la puerta a aplicaciones globales que antes eran técnicamente imposibles.

Eso sí, no es una BBDD para todos los públicos y vamos a hablar de ella en esta serie de artículos, en este primer artículo vamos a hablar de cómo hemos llegado hasta aquí y qué alternativas tenemos a Amazon Aurora DSQL, porque Amazon Aurora DSQL puede no ser lo más adecuado para nuestro caso de uso.

Por resumir que es Amazon Aurora DSQL, es una BBDD distribuida que permite la consistencia en escritura y por tanto permite transacciones ACID en multi-región.

En este artículo vamos a ver:

• Que es ACID y su importancia
• Cómo han ido evolucionando las BBDD para ser más eficientes.
• Cómo Aurora revolucionó las BBDD.
• Que nos aporta Aurora Global Database y qué limitaciones tiene.
• Por qué necesitamos Aurora DSQL

¿ACID qué es eso?

Lo primero es aclarar que es ACID (Atomicity, Consistency, Isolation and Durability).

ACID es un término que se acuñó en 1983 y en el que se basa todo el desarrollo de las BBDD actuales y aunque se acuñó en 1983, desde 1973 ya existían este tipos de Bases de Datos.

Para ser ACID compliant una BBDD debe permitir que sus transacciones cumplan estos requisitos:

Atomicity (Atomicidad)

Una transacción suele tener múltiples pasos, pero tiene que tratarse como una única entidad o la transacción se ejecuta correctamente o falla en su totalidad, no puede dejar datos modificados parcialmente.

Consistency (Consistencia)

La consistencia de una transacción es que los datos son consistentes, de forma que no puedan corromperse al ejecutar una transacción.

Isolation

El aislamiento garantiza que las operaciones se ejecutan de forma aislada y sin afectarse entre sí, de forma que al existir múltiples operaciones modificando el mismo registro una no se ejecute hasta que termine la anterior.

Durability

Garantiza que una transacción una vez completada no pueda perderse incluso en caso de desastre y que los datos sigan estando disponibles una vez recuperado el desastre.

¿Todas las BBDD soportan transacciones ACID?

No todas las BBDD soportan ACID, por ejemplo Amazon MemoryDB no es ACID e incluso otras BBDD en AWS como Athena o DynamoDB originalmente no soportaban transacciones ACID (Actualmente las 2 las soportan).

Ahora vamos a ver cómo se ha ido solucionando este problema históricamente y cómo hemos llegado a Amazon Aurora DSQL.

¿Es fácil conseguir que nuestra BBDD sea ACID?

No, no lo es, de hecho es una de las principales limitaciones de una BBDD, si alguna vez os habéis preguntado por qué las BBDD tienen tantos problemas con los sistemas de ficheros en Unix en general, es por esto.

Una transacción en BBDD suele conllevar muchas operaciones de lectura/escritura, además requiere cierto nivel de bloqueo (Mientras se realiza una transacción no se puede ejecutar otra que modifique los mismos datos).

Esto genera muchos problemas a nivel de latencia, pero no solo de latencia de red, incluso de latencia entre los propios componentes de un servidor. Para las BBDD históricamente la latencia de escritura a disco era un problema muy grande.

Los discos han mejorado mucho en velocidad, pero aun así no era suficiente, por eso hace unos años se optó por escribir en memoria en vez de disco. La memoria RAM es mucho más rápida en escritura y lectura por lo que todo son ventajas, pero también tiene una serie de problemas. Por un lado es volátil, con lo que podemos perder los datos y por otro lado tampoco podemos cargar el contenido entero, porque la memoria habitualmente tiene menos tamaño que nuestros discos.

Así que se optó por utilizar algo bastante habitual que es la memoria paginada que es crear “Páginas” de memoria que no dejan de ser bloques físicos de memoria. De esta forma podemos tener parte de nuestros datos en una página de memoria (Los datos frecuentes o nuevos) y volcamos de forma asíncrona los datos a disco para persistirlos. Esto además mejora tanto el performance al usar memoria, como el performance de disco ya que podemos optimizar las escrituras y las lecturas.

Pero tendríamos un problema en caso de un fallo antes de volcar los datos a disco o si necesitamos recuperarlos, pero esto se soluciona con un sistema de logging transaccional conocido como Write-Ahead Logging (WAL) que sigue el principio DO-UNDO-REDO.

Adicionalmente a escribir en memoria el resultado la transacción, se escribe un log con la transacción en sí:

De esta forma si tenemos un fallo podemos cargar una página antigua que esté persistida y aplicar todos las transacciones que no se han persistido (REDO). O en caso contrario si queremos rectificar una transacción podemos saber que ha modificado y volver al estado anterior (UNDO):

Este sistema mejora infinitamente el rendimiento de las BBDD y es algo que lleva utilizándose muchos años en cualquier motor de BBDD.

¿Y cómo una BBDD puede ser ACID en múltiples Zonas de Disponibilidad?

Hasta aquí hemos visto cómo conseguimos esto en un solo servidor, pero si queremos tener alta disponibilidad, tenemos que montar 2 servidores (Un primario y un Stand-By) y aquí aparece el principal problema de todos la latencia de red.

Una transacción no es solo una lectura o escritura en una BBDD, sino que es una secuencia de operaciones y por tanto el tiempo de ejecución de una transacción depende de la latencia. Esto es un problema con una replicación síncrona, porque tenemos que esperar a que cada operación se replique. Esto incrementa mucho la duración de la transacción, porque tenemos que mandar la operación por red, que se ejecute en la réplica y esperar a que nos devuelva el ACK. Como la latencia de red es mucho más elevada, el tiempo de ejecución de una transacción se multiplica exponencialmente. Podemos optar por una solución un poco más eficiente, que son las Read Réplicas, que en vez de utilizar una replicación síncrona utilizan una replicación asíncrona, de forma similar a como hacíamos con el disco, pero que van a tener un lag de replicación que es el tiempo en el que la réplica no tendrá el dato actualizado.

Seguramente os preguntaréis cómo podemos garantizar que una transacción es ACID con una replicación, si vamos a tener un lag de replicación, la respuesta es sencilla, limitando las escrituras a una sola instancia. De esta forma garantizamos la consistencia y el aislamiento.

¿Es mejorable?

Este método era mejorable, ya que el lag de replicación nos puede afectar bastante y aquí es donde entra la magia de Amazon Aurora.

Amazon Aurora hizo algo muy interesante que fue separar la capa de Almacenamiento y la de Computo. Dejando el motor de la BBDD en una instancia y gestionando la capa de almacenamiento de forma independiente.

El motor de BBDD es exactamente igual, pero a la hora de realizar una escritura en vez de llamar directamente a disco, llama a los Storage Node de Aurora. Cada nueva escritura lanza este esquema:

1. Los registros se reciben en el Incoming Queue y se almacenan en el Hot Log en memoria
2. Se devuelve el ACK al motor de la BBDD sin esperar la persistencia
3. Los datos se registran en el Update Queue y se agrupan para optimizar las escrituras
4. Se genera un nuevo Data Page distribuyéndolo en 6 copias sincronizadas (2 por cada AZ)
5. Se realizan backups periódicos de Hot Logs y Data Pages a S3

De esta forma se consigue una latencia de replicación muy baja, menor a 100 ms (La cual es bajísima para un entorno multi AZ) en varias zonas de disponibilidad repartidas en 6 Copias, además se consiguen backups continuos y la posibilidad de hacer restauraciones a puntos determinados de tiempo.

Lo mejor es que esto no impacta en el rendimiento de la BBDD ya que las operaciones de Storage no se ejecutan en la misma instancia donde está nuestro motor de BBDD, permitiendo un mayor rendimiento en general.

Y además se replica vía Log todas las transacciones en todos los nodos. Aurora soporta hasta 15 read réplicas y 64 TB de almacenamiento automático y puede manejar hasta 500,000 lecturas y 100,000 escrituras por segundo.

Nota: Existen más pasos que he simplificado para un correcto entendimiento, ya que es un almacenamiento distribuido, no solo existe un nodo de Storage, etc.

Nota 2: A nivel de motor de BBDD también se guardan los registros en memoria de forma que la escritura es más rápida.

¿Y en múltiples Regiones?

Si necesitamos replicar nuestra BBDD en otra región, nos vamos a encontrar que la latencia de replicación es mucho mayor, básicamente porque la latencia de red entre regiones es muy alta.

Pero aquí es donde entra Amazon Aurora Global Database a ayudarnos.

Amazon Aurora Global Database extiende su modelo de replicación a otras regiones, en este caso además de separar la capa de Almacenamiento, separa la capa de replicación.

De esta forma vamos a tener una capa independiente para gestionar la replicación entre regiones y una capa de storage independiente para gestionar la replicación entre zonas. Esto permite que Amazon Aurora Global Database tenga mejor rendimiento a nivel de BBDD y una replicación entre regiones muy optimizada.

Cada nueva escritura lanza este esquema:

1. Se escriben los nuevos registros en los Storage nodes y réplicas de la BBDD zonales y adicionalmente se escribe en un servidor de replicación.
2. El servidor de replicación replica los registros de escritura en el servidor con el agente de replicación perteneciente al grupo de servidores de replicación en otras regiones.
3. Este servidor de replicación actúa como si fuese una BBDD primaria y ejecuta los registros de escritura tanto en la réplica global de la BBDD como en los Storage nodes de esta región.
4. Por último, si el servidor de replicación detecta que no ha recibido algún registro de escritura, los recogerá de los storage nodes de la región primaria.

De esta forma también se consigue una latencia de replicación muy baja, menor a 1 segundo en hasta 5 regiones secundarias. Cada región secundario tendrá adicionalmente replicación en zonas de disponibilidad y 6 Copias repartidas entre ellas, además tenemos backup multiregionales y continuos ya que el backup se almacenará también en cada región secundaria.

¿Y la escritura en múltiples regiones?

Es el mayor problema que hay en este modelo, ya que las escrituras solo pueden ejecutarse en la región primaria y por tanto la latencia de escritura en multiregión es altísima.

Existe una solución intermedia que es utilizar write forwarding en Amazon Aurora, esto nos permite configurar una réplica global para escribir en ella, aunque realmente lo que estamos haciendo es enviar estas peticiones con un forward a la BBDD principal. Es una forma un poco más eficiente de escribir en multiregion, que nos permite utilizar endpoints por región, pero no es muy eficiente en escritura.

El Desafío de las escrituras multiregión consistentes

Como hemos visto, tanto Amazon Aurora como Aurora Global Database han resuelto los problemas de rendimiento y replicación, siguen teniendo una limitación fundamental: las escrituras deben centralizarse en una región primaria para garantizar la consistencia ACID.

Esta arquitectura funciona perfectamente para aplicaciones que pueden funcionar con escrituras centralizadas, pero ¿qué pasa cuando necesitamos que usuarios en diferentes regiones puedan escribir con baja latencia manteniendo la consistencia de escritura? Aquí es donde Amazon Aurora DSQL entra a escena.

Uno de los problemas de las escrituras, es controlar la secuencia de tiempos, porque si lanzamos una escritura desde una región y lanzamos otra escritura sobre el mismo registro 100ms después en otra región, para cada una de estas regiones el dato correcto no es el mismo, porque no podemos controlar el tiempo y tendremos un problema de consistencia bastante grande. (Bueno realmente sí podemos controlar el tiempo, pero lo veremos en el próximo artículo).

Conclusiones.

A lo largo de este artículo hemos recorrido la evolución en AWS que ha llevado al desarrollo de Amazon Aurora DSQL, desde los fundamentos de ACID hasta las limitaciones de los sistemas multiregión actuales.

El sistema de replicación que utiliza Amazon Aurora y Amazon Aurora Global Database es una auténtica maravilla, porque mejora el performance increíblemente y además reduce los tiempos de replicación drásticamente.

Si no necesitamos escrituras multiregion Amazon Aurora o Amazon Global Database es la mejor opción para la mayoría de casos, pero en caso de requerir una BBDD global, distribuida y con escritura consistente en multiregion tenemos que optar por Amazon Aurora DSQL.

¿Cuánto cuesta Aurora DSQL?

Aunque AWS todavía no ha publicado precios oficiales, Aurora DSQL será considerablemente más caro que Aurora debido a su complejidad distribuida.

Tomando como referencia Aurora MySQL/PostgreSQL
Aurora Global Database: es un 65% más caro
Aurora DSQL: Se estima entre 3 y 5 veces más que Aurora Global

¿Cuál elegir?

NO uses Aurora DSQL si:

• Tus escrituras pueden centralizarse en una región (>80% de casos)
• Necesitas usar MySQL como motor de BBDD
• Tus transacciones no requieren baja latencia en escritura multiregión

Puedes utilizar Aurora Global Database cuando :

• Puedes tolerar write forwarding o escrituras en una sola región
• Requieres lecturas intensivas multiregion con escrituras ocasionales
• Necesitas un DR multiregión pero no escrituras activo-activo

Puedes utilizar Aurora Cuando:

• Tienes Aplicaciones regionales
• El presupuesto limitado
• Requieres una simplicidad operacional

Ahora que tenemos claro el problema, nos tenemos que hacer una pregunta: ¿Cómo ha conseguido AWS una BBDD con escritura multiregional sin romper ACID?

En el próximo artículo desvelaremos los secretos de Aurora DSQL y como AWS ha conseguido domar el tiempo en una BBDD.

👉 Próximo: “Aurora DSQL: Como controlar el tiempo”