Caso de Estudio
HAMS nos contactó con un brief de una línea: "Estamos pagando de más. ¿Pueden echar un vistazo?". Detrás de esa frase había una API serverless que llevaba años corriendo en producción, resolviendo geolocalización en tiempo real para múltiples sistemas del negocio. La factura crecía mes a mes, y nadie tenía un panorama claro de qué parte de la arquitectura era responsable.
Antes de tocar nada, Renaiss pasó las primeras semanas extrayendo métricas reales de producción, mapeando los factores de costo y construyendo un panorama preciso de cómo se comportaba realmente la API a escala. Esa etapa de diagnóstico fue todo el trabajo. Los números revelaron dos problemas completamente distintos: un costo que escalaba correctamente con el crecimiento del negocio, y una ineficiencia estructural que iba a seguir acumulándose sin importar qué más se optimizara.
CloudFront procesaba 1640 millones de requests por mes con un cache hit ratio del 97%. Reemplazarlo por el cacheo nativo de API Gateway — una opción aparentemente más simple — hubiera costado entre 5800 y 6475 USD por mes, sin contar la degradación de performance en distintas geografías. CloudFront se quedó. La dependencia de EFS, no. Cada invocación de Lambda montaba un volumen remoto para consultar la base de datos de geolocalización — 47 millones de veces por mes. Migramos la función a una imagen de container que empaqueta el código y la base de datos completa juntos. El I/O remoto desapareció del hot path, el tiempo de ejecución cayó 3×, y la línea de facturación dejó de acumularse. El ciclo de actualización diaria se preservó a través de un pipeline automatizado que reconstruye y despliega la imagen cada 24 horas.
CloudFront no era el problema. El diagnóstico mostró un cache hit ratio del 97% y una estructura de costos proporcional al crecimiento real del negocio. Tocarlo hubiera salido más caro.
Sacar la llamada de red a EFS del critical path eliminó el principal factor de latencia. La función ahora lee de un archivo local empaquetado en la imagen del container.
47 millones de invocaciones mensuales montaban un volumen remoto en tiempo de ejecución. Migrar a una imagen de container con la base de datos embebida eliminó por completo la línea de facturación de ETDataAccess-Bytes.
El ciclo de actualización se preservó sin la instancia EC2. Un pipeline reconstruye la imagen del container con la base de datos de geolocalización actualizada todos los días y la despliega automáticamente.
El ciclo de actualización se preservó sin la instancia EC2. Un pipeline reconstruye la imagen del container con la base de datos de geolocalización actualizada todos los días y la despliega automáticamente.
El engagement dejó a la vista un gap de observabilidad que no era visible en el brief original. Las alertas se implementaron antes del traspaso, no después del próximo incidente.
Diagnóstico de infraestructura
Extrajimos métricas reales de producción antes de hacer cualquier recomendación. Atribuir los costos correctamente requería entender los patrones reales de tráfico, el comportamiento del cache y la mecánica de facturación — no suposiciones sobre lo que la arquitectura debía hacer.

Análisis de los factores de costo
Aparecieron dos centros de costo separados, con causas raíz distintas. Distinguir entre un costo que escala correctamente y uno que se acumula de forma estructural determinó qué intervención tenía sentido y cuál hubiera sido un error.

Evaluación de CloudFront
Aparecieron dos centros de costo separados, con causas raíz distintas. Distinguir entre un costo que escala correctamente y uno que se acumula de forma estructural determinó qué intervención tenía sentido y cuál hubiera sido un error.

Migración de Lambda a imagen de container
Migramos la función Lambda de un paquete de deployment tradicional a una imagen de container que embebe la base de datos de geolocalización completa. El I/O remoto se eliminó del path de ejecución; el tiempo de ejecución cayó 3×.

Automatización de pipeline e IaC
El script de actualización basado en EC2 se reemplazó por un pipeline automatizado que reconstruye y despliega una nueva imagen de container todos los días. Todo el stack se importó a Terraform, y las alertas se implementaron antes del traspaso.

Cobertura de alertas implementada
El engagement dejó a la vista un gap de observabilidad que no era visible en el brief original. Las alertas se implementaron antes del traspaso, no después del próximo incidente.

Trabajamos sobre todo con bancos y empresas del mercado de capitales en proyectos de modernización tecnológica: infraestructura, sistemas core e incorporación de IA a procesos reales. También tomamos proyectos de otros sectores cuando la exigencia técnica es la misma — varios de los casos de esta sección lo son. En todos los casos, entramos como equipo técnico senior embebido, no como una mesa de soporte tercerizada.
Tenemos base en Rosario, Argentina, y trabajamos con clientes en toda Latinoamérica. Eso significa conocimiento directo del contexto regulatorio y operativo de la región — por ejemplo la normativa del BCRA para fintechs argentinas — y coordinación en el mismo huso horario, sin la fricción de trabajar con un equipo a 10 horas de diferencia.
Nuestro trabajo está en la intersección de infraestructura cloud, arquitectura de aplicaciones e IA: diseño de arquitectura cloud-native, automatización de infraestructura, plataformas, pipelines de datos e integración de GenAI. No hacemos soporte cloud genérico — construimos y operamos sistemas que necesitan escalar.
Nuestra mayor profundidad es en AWS. También trabajamos con Azure y GCP según el stack que ya tenga el cliente — el objetivo siempre es adaptarnos a tu entorno, no imponer un proveedor.
Sí — es uno de los problemas en los que más trabajamos. Modernizar una aplicación suele implicar alguna combinación de: separar un monolito en servicios, migrar a infraestructura cloud-native, reemplazar dependencias obsoletas o mejorar el pipeline de CI/CD para que el equipo entregue más rápido. Siempre arrancamos con un diagnóstico técnico antes de recomendar un camino.