Definitivamente, el cloud público ha supuesto una revolución en la forma en la que vemos la IT: la capacidad que nos ha dado para experimentar sin necesidad de hacer una inversión inicial ha hecho posible muchos proyectos que de otra forma tan siquiera se hubieran probado. Por otro lado, su elasticidad nos ha permitido crear entornos resistentes a picos de carga imprevistos.
Pero esto ha venido acompañado de un pequeño problema: la gestión de costes variables. Cada elemento que arrancamos en un cloud público tiene un coste. Y cada cloud público tiene un esquema diferente de costes, ahorros, prepagos…
Con el objetivo de ahorrarnos algún susto, vamos a hablar de los principales “agujeros” por los que se nos puede ir el presupuesto en IT cuando trabajamos con cloud público.
Computación
En el Cloud Público, cada máquina virtual, base de datos, servidor de caché, etc… que tengamos levantado cuesta dinero. Contante y sonante. 0,07 Euros por hora puede no parecer mucho pero cuando lo contamos en un mes son 50 Euros.
Tener recursos sobredimensionados en un IaaS público también nos puede hacer perder dinero. Pensemos que los costes aumentan de forma lineal en base al tamaño de las instancias, por lo que reducir una máquina virtual al tamaño más pequeño nos ahorrará al menos la mitad de su coste.
No aprovechar donde sea posible las capacidades de cada proveedor para beneficiarse de su excedente de carga (spot instances, preemptive instances…) puede hacer que gastemos más dinero del necesario cuando podríamos estar pagando un 20-30% sobre el precio de tarifa.
Utilizar tarifas “on demand” para recursos que sabemos que van a estar vigentes durante un año o más, puede suponer un sobrecoste mínimo del 20% respecto a un recurso reservado.
Almacenamiento
El principal vampiro en esta área es el “snapshot olvidado”, la acumulación de los mismos puede engordar la factura mes a mes. Una mala o inexistente política de control de snapshots puede afectar a medio/largo plazo ya no solo en la factura, si no en la gestión de los recursos.
De la misma forma, nos podemos encontrar volúmenes abandonados que ya no se usan. Es importante configurar herramientas y alertas que nos informen de esta casuística, pues puede convertirse en un agujero negro en nuestra factura.
Para acabar, los tipos de disco también deben elegirse adecuadamente. No tiene sentido invertir en un disco con una capacidad de lectura/escritura elevadísima si el sistema no tiene apenas actividad.
Tráfico no previsto
Y no nos referimos a un pico de tráfico de clientes.
Nos referimos al tráfico que no sabíamos que valía dinero.
Por ejemplo, en AWS, el tráfico entre AZs cuesta dinero. ¿Cuánto dinero?
Según la documentación de AWS, el tráfico “Cross-AZ” cuesta 0,01$/GB “en cada dirección”, es decir, que cuesta 0,02$ / GB. Puede parecer poco, pero pensemos en componentes comunes:
- Clústeres de ElasticSearch con replicación multiAZ
- Despliegues de EKS (Kubernetes) multiAZ
- Despliegues de Kafka multiAZ
- …
¿Y la transferencia saliente? No sólo se refiere a lo que gastan los usuarios que visitan nuestras páginas web. Si hacemos llamadas a servicios de AWS usando las APIs públicas sin configurar el enrutamiento adecuadamente, acabaremos generando tráfico saliente. Como norma general podemos decir que todo lo que sale de un Internet Gateway en AWS se factura como tráfico saliente.
Llamadas a APIs al proveedor
Todos los proveedores de cloud público cobran de una forma o de otra por el acceso a sus APIs.
Tomemos por ejemplo S3:
- 0,005$ por cada 1000 peticiones PUT, COPY, POST o LIST
- 0,0004 por cada 1000 peticiones GET, SELECT
Que además varían en función del tipo de almacenamiento que se seleccione.
No sólo hay que tener en cuenta las peticiones que hace nuestra aplicación. Pensemos también en los sistemas de auditoría que nos dan los proveedores cloud, dónde almacenan sus resultados, y nos podremos encontrar con una desagradable sorpresa a final de mes.
PD: no sólo ocurre en AWS, en Google Cloud Platform, por ejemplo, tenemos el concepto de “Operations” en CloudStorage, con precios idénticos a los de S3.
¿Cómo evitar sustos?
Cuando se trata de elaborar presupuestos de sistemas desplegados en Cloud Público, lo mejor es conocer bien la arquitectura que se va a desplegar. Sea serverless, basada en VM’s, o mixta, cada elección tiene sus pequeños coladeros por donde céntimo a céntimo nuestra factura puede crecer.
La gestión de costes en cloud público es una tarea continua, que requiere dedicación y conocimiento. El uso de herramientas como los budgets (presupuestos) que los principales proveedores ponen a disposición de los clientes (y que, por cierto, también tienen coste en alguno de ellos), son sólo una forma de control, pero no la definitiva.
Hace falta comprender como infiere gastos cada servicio de cada proveedor para poder mantener el gasto a raya. Observar día a día como evoluciona el consumo de nuestras cuentas cuando hay nuevos despliegues y/o se usan nuevas tecnologías nos permite entender mejor como afectarán a los costes. Realizar pilotos con cuentas de prueba para medir que coste real tiene un sistema nos puede ahorrar sustos.
Tener en cuenta que cualquier herramienta que se integre con nuestro proveedor de cloud, incurrirá un gasto extra no previsto, también es una buena estrategia defensiva (Sí, plataformas de monitoring que os integráis con CloudWatch, os miro a vosotras)
En Teradisk contamos con un equipo de personas acostumbrado a realizar un seguimiento de costes e identificar gastos innecesarios, así como oportunidades de ahorro. Si os encontráis en la situación de tener los costes de AWS fuera de control, no dudéis en hablar con nosotros.
