Tabla de Contenidos
AWS posee un impresionante abanico de servicios que podemos emplear en un sinnúmero de cargas de trabajo diferentes. Esto nos permite implementar soluciones muy novedosas de una manera ágil y eficiente. Pero este poder conlleva consigo una gran responsabilidad; en esta ocasión, desde un punto de vista financiero.
En mi experiencia, uno de los comentarios más comunes que escucho cuando brindamos consultorías es:
La facturación mensual me está saliendo muy cara!
Las causas más usuales que he visto para esta realidad son:
Sobre Dimensionar
Esta es la causa más común que he observado y se da especialmente cuando se realizan una migración de una carga de trabajo que está en tierra y se pasa a AWS.
Normalmente el equipo a cargo de esa labor tiende a dimensionar de manera holgada las instancias de EC2 o de base de datos sin evaluar las diferencias que tienen respecto a una VM en EC2 o en RDS. Por ejemplo: en tierra cuentan con un VM de 16 cores y emplean una EC2 de 16 cores; pero no validan que esa VM en tierra usa un hardware que tiene muchos años de antigüedad o es obsoleto. Es muy probable que una EC2 con menor cantidad de vcores sería suficiente para lograr este objetivo.
Pero supongamos que es válido el argumento para minimizar un riesgo de subdimensionar una instancia. El problema radica en que migramos la carga de trabajo, vemos que todo funciona de maravillas y la dejamos así. Lo correcto es monitorear esas instancias o RDS y usando los elementos que ya nos brinda AWS -como el Cost Management o el Performance Insights- validar si están sobredimensionadas para proceder a hacer un proceso iterativo para seleccionar el tipo de instancia adecuada para cada caso de uso.
Errores de Configuración
En este apartado tenemos una multitud de posibles combinaciones; pero cada caso gira alrededor de un error de configuración que genera gastos innecesarios.
Tomemos este caso real: se tiene un grupo de escalamiento que dispone las instancias en las zonas de disponibilidad A, B y C. Estas instancias son expuestas a través de un balanceador de carga. Este balanceador esta configurado en las zonas de disponibilidad A y B.
El resultado de este error es que todas las instancias que el grupo de escalamiento crea en la zona de disponibilidad C jamás se van a usar; pero evidentemente si se van a facturar. Y posiblemente se tendrán que aprovisionar más instancias en A y B para poder afrontar la carga de trabajo que reciben.
Grupos de Autoescalamiento
Esta se puede ver como otro ejemplo del caso previo; pero esta tal su prevalescencia en diferentes consultorias realizadas que merece su propio apartado.
Este error se presenta cuando se crea un grupo de autoescalamiento en EC2; pero la política para incrementar o decrementar la cantidad de instancias esta ausente o carece de sentido.
Por ejemplo: se tiene como mínimo y máximo la misma cantidad de instancia; y esto nos lleva a que a lo largo del día la cantidad de ellas es siempre constante; aunque la carga real que reciben las instancias si es fluctuante.
Normalmente varios tipos de aplicaciones tiene sus picos operativos durante el día y tienden a decrecer en la noche o madrugada; es ahí donde la política de escalamiento entra en acción y de manera elástica incrementa o decrementa la cantidad de instancias durante el tiempo y esto nos genera un ahorro mensual.
Configuración de Lambdas
En el apartado de serverless la causa más común es tener funciones lambdas configuradas con una cantidad de memoria mayor a la que realmente necesitan.
Este efecto es especialmente notorio cuando se tienen miles o millones de llamadas sobre estas. Acá es recomendable que empleen una herramienta como el AWS Lambda Power Tuning de Alex Casalboni para buscar la configuración más conveniente.
Además, es importante revisar a nivel de código que elementos podemos optimizar; particularmente si nuestra función demora varios segundos en realizar el proceso que tiene a cargo.
Con el ajuste adecuado, se pueden lograr ahorros importantes en nuestras soluciones serverless que ejecutan sobre Lambda.
Configuración de ECS
Continuando con serverless y esta vez para el Elastic Container Service; el caso más habitual es cuando se definen tareas que sobredimensionan los requerimientos de CPU y RAM que se requieren o que se ven afectados por el error en los grupos de escalamiento descrito previamente.
Es recomendable monitorear los servicios que desplegamos en ECS de manera periódica; para evaluar si la configuración que empleamos es la adecuada. No es raro observar tareas con una definición de CPU elevada, con decenas o centenas de instancias en ejecución y un uso de CPU que no supera el 5%.
Volumenes GP2
En este caso, el problema es tener volúmenes de EBS del tipo gp2 y no haberlos migrado a gp3. No sólo logramos un mejor rendimiento a nivel de IO (3,000 IOPS sin importar el tamaño), sino que tenemos un 20% de ahorro en comparación con gp2.
Este escenario se encuentra de manera general cuando se desplegaron cargas en AWS previo al lanzamiento de gp3 y los equipos a carga de la gestión de la cuenta no se enteraron de esta posibilidad.
Tiene la ventaja que es trivial de aplicar y en mi experiencia no genera una pérdida de servicio en el proceso. No olviden revisar también los grupos de auto escalado y su definición; pues posiblemente también tengan definido gp2.
Instancias de Generaciones Previas
Va de la mano con el anterior, conforme AWS va lanzando nuevas familias de instancias o bien actualizaciones sobre las existentes (como de la C6g a la C7g) esto va acompañado de un mejor rendimiento y usualmente una mejora en el precio de las nuevas instancias.
Por tanto, hace mucho sentido hacer el cambio de instancia; pues no sólo tenemos un mejor rendimiento sino que además tenemos un ahorro en la facturación.
Servicios Sin Uso
Esta trampa se presenta cuando se tienen servicios desplegados en AWS que no se están usando del todo. Puede sonar poco plausible, pero me he encontrado con innumerables casos en donde un cliente ha dejado instancias de EC2 o clusters de RDS en ejecución porque hizo una prueba y olvidó borrarla.
Una variante de este error; es tener volúmenes de EBS sin uso o no asociados a ninguna instancia. De hecho la mejor práctica dicta borrarlos; no sólo por que incurren en un gasto mensual sino además porque pueden ser un riesgo de seguridad si almacenaron información sensible en ellos.
Y relacionado con este punto está el tener snapshots huérfanos; es decir, de instancias que ya habían sido borradas y que por tanto nos generan un gasto innecesario.
Lo anterior también se da al tener ELB sin uso o Elastics IPs no asociadas a una instancia. Se debe revisar que todo lo desplegado en la cuenta realmente este en uso. Una revisión de la factura mensual y el desglose de servicios usados nos sirve como guía inicial.
Ausencia de Planes de Ahorro
Este error es muy simple; tienes cargas de trabajo activas en AWS pero no has activado un Saving Plan o instancias reservadas. Acá se puede hacer uso de las recomendaciones que se brindan en el apartado de Billing de la consola de AWS, en donde se muestra el ahorro esperado que pueden tener en cada caso.
Conclusión
Este es un pequeño extracto de las causas más comunes para tener costos más altos en nuestra factura de lo que debería ser. Resumiendo siempre deben:
- Revisar el sobre dimensionamiento.
- Validar la configuración de nuestros servicios.
- Aprovechar las nuevas familias o servicios que se lanzan.
- Monitorear de manera activa tus gastos en servicios.
Espero que este artículo les haya sido de utilidad.
Inicia la conversación