Desplegando.cloud

¡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.
La semana pasada estuvo re tranquila de lanzamientos pero ya esta se vino muy interesante. Hay varias cosas a destacar. La primera es algo que no es tan nuevo que son las microcertificaciones, pero ahora son gratis y me parecen genial y además están en español. Las probaste? Yo a ver si tengo dos horas seguidas en la cual me puedo sentar y hacer la de serverless. Ya les contaré.
📢 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
🎓 Microcredenciales de AWS ahora son gratuitas: ¿por qué es importante?
AWS ha anunciado que sus microcredenciales, evaluaciones prácticas que permiten a los desarrolladores demostrar habilidades en la nube, ahora están disponibles de forma gratuita y sin necesidad de una suscripción a AWS Skill Builder. Esto las hace más accesibles para una audiencia global.
Estas evaluaciones prácticas validan la capacidad de resolver tareas del mundo real, como la configuración, optimización y solución de problemas en los servicios de AWS, todo en un entorno realista. Se subraya que las microcredenciales no reemplazan a las certificaciones de AWS; más bien, las complementan al validar habilidades prácticas.
La primera serie de microcredenciales incluye áreas como Serverless, Inteligencia Artificial, Redes de Aplicaciones y Respuesta a Incidentes, con más planeadas para el 2026.
🔗 Para más información, visita el blog de AWS sobre microcredenciales.
📦 Amazon Kinesis Data Streams ahora entrega datos directamente a los buckets de S3
Amazon Kinesis Data Streams ha lanzado una nueva funcionalidad que permite la entrega de datos de streaming directamente a los buckets de Amazon S3 de propósito general. Esta mejora elimina la necesidad de gestionar streams de entrega separadas para enviar los datos a S3, optimizando el proceso considerablemente.
Los datos se almacenan en su formato original, haciéndolos adecuados para archivado, respaldo, reprocesamiento y análisis por lotes. AWS describe esta opción como completamente gestionada y serverless, lo que permite a los usuarios pagar solo por los datos entregados satisfactoriamente.
🔗 Para más información, visita la página oficial de Amazon Kinesis Data Streams
🚀 AWS Lambda ahora admite SnapStart para funciones de imágenes de contenedor
AWS Lambda ha dado un gran paso al anunciar que SnapStart ahora es compatible con funciones empaquetadas como imágenes de contenedor. Esta innovadora función promete reducir los tiempos de inicio de varios segundos a niveles de menos de un segundo, lo que representa una mejora significativa en el rendimiento para las cargas de trabajo serverless que utilizan imágenes de contenedor.
🔗 Para obtener más información, visita la página oficial de AWS Lambda.
🚀 AWS adquiere DuckLabs para revolucionar el futuro de la analítica
AWS ha anunciado un acuerdo definitivo para adquirir DuckLabs, la compañía con sede en Ámsterdam detrás de DuckDB, una base de datos analítica de código abierto. Este movimiento busca fusionar la rapidez de DuckDB en el análisis de datos pequeños con el ecosistema de analítica a gran escala de AWS.
🔗 Para más información, visita el blog de AWS.
🔗 Aurora DSQL ahora soporta restricciones de clave foránea
AWS ha anunciado que Aurora DSQL ahora admite restricciones de clave foránea, un avance significativo en la compatibilidad con PostgreSQL para su base de datos SQL distribuida. Esta actualización permite a los equipos definir relaciones directamente en la base de datos, en lugar de imponer la integridad referencial solo en el código de la aplicación.
La nueva capacidad soporta comportamientos de restricciones comunes como NO ACTION, RESTRICT, CASCADE, SET NULL y SET DEFAULT, además de MATCH FULL, MATCH SIMPLE y restricciones de clave foránea diferibles. AWS también destaca que Aurora DSQL mantiene la integridad referencial a través de la verificación de instantáneas durante la transacción y la resolución de conflictos en el momento de la confirmación, asegurando que las transacciones confirmadas no violen las reglas de clave foránea.
🔗 Para más información, visita el artículo de AWS
🔗 Otras noticias que te pueden interesar
🔒 AWS Lambda ahora soporta políticas basadas en recursos IAM completas → Leer más
🛠️ AWS Lambda introduce runtimes gestionados en vista pública para Node.js 26 y Python 3.15 → Leer más
🔗 AWS Lambda MicroVMs ahora soporta AWS PrivateLink → Leer más
☕ IAM Roles Anywhere ahora proporciona un plugin de Java para el AWS SDK → Leer más
📦 Mountpoint para Amazon S3 añade controles de uso de memoria → Leer más
🔍 Amazon Bedrock Managed Knowledge Base introduce configuración administrada por el usuario para fuentes de datos de SharePoint, OneDrive y Confluence → Leer más
🔗 Amazon Bedrock Managed Knowledge Base ahora soporta ServiceNow como conector nativo de fuente de datos → Leer más
🔄 Amazon Bedrock Managed Knowledge Base ahora soporta programación de sincronización automática para conectores de fuentes de datos → Leer más
🛡️ Amazon Bedrock AgentCore Identity ahora ofrece un portal de consentimiento gestionado → Leer más
🔗 Amazon Bedrock AgentCore Memory ahora soporta variables de espacio de nombres flexibles → Leer más
🔒 Amazon Bedrock AgentCore Memory ahora soporta control de acceso detallado → Leer más
☁️ AWS MCP Server añade una capacidad sin servidor para funciones de AWS Lambda → Leer más
✉️ Amazon SES ahora soporta la firma de correos S/MIME → Leer más
🔄 Amazon Kinesis Data Streams ahora soporta una función de prueba en seco para validar solicitudes de API → Leer más
🧠 Claude Fable 5.1, el nuevo modelo de frontera de Anthropic, ahora está disponible en AWS → Leer más
⏱️ Amazon CloudWatch ahora soporta períodos de calentamiento para alarmas → Leer más
🤖 Amazon Cognito ahora soporta autorización máquina a máquina sin un dominio de usuario → Leer más
🔍 Amazon OpenSearch Service añade nuevos Cluster Insights para un diagnóstico más rápido del estado del clúster → Leer más
📊 Amazon Kinesis Data Streams anuncia tablas de streaming, entregando datos a tablas Apache Iceberg en Amazon S3 → Leer más
🎬 Video de la Semana
Un agente de soporte le inventó una política de reembolsos a un cliente. Se la dijo como si fuera un hecho. El desarrollador la buscó línea por línea en el código y no encontró ningún bug — porque el problema no estaba ahí. Estaba en el system prompt.
Esta semana te como escribir un system prompt que funciona.
📚 Artículos Interesantes
📧 Programando Campañas de Email a Gran Escala con Amazon EventBridge Scheduler
El artículo detalla cómo Amazon EventBridge Scheduler puede usarse para enviar campañas de email personalizadas a nivel de cada destinatario.
Puntos clave:
* EventBridge Scheduler puede actuar como el despachador de tiempo de envío por destinatario para campañas de email.
* AWS Step Functions Distributed Map ayuda a crear millones de horarios en paralelo.
* Amazon SES entrega los emails personalizados cuando EventBridge Scheduler activa cada horario.
🎯 Reflexión: La combinación de EventBridge Scheduler y Step Functions demuestra cómo es posible escalar campañas de email sin necesidad de mantener infraestructura infrautilizada, optimizando la entrega y personalización de los mensajes.
📖 Leer el artículo completo
🚀 AWS Lambda Managed Instances
Este artículo analiza las instancias gestionadas de AWS Lambda, centrándose en las compensaciones prácticas de esta nueva opción híbrida de computación.
Puntos clave:
* Reducción del dolor por tiempos de espera: Las instancias gestionadas pueden eliminar prácticamente los tiempos de espera para cargas de trabajo constantes, mejorando el rendimiento de aplicaciones sensibles a la latencia.
* Modelo de precios similar al de EC2: Incluye un cargo por solicitudes y una tarifa de gestión del 15%. Los beneficios de costo dependen de la consistencia del tráfico.
* Complejidad operativa y velocidad de escalado: Introducen consideraciones sobre la velocidad de escalado, siendo más adecuadas para tráfico predecible.
🎯 Reflexión: Las instancias gestionadas de Lambda ofrecen una alternativa viable para cargas de trabajo predecibles que requieren menor latencia y mejor rendimiento, aunque a expensas de la simplicidad y escalado elástico rápido de Lambda.
📖 Leer el artículo completo
📦 DynamoDB Streams: No Es Un Outbox
Este artículo argumenta que, aunque los DynamoDB Streams son útiles para reaccionar a los cambios a nivel de ítems, no son un verdadero outbox transaccional, ya que se generan después de la escritura en la base de datos, y no como parte de la misma transacción atómica.
Puntos clave:
* DynamoDB Streams captura cambios en la tabla, pero no proporciona garantías atómicas de ‘escribir datos + escribir evento’.
* El patrón de outbox transaccional sigue siendo la opción más segura cuando la fiabilidad del evento debe estar atada a la transacción de datos.
* Utiliza DynamoDB Streams como un mecanismo de captura de datos, no como un sustituto de la semántica del outbox.
🎯 Reflexión: La comprensión clara de las diferencias entre DynamoDB Streams y el patrón de outbox es fundamental para diseñar sistemas robustos en arquitecturas centradas en eventos. Es vital seleccionar la herramienta adecuada que se alinee con nuestras necesidades de transacciones y fiabilidad de eventos.
📖 Leer el artículo completo
💻 ¿Kiro es Más Eficiente de Verdad o Solo una Sensación?
En este artículo se explora la percepción de que Kiro, una herramienta de codificación impulsada por IA, se siente más eficiente que otras. Se cuestiona si esta sensación es subjetiva o si está respaldada por mejoras reales en el rendimiento.
Puntos clave:
* Kiro se posiciona como una herramienta de codificación que va más allá de la simple finalización de código, enfocándose en requisitos, diseño y secuenciación de tareas.
* AWS afirma que Kiro puede ser hasta un 50% más rentable que otras alternativas.
* La cuestión central del artículo es si la eficiencia de Kiro es subjetiva o medible, y las evidencias sugieren que hay ventajas reales tanto en rendimiento como en costos.
🎯 Reflexión: Kiro podría representar un cambio notable en la forma en que se enfoca la codificación, brindando una experiencia más estructurada y coste-efectiva para los desarrolladores.
📖 Leer el artículo completo
🛠️ Comienza con el Agent Toolkit para AWS en la AWS CLI
Este artículo presenta el Agent Toolkit para AWS en la AWS CLI y cómo ayuda a los agentes de codificación de IA a trabajar más efectivamente con AWS.
Puntos clave:
* Conocimiento Curado: El Agent Toolkit ofrece a los agentes de codificación un acceso seguro a conocimientos de AWS y una guía de seguridad.
* Configuración Simplificada: El comando aws configure agent-toolkit detecta automáticamente agentes y configura habilidades en un solo paso.
* Gestión de Habilidades Individuales: La CLI permite buscar, agregar, actualizar y eliminar habilidades de AWS según sea necesario.
🎯 Reflexión: La centralización de la configuración y la gobernanza en la CLI no solo simplifica el proceso, sino que también proporciona una ruta más rápida hacia una asistencia de desarrollo impulsada por IA en AWS, haciendo que sea más segura y precisa para los equipos.
📖 Leer el artículo completo
📝 Eventos en Español
📅 9 septiembre: [Bogotá] Ni todo es LLM. Ni todo es Pod. 📍 AWS UG Colombia 🔗 Más info
📅 11 Setiembre: Sesión de práctica y dudas 📍 AWS UG Mixtli 🔗 Más info
📅 11 Setiembre: Más allá del código: navegando la comunidad y la cultura Tech 📍 AWS Girls Argentina 🔗 Más info
📅 15 Setiembre: Credenciales, Slack y un camino no tradicional a DevOps con Laura Díaz 📍 AWS Girls Uruguay 🔗 Más info
📅 15 Setiembre: ¿Reemplaza o potencia? Nuestra perspectiva de evolución de la IA generativa 📍 AWS UG Ensenada 🔗 Más info
📅 17 Setiembre: We are back! AWS 101 para todos 📍 AWS UG Santo Domingo 🔗 Más info
📅 23 Setiembre: [Bogotá] Monkey is Back! 📍 AWS UG Colombia 🔗 Más info
📅 23 Setiembre: Observabilidad en AWS: monitoriza y diagnostica tus apps con DevOps Agent 📍 AWS UG Sevilla 🔗 Más info
📅 24 Setiembre: Frontier Agents y Ciberseguridad cognitiva para la IA 📍 AWS UG Zaragoza 🔗 Más info
📅 24 Setiembre: [Medellín] Monkey is Back! 📍 AWS UG Colombia 🔗 Más info
📅 3 octubre: AWS Community Day Peru 📍 AWS UG Perú 🔗 Más info
📅 5 octubre: AWS Modernizate: Seguridad a Velocidad de Maquina con AWS Continuum 📍 AWS UG Puerto Rico 🔗 Más info
⭐ 10 Octubre: AWS Community Day Guatemala 2026 | AWS UG Guatemala 📍 🔗 Más info
⭐ 17 Octubre: AWS Community Day Spain 2026 📍 AWS UG Spain 🔗 Más info
Gracias por leer Desplegando.cloud!
Eso es todo por esta semana. Recuerda que también puedes escuchar Desplegando.cloud en formato podcast en tus plataformas favoritas. ¡Nos vemos la próxima semana con más novedades del mundo AWS!
¡Feliz despliegue!
Marcia.
PD: Si estás en el proceso de aprender AWS y Serverless y necesitas ayuda —> hace click acá


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

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

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

¡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 través del navegador simplifica el movimiento de archivos entre máquinas locales y CloudShell.
🎯 Reflexión: CloudShell se presenta como un espacio de trabajo ligero para la gestión de archivos en AWS, permitiendo a los usuarios realizar ediciones rápidas y mover archivos sin requerir herramientas locales.
📖 Leer el artículo completo
📝 Eventos en Español
📅 24 Agosto: DevOps en la Nube de AWS y GitHub Actions 📍 AWS UG La Paz 🔗 Más info
📅 25 Agosto: Road To Community Day Bolivia 2026 | Día 2 📍 AWS Girls Bolivia 🔗 Más info
📅 27 Agosto: Road To Community Day Bolivia 2026 | Día 4 📍 AWS UG Cochabamba 🔗 Más info
📅 28 Agosto: Sesión 3: Aplicaciones de Modelos Fundacionales 📍 AWS UG Mixtli 🔗 Más info
📅 28 Agosto: El Camino Compartido: Voluntarios de AWS Community Day Bolivia 📍 AWS UG Cochabamba 🔗 Más info
📅 28 Agosto: Talento Tech: Habilidades que abren puertas 📍 AWS UG Bogotá 🔗 Más info
📅 29 Agosto: AWS UG Chile + JSCHILE Invierno 2026 📍 AWS UG Chile 🔗 Más info
📅 29 Agosto: 👑☁️Cloud Queens: Play, Learn, Certify 📍 AWS Girls Bolivia 🔗 Más info
⭐ 29 Agosto: AWS Community Day Bolivia 2026 🇧🇴 | AWS UG Cochabamba 📍 🔗 Más info
📅 5 Setiembre: Sesión 4: IA Responsable: Seguridad y Gobierno 📍 AWS UG Mixtli 🔗 Más info
⭐ 5 Setiembre: AWS Community Day Ecuador 2026 📍 AWS UG Ecuador 🔗 Más info
📅 11 Setiembre: Sesión de práctica y dudas 📍 AWS UG Mixtli 🔗 Más info
📅 11 Setiembre: Más allá del código: navegando la comunidad y la cultura Tech 📍 AWS Girls Argentina 🔗 Más info
📅 15 Setiembre: Credenciales, Slack y un camino no tradicional a DevOps con Laura Díaz 📍 AWS Girls Uruguay 🔗 Más info
📅 1 Septiembre: AWS Modernizate: Automatización Inteligente con DevOps Agent 📍 AWS UG Puerto Rico 🔗 Más info
📅 24 Setiembre: Frontier Agents y Ciberseguridad cognitiva para la IA 📍 AWS UG Zaragoza 🔗 Más info
⭐ 10 Octubre: AWS Community Day Guatemala 2026 | AWS UG Guatemala 📍 🔗 Más info
⭐ 17 Octubre: AWS Community Day Spain 2026 📍 AWS UG Spain 🔗 Más info
Gracias por leer Desplegando.cloud!
Eso es todo por esta semana. Recuerda que también puedes escuchar Desplegando.cloud en formato podcast en tus plataformas favoritas. ¡Nos vemos la próxima semana con más novedades del mundo AWS!
¡Feliz despliegue!
Marcia.
PD: Si estás en el proceso de aprender AWS y Serverless y necesitas ayuda —> hace click acá


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

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