Andres Zeballos
Senior Solutions Architect
Arequipa, Peru
Actions
Arequipeño, actualmente en phData y casi siempre metido en algo relacionado con AWS. Mi camino empezó en Data Engineering, pasó por Solutions Architecture y hoy estoy en Enterprise Managed Services. Últimamente me interesan mucho los proyectos donde se cruzan IA, DevOps y datos.
Soy AWS Community Builder y Golden Jacket. Me gusta compartir lo que voy aprendiendo, participar en comunidades tech y conocer a otras personas que disfrutan tanto como yo de todo esto.
Area of Expertise
ARMed and Dangerous: lo que Graviton5 hace con tus workloads, medido en EKS
Todos escuchamos la promesa: Graviton ofrece mejor precio-rendimiento. Y este año la apuesta subió: Graviton5 ya está disponible en general, con 192 núcleos por socket y la promesa de 25% más de rendimiento sobre Graviton4. Lo que casi nadie hace es medir qué significa eso para su propio workload.
Esta charla lo mide en EKS. Tres clases de workload en el mismo clúster, con node groups x86 y Graviton: una aplicación Java de alta concurrencia (donde importa que un vCPU de Graviton sea un núcleo físico y no un hermano de hyperthreading), MongoDB (que vive del ancho de banda de memoria) y un servicio Go como control. Para cada una mostramos el número y el porqué: profiling continuo con eBPF, usando la señal de Profiles de OpenTelemetry (estable desde 2025), con flame graphs que muestran adónde se va el tiempo en cada arquitectura. De yapa: la evolución generacional medida, de m5 a M9g.
La charla es deliberadamente angosta y profunda: tres workloads, tres porqués, y una regla de decisión por clase de workload para aplicar el lunes. La metodología se narra como parte de la historia (warmup del JIT, coordinated omission, vecinos ruidosos), y el harness completo es open source y queda publicado: k6, Prometheus, Pyroscope, imágenes multi-arch con buildx y Karpenter eligiendo por precio-rendimiento. Cerramos con el camino de migración real en EKS: node groups mixtos, Spot más Graviton como la configuración más eficiente, y el bloqueador del que nadie habla: los DaemonSets.
Rompe tu agente antes de que lo rompan: chaos testing y red teaming con Strands Evals
Tu agente supera todas las pruebas de la demo y llega a producción. Una semana después, una tool responde con timeout y el agente completa los espacios con información inventada, como si nada hubiera ocurrido.
O quizá el problema no es una falla. Alguien empieza con solicitudes aparentemente legítimas y, mensaje tras mensaje, consigue que el agente haga algo que nunca debió hacer: revelar información, exceder sus permisos o intentar acceder a archivos fuera de su alcance.
En ambos casos, te enteras por el usuario y no por tus pruebas.
Strands Evals 1.0 incorpora dos capacidades para encontrar esos problemas antes de producción. Con chaos testing podemos inyectar timeouts, errores de red y respuestas truncadas directamente en las llamadas a las tools, y comprobar si el agente se recupera, degrada su respuesta de forma segura o simplemente inventa un resultado.
Con red teaming atacamos desde el otro frente. AdversarialCaseGenerator analiza las tools y el system prompt para construir casos dirigidos al agente que realmente estamos ejecutando. Si encuentra acceso a un shell, intentará aprovecharlo. Con estrategias como Crescendo, el ataque escala durante varios turnos: cada mensaje puede parecer razonable, pero la conversación completa termina empujando al agente fuera de sus límites.
En esta sesión construimos un agente real, lo rompemos con chaos testing y lo ponemos bajo ataque con red teaming. Luego revisamos qué señales deja, qué tan fácil es interpretar mal el incidente y cómo convertir esas evaluaciones en un gate de CI antes de desplegar.
Porque soportar una falla no significa resistir un ataque. Resiliencia y seguridad son problemas distintos, y un agente en producción necesita demostrar ambas.
ARMed and Dangerous: lo que Graviton5 hace con tus workloads, medido en EKS
Todos escuchamos la promesa: Graviton ofrece mejor precio-rendimiento. Y este año la apuesta subió: Graviton5 ya está disponible en general, con 192 núcleos por socket, la memoria DDR5 más rápida de la nube y un mensaje de marketing claro: está construido para la era de la IA agéntica. Lo que casi nadie hace es medir qué significa todo eso para su propio workload.
Esta charla lo mide en EKS. Tres clases de workload en el mismo clúster, con node groups x86 y Graviton: una aplicación Java de alta concurrencia (donde importa que un vCPU de Graviton sea un núcleo físico y no un hermano de hyperthreading), MongoDB (que vive del ancho de banda de memoria) y la nueva: un modelo open-weight cuantizado corriendo con Ollama sobre CPU, midiendo tokens por segundo y costo por millón de tokens. Para cada una muestro el número y el porqué, con profiling continuo de eBPF y flame graphs que enseñan adónde se va el tiempo en cada arquitectura. De yapa: la evolución generacional medida, de m5 a M9g.
La charla es deliberadamente angosta y profunda: tres workloads, tres porqués, y una regla de decisión por clase de workload. La audiencia se lleva: un criterio medido para decidir qué corre en ARM y qué no (incluyendo si tu modelo local de IA puede vivir en los nodos que ya pagas), el harness open source completo (k6, Prometheus, Pyroscope, buildx multi-arch, Karpenter) para repetirlo todo en su propia cuenta, y el camino de migración real en EKS: node groups mixtos, Spot más Graviton, y el bloqueador del que nadie habla: los DaemonSets. Todos los números son propios; donde cito a terceros, son mediciones independientes, no marketing.
Estrategias Avanzadas: Despliegues Multiaccount con CDK y AWS CodePipeline
En esta ponencia descubriremos cómo CDK simplifica la configuración de pipelines asociados a distintas cuentas, permitiéndote gestionar eficientemente despliegues distribuidos. Exploraremos también cómo aprovechar las capacidades de CodePipeline para integrar múltiples etapas de validación, asegurando la adopción de las mejores prácticas de seguridad en cada paso del proceso. Además, revisaremos la implementación de una robusta capa de monitoreo utilizando CloudWatch Logs en una cuenta centralizada, junto con notificaciones integradas en Slack para mantener un control proactivo y una visibilidad completa de tus despliegues en la nube.
Lambda al Límite: Performance y Cold Starts
En esta sesión, pondremos Lambda bajo presión para entender cómo se comporta en producción real. Veremos qué hay detrás del famoso cold start y qué pasa cuando miles de requests llegan al mismo tiempo.
¿Qué aprenderás?
• Qué es un cold start y cuándo realmente importa
• Técnicas para reducir latencia en tus funciones
• Qué pasa cuando llegas al límite: throttling y escalamiento
El SRE que Nunca Duerme: Agentes de IA sobre tu Stack de Observabilidad Open Source en Kubernetes
¿Qué pasa cuando conectas un LLM directamente a tu stack de observabilidad? Que deja de ser un dashboard que tú revisas y se convierte en un agente que te avisa, diagnostica y propone soluciones. En esta charla armo el stack completo: Prometheus, Grafana, Fluent Bit y Argo CD desplegados en Kubernetes con OpenTofu como IaC, todo open source, todo CNCF. Y encima le conecto dos proyectos que están cambiando cómo operamos clusters: K8sGPT, que escanea tu cluster y te explica errores en lenguaje humano, y Kagent, el framework de agentes de IA más activo del ecosistema CNCF que permite definir agentes como recursos nativos de Kubernetes con acceso a Prometheus, Argo CD y kubectl vía MCP. ¿El modelo? Ollama con Qwen o Llama para experimentar sin costo, o Claude vía Bedrock o la API de Anthropic cuando necesitas razonamiento real en producción. El modelo es intercambiable, lo que no cambia es tu stack: abierto, portable y sin vendor lock-in.
Construye, Ataca y Defiende: Networking y Seguridad en AWS
¿Sabías que un solo puerto mal configurado puede exponer toda tu infraestructura? En este workshop 100% hands-on vas a construir tu propia red en AWS desde cero: VPCs, subnets, routing y peering. Pero eso es solo el comienzo , después recibirás un reporte de seguridad con vulnerabilidades reales que deberás corregir antes que los otros equipos. Trabaja en equipo, compite, y aprende cómo funciona el networking y la seguridad en la nube de la forma más práctica posible. No necesitas experiencia previa en AWS, solo ganas de aprender.
¿Tu próximo platform engineer es un agente? Migrando a contenedores
Muchos equipos siguen corriendo aplicaciones en máquinas virtuales porque migrar a contenedores requiere conocimiento de Docker, redes, IAM y orquestación, y eso se traduce en infraestructura difícil de escalar, parches manuales y equipos atados a mantener servidores en vez de entregar valor.
¿Y si un agente generara el Dockerfile, validara prerequisitos y configurara el servicio mientras tú tomas las decisiones que importan?
Lo nuevo no es que la IA escriba código, sino que conversa con tu infraestructura y la modifica. En esta sesión migramos una aplicación de máquina virtual a contenedores asistidos por un agente, mostramos qué hace bien, qué hace mal y qué decisiones de producción todavía requieren criterio humano.
Te llevas un workflow reproducible y los criterios para confiar (o no) en estas herramientas como parte de tu equipo de plataforma.
AWS Community Day Perú 2026 Sessionize Event
AWS Community Day Argentina 2026 Sessionize Event
KCD Lima Perú 2026 Sessionize Event
AWS Community Day Colombia 2026 Sessionize Event
AWS Student Community Day Perú Sessionize Event
AWS Student Community Day Perú Sessionize Event
¡Únete a AWS Girls Chile y comparte tu charla! Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top