Desplegando.cloud

Marcia Villalba
  • 0,0 (0)
  • Tecnologia
  • Semanal

Podcast y newsletter semanal de noticias sobre AWS y serverless en Español Hosted by Marcia Villalba desplegando.substack.com

  1. há 2 dias

    SQS, SNS, EventBridge o Kinesis: ¿cuál usás?

    Los cuatro mueven mensajes. Los cuatro son serverless. Los cuatro aparecen en casi todos los diagramas de arquitectura que vas a ver de AWS. Y la pregunta que más me hacen es siempre la misma: ¿cuál elijo para mi proyecto? La respuesta corta es “depende”. La respuesta larga es este post — con un árbol de decisión al final que resuelve la duda en menos de 30 segundos. 💡 No compiten entre sí, resuelven problemas distintos Antes de entrar en cada uno, sacate una idea de la cabeza: SNS no es la versión vieja de EventBridge, y Kinesis no es “SQS pero más caro”. Cada uno existe para un problema diferente. Cuatro analogías simples y te queda clarísimo: * SQS es una fila del banco — dejás un mensaje y el cajero (un solo consumidor) lo atiende cuando puede. * SNS es un grupo de WhatsApp — mandás un mensaje y todos los que están en el grupo lo reciben al mismo tiempo. Si alguien no está mirando el teléfono, se lo pierde. * EventBridge es un operador telefónico inteligente — recibe la llamada y la conecta con el departamento correcto según lo que decís, no solo según a quién iba dirigida. * Kinesis es una cinta transportadora — los datos fluyen sin parar, en orden, y varias estaciones de trabajo pueden leer de la misma cinta al mismo tiempo, incluso volver atrás si hace falta. Con eso en la cabeza, vamos servicio por servicio: SQS Tu opción cuando necesitás desacoplar dos servicios y absorber picos de tráfico sin perder nada: los mensajes quedan guardados hasta 14 días. Tiene dos sabores: Standard (rapidísimo, orden no garantizado) y FIFO (orden sagrado, con límite de velocidad). No lo uses si el mismo mensaje tiene que llegar a varios consumidores a la vez. SNS El rey del fan-out: publicás una vez y disparás varias acciones en simultáneo (un email, una alerta, un log). El dato que a casi todos les agarra de sorpresa: SNS no tiene memoria. Si el suscriptor no está disponible en ese momento, el mensaje se pierde. Por eso el combo más clásico en arquitecturas serverless es SNS + SQS: fan-out inmediato con la resiliencia de la cola detrás. EventBridge Como SNS pero con cerebro: puede leer el contenido del evento y rutearlo con reglas (”si el pedido es de más de $500, mandalo a auditoría”). Es también el que trae conectores nativos para Stripe, Shopify, Auth0 y otros SaaS, si estás arrancando una arquitectura event-driven desde cero, probablemente sea tu punto de partida. Kinesis Honestamente, la mayoría de los proyectos no lo necesitan. Es para flujo masivo y continuo de datos: logs de miles de servidores, clicks de millones de usuarios, sensores IoT. La diferencia clave con SQS es que los datos no desaparecen al leerlos, podés hacer replay si algo sale mal. Si estás dudando si lo necesitás, probablemente todavía no. 🧭 El árbol de decisión de 30 segundos ¿Necesitás que varios servicios reciban el mismo evento? * Sin lógica de ruteo → SNS * Con lógica de ruteo según el contenido → EventBridge ¿Necesitás absorber picos y que el consumidor procese a su ritmo? → SQS ¿Tenés un flujo continuo y masivo de datos que necesitás poder re-leer? → Kinesis ¿Tu caso es simple y no necesitás nada sofisticado? → Empezá con SNS + SQS y evolucioná si hace falta. No hay un servicio “mejor”. Hay uno mejor para tu caso y la complejidad que no necesitás hoy es complejidad que vas a tener que mantener mañana. 🚀 ¿Y cómo se orquestan estos servicios en un flujo real? Estos cuatro suelen aparecer combinados dentro de un proceso más grande, coordinados por Step Functions. Tengo un mini-curso gratuito donde construimos esa orquestación paso a paso — el mismo patrón que uso para automatizar procesos completos sin escribir la lógica de negocio en el código. 🎯 ACCEDER AL MINI-CURSO GRATUITO 💬 Tu turno ¿Cuál de estos cuatro usás más seguido, y cuál te genera más dudas todavía? Contame en los comentarios 👇 This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com

  2. 28 de ago.

    Tus proyectos no te consiguen trabajo

    Estoy segura que escuchaste mil veces este consejo: “hacé proyectos para demostrar tu experiencia”. Y como buen alumno, hiciste varios. Ahí seguís, esperando que te llamen para ese trabajo. Es un buen consejo. Pero es un consejo a medias — porque nadie te dice lo que realmente significa construir estos proyectos. Después de 20 años en tech, y de haber contratado a decenas de personas en empresas como AWS, te puedo decir exactamente qué miramos en un portfolio. Y no es código. Son señales de vida. 💡 Proyecto muerto vs. proyecto vivo Un proyecto muerto es el que solo existe como código: un repo que nadie clona, y lo reconocés por estas señales. * No está desplegado en ningún lado — para verlo funcionar habría que clonarlo, instalar dependencias, configurar credenciales de AWS y cruzar los dedos. * Nadie lo usó nunca. Ni siquiera vos, después de programarlo. * El README es una lista de instalación (npm install, npm run dev) y no cuenta qué problema resuelve ni para quién. * No hay una decisión de arquitectura explicada — usaste DynamoDB, Step Functions, Lambda, pero en ningún lado dice por qué esos y no otros. Un proyecto vivo es completamente distinto: * Se puede probar sin fricción: un link, una URL, un bot al que le podés escribir ahora mismo. * Alguien lo usa o lo usó de verdad — una ONG, el negocio de un conocido, una comunidad de algún hobby. No sos vos simulando ser el usuario. * Tiene un diagrama de arquitectura que explica las decisiones, no solo un dibujo bonito: por qué DynamoDB y no Postgres, por qué Step Functions y no una sola Lambda. * El README cuenta una historia — el problema de negocio, quién lo usa, qué resultado concreto generó (”le ahorré 10 horas por semana”, “procesa 200 pedidos por día sin intervención manual”). * Tiene señales de haber pasado por producción real: observabilidad, pipeline de despliegue, algo que se rompió y cómo lo arreglaste. La diferencia no es cuánto código escribiste. Es cuánta evidencia dejaste de que ese código sostiene algo real. ¿De dónde saco un problema real si nadie me está pagando por resolver nada? No hace falta que te contraten para esto. Hace falta encontrar a alguien que ya tiene el problema y ofrecerte a resolvérselo con lo que sabés: una causa que te importe, la fricción de tu propio trabajo, el negocio de un conocido, o crear tu propio producto. 🚀 Las inscripciones a Desplegando.cloud están abiertas Si ninguno de esos caminos te cierra — si no sabés qué proyecto construir, o sabés qué construir pero te falta guía para hacerlo bien — te puedo ayudar. Es la razón número uno por la que la gente se une a la comunidad: el plan de estudio te da un proyecto real y guiado, semana a semana (Agentes de IA, WebApps o Step Functions). En la comunidad vas a encontrar pares y acompañamiento para construir tus proyectos! Abrimos cupos limitados y las inscripciones cierran el 31 de agosto. 👉 VER LOS DETALLES E INSCRIBIRME 🗣️ Lo que dicen los que ya lo están haciendo “Cada semana tenía algo concreto que aprender y aplicar. No te quedás solo en la teoría, vas construyendo poco a poco hasta terminar con algo propio que podés mostrar con orgullo.” — Oscar Darío Florez Diaz, Software Developer 💬 Tu turno Volvé a tu GitHub ahora mismo: ¿cuántos proyectos tenés, y de esos, cuántos alguna vez usó alguien que no fueras vos? Contame en los comentarios 👇 This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com

  3. 24 de ago.

    Grok 4.6 ya está disponible en Amazon Bedrock 🚀

    ¡Bienvenidos a Desplegando.cloud! 🚀 Desplegando.cloud es tu fuente semanal en español para mantenerte al día con lo más relevante de AWS y Serverless. Esta semana fue otra semana de construcción: me enfoqué en terminar el plan de estudio de agentes que abre pronto. Para ayudar a los que están por arrancar, lancé un video con 5 ideas de proyectos de agentes — si estás estudiando esto, seguro te sirvan también. Te cuento más en la sección del video de la semana. Y si querés que te avise apenas abran las inscripciones a la comunidad, anotate en la lista de espera. ¡A desplegar! 🚀 📰 Noticias Relevantes 🔐 Amazon DynamoDB Streams ahora admite control de acceso basado en atributos Amazon ha anunciado que DynamoDB Streams ahora admite control de acceso basado en atributos (ABAC), permitiendo que los equipos utilicen condiciones basadas en etiquetas en las políticas IAM para un control de acceso más flexible a los streams, con menos políticas necesarias. Esta función es especialmente beneficiosa para las organizaciones que gestionan múltiples aplicaciones o entornos. La característica permite hasta 50 etiquetas por stream, las cuales pueden utilizarse en condiciones de políticas IAM para permitir o denegar acciones específicas. AWS ilustra ejemplos como otorgar acceso solo a streams etiquetados como producción, bloqueando los que no lo están, lo que ayuda en la segmentación de entornos y en el cumplimiento normativo. 🔗 Para más información, visita la página de novedades de AWS 📝 AWS CloudShell presenta un editor de archivos visual integrado AWS ha anunciado que CloudShell ahora incluye un editor de archivos visual que se lanza directamente desde una sesión de terminal con un solo comando edit, sin necesidad de configuración. Esta mejora elimina la dependencia de editores basados en terminal para realizar cambios rápidos en archivos dentro del entorno basado en navegador de CloudShell. 🔗 Para más información, visita el blog de AWS sobre el editor visual de CloudShell 🌐 Amazon Bedrock amplía su búsqueda en la web con acceso externo AWS ha anunciado una nueva característica para Amazon Bedrock Web Search que permite la recuperación de contenido directamente desde la web pública. Con la incorporación del parámetro external_web_access, ahora es posible fundamentar las respuestas del modelo en la información más actualizada, siendo especialmente útil para casos como resultados deportivos en vivo, precios y documentación recién publicada. Este nuevo recurso permite que los equipos mantengan un control de los datos. Si es necesario limitar la búsqueda a los límites de AWS, se puede configurar external_web_access: false, restringiendo los resultados al índice web interno de AWS y al grafo del conocimiento, asegurando que la información no salga de sus fronteras. Para utilizar el acceso web externo, se debe otorgar el permiso IAM correspondiente y dejar el parámetro en su configuración predeterminada true. 🔗 Para más información, visita el anuncio oficial de AWS. 🚀 Amazon Bedrock ahora soporta SpaceXAI Grok 4.6 con inferencia interregional Amazon Bedrock ha lanzado el soporte para SpaceXAI Grok 4.6, un modelo de vanguardia diseñado para tareas de codificación, trabajo basado en agentes y conocimiento. Esta actualización permite a los clientes acceder al modelo a gran escala mediante la inferencia interregional, optimizando el enrutamiento de solicitudes a través de múltiples regiones de AWS para mejorar el rendimiento y reducir costos. 🔗 Para más información, visita el artículo oficial de Amazon: 🔐 Actualizaciones en la experiencia de inicio de sesión de AWS AWS ha comenzado a implementar actualizaciones en la experiencia de inicio de sesión y registro, con el objetivo de hacer el acceso a las cuentas de AWS más consistente y fácil de usar. Estas mejoras incluyen nuevas opciones para crear y acceder a cuentas, además de una página de inicio de sesión rediseñada y una selección de sesiones actualizada para soportar el nuevo flujo. El principal objetivo de este rediseño es simplificar cómo diferentes tipos de usuarios inician sesión, asegurando una experiencia consistente en todos los dispositivos y tipos de cuentas. Este flujo actualizado busca mejorar tanto la creación de cuentas como la autenticación, y AWS lo está introduciendo gradualmente a los clientes. 🔗 Para más información, visita el blog de AWS sobre la experiencia de inicio de sesión. 🔗 Otras noticias que te pueden interesar 💳 AgentCore payments ya está disponible en Amazon Bedrock → Leer más 🔑 AWS IAM ahora soporta 20 políticas gestionadas por rol por defecto → Leer más 📊 Amazon CloudWatch Pipelines añade procesadores GeoIP, RDS y XML → Leer más 🔍 Amazon Aurora DSQL ahora soporta Amazon CloudWatch Database Insights → Leer más 🌐 Amazon CloudFront ahora soporta Control de Acceso de Orígenes (OAC) para Puntos de Acceso Multi-Región de Amazon S3 → Leer más 🔑 Amazon Timestream para InfluxDB ahora soporta claves gestionadas por el cliente → Leer más 📧 Amazon SES ahora soporta parámetros de anulación para el seguimiento de aperturas y clics → Leer más 🗺️ Amazon Location Service ahora soporta filtrado por categoría y densidad de POI en estilos de mapas → Leer más ☁️ Amazon MWAA Serverless ahora soporta PythonOperator y BashOperator → Leer más 🎬 Video de la Semana En el video de esta semana te dejo 5 ideas de proyectos de agentes en AWS, de principiante a avanzado. No importa cuál elijas — todos siguen el mismo estándar: propósito real, arquitectura pensada y desplegada con infraestructura como código, nada de tutorial copiado paso a paso. 📚 Artículos Interesantes Les dejo varios artículos donde se usan DynamoDB Vectors Search que salió hace poco. 🔍 Amazon DynamoDB Vector Search sin Vector Store Separado Amazon DynamoDB ha dado un gran paso al permitir la búsqueda vectorial nativa directamente sobre sus datos operativos. Esto significa que ya no es necesario mantener un vector store separado, lo que simplifica la arquitectura de búsqueda semántica. Puntos clave: * Embeddings almacenados junto a los datos: Ahora puedes almacenar embeddings junto con los datos de negocio en la misma tabla de DynamoDB. * No más bases vectoriales externas: Eliminación de la necesidad de una base vectorial externa o una pipeline de sincronización. * Reducción de la complejidad operativa: Ajuste perfecto para arquitecturas serverless, facilitando la escalabilidad. 🎯 Reflexión: Con la búsqueda vectorial nativa, DynamoDB se convierte en una herramienta más poderosa para los desarrolladores, permitiendo crear experiencias de búsqueda más rápidas y eficientes, mientras se minimiza la complejidad operativa. 📖 Leer el artículo completo 🤖 Arquitectura Unificada para Agentes de IA con DynamoDB y Bedrock En este artículo, se explora cómo construir una arquitectura de agentes de IA en AWS que utiliza una única tabla de DynamoDB para datos operativos y búsqueda semántica, eliminando la necesidad de depender de una base de datos vectorial separada. Se integran agentes de Amazon Bedrock con la búsqueda vectorial nativa de DynamoDB para que el agente maneje consultas estructuradas y recuperaciones basadas en similitud en un solo lugar. Puntos clave: * DynamoDB como base de datos operativa y tienda vectorial: DynamoDB puede actuar como la base de datos operativa y el almacén vectorial para agentes de IA. * Actualizaciones automáticas de incrustaciones con DynamoDB Streams: DynamoDB Streams puede automatizar actualizaciones de incrustaciones, manteniendo frescos los resultados de búsqueda semántica. * Uso de grupos de acción Lambda con agentes de Bedrock: Los agentes de Bedrock pueden utilizar grupos de acción Lambda para realizar operaciones de búsqueda y datos sin necesidad de una base de datos vectorial separada. 🎯 Reflexión: La combinación de DynamoDB y Bedrock permite crear sistemas de IA más simples y mantenibles, optimizando la eficiencia operativa y reduciendo la complejidad arquitectónica. 📖 Leer el artículo completo 🧭 Mejorando la Búsqueda Semántica en DynamoDB El artículo explica cómo añadir búsqueda semántica a una tabla de DynamoDB existente sin necesidad de trasladar los datos a una base de datos vectorial separada. La idea central es almacenar incrustaciones (embeddings) directamente en los elementos existentes, crear un índice vectorial nativo sobre ese atributo de incrustación y luego consultar la tabla mediante búsqueda de similitud. Esto simplifica la arquitectura al mantener juntos los datos de búsqueda y operativos en DynamoDB. Puntos clave: * Soporte para índices vectoriales nativos: DynamoDB permite la búsqueda semántica directamente sobre los datos existentes en la tabla. * Actualización sin migración completa: Se puede utilizar un flujo de UpdateTable para mejorar tablas existentes sin necesidad de recrearlas. * Proceso de retroalimentación: Se necesita un proceso único de retroalimentación para generar y almacenar incrustaciones de los registros existentes. 🎯 Reflexión: Este enfoque simplificado para añadir búsqueda semántica a tables de DynamoDB no solo mejora la eficiencia, sino que también permite a las organizaciones aprovechar los datos existentes con mayor facilidad y ofrece una arquitectura más cohesiva. 📖 Leer el artículo completo 🖥️ Tres Maneras de Gestionar Archivos en CloudShell Este artículo se centra en tres formas prácticas de gestionar archivos desde CloudShell. Puntos clave: * CloudShell soporta editores de terminal comunes como vim y nano para la edición directa de archivos. * El comando edit abre archivos en el editor integrado de CloudShell para una experiencia más visual. * La carga y descarga de archivos a

  4. 21 de ago.

    6 errores de AWS que te pueden costar una fortuna

    Pedro estaba aprendiendo AWS. Quiso probar un servicio para procesar un video de cinco segundos. Le costó ochenta y cinco dólares. Ochenta y cinco dólares por procesar un video de cinco segundos. Eligió el servicio equivocado, no puso límites, y cuando se dio cuenta ya era tarde. Ese miedo — “¿cuánto me va a costar esto?” cada vez que querés probar algo en AWS — es lo que más me frenan de la gente que empieza. Y la buena noticia es que AWS no tiene por qué ser caro: yo tengo múltiples apps en producción y pago menos de cinco euros por mes. Pero para llegar ahí tuve que aprender a evitar seis errores. 💡 Los 6 errores que te hacen pagar de más 1. No tener alarmas de billing AWS te deja poner alarmas de costo gratuitas (Budget Alerts). Una al 50% de tu presupuesto, otra al 80%, otra al 100%. La mayoría no las configura hasta que llega la primera factura que duele — no seas esa persona. Son dos alertas de presupuesto gratis, no hay excusa. 2. No usar serverless para tráfico bajo o impredecible Un EC2 corriendo 24/7 te cobra las 24 horas, incluso a las 3 de la mañana cuando nadie lo usa. Con serverless pagás por ejecución: si nadie usa tu servicio, pagás cero. Lambda te da un millón de requests gratis por mes — para siempre, no por 12 meses. Para proyectos personales o de tráfico variable, serverless gana casi siempre. 3. No aprovechar el Free Tier permanente Además de los créditos iniciales de cuenta nueva, muchos servicios tienen capa gratuita para siempre: Lambda (1M requests/mes), DynamoDB (25GB), SNS, SQS, Step Functions y más. Con eso podés construir una aplicación completa sin gastar un centavo. Mi factura de 4. Elegir servicios por comodidad, no por costo Usar RDS cuando DynamoDB alcanza: la instancia más chica de RDS te cuesta ~$15/mes corriendo 24/7, contra un DynamoDB que puede costarte cero con poco tráfico. O meter tus funciones de Lambda en una VPC “por las dudas” y terminar pagando un NAT Gateway que cuesta ~$32/mes solo por existir, más el costo por dato procesado. La calculadora de AWS es tu amiga — usala antes de desplegar, no después. 5. No entender el modelo de pricing de cada servicio Lambda cobra por invocaciones y duración. S3 por almacenamiento y requests. DynamoDB por lecturas y escrituras. API Gateway por llamada. CloudFront por transferencia de datos. Son modelos completamente distintos, y si no los entendés terminás como Pedro. Regla simple: si no sabés cuánto te va a costar, no lo despliegues. 6. Olvidarte del almacenamiento El error silencioso. CloudWatch Logs cobra por giga ingerido, y por defecto guarda los logs para siempre. Vi cuentas donde CloudWatch terminó siendo el servicio más caro — más que Lambda, más que DynamoDB — solo porque nadie le puso retención a los logs. Mismo problema con buckets de S3 que creás para probar algo y te olvidás. El storage es como la humedad: no lo ves, pero se acumula. 🚀 ¿Querés construir en AWS sin gastar de más? Tengo un mini-curso gratuito donde diseñamos una WebApp serverless completa — el tipo de arquitectura que, bien elegida, te cuesta centavos por mes. 🎯 ACCEDER AL MINI-CURSO GRATUITO This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com

  5. 17 de ago.

    AWS Agent Plugins: empaquetá tu agente una vez, usalo en todos lados

    ¡Bienvenidos a Desplegando.cloud! 🚀 Desplegando.cloud es tu fuente semanal en español para mantenerte al día con lo más relevante de AWS y Serverless. Esta semana me la pasé armando el próximo plan de estudio que va a tener la comunidad, viendo cómo estructurar las tareas para que puedan construir su primer agente de IA sin agobiarse. Hay tantas preguntas que responder en este mundo nuevo, más allá de la tecnología: ¿es realmente necesario un agente acá? ¿Cómo defino las instrucciones de este agente? ¿Cómo manejo el contexto? ¿Qué herramientas le agrego? Estas primeras semanas del plan de estudio van a estar cargadas de preguntas de diseño — las mismas que son fundamentales para cualquier proyecto de software, no solo para agentes. Si querés enterarte primero, antes de que abran los cupos, anotate en la lista de espera. ¡A desplegar! 🚀 📰 Noticias Relevantes 🔌 AWS apoya los Agent Plugins: un estándar abierto para extensiones portátiles de agentes Esta semana, AWS anunció su apoyo a los Agent Plugins 1.0.0, un estándar abierto y neutral para empaquetar extensiones de agentes de inteligencia artificial en un formato portátil. El objetivo es permitir que los desarrolladores empaqueten habilidades de agentes y configuraciones de servidores MCP una vez y las reutilicen en clientes compatibles, evitando la necesidad de reconstruir extensiones para cada herramienta o plataforma. 🔗 Para más información, visita el blog de AWS 💡 AWS Billing y Cost Management lanza Dashboards Gestionados para Visibilidad Financiera Instantánea AWS ha presentado los Dashboards Gestionados en AWS Billing y Cost Management, una herramienta que proporciona a los equipos visibilidad instantánea sobre el gasto en la nube sin necesidad de configuraciones previas. Estos dashboards están preconfigurados, son de solo lectura y se llenan automáticamente con los datos de tu cuenta, permitiendo a los usuarios observar rápidamente las tendencias de costos, los principales impulsores de servicio y el rendimiento de los compromisos. La funcionalidad incluye cinco dashboards curados que abarcan tres capas de visibilidad: un dashboard general de costos y tendencias, dos dashboards por categoría de servicio para Computación y Base de Datos, y dos dashboards de compromisos para Reservas y Planes de Ahorro. Un pestaña dedicada de Gestionados y los íconos de candado permiten distinguir estos dashboards de los personalizados, aunque los usuarios pueden duplicar un dashboard gestionado para crear su propia versión. 🔗 Para más información, visita el blog de AWS sobre la gestión de costos y facturación. 🌐 Amazon Bedrock lanza búsqueda web para una respuesta fundamentada en modelos Amazon anunció la disponibilidad general de la Búsqueda Web en Amazon Bedrock, una capacidad incorporada en el servidor que ayuda a los modelos fundamentales a fundamentar sus respuestas en conocimientos web actuales. La proposición de valor principal es la simplicidad: los desarrolladores pueden agregar respuestas basadas en la web sin necesidad de integrar proveedores de búsqueda externos o manejar revisiones de seguridad adicionales. Cuando se habilita la Búsqueda Web, Bedrock gestiona todo el ciclo de vida de la búsqueda en el servidor. El modelo determina si una consulta necesita información actualizada, Bedrock formula la búsqueda, recupera el contenido relevante de su índice web y grafo de conocimiento, y devuelve fragmentos de origen, URLs y títulos para que la respuesta final pueda ser citada y fundamentada. 🔗 Para más información, visita el artículo de Amazon Bedrock 🔧 AWS IAM presenta el administrador de roles para configurar roles IAM en servicios de AWS AWS ha anunciado la disponibilidad general del administrador de roles en AWS Identity and Access Management (IAM), una herramienta que configura automáticamente los roles IAM necesarios para los servicios de AWS compatibles. Cuando un usuario configura un servicio compatible en la consola, el administrador de roles puede crear un rol predeterminado automáticamente o reutilizar un rol existente que ya cumpla con los permisos requeridos. Esta función está diseñada para facilitar el inicio con los servicios de AWS al eliminar gran parte del trabajo manual de configuración de roles IAM. Además, AWS afirma que los usuarios pueden activar o desactivar el administrador de roles en cualquier momento y revisar las plantillas gestionadas por AWS que despliega en su nombre. 🔗 Para más información, visita el anuncio oficial de AWS IAM 🔗 Otras noticias que te pueden interesar 🔒 AWS Identity and Access Management mejora la asignación de roles IAM a usuarios de la fuerza laboral con el administrador de acceso a cuentas → Leer más 🐍 Presentamos los entornos de prueba pública en AWS Lambda, comenzando con Node.js 26 y Python 3.15 → Leer más 📦 Amazon SES ahora admite seguimiento de clics con rutas de URL personalizadas para el enlace profundo de aplicaciones móviles → Leer más 🏗️ Amazon Bedrock expande la asignación de costos de IAM principal al endpoint bedrock-mantle → Leer más 🔑 AWS Secrets Manager añade soporte para secretos externos gestionados para Jenkins y SonarQube → Leer más 🔍 Amazon OpenSearch Serverless ahora soporta hasta 10,000 colecciones por grupo de colecciones → Leer más 🌍 El Centro de Identidad de AWS IAM admite la opción de múltiples regiones con un solo clic para nuevas instancias de organización → Leer más 💡 Amazon Cognito ahora disponible como habilidad en el Kit de Herramientas para Agentes de AWS → Leer más ⏰ Amazon CloudWatch Alarms ahora soporta ventanas de evaluación de reloj calendario → Leer más 🎬 Video de la Semana ¿Trabajo full-time, quizás hijos, una casa que mantener — y aun así sentís que tenés que seguir aprendiendo para no quedarte atrás? El problema no es que te falte disciplina. En el video de esta semana te muestro los sistemas concretos que uso (y que le funcionan a la gente de la comunidad) para sostener el estudio semana tras semana, sin madrugar ni sacrificar el fin de semana con tu familia. 📚 Artículos Interesantes 🤖 Orquestación de Arquitecturas de IA Multi-Agente con Amazon S3 Files El artículo detalla cómo Amazon S3 Files puede funcionar como un sistema de archivos compartido para sistemas de IA multi-agente, permitiendo a los agentes acceder a un espacio de trabajo común con acceso a archivos al estilo POSIX. Esto simplifica las operaciones de colaboración entre múltiples agentes en servicios como EC2, Lambda, EKS, ECS en Fargate y Amazon Bedrock AgentCore Runtime. Puntos clave: * Sistema de archivos compartido al estilo POSIX: Permite la colaboración eficiente mediante archivos y directorios. * Uso de archivos como memoria de trabajo: Reduce la inflación de prompts y mejora el manejo de resultados intermedios. * Flujos de trabajo multi-agente simplificados: La orquestación es más sencilla si se configura correctamente el bucket, VPC y los permisos. 🎯 Reflexión: Amazon S3 Files ofrece una solución práctica para la colaboración entre agentes, permitiendo una arquitectura más simple y escalable en el trabajo con IA. 📖 Leer el artículo completo ⏳ Procesando Eventos de Larga Duración en AWS API Gateway AWS API Gateway se destaca en la gestión de solicitudes API, pero enfrenta retos al manejar eventos prolongados debido a sus limitaciones de tiempo de espera y su naturaleza sincrónica. Este artículo explora estrategias para abordar estas operaciones extendidas de manera efectiva, integrando patrones asíncronos que evitan bloquear a los clientes y garantizan una manipulación confiable de eventos. Puntos clave: * Integración Asíncrona es Clave: Utiliza respuestas 202 Aceptadas y servicios como EventBridge o SQS para desacoplar tareas largas de los límites sincrónicos de API Gateway (ej. timeout de 29 segundos). * Polling y Webhooks para Estado: Implementa polling del cliente o webhooks de retorno para rastrear el progreso de los procesos de backend sin bloquear la llamada inicial a la API. * Monitoreo y Manejo de Errores: Aprovecha CloudWatch para la observabilidad y los reintentos incorporados para asegurar un procesamiento confiable de eventos prolongados en arquitecturas sin servidor. 🎯 Reflexión: Aplicar patrones asíncronos y herramientas como EventBridge/SQS transforma la manera en que manejas eventos extensos en API Gateway, permitiendo construir sistemas más escalables y resilientes. 📖 Leer el artículo completo 🤖 La IA Cambia el Trabajo del Ingeniero: Cómo Adaptarse La IA está transformando el rol del ingeniero, pasando de una función centrada en la codificación a una de orquestador de IA. Las habilidades de juicio, entendimiento del producto, especificación clara y revisión son cada vez más valiosas. 🔑 Puntos Clave: * La codificación ya no es el diferenciador clave: Las habilidades de juicio y revisión cobran más relevancia en la ingeniería asistida por IA. * El desarrollo basado en especificaciones se vuelve esencial: Las especificaciones estructuradas guían mejor a los agentes de IA que los mensajes vagos. * Las herramientas de desarrollo deben evolucionar: Es necesario apoyar flujos de trabajo que incluyan revisión de especificaciones, verificación de código y colaboración más sencilla. 🎯 Reflexión: Adaptar las habilidades y herramientas en este nuevo entorno de desarrollo es crucial para que los ingenieros tomen decisiones más informadas y se conviertan en líderes en la integración de la IA. 📖 Leer el artículo completo 🤖 7 Consejos para Hacer tu Agente de IA Más Predecible Este artículo ofrece una guía práctica para hacer que los agentes de inteligencia artificial se comporten de manera más consistente y confiable en flujos de trabajo del mundo real. Se enfa

  6. 14 de ago.

    Un viernes a las 6 de la tarde, pensó que lo habían hackeado en AWS

    Viernes, 6 de la tarde. Me llega un mensaje de un miembro de la comunidad: “Marcia, creo que me hackearon, AWS me quiere cobrar miles de dólares y no sé qué hacer”. Dejé todo y volví corriendo a mi casa. Cuando entré a la llamada con él, ya estaba borrando usuarios, reseteando contraseñas, tirándose de los pelos. En pánico total. Y lo que hizo en esos primeros veinte minutos es exactamente lo que NO tenés que hacer. 💡 El protocolo que seguimos esa tarde Lo primero que le dije fue: pará. No sigas borrando nada. Si de verdad hubiera sido un hackeo, borrar usuarios a lo loco es justo lo que te puede dejar afuera de tu propia cuenta o destruir la evidencia que necesitás para entender qué pasó. Es como encontrar la llave de tu casa movida de lugar y, por las dudas, prender fuego la casa entera. La regla: primero mirás, después actuás. Y antes de tocar nada, sacás capturas de pantalla de todo — usuarios, policies, CloudTrail, el cargo en el Billing. Una vez que borrás o rotás algo, esa foto del momento exacto se pierde para siempre. Los tres lugares que hay que revisar, en orden 1. AWS Health Dashboard — ahí AWS reporta incidentes conocidos de sus propios servicios. En este caso, ahí apareció el dato que explicó todo. 2. Billing y Cost Explorer — ¿el cargo es un “estimated charge” o ya está facturado de verdad? No es lo mismo. 3. CloudTrail — el historial de cada acción en tu cuenta: quién, desde dónde, cuándo. Buscá usuarios o roles que no reconocés, cambios de policies, accesos desde regiones donde nunca trabajás. En su CloudTrail no había nada raro. Cero. Volvimos al Health Dashboard y ahí estaba: un bug conocido en el servicio que estima los gastos, que ese mismo día afectó a montones de cuentas al mismo tiempo. No era un hackeo. Era un número mal calculado que AWS le mostró como si fuera real. Si en tu caso SÍ es un hackeo real Si CloudTrail te muestra usuarios, roles o accesos que no reconocés, ahí sí hay que moverse rápido, en este orden: * Cambiar contraseña + agregar MFA a todos los usuarios comprometidos que encontraste (no solo el primero) * Desactivar las access keys comprometidas — o borrarlas y recrearlas * Invalidar las sesiones de STS activas * Revisar Cost Explorer buscando cargos inesperados en servicios y regiones que ni mirás normalmente * Contactar a soporte de AWS 🛡️ Cómo evitar vivir esto Todo esto se vive muy distinto si ya tenés resueltas algunas cosas de antes: ✅ AWS Budgets con alertas de costo — la misma alarma que le avisó a tiempo a mi amigo, en vez de enterarse con la factura ya cerrada ✅ MFA en TODOS los usuarios, sin excepciones, empezando por el root ✅ Mínimo privilegio en cada usuario y rol ✅ CloudTrail activo Ninguna te toma más de 15 minutos configurar. Y son la diferencia entre un diagnóstico claro en 5 minutos o borrar usuarios en pánico un viernes a la tarde. 🚀 ¿Querés dejar tu cuenta de AWS bien configurada desde el día uno? Tengo un curso gratuito de AWS Fundamentals donde vemos exactamente esto: cómo asegurar tu cuenta desde cero — MFA, alertas de billing, quién tiene acceso a qué — y los fundamentos que evitan que esto te pase. 🎯 ACCEDER AL CURSO GRATUITO This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com

  7. 10 de ago.

    Kiro Crew: mi nuevo compañero de desarrollo

    ¡Bienvenidos a Desplegando.cloud! 🚀 Desplegando.cloud es tu fuente semanal en español para mantenerte al día con lo más relevante de AWS y Serverless. Esta semana hubieron un montón de lanzamientos interesantes, pero el que más me llamó la atención es Kiro Crew. Ahora lo estoy probando y viendo cómo me puede ayudar a resolver problemas más rápido y de manera más eficiente que el setup que tenía antes. ¡Ya les contaré cómo lo llevo! ✏️ ¡Comparte tus recursos! Si has escrito en un blog o creado algo interesante sobre AWS o Serverless, envíamelo. A veces es imposible encontrarlo todo en internet, y me encantaría destacar tu trabajo. 🎧También puedes escuchar esta newsletter en formato podcast, donde resumo cada edición. Búscalo en las principales plataformas o en cada correo que recibas. 🗓 ¿Organizas un evento en español sobre AWS o Serverless? Escríbeme en redes o en los comentarios, y con gusto lo mencionaré. 📢 Si te gusta esta newsletter, compártela con tus colegas para que más personas puedan estar al día con el mundo serverless. Si tienes comentarios o sugerencias, escríbeme en LinkedIn, X, o Instagram. ¡A desplegar! 🚀 📰 Noticias Relevantes 🚀 Kiro Crew: Tu compañero de desarrollo persistente y open-source Kiro Crew se presenta como un espacio de trabajo de desarrollo persistente y open-source, diseñado para manejar tareas de ingeniería que requieren coordinación y seguimiento constantes. Este proyecto originado internamente en Amazon, busca facilitar el inicio y la continuidad de las tareas sin la necesidad de supervisión constante. Construido para flujos de trabajo de ingeniería del mundo real, Kiro Crew permite la delegación entre herramientas y habilita el procesamiento de tareas en segundo plano. Este sistema se integra con plataformas populares como Slack, Telegram y WeCom, y es compatible con los principales sistemas operativos, lo que lo hace accesible para todos los desarrolladores. 🔗 Para más información, visita el blog de Kiro Crew 💻 Instalar y actualizar la AWS CLI ahora es más fácil con comandos de una sola línea Finalmente actualizaron la instalación AWS CLI v2 para hacerlo con una sola línea, eliminando la necesidad de pasos manuales de descarga e instalación. Para los usuarios de macOS y Linux, se puede ejecutar un comando de curl que descarga y ejecuta el instalador oficial, mientras que los usuarios de Windows pueden utilizar un comando de PowerShell para iniciar el proceso de instalación. Además, se introduce un nuevo flujo de actualización integrado para la AWS CLI v2.36.0 y versiones posteriores. A partir de ahora, los usuarios pueden ejecutar el comando aws update para actualizarse a la última versión, el cual detecta automáticamente la ruta de instalación existente, permitiendo actualizar la configuración actual sin requerir una reinstalación manual. 🔗 Para más información, visita el blog sobre la instalación y actualización de AWS CLI. ⚡ Amazon DynamoDB ahora soporta búsqueda de vectores en tiempo real a escala Amazon DynamoDB ha lanzado la búsqueda de vectores nativa, ahora disponible de forma general. Esta característica permite almacenar vectores junto con datos operativos, facilitando búsquedas de similitud sin necesidad de bases de datos externas. Esta capacidad es crucial porque integra la búsqueda de vectores en una base de datos completamente gestionada y serverless, simplificando la arquitectura al permitir que los desarrolladores gestionen datos operativos y vectores en un solo sistema. 🔗 Para más información, visita el blog de Amazon DynamoDB 🤖 Amazon Bedrock AgentCore presenta instancias de runtime para agentes de IA Las instancias de runtime en Amazon Bedrock AgentCore, están diseñada para los agentes de inteligencia artificial que requieren infraestructura persistente y gestionada, y va más allá de los límites del modelo serverless tradicional. Las instancias de runtime permitirán que múltiples agentes colaboren en un mismo host, manteniendo un estado de sesión compartido y ejecutándose por períodos prolongados de hasta 14 días por sesión. Estas instancias se ejecutan sobre una infraestructura EC2 gestionada por AWS dentro de la cuenta del cliente, lo que ofrece beneficios de selección de hardware y precios de EC2, mientras AWS se ocupa de las operaciones de infraestructura como aprovisionamiento, parcheo, escalado y desmantelamiento. Entre las características destacadas se incluyen el soporte para aceleración GPU, la capacidad de detener/iniciar sesiones para reducir costos de inactividad, y despliegues en contenedores para equipos que deseen operar de manera independiente. Además, estas instancias se complementan con los microVMs de AgentCore, permitiendo a los equipos elegir el mejor modelo de computación según las necesidades de carga de trabajo. 🔗 Para más información, visita el blog de Amazon sobre instancias de runtime. 🚀 AWS presenta Dogwood: verificación en tiempo de ejecución para agentes de IA AWS ha lanzado Dogwood, un lenguaje de gobernanza de código abierto para agentes de IA que se centra en la verificación en tiempo de ejecución en lugar de la evaluación posterior. La idea principal es que las políticas pueden revisar los eventos recientes de un agente, permitiendo que las decisiones se basen en lo que el agente ha realizado anteriormente en la sesión. Dogwood está diseñado para extender y reutilizar políticas existentes de Cedar; cualquier política válida en Cedar también lo es en Dogwood, lo que facilita su adopción sin necesidad de reescribir o migrar conjuntos de políticas actuales. Además, se destaca que Dogwood añade condiciones temporales, permitiendo reglas que razonan sobre la secuencia y la historia reciente, como la imposición de restricciones de seguridad a lo largo de una cadena de acciones. Esta liberación posiciona a Dogwood como una forma práctica de mejorar la gobernanza de los agentes mientras se mantiene el sistema abierto y composable. Dogwood es de código abierto bajo la licencia Apache 2.0. 🔗 Para más información, visita el blog de AWS sobre Dogwood. 🔗 Otras noticias que te pueden interesar 💻 AWS Lambda console extiende la integración de consola a IDE con Kiro y Cursor → Leer más 🛡️ AWS WAF ahora soporta un grupo de reglas gestionadas por Salt Security para detección de amenazas en API y MCP → Leer más 📧 Amazon SES ahora ayuda a identificar eventos automatizados de apertura y clic en notificaciones de eventos → Leer más 🌐 AWS Lambda anuncia escalabilidad de ancho de banda de red de hasta 3,000 Mbps para funciones fuera de una VPC → Leer más ⚡ Amazon Aurora serverless ahora escalará más rápido para soportar AI agente y otras cargas de trabajo intermitentes → Leer más 🧠 OpenAI GPT-5.6 Sol, Terra y Luna ahora soportan ventanas de contexto de 1 millón de tokens en Amazon Bedrock → Leer más 📊 AWS Organizations ahora proporciona visibilidad máxima de cuotas de cuenta en Service Quotas → Leer más 📦 AWS Lambda en Modo Provisionado para mapeos de eventos de Amazon SQS ahora soporta hasta 10,000 pollers de eventos → Leer más 🔐 AWS WAF ahora soporta grupos de reglas gestionadas por Miggo Security para amenazas emergentes y protección de aplicaciones AI/ML → Leer más ☕ AWS Lambda ahora soporta Java 8, 11 y 17 en Amazon Linux 2023 → Leer más 🧩 AWS IAM Identity Center amplía el soporte multi-región al directorio del Identity Center → Leer más 📄 AWS WAF agrega transformaciones de texto pre-parse y nuevas transformaciones de texto → Leer más 📅 Anunciando políticas temporales y limitación de tasa en Amazon Bedrock AgentCore → Leer más ⚙️ Instancias de tiempo de ejecución: cómputo persistente para agentes de IA de producción en Amazon Bedrock AgentCore → Leer más 🎬 Video de la Semana Esta semana te traigo un video sobre algo que probablemente ya usás sin saber su nombre: el agent harness. Si trabajás con Claude Code, Cursor o Kiro, ya lo estás usando. Un modelo de lenguaje solo no hace nada — es el harness el que lo convierte en un agente de verdad: orquesta el loop, ejecuta las herramientas y arma el contexto en cada vuelta. Te explico qué es, cómo se ve en un stack real de AWS con Bedrock y Strands, y las 3 capas de 2026 (prompt, context y harness engineering). Es la pieza que separa un agente que funciona divino de uno impredecible. 📚 Artículos Interesantes 📜 Los 10 Mandamientos para Trabajar en Producción Este artículo presenta un conjunto práctico de hábitos de seguridad en producción para ingenieros que trabajan con AWS y otros sistemas en producción. El mensaje central es que los cambios en producción deben ser tratados como operaciones de alto riesgo. Puntos clave: * Siempre ten un plan de reversión antes de hacer cambios en producción. * Promueve los cambios gradualmente de desarrollo a staging y luego a producción. * Usa disciplina operativa estricta: revisiones de PR, control de versiones, evita atajos manuales en la consola y código generado por IA no verificado. 🎯 Reflexión: Las prácticas disciplinadas en producción no solo mitigan riesgos, sino que también fomentan un entorno de aprendizaje constante para los equipos, permitiéndoles mejorar con cada incidente. 📖 Leer el artículo completo 🤖 Cómo Uso Kiro: Un Compañero, No un Piloto Automático En este artículo, el autor comparte su experiencia utilizando Kiro como un asistente de IA colaborativo en lugar de un agente completamente autónomo. Kiro actúa como un compañero de trabajo, ayudando en la ejecución y organización de tareas, mientras que el humano establece la dirección y toma decisiones finales. Puntos clave: * La colaboración humano-IA es clave: Kiro es más útil cuando el usuario dirige el trabajo en

  8. 7 de ago.

    Todos hablan de agentes de IA. ¿Ya construiste uno?

    Todos te hablan de agentes. Pocos construyeron alguno de verdad. Hoy lo hacemos juntos: un agente funcional de punta a punta, en menos 10 minutos, con Python y Strands sobre AWS. No un chatbot — un agente que toma decisiones, usa herramientas y ejecuta acciones. 💡 De un wrapper de LLM a un agente de verdad Tres líneas de código contra un modelo es un chatbot. Un wrapper. No hace nada por sí solo. Un agente aparece cuando le sumás herramientas que puede ejecutar, un rol claro en el system prompt, y un loop donde el modelo decide qué hacer, lo hace, ve el resultado y sigue hasta resolver la tarea. En el video construimos un chef assistant: le decís qué tenés en la heladera y te dice qué cocinar según la hora y para cuántos comensales. Suena tonto, pero adentro está todo lo que hace a un agente ser agente. Lo que armamos, pieza por pieza 1. Herramientas built-in — current_time para saber la hora, calculator para ajustar cantidades. El modelo decide cuándo usarlas, vos no las llamás a mano. 2. Una herramienta propia (mi_heladera) — una función Python decorada con @tool que agrega, quita y lista ingredientes. El truco está en el docstring: le explicás al modelo cuándo usarla y qué espera recibir. Ese texto es la interfaz entre el modelo y tu código. 3. El system prompt como rol — no es “sos útil”. Es “sos un chef profesional, así trabajás, estas son tus herramientas y cuándo usarlas, y estas son tus reglas”. Cuanto más claro el rol, mejor elige. 4. El loop interactivo — un while que mantiene la conversación viva y le pasa el contexto al agente en cada vuelta. Ahí es donde el agente razona, ejecuta y recuerda lo que ya pasó. El momento en que se nota que es un agente Le tiro ingredientes random a la heladera. El agente guarda eso con mi_heladera, consulta la hora con current_time, ve que es mediodía y sugiere almuerzos concretos. Le digo “sandwich para dos” y calcula las cantidades. Le pregunto qué queda en la heladera después y vuelve a la herramienta a chequear el estado real. Nadie programó ese orden. El modelo decidió qué herramienta usar y cuándo. Eso es un agente: rol definido, herramientas reales, decisiones autónomas y memoria de la conversación. Y esto corre local. Llevarlo a la nube, sumarle un MCP para buscar recetas de verdad, o desplegarlo en AWS — es el siguiente paso. 🚀 ¿Querés construir el tuyo (y llevarlo a la nube)? Tengo un mini-curso gratuito de Agentes IA donde vemos exactamente esto: las piezas de un agente, cómo conectar herramientas reales, cómo usar MCPs y cómo desplegarlo en AWS. Con el código para que lo hagas conmigo. 🎯 ACCEDER AL MINI-CURSO GRATUITO 💬 Tu turno ¿Ya construiste un agente o todavía estás en la etapa de “un prompt largo con un modelo potente”? Contame qué te gustaría que resuelva tu primer agente 👇 This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com

Ver tudo (91)

Sobre

Podcast y newsletter semanal de noticias sobre AWS y serverless en Español Hosted by Marcia Villalba desplegando.substack.com

Informações

  • Criado por
    Marcia Villalba
  • Anos de atividade
    2025 - 2026
  • Episódios
    91
  • Classificação
    Livre
  • Copyright
    © Marcia Villalba
  • Site do podcast
    Desplegando.cloud