DEV Community: Iván Castañeda

Crea tu propia guía de certificación para exámenes de AWS con IA y Notion

Iván Castañeda — Tue, 27 Oct 2026 01:32:39 +0000

Hay preguntas que uno responde y olvida al cabo de unas horas. Otras, en cambio, se quedan rondando por la cabeza como un acreedor a la puerta de casa, recordándonos que todavía tenemos algo pendiente por aprender.

Quienes hemos preparado una certificación de AWS conocemos bien ese pequeño drama: capturas de pantalla desperdigadas por el escritorio, preguntas guardadas en carpetas con nombres que nadie recuerda y frases subrayadas en colores que, con el tiempo, terminan pareciendo las notas de un detective que abandonó el caso a mitad de la investigación.

Y entonces surge la pregunta inevitable: ¿por qué no construir un lugar donde todas esas preguntas puedan vivir, organizarse y convertirse en una herramienta de estudio?

La idea es sencilla. Guardar una pregunta de certificación debería ser tan fácil como tomar una captura de pantalla. El resto del trabajo —leerla, comprender su estructura, analizar sus opciones y organizarla— puede dejarse en manos de una pequeña cuadrilla de servicios de AWS y un modelo de inteligencia artificial.

Así nació AWS Exam Questions AI, un proyecto que conecta los servicios de AWS con Notion para transformar imágenes de preguntas técnicas en un archivo de estudio estructurado, acompañado de respuestas y explicaciones en español.

Porque estudiar para una certificación ya tiene suficientes dificultades como para añadirle la de administrar un cementerio de capturas de pantalla.

Antes de abrir el caso: prepara tu cuaderno

No hace falta construir una biblioteca desde sus cimientos para empezar a llenarla de conocimiento. Puedes utilizar cualquier página de Notion que tengas a mano o, si prefieres comenzar con algo preparado, descargar la plantilla que he creado para organizar preguntas de certificaciones de AWS.

Tu siguiente paso comienza aquí:

Descargar la plantilla de AWS Certifications Exam en Notion

La intención es que tengas un lugar donde reunir preguntas, conservar sus respuestas, identificar palabras clave con colores y repasar aquellos conceptos que suelen aparecer una y otra vez en los exámenes.

Una palabra resaltada a tiempo puede ahorrarte varios minutos de confusión. Y, en un examen de certificación, unos cuantos minutos bien administrados pueden valer más que una enciclopedia entera.

Los sospechosos habituales: ¿qué servicios de AWS utilizaremos?

Todo buen misterio necesita personajes con funciones claras. En nuestro caso, ninguno lleva gabardina ni fuma junto a una ventana, pero todos cumplen con su cometido.

Amazon S3: el archivo donde comienza todo

Amazon Simple Storage Service, mejor conocido como Amazon S3, será nuestro depósito de imágenes. Aquí guardaremos las capturas de pantalla de las preguntas que queramos estudiar. Cada archivo quedará almacenado en un bucket, esperando el momento en que alguien lo llame a declarar. S3 no necesita comprender lo que contiene la imagen. Su trabajo es más sencillo: conservarla y ponerla a disposición del proceso que viene después. Es, por decirlo de algún modo, el archivista de nuestra investigación.

Amazon Textract: el testigo que sabe leer

Una imagen puede contener una pregunta brillante, pero para una máquina sigue siendo, en principio, un conjunto de píxeles. Aquí entra Amazon Textract, un servicio capaz de detectar y extraer texto de documentos e imágenes. Su misión consiste en recuperar las palabras que aparecen en la captura: el enunciado, las opciones de respuesta y cualquier otro texto relevante.

Textract no decide cuál es la respuesta correcta ni interpreta por sí solo toda la intención de la pregunta. Primero necesitamos obtener el contenido escrito. La interpretación llegará después. Es como interrogar a un testigo que puede repetir exactamente lo que vio, aunque todavía no conozca el significado de lo ocurrido.

AWS Lambda: el detective que aparece cuando lo llaman

AWS Lambda es el encargado de coordinar una parte fundamental del proceso sin necesidad de mantener un servidor funcionando permanentemente para esta tarea. Cuando se carga una imagen en el bucket de S3, un evento puede activar una función Lambda. Esta recibe la notificación, identifica el archivo y pone en marcha el flujo de procesamiento.

No hay que llamar a un operador ni esperar a que alguien abra una terminal. El procedimiento comienza automáticamente cuando ocurre el evento configurado. Lambda es ese detective discreto que aparece cuando el caso lo requiere, hace su trabajo y se retira hasta la próxima llamada.

Amazon Bedrock: el interrogador que encuentra sentido en las palabras

Ya tenemos el texto, pero todavía falta comprenderlo. Amazon Bedrock permite trabajar con modelos de inteligencia artificial generativa para analizar información, interpretar instrucciones y producir respuestas estructuradas.

En nuestro proyecto, el texto extraído por Textract se entrega al modelo junto con un prompt: una serie de instrucciones que le indican cómo debe analizar la pregunta, identificar sus opciones y organizar el resultado. El objetivo es obtener una estructura consistente que incluya el enunciado, las respuestas posibles, la respuesta propuesta y su explicación en español.

Bedrock es el interrogador de nuestro pequeño despacho: reúne las pistas y propone una interpretación de lo sucedido. Conviene recordar algo importante: la inteligencia artificial puede equivocarse. Por eso, las respuestas generadas deben verificarse, especialmente cuando se estudian conceptos técnicos que podrían aparecer en un examen real.

El plano del delito: ¿cómo funciona la arquitectura?

Toda investigación necesita un mapa. De lo contrario, uno termina persiguiendo sospechosos por callejones que no conducen a ninguna parte. La arquitectura de AWS Exam Questions AI sigue una secuencia bastante directa: una imagen entra en S3, un evento activa Lambda, Textract extrae el texto, Bedrock analiza el contenido y, finalmente, la información se organiza en Notion mediante su API.

Arquitectura general

El recorrido puede entenderse en seis etapas:

Carga de la imagen. El usuario sube una captura de pantalla con una pregunta de certificación a un bucket de Amazon S3.
Activación del proceso. Un evento de S3 invoca la función AWS Lambda configurada para procesar el archivo.
Extracción del texto. Lambda utiliza Amazon Textract para obtener el texto contenido en la imagen.
Análisis con inteligencia artificial. El texto se envía a Amazon Bedrock, donde un modelo generativo recibe las instrucciones necesarias para estructurar la pregunta y analizar sus opciones.
Construcción del resultado. La información se organiza en un formato JSON que puede contener el enunciado, las opciones, la respuesta propuesta y su explicación.
Registro en Notion. Mediante la API de Notion y la biblioteca PyToNotion, los datos se convierten en contenido dentro de la página configurada.

El resultado es un proceso automatizado en el que una simple captura puede terminar convertida en una ficha de estudio organizada.

La lógica del proyecto

La arquitectura nos muestra qué servicios participan. El flujo lógico, en cambio, nos permite entender cómo se relacionan. La distinción es importante: una cosa es saber qué personajes aparecen en la historia y otra muy distinta comprender por qué cada uno entra en escena.

En este proyecto, Lambda actúa como punto de coordinación. Textract se ocupa de la lectura, Bedrock de la interpretación y Notion de conservar el resultado en un formato útil para estudiar.

La integración con Notion es el último eslabón de la cadena, pero también uno de los más importantes. Una respuesta que termina perdida en un registro técnico sirve de poco; una respuesta que aparece en el cuaderno donde estudias puede convertirse en conocimiento reutilizable.

Las huellas digitales: políticas y permisos de IAM

Ningún detective sensato entrega las llaves de toda la ciudad a un desconocido. En AWS, esa misma prudencia tiene nombre: AWS Identity and Access Management (IAM).

Los servicios necesitan permisos para interactuar entre sí, pero concederlos sin cuidado puede abrir puertas que no deberían estar abiertas.

Para este proyecto, conviene distinguir los permisos relacionados con el almacenamiento de aquellos que necesita la función Lambda para ejecutar el flujo completo.

Permisos para Amazon S3

Las siguientes acciones pueden ser necesarias según las operaciones que realice el código:

s3:GetObject: permite leer los objetos almacenados en el bucket.
s3:PutObject: permite cargar o escribir objetos.
s3:ListBucket: permite consultar la lista de objetos del bucket.

No todas las acciones son imprescindibles en cualquier implementación. Si la función únicamente lee las imágenes y nunca escribe archivos ni enumera el contenido del bucket, puedes reducir los permisos en consecuencia.

Permisos para AWS Lambda

La función necesita una política de ejecución que le permita acceder a los servicios involucrados. Entre las acciones relacionadas con el flujo se encuentran:

s3:GetObject: leer la imagen que debe procesarse.
textract:DetectDocumentText: detectar y extraer texto de la imagen.
textract:AnalyzeDocument: analizar la estructura de documentos cuando esa capacidad sea necesaria.
bedrock:InvokeModel: invocar un modelo de Amazon Bedrock.
bedrock:InvokeModelWithResponseStream: utilizar respuestas en streaming si la implementación las requiere.
bedrock:ListFoundationModels: consultar modelos disponibles, si el código realiza esa operación.

Las acciones de escritura y listado de S3 también pueden ser necesarias si Lambda guarda resultados o enumera objetos.

Una precaución importante: estos permisos no deben copiarse indiscriminadamente en una única política. La función debería recibir únicamente las acciones que utiliza, restringidas a los recursos correspondientes siempre que sea posible.

Además, Lambda necesita sus permisos habituales para escribir registros en Amazon CloudWatch Logs. La invocación desde S3 requiere configurar correctamente los permisos de la política basada en recursos de la función, mientras que las llamadas a Textract y Bedrock dependen del rol de ejecución de Lambda.

En particular, el acceso a Bedrock debe estar habilitado para el modelo elegido y la región utilizada.

En seguridad, la elegancia no consiste en tener todas las llaves, sino en necesitar muy pocas.

El expediente del proyecto: estructura del repositorio

Si deseas examinar el funcionamiento del proyecto con más detalle, el repositorio está organizado en módulos para separar las responsabilidades principales.

AWS-Exam-Qustons-AI-AWS/
├── main.py                  # Punto de entrada de AWS Lambda
├── aws_question_agent.py    # Flujo principal de procesamiento
├── utils/
│   ├── ocr.py               # Extracción de texto de imágenes
│   ├── llm.py               # Análisis de preguntas con IA
│   └── notion.py            # Guardado de resultados en Notion
├── images/
│   ├── vaniadev.png
│   └── video.jpg
├── requirements.txt         # Dependencias de Python
├── pyproject.toml           # Configuración del proyecto
├── uv.lock                  # Bloqueo de dependencias
├── .python-version          # Versión de Python
├── .gitignore               # Archivos excluidos de Git
└── LICENSE.txt              # Licencia MIT

La estructura deja entrever una decisión acertada: cada módulo tiene una responsabilidad definida, main.py recibe la ejecución de Lambda; aws_question_agent.py coordina el trabajo; y la carpeta utils reúne las piezas especializadas en lectura, análisis y almacenamiento.

Esta separación facilita mantener el código, detectar errores y modificar una parte del sistema sin convertir cada cambio en una operación a corazón abierto.

¿Cómo desplegarlo en AWS Lambda?

A grandes rasgos, el despliegue contempla los siguientes pasos:

Preparar el código y sus dependencias para el entorno de ejecución de Lambda.
Crear la función Lambda y configurar su rol de ejecución.
Configurar el bucket S3 y el evento que activará la función.
Configurar el acceso al modelo de Amazon Bedrock y las credenciales o integraciones necesarias para Notion.
Subir una imagen de prueba y verificar los registros, el procesamiento y la creación del contenido.

Antes de poner el sistema a trabajar con muchas imágenes, conviene probarlo con unas cuantas capturas representativas. Los errores más interesantes suelen esconderse en los detalles: una opción mal leída, una respuesta que no respeta el formato esperado o una propiedad de Notion que no coincide con la estructura enviada.

La reconstrucción de los hechos: del archivo a la respuesta

Para entender mejor el recorrido, imaginemos una pregunta habitual de una certificación de AWS.

Una empresa utiliza clústeres de Amazon EMR para analizar sus cargas de trabajo. El equipo de ciencia de datos los deja funcionando incluso después de terminar sus tareas, lo que provoca gastos innecesarios. La dirección quiere encontrar una solución automatizada para terminar los clústeres inactivos.

La pregunta aparece en una captura de pantalla y comienza nuestro procedimiento.

1. La imagen entra en el archivo

El usuario sube la captura al bucket de S3. El objeto queda almacenado y el evento configurado notifica a Lambda.

Lambda solicita la extracción del texto mediante Textract. El resultado contiene el enunciado y las opciones que aparezcan en la imagen.

La calidad de la captura importa. Una imagen borrosa, una opción cortada o un texto demasiado pequeño pueden producir errores de extracción que después se propagarán al resto del flujo.

3. Bedrock analiza las pistas

El texto recuperado se envía al modelo junto con instrucciones que definen el formato esperado.

Por ejemplo, el prompt puede solicitar una estructura que incluya:

La pregunta original.
Las opciones de respuesta.
La opción considerada correcta.
Una explicación en español.
Los conceptos clave que conviene recordar.

La precisión del resultado dependerá tanto de las instrucciones como del modelo, la calidad del texto y la complejidad de la pregunta.

4. El resultado toma forma de JSON

Para que la información pueda trasladarse de manera consistente a Notion, el proyecto utiliza una estructura de datos. JSON permite representar los distintos campos de la pregunta de forma organizada.

Un ejemplo simplificado del resultado que podría generar el análisis sería:

{
  "question": "¿Cómo automatizar la terminación de clústeres EMR inactivos?",
  "options": [
    "Opción A",
    "Opción B",
    "Opción C",
    "Opción D"
  ],
  "correct_answer": "Opción B",
  "explanation": "La solución debe identificar los clústeres inactivos y terminarlos de acuerdo con las condiciones definidas."
}

Este fragmento es ilustrativo: las opciones y la respuesta son marcadores de ejemplo, no una resolución verificada de la pregunta original.

La ventaja de utilizar una estructura definida es que el contenido deja de ser un bloque de texto difícil de manipular y se convierte en información que el programa puede validar y transformar.

5. Notion recibe el expediente

Una vez construido el resultado, la integración con Notion utiliza la API para crear los bloques de contenido correspondientes.

La biblioteca PyToNotion forma parte de esta integración. Su función dentro del proyecto es facilitar el trabajo con Notion desde Python; la estructura exacta de los bloques y las propiedades enviadas depende de cómo se implemente la integración.

El resultado puede incluir preguntas numeradas, respuestas y explicaciones, de modo que el usuario tenga una colección lista para repasar.

El último documento: ejemplo de respuesta de la API de Notion

Cuando se crean bloques mediante la API de Notion, la respuesta puede incluir metadatos como el identificador del bloque, su tipo, la página a la que pertenece y las fechas de creación y edición.

El siguiente ejemplo muestra una respuesta representativa con una pregunta almacenada como elemento de lista numerada. Los identificadores y datos personales se han sustituido por valores ilustrativos.

{
  "object": "block",
  "id": "304e03e4-e8f2-492f-a7c0-3fd7",
  "parent": {
    "type": "page_id",
    "page_id": "2a3e03e9-f057-a765-8"
  },
  "created_time": "2026-02-11T02:05:00.000Z",
  "last_edited_time": "2026-02-11T02:05:00.000Z",
  "has_children": true,
  "archived": false,
  "type": "numbered_list_item",
  "numbered_list_item": {
    "rich_text": [
      {
        "type": "text",
        "text": {
          "content": "¿Cuál es la mejor solución automatizada para terminar clústeres EMR inactivos?"
        },
        "annotations": {
          "bold": false,
          "italic": false,
          "strikethrough": false,
          "underline": false,
          "code": false,
          "color": "default"
        }
      }
    ],
    "color": "default"
  }
}

La respuesta de la API confirma que Notion ha recibido un bloque y devuelve sus metadatos. Eso no significa que toda la respuesta de la inteligencia artificial sea correcta ni que todos los bloques de la página se hayan creado como esperamos: esas condiciones deben comprobarse en el flujo de la aplicación.

Para conocer los detalles de la estructura admitida por Notion, puedes consultar su documentación oficial de la API.

Las herramientas del oficio: dependencias de Python

Detrás de la arquitectura hay otra pequeña colección de herramientas que permite conectar los servicios y organizar el código.

Dependencia	Función dentro del proyecto
`boto3`	Interactuar con los servicios de AWS desde Python.
`langchain-aws`	Integrar componentes de LangChain con servicios de AWS, incluido Bedrock.
`langgraph`	Definir y coordinar flujos de trabajo con componentes de IA.
`PyToNotion`	Facilitar la integración con Notion desde Python.
`langchain-community`	Proporcionar integraciones y utilidades adicionales de LangChain.
`langchain-core`	Ofrecer componentes fundamentales de LangChain.
`pydantic`	Validar y estructurar los datos mediante modelos.
`numpy`	Proporcionar operaciones numéricas cuando sean necesarias.

No todas las dependencias tienen que intervenir directamente en cada ejecución. Su participación concreta depende de la implementación y de los módulos que las importen.

Si vas a modificar el proyecto, revisa también pyproject.toml y uv.lock para entender cómo se gestionan las dependencias y mantener un entorno reproducible.

Lo que conviene saber antes de cerrar el caso

El proyecto está pensado para trabajar con imágenes PNG y JPG y contempla preguntas de opción múltiple con alternativas como A, B, C y D. Las explicaciones se generan en español y se requiere acceso al modelo de Amazon Bedrock que se vaya a utilizar.

Sin embargo, hay algunos detalles que merece la pena tener presentes:

Calidad de imagen: una captura legible ayuda a reducir errores de extracción.
Validación de respuestas: la inteligencia artificial puede confundir servicios, condiciones o alternativas muy parecidas. Contrasta las respuestas con documentación oficial y material de estudio fiable.
Formato de salida: valida el JSON antes de enviarlo a Notion para evitar que una respuesta mal formada interrumpa el proceso.
Errores de integración: controla los fallos de permisos, las respuestas de los servicios y los límites de solicitudes.
Costos: revisa el uso de Lambda, Textract y Bedrock, especialmente si automatizas el procesamiento de muchas imágenes.
Seguridad: utiliza permisos de IAM de mínimo privilegio y protege los tokens de integración con Notion.

La automatización ahorra trabajo, pero no sustituye el criterio. El propósito no es memorizar respuestas a ciegas, sino construir una herramienta que ayude a comprender los conceptos que hay detrás de cada pregunta.

El archivo queda abierto: repositorio y videos

Si quieres examinar el código, reproducir el proyecto o adaptarlo a tus propias necesidades, aquí tienes el repositorio: AWS Exam Questions AI — GitHub

También he preparado material audiovisual para explicar el funcionamiento con mayor detalle.

Video: explicación del proyecto

En este video encontrarás una explicación más visual del flujo y de cómo se relacionan sus componentes.

Charla: AWS Student Builder Group UNAM

El proyecto también se presentó en una charla para la comunidad de AWS Student Builder Group UNAM, donde se explicó su funcionamiento y hubo espacio para preguntas y respuestas.

Charla en la comunidad de AWS Puebla

Durante el mes de marzo, el proyecto también llegó a la comunidad de AWS Puebla. Fue otra oportunidad para compartir la idea, conversar sobre su funcionamiento y mostrar cómo los servicios de nube pueden resolver problemas cotidianos de aprendizaje.

Entre agentes, libros y café, nuestro tercer meetup de AWS UG Ciudad de México

Iván Castañeda — Wed, 30 Sep 2026 22:57:01 +0000

Hay lugares que, con el paso del tiempo, comienzan a sentirse como una segunda casa. Casa Rafael Galván es uno de ellos. En nuestro tercer meetup, sus puertas volvieron a abrirse para recibir a una comunidad que, entre conversaciones, preguntas y alguna que otra sorpresa, se reunió para descubrir dos formas muy distintas de darle vida a las ideas: crear nuestro primer agente de inteligencia artificial y escribir un libro con la ayuda de AWS.

Como ya es costumbre, Edwin tomó la palabra para dar la bienvenida y compartir algunas de las novedades que AWS tiene preparadas, entre ellas los próximos eventos relacionados con re:Invent. Y así, entre anuncios y saludos, comenzó una velada que prometía dejarnos algo más que conocimientos.

El primero en subir al escenario fue Ramses Mata, quien tomó el micrófono con la soltura de quien conoce bien el camino que está a punto de mostrarnos. Su charla nos llevó al mundo de los agentes de inteligencia artificial y a la posibilidad de construir uno desde cero, sin perdernos en un laberinto de conceptos difíciles de seguir.

Con Strands Agents como compañero de viaje, Ramses fue desarmando cada engranaje del harness, explicando cómo se conectan las piezas que permiten a un agente interpretar instrucciones y actuar. Pero no se quedó en las palabras: para que nadie tuviera que conformarse con imaginarlo, nos mostró un proyecto sencillo, didáctico y directo, de esos que consiguen que una idea que parecía lejana comience a tomar forma frente a nuestros ojos. Porque hay cosas que se entienden mejor cuando alguien se toma el tiempo de construirlas contigo.

Después, Edwin regresó al escenario con una de esas ocurrencias que solo nacen cuando la confianza entre quienes comparten una sala comienza a crecer. Esta vez, el destino decidió al azar quién tendría que ponerse frente al público para explicar qué es S3, más allá de aquel famoso clóset de casa con el que solemos comparar el almacenamiento.

La elegida fue Liliana, quien pasó de ser una asistente más a convertirse, por unos minutos, en protagonista de la velada. Y mientras intentaba explicar el concepto, entre risas y miradas cómplices, más de uno recordó aquellos días de primaria en los que el profesor te llamaba al frente para exponer un tema del que apenas habías escuchado hablar. Fue uno de esos momentos espontáneos que no aparecen en ninguna presentación, pero que terminan convirtiéndose en parte de la historia de una comunidad.

La segunda charla nos llevó por un camino distinto. Vania Lockheart tomó el escenario para compartirnos cómo nació su proceso creativo al escribir un libro, aunque no precisamente de la manera en que uno suele imaginarlo. En lugar de comenzar con una página en blanco y una pluma entre los dedos, su método parte de la grabación de video, la extracción del audio y la transformación de esas palabras en historias con ayuda de la inteligencia artificial. A partir de ahí, AWS se convierte en una pieza más de un proceso que combina tecnología, imaginación y trabajo editorial.

Porque escribir, incluso cuando la tecnología nos acompaña, sigue siendo un oficio de paciencia. Revisar, corregir, volver a redactar y encontrar la forma precisa de contar aquello que uno lleva dentro son pasos que ninguna herramienta puede dar por nosotros. Vania también nos habló de los desafíos que enfrenta un autor independiente al publicar su primer libro y nos acercó al proceso de distribución a través de Kindle Direct Publishing (KDP), de Amazon. Una mirada honesta a ese camino que comienza con una idea y que, después de muchas revisiones, puede terminar entre las manos de un lector.

Y así, entre dos charlas, preguntas que encontraron respuesta, otras que seguramente nos acompañarán hasta el próximo encuentro y conversaciones que continuaron más allá del escenario, transcurrió nuestro tercer meetup. Hubo nuevos rostros, historias compartidas y esa alegría discreta que aparece cuando uno descubre que, al otro lado de una pantalla o de una conversación, hay personas dispuestas a aprender y construir en compañía.

Como manda la tradición, cerramos la noche con la fotografía grupal. Una imagen que guarda algo más que los rostros de quienes estuvimos ahí: conserva un pedacito de todo lo que compartimos y nos recuerda que las comunidades se construyen precisamente así, encuentro a encuentro.

Si aquella noche dejó ganas de seguir la conversación, la comunidad continúa en línea. Puedes conocer sus próximos eventos, iniciativas y formas de participar en la página web de AWS User Group Ciudad de México , revivir las charlas y transmisiones en YouTube , seguir el día a día de la comunidad en Instagram o conectar con ella a través de LinkedIn . Y para quienes ya tienen ganas de volver a encontrarse, la próxima cita está marcada en el calendario: 30 de octubre .

Así que, mientras llega ese día, queda el recuerdo de una noche en la que la tecnología se mezcló con la creatividad, las risas y las ganas de aprender. Porque algunas historias no terminan cuando se apagan las luces del escenario; simplemente esperan la siguiente taza de café para continuar.

La noche en que la comunidad tomó Falling Piano

Iván Castañeda — Wed, 09 Sep 2026 16:37:51 +0000

Hay eventos que comienzan cuando alguien toma el micrófono y otros que empiezan un poco antes, cuando todavía nadie sabe muy bien qué va a ocurrir. El segundo meetup de AWS User Group Ciudad de México tuvo algo de eso. Esta vez la comunidad cambió de escenario y encontró en Falling Piano un lugar más social, abierto a todo el público, justo un día antes del AWS Summit México 2026. Edwin fue el encargado de abrir la noche y, antes de entrar de lleno en las charlas, puso sobre la mesa lo que vendría al día siguiente: los speakers que participarían en el Summit, las ventajas de asistir y hasta algunos detalles del diseño de la página web de la comunidad, donde los cuestionarios interactivos escondían sorpresas para quienes estuvieran atentos.

Después de la introducción llegó Luis Guerra, y con él una primera sorpresa que, por razones que conviene dejar para el stream, es mejor descubrir por cuenta propia. Su charla giró alrededor de Runners Everywhere, un workflow construido con distintos servicios de AWS y nacido de una pregunta bastante conocida para quienes han tenido que hacer crecer una arquitectura: ¿cómo escalar GitHub Actions sin que el proceso termine convirtiéndose en otro problema? Luis recorrió distintas estrategias para trabajar con self-hosted runners en AWS y puso sobre la mesa alternativas como EC2, ECS, EKS y CodeBuild, explicando sus características, sus dificultades y los escenarios en los que cada una puede tener más sentido. No se trataba simplemente de elegir un servicio, sino de entender qué arquitectura pide cada situación.

Al terminar la primera charla llegó uno de esos momentos que ya empiezan a formar parte de la personalidad de la comunidad. Edwin explicó que, a partir de las slides del speaker, un flujo de inteligencia artificial construido completamente en AWS comenzaba a generar un quiz en tiempo real para la audiencia. Las preguntas aparecieron y, con ellas, la posibilidad de llevarse uno de los tres premios destinados a quienes obtuvieran las mejores posiciones. La tecnología, por una vez, no estaba solamente sobre el escenario: también estaba jugando con quienes estaban frente a él.

Con la primera ronda de premios terminada, Arturo Ochoa tomó el relevo para hablar de Amazon Bedrock AgentCore: La plataforma para construir, conectar y optimizar agentes. La charla llevó la conversación hacia otro de los territorios que más rápido están cambiando dentro de AWS: los agentes de inteligencia artificial. Arturo mostró cómo Bedrock y AgentCore pueden facilitar la construcción de agentes capaces de automatizar tareas complejas, pero la explicación no se quedó en las diapositivas. Una demo en tiempo real permitió ver un tablero donde múltiples agentes colaboraban en un flujo de análisis de imágenes. De pronto, conceptos que sobre el papel pueden parecer abstractos tenían un lugar concreto donde ocurrir.

Después de la segunda charla llegó otra dinámica de regalos, aunque la noche todavía guardaba una aparición más. Como si el programa tuviera algún truco preparado, apareció Ale Bricio para hablar de todo aquello que ocurre alrededor de las comunidades de AWS: iniciativas, eventos, grupos de usuarios, comunidades estudiantiles y otras formas de participar en un ecosistema que no termina cuando se apagan las luces de una charla. También invitó a participar a Veronica Rivera, integrante de AWS Tech Girls, quien compartió el proceso con el que está ayudando a la comunidad a prepararse para obtener la certificación AWS Certified AI Practitioner.

Y quizá ahí está el verdadero motivo por el que esta noche merece ser contada. El segundo meetup de AWS User Group Ciudad de México no fue solamente una sucesión de speakers, demos y premios. Fue una muestra pequeña de algo mucho más grande: una comunidad que sigue encontrando maneras de reunirse, aprender, hacer amistades y poner nuevos proyectos en movimiento. Detrás de las charlas también están las cosas que todavía no se ven, los proyectos que se están preparando y el trabajo que ocurre entre un meetup y otro para acercar AWS a quienes quieren formar parte de esta comunidad. La siguiente cita ya tiene fecha: 23 de septiembre, cuando la historia vuelva a comenzar en el próximo meetup.

Si aquella noche dejó ganas de seguir la conversación, la comunidad continúa en línea. Puedes conocer sus próximos eventos, iniciativas y formas de participar en la página web de AWS User Group Ciudad de México, revivir las charlas y transmisiones en YouTube, seguir el día a día de la comunidad en Instagram o conectar con ella a través de LinkedIn. La próxima cita ya tiene fecha: 23 de septiembre. La historia, como suele ocurrir con las buenas comunidades, apenas está comenzando.

El día en que AWS encontró una nueva casa en la Ciudad de México

Iván Castañeda — Wed, 02 Sep 2026 00:45:05 +0000

Hay comunidades que nacen con grandes anuncios y otras que simplemente abren una puerta, preparan algunas sillas y esperan a ver quién llega. El 23 de julio ocurrió esto último. En la Casa Rafael Galván de la UAM, un lugar quizá familiar para quienes suelen recorrer la ruta de los eventos tecnológicos de la Ciudad de México, se celebró el primer meetup de AWS User Group CDMX. Podría parecer simplemente otro evento en el calendario, pero aquella noche tenía algo distinto. Era el comienzo de una comunidad que buscaba encontrar su propia voz. Edwin Moedano, líder del grupo, fue el encargado de dar la bienvenida y compartir una idea sencilla este User Group no sería de una sola persona, sería de todos. Un espacio para quienes viven, trabajan o simplemente sienten curiosidad por AWS, donde las voces de la comunidad pudieran escucharse y donde hubiera speakers, temas variados y conversaciones que realmente valiera la pena tener.

Sin más anuncios, Edwin cedió el escenario a Carlos Cano, Solution Architect en AWS México, quien llegó con una pregunta que cada vez resulta más difícil ignorar, La IA ya hace mi chamba… ¿y ahora qué?. La inteligencia artificial ya genera código, propone arquitecturas y es capaz de construir aplicaciones completas. Entonces la pregunta inevitable es qué significa ser desarrollador en un mundo donde una máquina puede hacer buena parte del trabajo que antes parecía exclusivamente nuestro. Carlos llevó la conversación hacia algo más interesante. Quizá el futuro del desarrollador no está en escribir más código, sino en aprender a resolver problemas, integrar sistemas, validar resultados y construir productos que tengan sentido. Porque nunca había sido tan accesible tomar una idea y convertirla, al menos, en el primer intento de una startup.

Terminada la charla, Edwin volvió al micrófono para presentar al segundo speaker de la noche, César Méndez, Senior Data Science & AI Specialist en Novartis México. Llegó con un tema que sonaba tan prometedor como práctico, De tu primer prompt a producción con Claude y AWS MCP Server. Pronto la teoría dejó espacio para la práctica. César mostró cómo utilizar los MCP Servers de AWS Labs junto con Claude Code y Claude Desktop para consultar documentación, generar infraestructura y desplegar aplicaciones en AWS utilizando lenguaje natural. La idea era sencilla, pero poderosa, llevar algo tan cotidiano como un prompt hasta una solución lista para producción.

Y entonces llegó uno de esos momentos que muchos conferencistas prefieren evitar una demo en vivo. Todo parece sencillo hasta que tienes una sala llena de personas mirando mientras presionas Enter. Hubo algunos detalles técnicos, como suele ocurrir cuando la tecnología decide recordarnos que también tiene personalidad, pero César logró llegar al otro lado. La demostración cumplió su cometido y dejó una pequeña lección que cualquiera que haya hecho una demo en público conoce bien a veces la mejor manera de demostrar que algo funciona es atreverse a hacerlo frente a todos.

Después, Edwin retomó el micrófono, felicitó a los dos speakers y agradeció a quienes habían decidido pasar aquella noche ahí. También anunció lo que sigue, el segundo meetup de AWS User Group CDMX, programado para septiembre. Pero para entonces la parte más interesante de la noche apenas comenzaba. Cuando las diapositivas desaparecieron y los micrófonos quedaron en silencio llegó ese momento que ninguna agenda consigue medir demasiado bien el networking.
Las conversaciones comenzaron a mezclarse. Alguien conoció a alguien, una pregunta sobre AWS terminó hablando de trabajo y una charla técnica acabó en una nueva amistad. Entre comentarios y presentaciones improvisadas, aquella reunión dejó de ser solamente un evento. Poco a poco comenzaba a parecerse a una comunidad.
La noche terminó con una fotografía de todos los presentes. Una de esas imágenes que parecen normales cuando se toman, pero que con el tiempo pueden adquirir otro significado. Quizá dentro de algunos años alguien vuelva a verla y recuerde aquella primera reunión, aquel escenario y aquellas conversaciones. Entonces podrá señalar una esquina de la fotografía y decir, con una sonrisa Yo estuve ahí. Ese fue el primero.