AWS cost optimization: 5 formas de ahorrar en AWS

La nube trae muchas ventajas, la mayoría de ellas relacionadas con la agilidad, flexibilidad y la posibilidad de pagar por lo que se usa y solamente cuando se usa. No obstante, si no se tiene un mínimo nivel de control, esas ventajas pueden tornarse en todo lo contrario, haciendo que los costes se disparen.

En este blog evaluaremos algunas de las formas de optimizar un ecosistema AWS de manera sencilla.

No hay optimización sin concienciación

En líneas generales, cuando se desea optimizar un sistema, lo más importante es ser consciente de cómo funciona dicho sistema, es decir, hemos de conocer la problemática que solventa, los elementos que lo componen, cómo es la interacción con los usuarios, etc.

Además, cualquier proceso de optimización necesita partir de un marco de trabajo que facilite entender los elementos optimizables del sistema, ya que, según el contexto, serán unos u otros los elementos que podemos modificar para adaptar el desempeño del sistema a nuestras necesidades de manera óptima.

Cuando hablamos de nube publica en general, y AWS en particular, ese marco de trabajo es precisamente el Well-Architected Framework, el cual nos invita a evaluar nuestro ecosistema AWS desde 6 pilares diferentes:

• Excelencia operacional
• Eficiencia de rendimiento
• Fiabilidad
• Optimización en Costes
• Seguridad
• Sostenibilidad

¿Cómo es un proceso típico de optimización?

Siempre decimos, y seguiremos diciendo, que cada cliente es único, ya que sus necesidades también lo son, por lo que la solución desplegada tanto en AWS como en cualquier otro sitio, inevitablemente, será única.

No obstante, sí que suele haber aspectos comunes a cualquier tipo de ecosistema cloud que, casi con total seguridad, aplican a la mayoría de las arquitecturas desplegadas en AWS.

En este blog veremos algunas optimizaciones que, con un nivel bajo de esfuerzo, pueden aportar a tu empresa una gran optimización del pilar de costes sin impactar en el resto de pilares.

A modo de resumen, algunos de los puntos más comunes son:

• Tiempo de levantamiento vs tiempo de uso de los servicios
• Dimensionamiento de los servicios
• Vías de aumento de rendimiento
• Uso óptimo de capas de almacenamiento
• Costes de tráfico

En los siguientes puntos iremos profundizando en cada uno de los aspectos anteriores de cara a entender las posibilidades de optimización económica que tenemos a nuestra disposición.

Tiempo de levantamiento VS Tiempo de uso de los servicios

Debido a la inercia del mundo On Premise, en el cual disponemos de servidores, licencias y datacenter propio o de un tercero, muchas compañías no se plantean los ahorros derivados de mantener levantados los entornos solamente cuando se usan.

El mejor ejemplo son los entornos no productivos, como los entornos de test, desarrollo o staging, los cuales no tiene sentido que estén levantados permanentemente (24x7) sino que deberán estar levantados cuando los equipos encargados de esas tareas (test, desarrollo o staging) los usen.

Como referencia, es factible estimar ahorros de 70-75% al levantar los entornos no productivos en horario laboral (8x5) en lugar de mantenerlos en modo 24x7.

Incluso podemos ir más allá, levantándolos exclusivamente bajo demanda, con lo que el ahorro podría ser mucho mayor dependiendo del tiempo final de levantamiento.

Dimensionamiento de los servicios

Si bien el punto anterior nos ofrece un ahorro inmediato y de una manera muy sencilla, este punto es también uno de los que nos permiten una mayor optimización de costes con un menor esfuerzo.

Básicamente, consiste en monitorizar y analizar si la cantidad de recursos asociados a un servicio, normalmente la capacidad de cómputo asignada a una instancia, tamaño de los volúmenes de disco, RAM, etc., es la necesaria para que ese servicio responda ante la carga de trabajo que se le exige.

De nuevo, en multitud de ocasiones vemos instancias sobredimensionadas en las que el uso medio está muy por debajo del 50% de la capacidad de la máquina, y adicionalmente los picos puntuales de uso no superan igualmente ese 50%.

En casos como este, optar por el shape (tamaño de máquina) inmediatamente inferior (mitad de vCPU) conlleva un ahorro de un 50% en la parte de computación (coste EC2), con lo que el impacto en la factura de final de mes resulta considerable.

Vías de aumento de rendimiento

Si bien el punto anterior hablaba de entornos sobredimensionados, este punto versa sobre todo lo contrario: ¿Qué hacer cuando la capacidad de la instancia actual no es suficiente y ha de aumentar?

Una solución que vemos comúnmente es irse a un shape mayor (con lo que el coste de computación se duplica), pero ¿es realmente la cantidad de vCPU lo que hace que el rendimiento no sea suficiente?

En esta situación, desde Neteris siempre nos planteamos la búsqueda del elemento que está provocando que el rendimiento no sea el necesario, y no solamente se trata de vCPU, sino de otros elementos como cantidad de RAM o IOPS de disco.

Por ejemplo, nos encontramos situaciones en las que una instancia RDS Oracle no rinde lo suficiente a causa de que el volumen asignado supone un cuello de botella, generando unos tiempos de espera demasiado altos.

En esta situación, la vCPU está ociosa, con lo cual no solucionamos nada duplicándola. Por tanto, la primera acción es incrementar la capacidad en IOPS de los volúmenes asignados, buscando el equilibrio entre coste y rendimiento.

A modo de ejemplo, solemos encontrarnos casos en los que un aumento de las IOPS de almacenamiento supone un incremento de un 10-15% de costes, mucho menor de lo que supondría ir a un shape superior, lo cual duplicaría el coste.

Uso óptimo de capas de almacenamiento

Hablar de Amazon S3 es hablar de almacenamiento de objetos, imágenes, documentos, backups… Es decir, información que, en muchas ocasiones, puede catalogarse como información fría, o como mínimo información que no es accedida frecuentemente.

Dependiendo del caso de uso, vemos que se hace una utilización más o menos óptima de este tipo de almacenamiento. De nuevo, en la mayoría de las ocasiones, vemos que hay una gran capacidad de optimización, ya que la información queda obsoleta cada vez con mayor rapidez, lo cual no significa que sea información eliminable, sino que debe ser almacenada en un tier de S3 que responda de manera óptima a los patrones de acceso del dato en cuestión.

Partiendo del coste de la capa estándar de S3, los ahorros que podemos lograr mediante la elección óptima de la capa S3 en la que alojar el dato en función de su tipología es considerable:

• Datos que se acceden infrecuentemente: ahorro de 45%
• Datos de archivo que necesitan un acceso rápido: ahorro de 85%
• Datos de archivo que hay que conservar por temas regulatorios o de auditoría y cuyo acceso es bastante improbable: ahorro de 95%

Costes de tráfico

Presentado en muchas ocasiones como uno de los grandes costes ocultos de la nube pública, el tráfico es uno de los elementos que solemos analizar en nuestras revisiones de la Well-Architected Framework desde Neteris.

Está claro que es difícil predecir el tráfico saliente de nuestra región, o incluso el tráfico entre datacenters (Availability Zones); sin embargo, sí que está en nuestra mano realizar optimizaciones de cara a que el coste sea el mínimo, impactando positivamente en otros pilares como veremos a continuación.

Como todos sabemos, AWS despliega sus regiones con un mínimo de 3 datacentes (AZ) de cara a habilitarnos el despliegue de arquitecturas en alta disponibilidad. No obstante, si desplegamos una carga de trabajo en base a servicios repartidos por diferentes AZ, incurriremos en costes de tráfico entre AZ, con lo que, a nivel de arquitectura, debemos elegir bien donde desplegar los servicios que pertenecen a una misma carga de trabajo para reducir dichos costes.

Puesto que este blog trata de aproximar las formas sencillas de optimización, y el punto anterior requiere una revisión más profunda a nivel de arquitectura, nos centraremos en cuál es la manera óptima de comunicación entre servicios gestionados en AWS. Esto puede ser comunicación de una instancia EC2 con Amazon S3 o del servicio gestionado de contenedores (Amazon ECS) con el servicio gestionado de registro de contenedores (Amazon ECR).

En muchas ocasiones nos encontramos que, de cara a comunicar servicios sin salida directa a internet (al estar en subredes privadas, una instancia EC2 por ejemplo) con servicios que disponen de un endpoint público (S3 por ejemplo), el tráfico se dirige a través del Servicio NAT. Situación similar suele producirse cuando ECS habla con ECR para la recuperación de imágenes Docker.

Una alternativa a esta arquitectura es la utilización de VPC Endpoints. Los cuales, además de mantener la comunicación privada al utilizar solamente la red privada de AWS y no salir hacia la internet pública (lo cual aumenta el nivel de seguridad), supone un coste de procesamiento de tráfico 4 veces inferior al coste de procesamiento de tráfico en el NAT, con lo que tenemos un ahorro del 75% en procesado de tráfico.

Conclusión

En este blog hemos visto 5 maneras de optimizar los costes en AWS, pero son solamente algunos de los ejemplos más sencillos que podemos encontrarnos comúnmente.

Desde Neteris realizamos este tipo de estudios con el objetivo de optimizar no solamente el pilar de costes, sino el resto de pilares, especialmente la seguridad, la eficiencia de rendimiento y la fiabilidad.

Te invitamos a que agendes reserves un hueco para que podamos comentar cómo podríamos ayudarte a realizar este análisis en tu infraestructura, y calcules tu potencial ahorro.