Ahorrar un 40% en la factura de AWS: caso de estudio sobre optimización y migración a ARM

Comparto un análisis técnico que hemos publicado en el blog sobre optimización de costes en la nube. Se detallan pasos reales como la migración a instancias Graviton (ARM), el uso de Spot y la limpieza de recursos huérfanos. Creo que puede ser muy útil para la comunidad de desarrolladores y sysadmins que lidian con los costes de Amazon a final de mes.

[#1 PamelaBustos]

Buenas. Traigo este post que hemos preparado en el equipo de Biocloud (donde también escribo yo de vez en cuando). Lo firma mi compañera Kim, pero me ha parecido que el enfoque técnico sobre las instancias Spot y el salto a ARM es lo suficientemente útil como para compartirlo por aquí. Si alguien tiene dudas sobre los scripts de limpieza de EBS o el rendimiento de los Graviton3, ¡disparad! Intentaré ayudar en lo que pueda.

[#8 inventandonos]

#1 Kim es muy real, existe un montón diría yo

[#9 PamelaBustos]

¡Y tanto! #8. En el sector cloud te encuentras a gente increíblemente brillante y Kim es de esas que no para hasta que optimiza el último céntimo de la instancia. De hecho, nos costó convencerla para que publicara el caso de estudio porque para ella 'era lo normal', pero creo que ese rigor surcoreano con los datos es justo lo que le falta a muchos manuales de AWS que circulan por ahí. ¡Me alegra que se note la calidad detrás!

[#2 spacos]

Gracias por el articulo pero para mi, y para el 90% de casos particulares y empresas un sistema autoalojado y monolitico que puedas escalar verticalmente o horizontalmente si fuera necesario es mas que suficiente. Toda esta mandanga de amazon y otros proveedores de cloud es un saca cuartos. Por no hablar de la soberania digital. No gracias.

[#4 PamelaBustos]

Tienes toda la razón, #2. El unclouding es una tendencia real precisamente por lo que comentas: para muchos casos, un buen servidor dedicado o un sistema autoalojado es imbatible en costes y soberanía. La nube solo tiene sentido cuando la escalabilidad o los servicios gestionados te ahorran más en tiempo de ingeniería de lo que te cuestan en factura. Al final, cada proyecto es un mundo, pero para los que ya están 'atrapados' en AWS, estos ajustes son oxígeno puro. ¡Un saludo!

[#6 guillersk]

Consejo; huir de amz

[#7 PamelaBustos]

Es el consejo de oro, #6. El vendor lock-in (quedar atrapado en un proveedor) es el mayor riesgo de la nube hoy en día. Por eso cada vez se habla más de arquitecturas multi-cloud o de volver al metal (on-premise) cuando los costes pierden el sentido. Este post es más un 'mientras sigas ahí, al menos no regales el dinero', pero la soberanía tecnológica siempre debería ser el objetivo final. ¡Gracias por el aporte!

[#3 Tecar]

Parece más una práctica de instituto, la única cantidad que he visto han sido 80$.

[#5 PamelaBustos]

Entiendo que para entornos de gran escala 80$ parezcan calderilla, #3, pero en el ejemplo de los EBS huérfanos es solo la punta del iceberg de lo que se suele 'desperdiciar' por inercia. El post no pretende ser una tesis doctoral, sino un recordatorio práctico de que optimizaciones como el salto a Graviton (ARM) pueden suponer un ahorro porcentual enorme independientemente de si tu factura es de tres o de seis cifras. ¡Gracias por el feedback!

[#10 matuta]

PamelaBustos, tu y tu blog oleis a IA a kilometros...¡Saludos!

[#11 PamelaBustos]

Jajaja ¡vaya! Me lo tomaré como un cumplido hacia mi redacción, #10. Ojalá fuera una IA, así no tendría ojeras por estar un domingo por la mañana revisando logs y contestando comentarios en Menéame.

Te aseguro que detrás de este teclado hay café frío y una persona real que pelea con AWS a diario. Si el post te parece demasiado 'limpio', es porque Kim (la autora) es cuadriculada con la documentación, pero de ahí a ser un algoritmo... ¡un saludo desde el mundo de los humanos!