Para empresas en AWS, o que migran a AWS desde otras nubes o desde sus propios servidores
Una factura de AWS más baja y una infraestructura cloud más sencilla
Los costes de la nube crecen sin hacer ruido: recursos que nadie apagó, servidores sobredimensionados, transferencias de datos que nadie previó, varias nubes donde bastaría una. Analizo a dónde va el dinero, planifico el ahorro y la migración, los implanto como código y le entrego una infraestructura que su equipo puede gestionar.
Situaciones habituales
La mayoría de los problemas de costes no son un gran error, sino muchos pequeños que se acumulan.
La factura no deja de crecer
El gasto sube mes a mes y nadie sabe a qué producto, equipo o entorno corresponde.
Varias nubes, varias facturas
Las cargas de trabajo están repartidas entre AWS, Azure, Google Cloud o servidores propios, cada uno con sus herramientas, contratos y conocimientos.
Los entornos de pruebas funcionan como producción
Desarrollo y preproducción están en marcha día y noche, con el mismo tamaño que producción, aunque solo se usan unas horas al día.
Infraestructura que nadie quiere tocar
Configurada a mano hace años, apenas documentada y, por tanto, arriesgada y cara de cambiar.
Kubernetes sin un plan
Los clústeres reservan mucha más capacidad de la que usan las aplicaciones, o ejecutan cargas que un servicio más sencillo resolvería.
Caso práctico: Talk-A-Bot
Talk-A-Bot Zrt., empresa de software de IA conversacional
2023–2025 · arquitecto de infraestructura cloud y responsable de la migración
Talk-A-Bot tenía su plataforma y los proyectos de sus clientes repartidos entre tres nubes: Google Cloud, Azure y AWS. Diseñé y llevé a cabo su consolidación en una única plataforma estandarizada en AWS, sobre Kubernetes (EKS).
- de ahorro en costes de infraestructura
- 77 %
- nubes consolidadas en una sola plataforma AWS
- 3 → 1
- menos incidencias operativas, gracias al autoservicio
- 50 %
El punto de partida
Tres proveedores de nube, cada uno con su configuración y su factura; despliegues que dependían de pasos manuales; y una plataforma de microservicios que debía seguir atendiendo a los clientes durante la migración.
Qué hice
- Diseñé la plataforma de destino en AWS EKS, con toda la infraestructura en Terraform y gestionada mediante Git
- Migré los proyectos de los clientes desde Google Cloud, Azure y AWS a la nueva plataforma, paso a paso
- Estandaricé los despliegues con Helm charts comunes, para que los equipos pudieran desplegar por su cuenta
- Cifré y autentiqué el tráfico entre servicios con Istio en modo mutual TLS estricto; secretos mediante External Secrets y políticas del clúster con Kyverno
- Implanté despliegues GitOps con ArgoCD y entornos de preproducción: entregas rápidas, repetibles y revisables
Tecnología
- AWS EKS
- Terraform
- Helm
- ArgoCD
- Istio
- Kafka
- Kyverno
- External Secrets
- GitHub Actions
Cómo se organiza el trabajo
Tres fases, cada una con un resultado por escrito. Después de cada fase, usted decide si continuar.
Revisión de costes y arquitectura
A dónde va el dinero, y por qué.
- Acceso de solo lectura a la facturación y a las cuentas de AWS
- Costes desglosados por servicio, entorno y equipo
- Una lista de ahorros, cada uno con su esfuerzo y su riesgo
- Observaciones de arquitectura y seguridad que afectan a los costes
Ahorro y migración
El plan, llevado a cabo como código.
- Primero lo inmediato: recursos sin uso, servidores bien dimensionados, horarios para los entornos de pruebas
- Descuentos por compromiso de uso (Savings Plans) cuando el consumo es estable
- Migración o consolidación en AWS, paso a paso
- Infraestructura en Terraform y despliegues mediante CI/CD
Traspaso y formación
Su equipo la gestiona y mantiene los costes a la vista.
- Documentación y una presentación guiada de la nueva infraestructura
- Presupuestos, alertas y etiquetas de asignación de costes, para detectar desviaciones a tiempo
- Formación para sus desarrolladores y su equipo de operaciones
- Opcionalmente, la gestión continua y revisiones periódicas de costes
Alcance y forma de trabajo
Primero, medir
Los ahorros se estiman a partir de sus propios datos de uso, no de reglas generales, y cada recomendación indica su esfuerzo y su riesgo.
Infraestructura como código
Los cambios pasan por Terraform y por el control de versiones: revisables, repetibles y documentados, sin pasos manuales pendientes.
Ubicación y horario
Desde Alicante (España), trabajo en remoto con equipos de toda Europa y de fuera de ella, en horario de Europa central (CET/CEST), en inglés o en español.
Confidencialidad y acceso
Antes de cualquier acceso a los sistemas se firma un acuerdo de confidencialidad. El acceso es el mínimo necesario y por tiempo limitado, y no se realiza ningún cambio en producción sin su autorización.
Fuera del alcance
- Desarrollo de software: escribir o reescribir el código de la aplicación. Si un cambio en el código ahorraría costes, lo describo y lo implementan sus desarrolladores.
- La reventa de capacidad de nube o de licencias, y cifras de ahorro prometidas antes de la revisión.
Trabajo como consultor independiente en infraestructura AWS, Kubernetes, CI/CD y controles de cumplimiento automatizados. Ver experiencia
Lecturas recomendadas
Preguntas frecuentes
¿Cuánto podemos ahorrar?
Depende de dónde se originen los costes, que es justo lo que muestra la revisión. El 77 % de Talk-A-Bot se debió a consolidar tres nubes en una; una única cuenta de AWS bien gestionada tiene menos margen. No doy una cifra sin haber visto los datos.
¿Necesita acceso a nuestra cuenta de AWS?
Para la revisión basta con acceso de solo lectura a la facturación y a las cuentas. Los cambios posteriores se hacen solo con su autorización y, siempre que sea posible, mediante infraestructura como código.
¿Va a cambiar nuestra aplicación?
No. Trabajo en la infraestructura: cuentas, redes, clústeres y despliegues. Si un cambio en la aplicación ahorraría costes, por ejemplo una caché u otra configuración de la base de datos, lo describo y lo implementan sus desarrolladores.
¿Necesitamos Kubernetes?
No necesariamente. Para unos pocos servicios, opciones gestionadas como Amazon ECS o AWS Lambda suelen ser más sencillas de gestionar. La revisión recomienda lo que encaja con la carga de trabajo y con el equipo.
Usamos Azure o Google Cloud. ¿Puede ayudarnos?
Sí, si se trata de trasladar las cargas de trabajo a AWS: la migración de Talk-A-Bot partía de ambas. El trabajo continuado lo centro en AWS.
¿Podrá nuestro equipo gestionar la infraestructura después?
Ese es el objetivo. El traspaso incluye documentación y formación, y la infraestructura utiliza herramientas muy extendidas, como Terraform, Kubernetes y GitHub Actions, en lugar de scripts a medida.
Solicitar una consulta
Describa brevemente su infraestructura: qué nubes utiliza, cuánto gasta aproximadamente y qué le preocupa (los costes, una migración o ambas cosas). No envíe contraseñas ni datos de acceso a través de este formulario.