Caso de éxito
Digiventures migra a Amazon EKS multi-cuenta y proyecta un ahorro de alrededor del 40%
Resumen
Digiventures ofrece soluciones de onboarding digital y captación de leads a instituciones financieras. Su arquitectura, en una única cuenta root y fuera de las buenas prácticas de AWS, generaba riesgos operativos y financieros. En 4 meses, Craftech migró sus microservicios a Amazon EKS en una arquitectura multi-cuenta, con un ahorro proyectado de alrededor del 40% y despliegues más rápidos.
~40%
de ahorro proyectado
1–2 min
de despliegue de APIs (antes, 5–6 min)
3–4 min
de despliegue de frontends (antes, 6–7 min)
Digiventures ofrece soluciones de onboarding digital y captación de leads a instituciones financieras, como bancos y empresas de factoring, para digitalizar la adquisición de clientes.
Solución implementada
- Diseñó una arquitectura multi-cuenta y EKS según el AWS Well-Architected Framework, con entornos PRD, STG y QA segmentados
- Migró los microservicios desde Elastic Beanstalk, Lambdas y EC2 a Amazon EKS
- Implementó redes privadas con acceso solo por VPN, sin exposición pública innecesaria
- Implementó GitOps con ArgoCD para ganar control, visibilidad y rollbacks rápidos
- Sumó observabilidad con Grafana, Prometheus y Loki
- Definió como código la mayoría de los recursos, listos para replicación y planes de DRP
Desafío de negocio
La arquitectura de Digiventures estaba fuera de las buenas prácticas de AWS, lo que generaba riesgos operativos y financieros. Todo estaba en una única cuenta root, con QA, staging y producción expuestos a impacto cruzado, accesos no controlados y poca trazabilidad. Había recursos críticos expuestos innecesariamente a internet. Elastic Beanstalk y EC2 implicaban un gasto mensual elevado y despliegues lentos, de 5 a 7 minutos, con poca visibilidad. Además, había limitaciones para escalar horizontalmente.
Solución
En 4 meses, Craftech migró los microservicios (desde Elastic Beanstalk, Lambdas y EC2) a una arquitectura multi-ambiente y multi-cuenta en Amazon EKS, diseñada según el AWS Well-Architected Framework, con los entornos PRD, STG y QA segmentados. Los recursos quedaron en redes privadas con acceso solo por VPN, sin exposición pública innecesaria. Implementó GitOps con ArgoCD para ganar control, visibilidad y rollbacks rápidos, y observabilidad con Grafana, Prometheus y Loki. La mayoría de los recursos quedaron definidos como código, listos para replicación y planes de DRP.
Resultados
- Ahorro proyectado de alrededor del 40%, con ROI proyectado en 4 meses una vez completada la baja de la infraestructura anterior
- Despliegue de APIs de 5–6 minutos a 1–2 minutos y de frontends de 6–7 minutos a 3–4 minutos
- Sin riesgo de impacto cruzado ni exposición pública de servicios: mejor seguridad y gobernanza
- Plataforma en Amazon EKS lista para escalar y para futuras optimizaciones, como instancias ARM y políticas de apagado
Stack & tecnologías
¿Tu equipo enfrenta un desafío parecido?
Pide un assessment gratuito de costos y arquitectura en AWS.