Una factura de AWS rara vez crece por una sola gran decisión. Crece por muchas pequeñas: un servidor de pruebas que nadie apagó, un NAT gateway mal situado, registros que se conservan indefinidamente. Este artículo recoge las causas que encuentro con más frecuencia y las herramientas de AWS que muestran a dónde va el dinero.
Primero, saber a dónde va el dinero
Adivinar sale caro; AWS ofrece las herramientas para medir.
- AWS Cost Explorer desglosa los costes por servicio, cuenta, región y tipo de uso a lo largo del tiempo (documentación de AWS, en inglés).
- Las etiquetas de asignación de costes permiten repartir los costes por producto, equipo o entorno. Primero se etiquetan los recursos y después se activan las etiquetas en la consola de facturación (documentación de AWS, en inglés). Sin etiquetas se ve que los costes de computación han subido, pero no qué producto lo ha causado.
- AWS Budgets y Cost Anomaly Detection envían una alerta antes de que termine el mes, en lugar de una sorpresa al llegar la factura (Budgets, Cost Anomaly Detection, en inglés).
Las causas habituales
Recursos que ya nadie usa
Un servidor detenido sigue pagando sus discos. Un volumen EBS desconectado se factura hasta que se elimina (documentación de AWS, en inglés). Las instantáneas antiguas, los balanceadores de carga sin tráfico y las instalaciones de prueba olvidadas suman de la misma manera. Las direcciones IPv4 públicas también entran en esta lista: AWS cobra una tarifa por hora por cada dirección IPv4 pública, esté asociada a un recurso o no (AWS News Blog, en inglés).
Servidores y bases de datos sobredimensionados
Las instancias suelen dimensionarse para un pico que nunca llegó. AWS Compute Optimizer recomienda tamaños a partir del uso real (documentación de AWS, en inglés), y Cost Optimization Hub reúne estas recomendaciones de todas las cuentas y regiones (documentación de AWS, en inglés).
Entornos de pruebas que funcionan como producción
Los entornos de desarrollo y preproducción suelen estar en marcha día y noche, con el mismo tamaño que producción, aunque solo se usan unas horas al día. Un horario que los detenga fuera de la jornada laboral, instancias más pequeñas y menos réplicas fuera de producción están entre los ahorros más sencillos.
Tráfico de red: NAT gateways y transferencia de datos
- Un NAT gateway se factura por cada hora de funcionamiento y por cada gigabyte que procesa, sea cual sea el destino, incluido Amazon S3 en la misma región (precios de Amazon VPC, en inglés). Para S3 y DynamoDB, un punto de enlace de VPC de tipo gateway evita ese cargo (documentación de AWS, en inglés).
- El tráfico entre zonas de disponibilidad se factura; dentro de la misma zona es gratuito (AWS Architecture Blog, en inglés). Los servicios que se comunican mucho entre zonas lo hacen visible en la factura.
- La transferencia de datos hacia internet se factura por gigabyte a partir de un volumen mensual gratuito (precios de Amazon EC2, en inglés).
Almacenamiento que solo crece
- CloudWatch Logs conserva los registros de forma indefinida, salvo que se defina un periodo de retención para el grupo de registros (documentación de AWS, en inglés).
- En S3, las cargas multiparte incompletas siguen ocupando almacenamiento hasta que se cancelan; AWS recomienda una regla de ciclo de vida que las cancele (documentación de AWS, en inglés). Las reglas de ciclo de vida también pueden mover los datos antiguos a clases de almacenamiento más económicas.
- Los volúmenes EBS de tipo gp2 se pueden cambiar a gp3, que AWS cobra hasta un 20 % menos por gigabyte, sin desconectarlos (AWS Storage Blog, en inglés).
Precios bajo demanda para un uso estable
Los Savings Plans ofrecen precios más bajos a cambio de comprometerse a un nivel de uso constante durante uno o tres años (documentación de AWS, en inglés). Compensan cuando el uso es estable y está bien dimensionado; un compromiso adquirido antes de la limpieza consolida el despilfarro.
Clústeres de Kubernetes con capacidad de sobra
En Kubernetes, los nodos se dimensionan según lo que las aplicaciones solicitan, no según lo que usan. Las solicitudes (requests) que se fijaron con generosidad y nunca se revisaron dejan sin uso buena parte de la capacidad que se paga.
Por dónde empezar
- Active las etiquetas de asignación de costes y revise Cost Explorer por servicio y por etiqueta.
- Defina un presupuesto con alertas y active Cost Anomaly Detection.
- Elimine lo que no se usa, defina la retención de los registros y cambie los volúmenes gp2 a gp3.
- Ajuste el tamaño de servidores y bases de datos; solo después, valore los Savings Plans.
- Revise la arquitectura: rutas de red, entornos de pruebas y si varias nubes o cuentas podrían consolidarse.
Un ejemplo
En Talk-A-Bot, el mayor ahorro no vino de los ajustes finos, sino de la arquitectura: la plataforma y los proyectos de sus clientes estaban repartidos entre tres nubes, Google Cloud, Azure y AWS, y se consolidaron en una única plataforma en AWS sobre Kubernetes. Los costes de infraestructura bajaron un 77 %. Los detalles están en el caso práctico de Talk-A-Bot.
Cómo puedo ayudarle
Reviso los costes y la arquitectura, planifico el ahorro y la migración, los implanto como código y le entrego una infraestructura que su equipo puede gestionar. Los cambios en el código de la aplicación siguen en manos de sus desarrolladores.