.jpg)
Hace poco desplegué una demo pública en Cloud Run y en pocos días mi factura se disparó; la causa fue tráfico malicioso que mantenía conexiones WebSocket abiertas y consumía CPU de forma sostenida. Tras investigar registré patrones claros: muchas conexiones que nunca se cerraban, picos de concurrencia repetidos y direcciones IP dispersas, incluida actividad originada desde Polonia. La experiencia fue una lección práctica sobre cómo los modelos de consumo serverless pueden volverse costosos cuando una botnet encuentra una superficie expuesta.
Lo primero que aprendí es que bloquear dentro de la aplicación llega demasiado tarde. En plataformas como Cloud Run, el proceso de la aplicación se inicia cuando el handshake del WebSocket se completa, y ese tiempo ya se factura. Medidas a nivel de código, como comprobaciones de cabeceras o páginas de autenticación, reducen el riesgo funcional pero no evitan el coste asociado a la conexión inicial. Conviene separar el plano de control del plano de ejecución: una barrera que actúe antes de despertar el runtime.
Mi solución práctica fue colocar un proxy ligero delante del servicio que inspeccionara X-Forwarded-For y aplicara listas de bloqueo y límites de tasa antes de enrutar al backend. Elegí una opción de baja huella para mantener la eficiencia en un contenedor pequeño y configuré reglas que reconocieran el proxy interno de la plataforma como trusted proxy para leer correctamente la IP real del cliente. Con ese patrón, la mayor parte del tráfico malicioso recibe una respuesta 403 o es mitigado en el borde, lo que reduce de forma drástica el tiempo de CPU facturable en el servicio principal.
También evalué alternativas gestionadas: un firewall web o un load balancer con WAF son soluciones robustas pero implican coste fijo mensual que en mi caso superaba la alternativa de proxy embebido. Para equipos con necesidades empresariales diferentes, la decisión entre una solución integrada y una gestionada depende del volumen esperado, requisitos de cumplimiento y del presupuesto operativo. En escenarios multi-cloud, nuestros ingenieros recomiendan valorar arquitecturas equivalentes en servicios cloud aws y azure para comparar costes y capacidades nativas.
En el plano operativo desplegué varias medidas complementarias: alertas de facturación con umbrales bajos, límites de concurrencia por servicio, métricas de tiempo medio de conexión y reglas de rate limiting en el proxy. A nivel de detección añadí feeds básicos de reputación y reglas para patrones IPv6, porque las botnets modernas alternan entre familias de direcciones para dificultar el bloqueo por lista simple. Para visibilidad y análisis posterior integré paneles de monitorización y alertas que alimentan procesos de respuesta automática y dashboards de inteligencia de negocio.
Las lecciones técnicas se traducen en buenas prácticas que cualquier equipo que gestione demos públicas o APIs debería aplicar: no exponer directamente runtimes que mantienen conexiones largas, colocar control de acceso y límites en el borde, definir alertas de coste y usar proxies o servicios de WAF adecuados. Si se trabaja con aplicaciones a medida o se construyen agents IA que interactúan en tiempo real, estas defensas evitan sorpresas indeseadas en la factura y protegen la experiencia de usuario.
En Q2BSTUDIO acompañamos a clientes en este tipo de retos, desde la definición de arquitecturas seguras y eficientes hasta el desarrollo de software a medida con foco en escalabilidad y costes predecibles. Podemos diseñar la capa de borde que mejor convenga a cada caso y validar opciones entre soluciones embebidas o servicios gestionados. Si además su proyecto requiere análisis y visualización de datos operativos, integramos pipelines que alimentan cuadros de mando tipo power bi y servicios de inteligencia de negocio para tomar decisiones basadas en métricas reales.
Si su prioridad es endurecer la superficie ante ataques y realizar pruebas proactivas, ayudamos a establecer controles y pruebas de penetración adaptadas al entorno serverless y a implementar políticas de ciberseguridad que minimizan el impacto operativo. Para arquitecturas que combinan modelos de IA en producción, analizamos patrones de consumo y proponemos estrategias para que la inteligencia artificial aporte valor sin perjudicar el coste operativo. Más información sobre nuestras capacidades de seguridad está disponible en la página de ciberseguridad y pentesting y sobre opciones cloud en nuestros servicios cloud AWS y Azure.
Resumen de recomendaciones prácticas: aplicar filtrado previo al runtime, usar rate limiting y listas dinámicas, instrumentar alertas de coste, considerar soluciones gestionadas si la escala lo justifica y diseñar contenedores con un proxy de borde cuando el objetivo sea minimizar gasto sin perder la exposición pública. La reducción que logré fue significativa: una optimización bien planteada no solo mitigó la botnet polaca sino que transformó un gasto imprevisible en un coste controlado y sostenible.
