En Buk adoptamos instancias AWS Spot para cerca del 80% de nuestra infraestructura, incluyendo ambientes productivos. Spot ofrece la misma capacidad que On‑Demand, pero a un precio variable sujeto a disponibilidad; cuando AWS necesita la capacidad, puede recuperar la instancia con un aviso breve.
¿Estamos pagando de más por ejecutar todo en On‑Demand o exponiéndonos de más al usar Spot sin control? ¿Qué decisiones técnicas y operativas tomamos en Buk para que Spot sea una ventaja y no un riesgo?
En Kubernetes (k8s) mitigamos los riesgos de Spot con prácticas de orquestación y diseño de aplicaciones. Los escenarios donde conviene y donde no, dependen de la tolerancia a fallas y de los SLOs: es posible capturar ahorros significativos sin sacrificar resiliencia ni la experiencia de usuario.
Spot aprovecha capacidad no utilizada de EC2 con un precio variable por tipo de instancia y zona de disponibilidad. No es necesario ofertar manualmente; si se desea, puede fijarse un precio máximo (por defecto, igual al de On‑Demand).
Cuando AWS requiere la capacidad, puede interrumpir una instancia con un aviso aproximado de dos minutos. Ese aviso llega como evento (EventBridge/CloudWatch) y vía IMDS; en Kubernetes, herramientas como Node Termination Handler permiten drenar el nodo a tiempo para minimizar impacto.
La facturación es por segundo (con mínimo de 60 segundos en Linux) al precio Spot vigente mientras la instancia está ejecutándose. Si la interrupción la inicia AWS, no se factura el tiempo restante desde el evento de recuperación; si la detención o terminación la hace el usuario, se cobra el tiempo efectivamente utilizado.
Además del cómputo, se siguen cobrando servicios asociados como volúmenes EBS, snapshots, transferencia de datos y Elastic IPs, cuyos precios no dependen de la tarifa Spot. Para mejorar la disponibilidad, conviene diversificar pools de capacidad usando múltiples familias y tamaños de instancia en varias AZ, lo que reduce la probabilidad de quedarse sin capacidad.
Para ilustrar órdenes de magnitud, supongamos:
m6i.large (2 vCPU, 8 GiB) en us-east-1.Horas de instancia totales en el mes: 10 nodos × 720 h = 7.200 h.
Resultado: ahorro estimado ≈ 62,8 % frente a solo On‑Demand.
Notas:
Spot es ideal para APIs stateless, servicios idempotentes, procesamiento batch y ETL, workers de colas, pipelines de datos o trabajos de render e inferencia offline. Estos escenarios toleran reintentos y reprogramación, y suelen operar con SLIs que admiten pequeñas variaciones durante eventos de interrupción controlada.
En cambio, suele evitarse —o combinarse con un porcentaje de On‑Demand— para bases de datos, colas autogestionadas y componentes stateful (con estado) de baja latencia o con ventanas de mantenimiento estrictas.
En Kubernetes configuramos pods y nodos para detectar y manejar interrupciones sin pérdida de información. Partimos con grupos de nodos mixtos, combinando On‑Demand y Spot según la criticidad de cada servicio, y con una diversificación real de familias y tamaños de instancia desplegados en varias zonas de disponibilidad para reducir la correlación de eventos. Esta mezcla nos permite mantener una base estable para componentes sensibles y, al mismo tiempo, capturar el ahorro con cargas tolerantes.
El escalado ocurre en dos capas. A nivel de infraestructura, Cluster Autoscaler ajusta la cantidad de nodos cuando hay pods en cola o nodos poco utilizados; a nivel de aplicación, HPA incrementa o reduce réplicas en función de métricas robustas para mantener el rendimiento deseado. Esta combinación ayuda a absorber picos mientras se mantiene el control de costos.
Para el manejo de interrupciones utilizamos AWS Node Termination Handler, que detecta el aviso y ejecuta un drenado (kubectl drain) con período de gracia. En los pods definimos terminationGracePeriodSeconds acordes a cierre seguro, configuramos probes de readiness y liveness, y agregamos hooks de preStop para concluir trabajos y vaciar buffers. Los jobs y consumidores de colas son idempotentes y pueden reanudar desde checkpoints, minimizando reprocesamientos y pérdida de datos. En servicios HTTP, el preStop retira la instancia del balanceador y espera a que finalicen las solicitudes en curso.
En cuanto a colocación, usamos Taints/Tolerations y reglas de Affinity/AntiAffinity para separar servicios críticos de procesos de background; los componentes stateful y de baja latencia se anclan a On‑Demand o a grupos con mayores garantías. En persistencia evitamos bases de datos sobre Spot y favorecemos servicios administrados, o arquitecturas híbridas cuando corresponde.
La operación diaria se apoya en observabilidad y procesos claros. Seguimos métricas de autoscaling (autoescalado), tasas de interrupción, latencia y errores con Prometheus, Grafana y Mimir, organizando dashboards por tipo de carga para detectar patrones. Alertamos por colas de trabajo en crecimiento, errores de reintento inusuales y tiempos de drenado que exceden el período de gracia.
Desde el punto de vista de confiabilidad, definimos SLOs y, cuando aplica, SLAs que incorporan la naturaleza de Spot. Controlamos el error budget para decidir ajustes en la mezcla Spot/On‑Demand y para priorizar mejoras cuando un servicio consume el presupuesto más rápido de lo esperado.
Mantenemos runbooks para eventos de interrupción y validamos continuamente, en CI/CD, que los chequeos de readiness, los fallbacks y los mecanismos de reintento respondan como se espera. Los ejercicios de publicación incluyen verificaciones de que los hooks de apagado se ejecuten en el tiempo previsto y que los consumidores sean realmente idempotentes.
Si bien el uso de instancias Spot implica riesgos, estos se mitigan con una estrategia técnica y operativa consistente:
preStop, más aplicaciones idempotentes con checkpoints para reanudar trabajo.Las instancias Spot permiten ahorros sustanciales —en algunos casos, reducciones cercanas al 90 % del costo de cómputo—, a cambio de operar con capacidad variable y posibles interrupciones. En Buk, sobre Kubernetes, se combinan diversificación de capacidad, autoscaling, drenado controlado y prácticas de resiliencia a nivel de pod para mantener estabilidad operando cerca del 80 % en Spot. El balance entre costo y confiabilidad depende de la tolerancia a fallas de cada servicio y de sus SLOs.