Forem: Franchesco Romero

Pros y Cons de las arquitecturas multi-región

Franchesco Romero — Thu, 02 Apr 2026 22:07:40 +0000

Pros y Cons de las arquitecturas multi-región - Speaker Deck

speakerdeck.com

Los retos reales de ir multi-región

Antes de hablar de soluciones, hay que nombrar los retos con claridad porque es donde más se subestima el esfuerzo. El primero es elegir la solución tecnológica correcta — no todas las cargas de trabajo necesitan multi-región y no todos los servicios de AWS están disponibles igual en todas las regiones. El segundo es el manejo de fallos a escala: no basta con tener recursos en dos regiones si no has pensado cómo se comporta cada componente ante una falla. El tercero es la cercanía a los usuarios, que no siempre es puramente técnica — hay leyes, regulaciones y requisitos de soberanía de datos que dictan dónde puede vivir tu información.

Ignorar cualquiera de estos puntos al inicio garantiza una conversación mucho más difícil después.

Tolerancia a fallos: el modelo mental que todo lo rige

El concepto clave aquí es el dominio de error (fault domain). Cada componente de tu arquitectura pertenece a un dominio que define su política de falla: puede ser redundante (se replica), ignorable (su caída no afecta el sistema), o en cascada (si cae, arrastra a quien depende de él — el temido SPOF).

El problema clásico es una arquitectura donde la base de datos es un dominio en cascada dentro de una sola AZ, en una sola región. Si esa AZ tiene problemas, caes completo. La estrategia multi-región resuelve esto añadiendo un nivel más en la jerarquía de dominios, pero también introduce nuevas preguntas sobre consistencia y latencia de replicación que hay que responder explícitamente.

Las capas de una arquitectura multi-región

Pensar en capas ayuda a no perderse. Cada capa tiene sus propias decisiones y sus propios servicios.

Capa de redes. El CDN entrega contenido global con acceso seguro y rápido — CloudFront es el componente natural aquí en AWS. El DNS, específicamente Route 53, es quien realmente orquesta el tráfico entre regiones: puedes rutear por latencia, por failover, por geolocalización o con políticas ponderadas. Una buena estrategia de DNS hace más diferencia de lo que la gente espera — es literalmente el primer punto de decisión que toca cada request de usuario. Las redes internas entre regiones deben estar interconectadas y planificadas desde el inicio, no como un afterthought.

Capa de cómputo. Los servicios deben ser modulares, organizados por dominio de negocio y escalables bajo demanda. La elección entre Lambda, EC2, ECS o Kubernetes depende del caso de uso — no hay respuesta genérica, y lo que sí aplica siempre es que la capa de cómputo debe poder replicarse o levantarse en otra región sin fricción manual.

Capa de aplicación. Aquí hay un principio que marca la diferencia: la aplicación debe ser agnóstica a la región. Eso implica configuración externalizada, procesos sin estado (stateless) y secretos administrables. Un ejemplo concreto: leer el region_name desde una variable en lugar de hardcodearlo en el código. Suena básico y sin embargo es donde se rompen más arquitecturas multi-región en la práctica.

Capa de datos. Esta es la más compleja. Antes de elegir un servicio hay que identificar los patrones de acceso, el tipo de almacenamiento (bloque, archivo u objeto), el costo de replicación y dónde están los usuarios. AWS tiene soporte de replicación cross-region en DynamoDB, RDS Aurora, RDS estándar, S3, ElastiCache y DocumentDB. Cada uno tiene sus propias implicaciones de consistencia eventual vs. consistencia fuerte que hay que entender antes de decidir.

Capa de seguridad, identidad y acceso. IAM es global, lo cual simplifica la gestión de usuarios, roles y grupos. KMS permite crear llaves con capacidad multi-región. Secrets Manager puede replicar secretos en regiones secundarias — y aquí hay un detalle importante de Terraform: cuando configuras un aws_secretsmanager_secret con un bloque replica, la región secundaria se sincroniza automáticamente. Parece trivial hasta que lo necesitas en un failover real.

Monitoreo: no es opcional, es parte de la arquitectura

Una arquitectura multi-región sin observabilidad centralizada es básicamente una caja negra distribuida. CloudWatch, Config, GuardDuty y CloudTrail son servicios regionales, pero servicios como Security Hub y CloudTrail soportan agregados multi-región, lo que permite tener una vista unificada de eventos de seguridad sin tener que revisar consola por consola.

Hay un punto importante aquí: una estrategia de monitoreo requiere varias iteraciones. No sale perfecta a la primera. Herramientas como Amazon DevOps Guru ayudan a identificar comportamientos anómalos, sugerir mejoras de configuración y alertar sobre fallos críticos — complementan bien el stack base de observabilidad.

Despliegue: IaC o no escala

En arquitecturas multi-región, el despliegue manual no es una opción viable a largo plazo. Infraestructura como código (Terraform, CDK, CloudFormation) no es solo una buena práctica — es lo que permite recrear un entorno completo en otra región en minutos en lugar de días. El control de cambios debe ser granular: por cuenta, por ambiente y por región. IAM debe seguir el principio de mínimo privilegio, y los fallos deben estar controlados — es decir, un error en el despliegue de una región no debe tumbar las otras.

Un tip práctico: las nuevas regiones también funcionan muy bien como sandbox para validar nuevas funcionalidades o para simular desastres antes de que lleguen solos.

Lo que realmente hay que considerar antes de empezar

Multi-región no es gratis ni en costo ni en complejidad operacional. El operational overhead es real: cada recurso que existe en una región ahora existe en dos o más, con todo lo que eso implica en mantenimiento, monitoreo y actualizaciones. Los costos de transferencia de datos entre regiones también se acumulan rápido si no se modelan desde el inicio.

Antes de empezar, vale la pena hacer un ejercicio de planeación con una matriz de prioridad, esfuerzo, complejidad y dependencias — algo similar al Método Eisenhower. No todo tiene que regionalizarse al mismo tiempo ni con la misma urgencia. Siempre hay componentes que son candidatos naturales para regionalizarse primero (típicamente los más críticos y con menor complejidad de replicación) y otros que pueden esperar.

Un Well Architected Review es un buen punto de partida para hacer ese inventario con una metodología estructurada.

La arquitectura evoluciona

El estado final de una arquitectura multi-región en AWS se ve algo así: el usuario llega a Route 53, que rutea al CloudFront más cercano, que a su vez dirige el tráfico a la región correspondiente — donde viven el API Gateway, las Lambdas y la base de datos Aurora replicada. Todo gestionado por certificados en ACM y con tráfico distribuido por políticas de latencia o failover en DNS.

Llegar ahí no pasa de un día para otro. Llega por iteraciones, con IaC como columna vertebral y con una estrategia de DNS que desde el primer día esté pensada para escalar.

Multi-región no es un problema de servicios, es un problema de diseño. Los servicios de AWS están listos. La pregunta es si tu arquitectura, tu código y tus procesos también lo están.

Multi-Stage Continuous Delivery

Franchesco Romero — Thu, 02 Apr 2026 21:59:47 +0000

Multi-Stage Continuous Delivery - Speaker Deck

speakerdeck.com

El problema con los pipelines tradicionales

El concepto de Multi-Stage CD es sencillo: llevas código a prod en varias iteraciones y a través de diferentes ambientes — dev, staging, prod — con fases bien definidas: build, prepare, deploy, test, notify, rollback. Suena limpio. Y en papel, lo es.

El problema es la realidad. Según el State of DevOps Report 2020, el 95% del tiempo se va en mantenimiento de pipelines, el 80% en tareas manuales, y el 90% en remediación también manual. Nadie escribe esas métricas en su README, pero todos las vivimos.

Los retos concretos son tres y son los de siempre: la disponibilidad de ambientes (el clásico "no le muevan a dev que estoy probando algo"), satisfacer dependencias externas correctamente — JS, Python, AWS, lo que sea — y los ambientes con candado cuando hay un bug en prod y todo se paraliza. A eso le sumas llegada lenta a producción, más de siete herramientas involucradas en el proceso, y pipelines distintos para web, API y mobile que cada quien personalizó a su manera. El resultado es un Frankenstein difícil de mantener para cualquier persona del equipo.

Lo que realmente se necesita no es magia: capacidad de poner ambientes en cuarentena, dependencias siempre disponibles y seguras, configuración que realmente funcione, y despliegues validados con tests, métricas de performance y SLOs/SLIs bien definidos.

Keptn: un control plane para gobernarlos a todos

La solución que propongo es Keptn — y el título de esta sección es intencional. Keptn es una plataforma open source de orquestamiento que automatiza la configuración y provee en un solo control plane todo lo que normalmente está disperso: monitoreo, despliegue, remediación y resiliencia.

Lo que lo hace diferente es su enfoque declarativo y orientado a GitOps. Defines tus ambientes y estrategias en un archivo shipyard.yaml y Keptn se encarga de la orquestación basada en eventos. No necesitas escribir la lógica de coordinación entre herramientas — eso ya está resuelto.

Desde el punto de vista de plataforma, Keptn entrega progressive delivery, automatización de SRE, auto-remediación y rollback, y una configuración codificable e independiente de herramientas. Pero la parte más importante: mantiene conectividad con las herramientas que ya tienes — JMeter, Argo, Jenkins, Helm, lo que ya está corriendo en tu stack.

Un beneficio que no es obvio a primera vista: los pipelines tradicionales dejan de ser necesarios. Keptn reemplaza esa necesidad con fases dedicadas y orquestamiento event-driven. Tienes estrategias out-of-the-box como Blue/Green y Canary, más observabilidad integrada en el proceso con auditabilidad y trazabilidad completas.

Cómo funciona por dentro

El modelo mental es el siguiente: Keptn expone servicios a los cuales las herramientas se suscriben por medio de integraciones. Los eventos de Keptn se traducen a llamadas API hacia y desde esas herramientas.

En la práctica: Keptn crea un evento y lo distribuye a cualquier servicio que esté escuchando — por ejemplo, sh.keptn.event.hello-world.triggered. El Job Executor Service (JES) detecta el evento, busca la configuración en el YAML correspondiente y ejecuta el contenedor. Una vez que termina, el JES envía de vuelta un par de eventos .started y .finished. Keptn los recibe, sabe que la tarea está completa y avanza en la secuencia. Simple, trazable, predecible.

El ecosistema de integraciones es amplio. Para despliegue: Argo, Jenkins, CircleCI. Para observabilidad: Prometheus, Grafana, Splunk. Para testing: JMeter, Selenium, Artillery. Para notificaciones: Slack, webhooks, Tekton. Para automatización: Ansible, webhooks, AWS Lambda. La idea es clara — Keptn maneja la orquestación, las tareas y la ejecución; nosotros decidimos las herramientas.

Por qué esto importa frente a pipelines tradicionales

La comparación es directa. Los pipelines tradicionales sufren de falta de separación de responsabilidades, código lleno de dependencias y personalizaciones ad hoc, y dificultad para incorporar herramientas específicas sin romper todo. Keptn resuelve esto con fases dedicadas y orquestamiento basado en eventos, interoperabilidad a través de abstracciones bien definidas, y flexibilidad real para cambiar herramientas sin reescribir la lógica de entrega.

Próximos pasos: quality gates y progressive delivery

Una vez que el flujo básico está corriendo, los casos de uso avanzados son los que realmente cambian el juego. Los Quality Gates basados en SLI/SLO permiten que un despliegue sólo avance si cumple criterios medibles — por ejemplo, que el porcentaje de éxito de probes sea mayor al 95%, o que la duración de respuesta sea menor a 200ms. El score total determina si el pipeline pasa o emite una advertencia.

El Progressive Delivery lleva esto un paso más lejos: defines un flujo que va de dev a hardening a production, con estrategias blue/green en los ambientes de mayor criticidad y remediación automatizada en prod. Keptn evalúa quality gates entre cada etapa y sólo promueve si los números lo justifican.

El punto de todo esto no es adoptar una herramienta más por el gusto de hacerlo. Es reconocer que los pipelines monolíticos tienen un techo bajo, y que un modelo orientado a eventos con separación clara de responsabilidades escala mucho mejor — tanto en complejidad técnica como en tamaño de equipo.

Si quieres profundizar, el punto de partida es keptn.sh y los recursos de la comunidad en keptn.sh/resources/slides.

Optimización de costos para transacciones de alto volumen

Franchesco Romero — Thu, 02 Apr 2026 21:51:48 +0000

Optimización de costos para transacciones de alto volumen - Speaker Deck

speakerdeck.com

Optimización de Costos para Transacciones de Alto Volumen en AWS

Cuando se habla de optimización de costos en AWS, la conversación suele ir a los mismos lugares de siempre: Reserved Instances, Savings Plans, apagar recursos que no usas. Todo eso está bien y deberías hacerlo, pero hay un nivel más profundo que la mayoría de los equipos no toca — las decisiones de arquitectura y tecnología que generan costos innecesarios a escala sin que nadie se dé cuenta. Este post va sobre eso.

La economía oculta de las API calls

En arquitecturas serverless, cada llamada API tiene un costo. Eso parece obvio, pero las implicaciones no siempre son visibles cuando estás diseñando el sistema.

El patrón más común que genera costo silencioso es el polling. Imagina una aplicación que consulta un endpoint REST cada 5 segundos para verificar si hay nuevas órdenes en DynamoDB. A volumen bajo nadie lo nota. A volumen alto, estás pagando por miles de requests a API Gateway y Lambda que en su mayoría regresan vacío. La corrección es dejar de preguntar y empezar a escuchar: DynamoDB Streams detecta los cambios en la tabla y los envía a EventBridge, que filtra y transforma el evento antes de disparar el downstream — SNS, Step Functions, WebSockets. Cero polling, costo proporcional al trabajo real.

Otro patrón costoso es usar Lambda para cada operación que pasa por API Gateway. Si tienes un frontend enviando datos JSON que necesitan ser validados y escritos en DynamoDB, el reflejo natural es meter una Lambda en el medio. El problema es que cada invocación tiene costo. API Gateway tiene Mapping Templates que pueden hacer validaciones y transformaciones de request sin necesidad de invocar ninguna función. Para operaciones simples y de alto volumen, eliminar esa Lambda puede significar cientos de miles de invocaciones menos por mes.

El tercer caso tiene que ver con los límites internos de AWS. Cuando una aplicación escribe a DynamoDB a alta velocidad y alcanza el límite de Write Capacity Units, AWS aplica backoff exponencial y genera reintentos automáticos — que también cuestan. Meter SQS como buffer entre la aplicación y DynamoDB nivela el throughput y elimina esos reintentos, convirtiendo un patrón de escritura caótico en uno predecible y controlable.

Data transfer: el costo que nadie presupuesta

La transferencia de datos en AWS tiene una particularidad: es casi invisible en el diseño inicial y muy visible en la factura a fin de mes.

El ejemplo más costoso y fácil de corregir es usar NAT Gateway para que instancias en subnets privadas accedan a S3. NAT Gateway cobra por procesamiento de datos — a $0.045 por GB, 5TB al mes son $225 adicionales que no agregan ningún valor técnico. La solución es un VPC Endpoint para S3: el tráfico fluye directamente dentro de la red de AWS sin pasar por NAT, sin costo por transferencia. Es una de las optimizaciones con mejor ratio esfuerzo/impacto que existen.

Para APIs con alto tráfico de lectura, CloudFront delante de API Gateway puede eliminar la gran mayoría de invocaciones a Lambda. Si configuras CloudFront para cachear respuestas comunes por 5 minutos, todo ese tráfico repetido deja de llegar al backend. Para catálogos de productos, configuraciones, datos de referencia — el impacto puede ser dramático.

El caso de GenAI agrega una dimensión nueva. Si tienes un chatbot en AWS que manda cada query a un modelo externo como OpenAI, estás pagando transferencia de datos de salida en cada request. Mover el modelo a Amazon Bedrock o SageMaker dentro de AWS no solo elimina esa transferencia — también te da más control sobre latencia, disponibilidad y costos por token.

La economía del almacenamiento

El formato de compresión que usas para tus datos puede parecer un detalle técnico menor. En cargas de análisis a escala, no lo es. GZIP es el default en muchos pipelines de Redshift, EMR y Glue, pero tiene latencia de descompresión alta y peor ratio de compresión comparado con alternativas más modernas. Zstandard en nivel 3 ofrece mayor eficiencia tanto de almacenamiento como de procesamiento, con reducciones de más de un 30% en tamaño. Para 50TB de logs de transacciones, ese 30% es dinero real.

El zero-copy data sharing es otro concepto que vale la pena entender. El patrón ineficiente es copiar datos entre cuentas de AWS para que cada equipo tenga su propia copia en S3. Cada copia es storage adicional, cada sincronización es transferencia. Con AWS Lake Formation y Glue Catalog Cross-Account, puedes dar acceso a las mismas tablas registradas a múltiples cuentas sin mover un solo byte. Los datos viven en un lugar, el acceso se gestiona con permisos.

Computación selectiva: elegir bien el tipo de recurso

Aquí hay una distinción que muchos equipos no hacen: no todos los workloads tienen el mismo cuello de botella. Algunos son CPU-intensivos, otros son memory-bound, otros son IO-bound. Elegir la familia de instancia equivocada significa pagar por recursos que no estás usando.

Un ejemplo concreto: una base de datos MySQL en RDS con instancias t3.medium que tiene la RAM llena y hace swapping a disco. El problema no es CPU — es memoria. La solución no es subir a una instancia con más CPU, es cambiar a una familia memory-optimized. Las instancias R6g con Graviton2 ofrecen 50% más memoria por dólar que T3. Para Elasticsearch con alto uso de IOPS donde EBS gp3 ya es el cuello de botella, instancias I4i con almacenamiento NVMe local reducen la latencia de consultas en un 60%.

En Lambda, la relación memoria-CPU tiene una implicación de costos contraintuitiva. Con 128MB de RAM, una función de procesamiento de imágenes puede tardar 6 segundos. Con 1024MB tiene acceso a una vCPU completa y la misma operación tarda 0.8 segundos — 7 veces más rápida. Lambda Power Tuning existe para encontrar el punto óptimo entre costo por ejecución y tiempo de ejecución, y el resultado frecuentemente sorprende: más memoria puede ser más barato.

En Kubernetes, el costo escala con el número de nodos, y el número de nodos escala con el número de pods. Si cada microservicio tiene su propio pod con límites de CPU y memoria dedicados, terminas con mucha capacidad reservada que en promedio está subutilizada. Consolidar servicios relacionados en pods multi-tenant reduce el número total de nodos necesarios y mejora la utilización del clúster.

Estrategias de bases de datos

Aurora tiene una característica que justifica su adopción para cargas intensivas en I/O: Aurora I/O-Optimized elimina el cobro por operaciones de lectura y escritura, cambiando el modelo de precio a uno más predecible basado en capacidad. Si tienes un workload con miles de IOPS, la diferencia puede ser sustancial. Combinado con auto-tiering para mover datos históricos a almacenamiento más barato y Aurora Backtrack para reducir snapshots innecesarios, el costo total de una instancia de 5TB puede bajar considerablemente.

Para logs de transacciones en PostgreSQL que crecen a millones de registros con el tiempo, la solución no es escalar la instancia — es particionar los datos por tiempo. En lugar de una tabla gigante donde las consultas escanean todo el historial, particiones mensuales o diarias limitan el scope de cada query al período relevante. Amazon Timestream también es una alternativa cuando el patrón de acceso es fundamentalmente time-series.

Con DynamoDB a escala, TTL es una herramienta de costo que se subestima. Los ítems expirados se eliminan automáticamente sin consumir Write Capacity Units, lo que mantiene la tabla limpia sin operaciones de borrado explícitas. DAX como capa de caché elimina lecturas repetidas a la tabla principal y DynamoDB Streams permite reaccionar a cambios sin polling — ambos ya cubiertos en la sección de API calls.

Los anti-patterns que hay que evitar

Tan importante como saber qué optimizar es saber qué no hacer. Over-engineering en arquitecturas event-centric es frecuente: agregar capas de EventBridge, SNS y SQS a flujos que podrían ser síncronos simples, creando complejidad operacional por ahorros marginales que nunca se materializan.

El mito de que serverless siempre es más económico que servidores es exactamente eso: un mito. Para cargas con throughput constante y predecible, un servicio administrado de contenedores o incluso instancias reservadas pueden salir más baratos que pagar por invocación a escala. El modelo correcto depende del patrón de tráfico.

Los logs sin filtrar son otro agujero silencioso. Loggear todo en CloudWatch Logs a nivel DEBUG en producción, sin retention policies, sin filtros, genera costos de ingesta y almacenamiento que crecen con el tráfico. Filtrar a nivel del source, definir retention apropiado y usar Log Insights solo cuando se necesita mantiene eso bajo control.

La conclusión más importante es también la más sencilla: la optimización no es un proyecto con fecha de inicio y fin, es una práctica continua. Las estrategias no convencionales que van más allá de Reserved Instances y right-sizing pueden aportar entre un 15-30% adicional de ahorro. Pero solo si el equipo tiene cultura de cost awareness integrada desde el diseño, no como una corrección posterior.

Optimizando Cargas de Trabajo Serverless Técnicas para mejorar Rendimiento y Eficiencia

Franchesco Romero — Thu, 02 Apr 2026 21:19:45 +0000

Optimizando Cargas de Trabajo en Lambda - Speaker Deck

speakerdeck.com

Este post va sobre las técnicas que realmente mueven la aguja cuando estás buscando rendimiento y eficiencia en Lambda.

Cómo está construido lo que estás ejecutando

Lambda tiene una arquitectura en capas que vale la pena entender antes de optimizar cualquier cosa: tu función vive dentro de un Language Runtime, que a su vez corre en un Execution Environment, administrado por el Lambda Service sobre un Compute Substrate. Cada capa tiene implicaciones en cómo se comporta tu función al arrancar y durante la ejecución.

Dos mecanismos que se aprovechan bien una vez que entiendes esto son las Layers y las Extensions. Las capas te permiten separar tu código de función de sus dependencias y recursos compartidos — librerías, SDKs, utilerías comunes — y reutilizarlos en múltiples funciones sin empaquetar lo mismo en cada deployment. Las extensiones, por su parte, se integran en el ciclo de vida de la invocación para conectar Lambda con herramientas de monitoreo, seguridad y observabilidad, corriendo en paralelo al runtime sin modificar el código de tu función.

El problema de los Cold Starts

Si hay un tema que aparece en todas las conversaciones sobre Lambda es este. Un cold start ocurre cuando AWS necesita provisionar un nuevo contexto de ejecución — descarga el código, levanta el entorno, inicializa el runtime, y luego ejecuta tu función. Esto pasa con cambios de código, durante scale-up, en rebalanceos de AZs, o después de fallos.

El impacto varía bastante por runtime. Python y JavaScript tienen cold starts en el rango de 200-500ms. Java y Docker pueden llegar fácilmente al segundo y medio. No es lo mismo si tienes una API interactiva donde el usuario espera la respuesta, que un pipeline batch asíncrono donde nadie nota 800ms extra.

La estrategia más simple para mitigarlo es el warmup con eventos de CloudWatch o EventBridge que disparan la función cada X minutos para mantenerla activa. Funciona, pero tiene sus trade-offs: es periódico, no puedes controlar qué instancias específicas se calientan, y a escala puede tener un costo no despreciable. Haz los números: una sola función ejecutándose cada 5 minutos cuesta alrededor de $0.18 al mes. Diez funciones: $14.58 más costos de CloudWatch. No es dramático, pero tampoco es gratis.

La alternativa más robusta es Provisioned Concurrency: le dices a Lambda cuántos entornos de ejecución quieres inicializados y listos en todo momento. Por cada unidad de simultaneidad aprovisionada se mantienen mínimo dos entornos en AZs separadas, lo que también da alta disponibilidad. El contra es que pagas por esa capacidad aunque no la uses, y hay restricciones importantes: no funciona con $LATEST ni con Lambda@Edge. Úsalo con inteligencia — tiene más sentido en runtimes de inicio lento como Java, y puedes combinarlo con Application Auto Scaling para ajustar la capacidad según patrones de tráfico.

Para Java específicamente, SnapStart es un game changer: toma una snapshot del estado inicializado de la función y la restaura en invocaciones posteriores, logrando hasta 10x mejora en tiempo de arranque sin cambios en el código. Disponible desde la consola, SAM y CDK.

Vale mencionar también LLRT (Low Latency Runtime) — un runtime JavaScript liviano escrito en Rust que AWS Labs lanzó como experimental. Ofrece inicio hasta 10x más rápido y costo hasta 2x menor comparado con el runtime de Node.js estándar. Si estás en JavaScript y los cold starts te están afectando, vale la pena explorarlo.

Right-sizing y optimización de costos

Más memoria no siempre significa más costo — en Lambda, memoria y CPU están acoplados, así que a veces asignar más RAM resulta en ejecuciones más rápidas que al final cuestan lo mismo o menos. El problema es que nadie sabe exactamente cuánta memoria necesita una función sin medirlo.

Para esto existe AWS Lambda Power Tuning, una State Machine de Step Functions que ejecuta tu función con diferentes configuraciones de memoria, mide duración y costo, y te da una visualización clara del trade-off. La diferencia entre la configuración óptima para costo (1536MB en el ejemplo de la presentación) vs. la óptima para velocidad (3008MB) puede ser significativa, y depende completamente de tu workload específico.

Otros recursos útiles para right-sizing son AWS Compute Optimizer, Lambda Insights, y DevOps Guru, que pueden darte recomendaciones basadas en patrones de uso histórico.

Si tu workload tolera migrar a arm64 (Graviton2), el ahorro en precio/performance es aproximadamente un 34% frente a x86. La migración no es siempre trivial — lenguajes compilados y algunos containers requieren adaptaciones — pero el beneficio es real y verificable con Lambda Power Tuning comparando ambas arquitecturas. Los Compute Savings Plans también aplican a Lambda y pueden dar hasta un 17% adicional de ahorro sobre demanda.

Optimizaciones que están en tu control

Hay cosas que AWS optimiza por ti (descarga del código, setup del entorno) y cosas que dependen de ti (init code y handler code). La mayor palanca que tienes está en mantener tus funciones ligeras: dependencias mínimas, frameworks más pequeños, sin código muerto, y empaquetado en un único archivo minificado. El tamaño del ZIP afecta directamente cuánto tarda Lambda en descargar y cargar tu función.

Lazy-loading es otra práctica que marca diferencia: en lugar de importar todo al inicio del módulo, carga las dependencias solo cuando realmente se necesitan. El código de la presentación lo ilustra bien tanto en JavaScript como en Python — inicializas el cliente de DynamoDB o S3 dentro del handler, condicionado a si ya está inicializado, y lo reutilizas en invocaciones posteriores dentro del mismo contexto de ejecución.

Para bases de datos relacionales, si estás llamando RDS desde Lambda, RDS Proxy resuelve el problema de agotamiento de conexiones que ocurre cuando Lambda escala agresivamente. Agrupación de conexiones, mayor disponibilidad y caché de queries — sin cambios en el código de la función.

Si tu función sirve respuestas que no cambian con cada invocación, configurar caché a nivel de API Gateway o CloudFront puede eliminar completamente la invocación de Lambda para esas peticiones. Para algunos patrones esto es la optimización más impactante de todas.

Métricas que realmente importan

Medir promedios de latencia es engañoso. Lo que importa es el percentil p95 o p99 — el rendimiento que experimentan el 5% o el 1% más lento de tus usuarios. Un promedio de 200ms con un p99 de 4 segundos es una función con problemas serios que el promedio oculta.

AWS X-Ray es la herramienta para esto: tracing end-to-end de requests, service map de tu aplicación, y visibilidad sobre exactamente dónde se producen los cuellos de botella. Un Tracing: Active en tu template de SAM o CDK y ya tienes trazas automáticas de Lambda y los servicios downstream.

El punto que más se subestima

Lambda no debería ser el default para absolutamente todo. Hay operaciones donde otros servicios hacen el trabajo mejor y más barato sin invocar ninguna función. Orquestación compleja de workflows: Step Functions. Filtrado de mensajes antes de procesarlos: SNS con filter policies. Scheduling de tareas: EventBridge Scheduler. Integrar Lambda innecesariamente en esos flujos agrega latencia y costo sin valor real.

Optimizar Lambda no es una sola cosa — es la suma de decisiones en configuración, código, arquitectura y monitoreo. El punto de partida es medir con X-Ray, ajustar con Lambda Power Tuning, y construir con las restricciones del caso de uso en mente, no con el toolset que conoces mejor.

Mejorando tu Seguridad en AWS con ML y AI

Franchesco Romero — Thu, 02 Apr 2026 21:10:57 +0000

Mejorando tu Seguridad en AWS con ML y AI - Speaker Deck

speakerdeck.com

Mejorando tu Seguridad en AWS con ML y AI

Las aplicaciones modernas son complejas, distribuidas, y cada nuevo servicio que agregas es también una nueva superficie de ataque potencial. A eso súmale el volumen brutal de logs, métricas y trazas que genera una plataforma en producción, y tienes la receta perfecta para que identificar la causa raíz de un incidente se convierta en una tarea que consume horas — o días — de personas con conocimiento muy especializado.

Las amenazas tampoco se quedan quietas. Suplantación de identidad, ransomware, fraudes, amenazas internas, accesos no autorizados... la lista es larga y la frecuencia con la que ocurren no para de crecer. El problema de la seguridad tradicional es que trabaja con reglas fijas y estáticas, y los atacantes hace mucho que aprendieron a moverse entre los huecos que esas reglas dejan.

¿Qué necesitamos realmente?

Más allá de detectar incidentes, necesitamos hacerlo rápido. Reducir el tiempo de detección, de triaging, de debugging. Necesitamos protección continua que se adapte a nuestra operación, que nos ayude a cumplir con marcos normativos, y que no nos despierte a las 3am por un falso positivo. En resumen: necesitamos que el sistema aprenda.

Y ahí es donde entran ML y AI.

Cómo funciona

El concepto es sencillo: un algoritmo aprende a reconocer patrones en datos históricos, y una vez entrenado, usa ese conocimiento para hacer predicciones sobre datos nuevos y disparar acciones en consecuencia. Nada de magia, pura estadística aplicada a escala. Lo interesante es cómo AWS ha integrado esto directamente en sus servicios de seguridad, sin que tengas que construir ni operar los modelos tú mismo.

Las aplicaciones concretas van desde detección de anomalías en tráfico de red — identificar un DDoS antes de que te rompa el día — hasta modelado de comportamiento para detectar actividad maliciosa o fraudulenta que ningún operador humano hubiera notado a tiempo.

Los servicios que importan

Amazon GuardDuty es el punto de entrada natural. Es un servicio administrado que usa ML para analizar de forma continua eventos de CloudTrail, VPC Flow Logs y DNS Logs. Lo que hace bien es identificar patrones: acceso inicial sospechoso, escalación de privilegios, reconocimiento, acciones defensivas del atacante para cubrir sus huellas. No tienes que configurar reglas; el modelo se encarga.

Amazon Detective entra cuando ya ocurrió algo y necesitas entender qué pasó. Usa aprendizaje automático para analizar los mismos logs y te da contexto: qué cuentas estuvieron involucradas, desde qué IPs, qué recursos tocaron, y desde dónde geográficamente. La diferencia entre tardar 2 horas o 2 días en contener un incidente muchas veces está en tener ese contexto disponible de inmediato.

CloudWatch tiene algo que mucha gente no usa: detección automática de anomalías basada en ML. Analiza el histórico de tus métricas, aprende el comportamiento esperado, y te permite definir ventanas de detección y umbrales de tolerancia adaptados a tu operación — por ejemplo, excluir el ruido durante una ventana de deployments.

Para cumplimiento normativo, Amazon Macie usa ML para descubrir y clasificar datos sensibles en S3: PII, datos financieros, credenciales expuestas.

AWS DevOps Guru apunta más hacia el análisis predictivo: monitoreo continuo con algoritmos de ML sobre tus métricas de aplicación, detectando comportamientos anómalos antes de que se conviertan en incidentes, y creando automáticamente OpsItems en SSM OpsCenter para que el equipo los atienda.

Finalmente, IAM Access Analyzer usa Automated Reasoning — no ML clásico, sino análisis formal — para revisar tus políticas de IAM e identificar configuraciones que podrían permitir acceso no autorizado. Es el tipo de análisis que un humano haría manualmente en una auditoría, automatizado y corriendo de forma continua.

Lo que hay que tener claro

Ninguno de estos servicios es plug-and-play en el sentido de que funciona perfecto desde el día uno. Hay un período de aprendizaje — entre 15 minutos y 48 horas dependiendo del servicio — y cada ambiente es único, así que la configuración importa. El punto más importante, y el que más confunde a los equipos que recién empiezan: anómalo no es lo mismo que vulnerable, roto o malicioso. Un comportamiento fuera de lo normal es una señal para investigar, no necesariamente una alarma de incendio.

La combinación de GuardDuty, Detective, Macie, CloudWatch Anomaly Detection y DevOps Guru crea una capa de seguridad inteligente que detecta lo que las reglas estáticas no ven, responde más rápido de lo que cualquier equipo humano podría, y se adapta al comportamiento real de tu plataforma. ML y AI ya son parte central de la oferta de seguridad de AWS — la pregunta no es si usarlos, sino cuáles activar primero.

Dominando el Caos en Cargas de Trabajo Sin Servidores

Franchesco Romero — Thu, 02 Apr 2026 20:44:50 +0000

Dominando el Caos en Cargas de Trabajo Sin Servidores - Speaker Deck

La ingeniería del caos implica provocar intencionalmente interrupciones en las cargas de trabajo, generalmente en servidores tradicionales. En esta char…

speakerdeck.com

Dominando el Caos en Cargas de Trabajo Sin Servidores

La ingeniería del caos es la práctica de introducir fallos intencional y proactivamente en un sistema para identificar y solucionar debilidades. Esta definición suena contraintuitiva — ¿por qué romper algo que funciona? — pero la premisa es simple: si no pruebas cómo falla tu sistema en condiciones controladas, lo descubrirás en el peor momento posible.

Los beneficios son concretos: mejor resiliencia, mayor disponibilidad, experiencia de usuario más confiable, y equipos que confían en sus sistemas porque los han probado de verdad.

Pre-requisitos antes de introducir el caos

No se puede empezar a romper cosas sin preparación. Antes de ejecutar cualquier experimento de caos en un entorno serverless, hay cinco condiciones que deben estar cubiertas.

Primero, necesitas tener pruebas existentes — un suite de tests que defina qué es comportamiento correcto, para poder detectar desviaciones cuando introduces fallos.
Segundo, debes conocer a fondo la arquitectura: qué servicios están involucrados, cómo se comunican, qué dependencias existen.
Tercero, hay que determinar alcances y riesgos antes de ejecutar, no durante — saber exactamente qué se puede afectar y qué queda fuera de scope.
Cuarto, es preferible contar con entornos dedicados para los experimentos más agresivos; no todo debe probarse en producción desde el primer día.
Quinto, necesitas monitoreo y observabilidad en su lugar antes de comenzar, porque sin métricas no puedes saber qué está pasando durante el experimento.

El ciclo del caos

La ingeniería del caos no es caos sin estructura — es un ciclo bien definido. Empieza con una hipótesis: una pregunta específica sobre el comportamiento del sistema bajo estrés. A partir de ella se diseña un experimento, se crean los fallos, se analizan los resultados, se corrigen los fallos encontrados, se valida la hipótesis, y los aprendizajes alimentan mejora continua que genera nuevas hipótesis. El ciclo se repite.

El diseño de cada experimento sigue cuatro pasos: definir el estado estable (los KPIs que representan operación normal), formular la hipótesis (qué se espera que pase bajo estrés), especificar la definición y ejecución (tipos de fallo, sistemas a probar, condiciones), y establecer el monitoreo y análisis (cómo se verificarán los KPIs y las desviaciones).

Un ejemplo concreto: dado un API Gateway multi-región con funciones Lambda detrás de un enrutamiento basado en latencia, la hipótesis sería que inyectar latencia en una región no debería afectar el rendimiento de las demás, y que Route 53 debería detectar el aumento de latencia y redirigir el tráfico a una región más saludable. La ejecución del experimento tendría tres componentes: acción (inyectar latencia en Lambda), objetivo (funciones Lambda en una región específica), y condición de monitoreo (métricas de latencia en CloudWatch).

Técnicas de inyección de fallos

Hay tres categorías principales de fallos que se pueden inyectar en entornos serverless.

Resiliencia de red cubre latencia en respuestas y pérdida de paquetes — los fallos más comunes en sistemas distribuidos y los más fáciles de introducir de forma controlada.

Interrupciones simula servicios no disponibles y respuestas inesperadas — el escenario donde una dependencia simplemente deja de responder o responde con errores.

Límites prueba qué pasa cuando se alcanzan los topes de uso de APIs, memoria, o tiempo de ejecución — particularmente relevante en Lambda donde estos límites son hardcoded.

Más allá de la capa de red, los fallos también pueden inyectarse a nivel de código, de ambiente, o de configuración — tres vectores distintos que cubren la mayoría de los escenarios de fallo reales.

Herramientas disponibles en AWS

Para entornos serverless en AWS, hay cuatro opciones principales que vale comparar:

AWS Fault Injection Service (FIS) es el servicio nativo de AWS, 100% manejado e integrado con el ecosistema. Es programable desde consola, CLI y CDK, permite experimentos controlados tanto en secuencia como en paralelo, y opera a todos los niveles — red, infra, aplicación. Tiene excelente documentación pero tiene costo por uso.

Chaos Toolkit es una herramienta open source para caos en entornos generales. Documentación buena, facilidad media, gratuita.

Chaos_lambda está enfocada en fallos a nivel de runtime de Lambda. Documentación limitada, gratuita.

Failure Lambda opera a nivel de código de Lambda. También gratuita pero con documentación limitada.

Para la mayoría de los casos en AWS, FIS es la opción más práctica por su integración nativa y el nivel de control que ofrece.

AWS Fault Injection Service en detalle

Un experimento en FIS se construye con cuatro componentes: una plantilla de experimento que define todo lo que va a ocurrir, acciones que especifican qué fallos se van a introducir, objetivos que determinan sobre qué recursos se aplican (por ejemplo, instancias EC2 con tags específicos), y condiciones de paro vinculadas a alarmas de CloudWatch que detienen el experimento si las cosas se salen de control.

Para entornos serverless específicamente, FIS soporta los siguientes fallos: DynamoDB no responde, una región completa no funciona, Lambda tarda mucho en responder, Lambda responde con error, y throttling de API. Estos cubren los escenarios de fallo más comunes en arquitecturas event-driven y de microservicios sin servidor.

El monitoreo durante los experimentos se hace con CloudWatch para métricas, X-Ray para rastreo distribuido, y dashboards personalizados que permiten ver el comportamiento en tiempo real mientras el experimento está activo.

La arquitectura de implementación de FIS para Lambda sigue un flujo claro: FIS lee una plantilla de experimento, ejecuta una automatización que interactúa con Parameter Store para configurar el comportamiento de caos, y la Lambda bajo prueba reporta métricas a CloudWatch. En el caso del patrón Chaos Injection Lambda Layers, FIS orquesta a través de una plantilla y una automatización que actualiza Parameter Store, y la Lambda tiene un Chaos Lambda Layer adicional que lee esa configuración e inyecta el comportamiento anómalo antes de ejecutar el código de negocio. Esto permite activar y desactivar el caos sin modificar el código de la función.

La extensión chaos-lambda-extension es otro patrón que opera dentro del ambiente de ejecución de Lambda: se registra como una extension que se ejecuta junto al runtime, intercepta las invocaciones a través de la Extension API y la Runtime API, e inyecta los fallos configurados antes de que el código de la función se ejecute. Es más invasiva que las Lambda Layers pero también más precisa.

Técnicas de resiliencia para responder al caos

Identificar dónde falla el sistema es la mitad del trabajo. La otra mitad es construir resiliencia que haga que los fallos sean manejables. Hay tres principios fundamentales para aplicaciones serverless con tolerancia a fallos:

Redundancia significa tener múltiples instancias de los componentes críticos — en el contexto serverless, esto se traduce en deployments multi-región, DLQs para mensajes fallidos, y funciones de respaldo.

Degradación elegante implica mantener funcionalidad parcial cuando un componente falla. En lugar de retornar un error 500, la aplicación retorna una respuesta reducida pero funcional — datos en caché, respuestas por defecto, o funcionalidad limitada con un mensaje claro al usuario.

Recuperación automatizada significa que los procesos de recuperación de fallos no dependen de intervención manual. Los runbooks deben ejecutarse solos.

A nivel de código, las tres técnicas más importantes son lógica de reintento con backoff exponencial, circuit breakers, y throttling.

La lógica de reintento con backoff exponencial es el patrón básico de resiliencia para fallos transitorios. En Python con boto3, se traduce a reintentar la operación hasta N veces, con un time.sleep(2 ** attempt) entre intentos — los tiempos de espera crecen exponencialmente para no sobrecargar un servicio que ya está bajo presión.

Los circuit breakers son más sofisticados: un objeto que rastrea el número de fallos consecutivos y, cuando supera un umbral, abre el circuito durante un período de recuperación. Durante ese período, las llamadas fallan inmediatamente sin intentar la operación, dando tiempo al servicio dependiente de recuperarse. Una vez pasado el timeout de recuperación, el circuito se cierra y las operaciones se reanudan.

Los límites de throttling en API Gateway, configurados a través de UsagePlans con BurstLimit y RateLimit, protegen los backends de ser sobrecargados bajo picos de tráfico inesperados.

Mejores prácticas

Independientemente de las herramientas que uses, hay cinco principios que aplican a cualquier práctica de ingeniería del caos:

Comenzar pequeño. El primer experimento no debe ser "apagamos una región". Empieza con latencia en una función, en un ambiente de staging, con radio de blast controlado.

Automatizar. Los experimentos ejecutados manualmente son inconsistentes y difíciles de repetir. Automatizar la ejecución, el monitoreo y la condición de paro desde el principio.

Monitorear de cerca. No ejecutes un experimento y te vayas a hacer otra cosa. El valor está en observar el comportamiento en tiempo real.

Comunicar. El equipo necesita saber cuándo se está ejecutando un experimento, qué se está probando, y cuál es el plan de rollback. Los experimentos no anunciados generan pánico innecesario.

Documentar. Cada experimento, sus resultados, y los cambios que generó deben quedar registrados. La ingeniería del caos sin documentación es simplemente romper cosas.

Resumen

La ingeniería del caos en entornos serverless no es una práctica de nicho — es una necesidad para cualquier sistema que aspire a alta disponibilidad. AWS FIS hace que sea significativamente más accesible.

Integrando IA generativa con Bases de Datos relacionales en AWS

Franchesco Romero — Thu, 02 Apr 2026 20:15:07 +0000

Integrando IA generativa con Bases de Datos relacionales en AWS - Speaker Deck

En esta charla mostraremos cómo AWS Bedrock puede conectarse a una base de datos tradicional, comprender su estructura, y generar consultas a partir de …

speakerdeck.com

Integrando IA Generativa con Bases de Datos Relacionales en AWS

Foundation Models y el ecosistema de Bedrock

Antes de entrar en la implementación, vale la pena aclarar los conceptos base. La IA Generativa, en términos prácticos, es un tipo de IA capaz de crear nuevo contenido: textos, conversaciones, resúmenes, imágenes.

Los Foundation Models son los modelos de aprendizaje automático que hacen esto posible, entrenados sobre cantidades masivas de datos no etiquetados y luego adaptados para tareas específicas como generación de texto, extracción de información, Q&A o chatbots.

AWS Bedrock es el servicio que te da acceso a varios de estos modelos — desde Claude de Anthropic hasta Titan de Amazon, Llama 2 de Meta, Mistral, Cohere y Stable Diffusion — a través de una API unificada, sin tener que administrar infraestructura de ML por tu cuenta.

Arquitectura

La arquitectura que propuse es deliberadamente simple: un usuario interactúa con una aplicación, esta invoca una Lambda Function, la Lambda se conecta a Amazon Aurora, y Aurora llama a Bedrock directamente usando Aurora ML. Este componente es la pieza central del patrón — Aurora ML es una característica de Amazon Aurora (disponible desde la versión 3.06 en adelante) que permite invocar algoritmos de machine learning directamente desde SQL. Esto significa que puedes hacer un SELECT que internamente llama a un Foundation Model en Bedrock y regresa el resultado como si fuera cualquier otro valor de la base de datos. La simpleza de esto es lo que hace la integración tan poderosa: los datos nunca salen de Aurora, no hay ETL, no hay pipelines intermedios.

Pre-requisitos

La configuración requiere cuatro pasos previos:

Crear un IAM Role con los permisos necesarios para que Aurora pueda llamar a Bedrock, y asignar ese rol al cluster.
Habilitar los modelos base en la consola de Bedrock para la región donde está tu cluster — esto es un paso explícito que AWS requiere antes de poder usarlos.
Crear las funciones SQL que mapean a cada modelo de Bedrock.

Este último paso es lo más interesante: con apenas un CREATE FUNCTION que usa el alias AWS_BEDROCK_INVOKE_MODEL y especifica el MODEL ID, ya tienes disponible en tu base de datos una función que puedes llamar desde cualquier query o stored procedure. En la demo creé dos funciones, una para Amazon Titan y otra para Claude 3 Haiku.

CREATE FUNCTION invoke_titan (request_body TEXT)
RETURNS TEXT
ALIAS AWS_BEDROCK_INVOKE_MODEL
MODEL ID 'amazon.titan-text-express-v1'
CONTENT_TYPE 'application/json'
ACCEPT 'application/json';

CREATE FUNCTION claude3_haiku (request_body TEXT)
RETURNS TEXT
ALIAS AWS_BEDROCK_INVOKE_MODEL
MODEL ID 'anthropic.claude-3-haiku-20240307-v1:0'
CONTENT_TYPE 'application/json'
ACCEPT 'application/json';

Casos de uso

Para ilustrar los patrones usé el dataset público de películas de IMDb, que incluye títulos, calificaciones, géneros e información de personas.

Insights de cultura pop

El primer caso fue generar análisis culturales sobre películas de los 90s. Un stored procedure itera sobre las películas más populares de la década, construye un prompt con el título, año y géneros de cada una, lo pasa a Claude 3 Haiku vía la función SQL, y guarda el resultado en una tabla de title_insights. El modelo recibe el contexto de que la película fue lanzada en los 90s y genera análisis sobre qué reflejaba sobre el momento histórico, qué tendencias capturaba y por qué resonó con su audiencia. Todo esto ejecutado desde un simple CALL generate_90s_insights().

Consultas en lenguaje natural

El segundo caso fue más interesante: un stored procedure natural_language_query recibe una pregunta en texto libre — por ejemplo, "Encuentra las 10 películas mejor calificadas de la década de 1990" — y hace dos cosas. Primero, le pasa esa pregunta a Bedrock junto con el schema de la base de datos como contexto, pidiendo que genere únicamente el SQL necesario para responderla. Segundo, ejecuta ese SQL generado dinámicamente con PREPARE y EXECUTE.

El truco está en el prompt engineering: hay que ser muy explícito en las instrucciones — solo SQL ejecutable, sin explicaciones, sin markdown, sin backticks — y luego limpiar la respuesta con REGEXP_REPLACE antes de ejecutarla. El resultado es que un usuario sin conocimiento de SQL puede hacer preguntas en lenguaje natural y obtener resultados reales de la base de datos.

Resumen de películas

El tercer caso fue enriquecimiento en batch: un procedimiento que toma películas sin resumen en la base de datos, construye un prompt con título, año y géneros, y le pide a Claude que genere una descripción breve. El resultado se guarda directamente con un UPDATE. Un CALL generate_movie_summaries() es todo lo que necesitas para enriquecer un catálogo entero.

Casos avanzados

Más allá de estos tres patrones básicos, la integración abre posibilidades más sofisticadas: análisis de query plans con sugerencias de índices, detección de anomalías en datos con propuestas de corrección automática, o análisis de evolución de schemas. En todos los casos el patrón es el mismo — datos de Aurora como contexto, Foundation Model como motor de razonamiento, resultado guardado de vuelta en la base de datos.

Mejores prácticas

Hay cuatro áreas que vale subrayar:

Safe defaults. Configurar defaults seguros tanto a nivel de base de datos como del cliente, para evitar que errores del modelo afecten datos críticos.

Chain of Transformations. Pensar en los flujos de enriquecimiento como cadenas de transformaciones explícitas: get_data() → enrich_with_ai() → validate_data() → store_in_db(). No mezclar estas responsabilidades en un solo procedimiento.

Prompt Engineering con templates. La calidad del output depende directamente de la calidad del prompt. Vale la pena invertir tiempo en construir plantillas bien estructuradas y reutilizables.

Caching, rate limiting y manejo de errores. Implementar caching inteligente para consultas similares, rate limiting para evitar resource exhaustion cuando el volumen escala, y manejo de errores robusto para cuando el modelo devuelve algo inesperado.

Observabilidad

Las métricas que más importan en este tipo de integración son:

Latencia de generación de prompts
Tasa de éxito y fallo de llamadas al LLM
Calidad de respuestas (requiere algún tipo de evaluación downstream)
Consumo de tokens y costos asociados
Cache hit/miss ratio

Consideraciones

El control de acceso a datos sensibles es una preocupación válida. Bedrock Guardrails y el abuse detection nativo son los mecanismos disponibles para esto. También hay que tener en cuenta las limitaciones inherentes de precisión de los modelos, que hacen necesario validar outputs antes de usarlos en decisiones críticas.

Para quienes prefieran alternativas open source, el patrón equivalente sería PostgreSQL o MariaDB conectado a LangChain, con LLaMA 2 o Mistral como modelo, y un Vector Store para búsqueda semántica. Es una arquitectura perfectamente válida, con más flexibilidad pero también más infraestructura que administrar.

Resumen

Este patrón es valioso por tres razones concretas: facilita el acceso a datos complejos sin mover nada fuera de la base de datos, puede incorporarse a infraestructuras Aurora existentes sin rediseño mayor, y aprovecha Foundation Models de clase mundial con la misma interfaz SQL que tu equipo ya conoce.

El código de la demo está disponible en GitHub bajo Amazon Bedrock and Aurora MySQL Integration.

AWS mas allá de la nube con IAM Anywhere y Amazon Verified Permissions

Franchesco Romero — Thu, 02 Apr 2026 18:46:26 +0000

Cuando hablamos de seguridad en AWS, la conversación casi siempre empieza y termina en IAM.

Pero hay un escenario que muchas organizaciones enfrentan y que no siempre tiene una respuesta obvia: ¿qué pasa cuando el workload que necesita acceder a recursos en AWS no vive dentro de AWS?

Hay compañías con regulaciones estrictas de seguridad y cumplimiento que mantienen parte de su infraestructura detrás de data centers propios o firewalls corporativos. Hay equipos en medio de migraciones o modernizaciones que todavía tienen servidores tradicionales que necesitan hablar con servicios en la nube. En todos estos casos, la solución más obvia — usar access keys — trae consigo una lista de problemas conocidos: pueden olvidarse, necesitan rotarse periódicamente, hay que controlar cómo se exponen, y las sesiones expiran de formas que a veces nadie monitorea. Sin mencionar que la trazabilidad de quién usó qué credencial y cuándo se vuelve una pesadilla de auditoría.

La respuesta que propusimos es IAM Roles Anywhere, un servicio que permite emitir credenciales temporales de AWS para cargas de trabajo que viven fuera de la nube, ya sean servidores bare metal, contenedores on-prem o cualquier aplicación corriendo en un data center corporativo.

El mecanismo de verificación se basa en certificados X.509 y PKI, lo que significa que en lugar de manejar access keys estáticas, estás manejando una infraestructura de confianza basada en certificados — algo que los equipos de seguridad entienden y controlan mucho mejor.

Primero, una Certificate Authority emite certificados para cada carga de trabajo, confirmando que son entidades reconocidas dentro de tu infraestructura.
Luego se configura un Trust Anchor en AWS que referencia esa CA — usando AWS Private CA es la ruta más integrada, aunque también puedes usar Let's Encrypt u otra CA pública si entiendes las implicaciones de a quién le estás otorgando confianza.
Finalmente, cuando una carga de trabajo necesita credenciales, presenta su certificado firmado por la CA, firma la solicitud con su llave privada, y AWS devuelve credenciales temporales para el IAM Role asociado.
Todo esto orquestado por el aws_signing_helper, el credential helper oficial que hace que el proceso sea transparente para tus aplicaciones.

En Terraform, la implementación se divide en tres recursos principales: la aws_acmpca_certificate_authority para levantar la CA privada, el aws_rolesanywhere_trust_anchor que la referencia y sirve como punto de confianza, y el aws_rolesanywhere_profile que define qué IAM Role puede ser asumido por qué carga de trabajo. El IAM Role en sí se configura de la misma forma que cualquier otro, con la diferencia de que el principal en el assume role policy es rolesanywhere.amazonaws.com y las acciones incluyen sts:SetSourceIdentity para mejor trazabilidad.

Una de las cosas que más me gusta de esta arquitectura es que el monitoreo queda completamente integrado con los servicios nativos de AWS. CloudWatch Metrics te da visibilidad sobre expiración de certificados e intentos de login fallidos.

CloudTrail registra todos los eventos relevantes de API. Y con EventBridge puedes construir automatizaciones sobre cualquiera de esos eventos — por ejemplo, una alerta cuando un certificado está próximo a expirar o cuando hay un patrón anómalo de intentos fallidos.

En cuanto a mejores prácticas, la recomendación central es tratar esto exactamente como tratas cualquier estrategia de IAM: un rol por carga de trabajo, mínimo privilegio, y roles exclusivamente asumibles por rolesanywhere para no abrir superficies de ataque innecesarias.

IAM Roles Anywhere como servicio no tiene costo — lo que sí tiene costo es AWS Private CA, que vale la pena evaluar contra alternativas como usar una CA pública, siempre considerando el modelo de confianza que eso implica.

También es importante configurar soporte para CRL (Certificate Revocation Lists) desde el principio, porque si un certificado se pierde o se compromete, necesitas poder revocarlo sin tener que reconstruir toda la cadena de confianza.