¿Cómo funciona realmente el autoescalado y cómo lo ajustas?

Una política de escalado vigila una métrica y ajusta la capacidad hacia un objetivo, así que el target tracking mantiene la CPU media o las peticiones por instancia cerca de un punto fijado. Ajustarlo significa elegir una métrica que refleje la carga de verdad, contar con el tiempo de calentamiento de la instancia antes de que la nueva capacidad cuente, escalar hacia fuera rápido y hacia dentro despacio, y fijar un mínimo que cubra todas las zonas de disponibilidad. Añade capacidad programada para los picos predecibles, ya que el escalado reactivo siempre va por detrás.

Es un lazo de realimentación. Le das una métrica y un objetivo, compara y añade o quita capacidad para cerrar la brecha. La primera decisión es la métrica, y la CPU es el valor por defecto que muchas veces está mal, porque un servicio limitado por entrada y salida puede estar al treinta por ciento de CPU mientras su pool de conexiones está agotado. Las peticiones por instancia o la profundidad de la cola suelen ser una señal más fiel de la carga. Lo segundo es el retardo, y aquí es donde la gente se hace daño. Si una instancia tarda tres minutos en arrancar y pasar los health checks, entonces un pico que llega en sesenta segundos ya ha terminado antes de que llegue la ayuda, así que fijo un periodo de calentamiento para que las instancias nuevas no cuenten antes de estar listas, y preescalo por calendario para patrones predecibles como la avalancha de logins de las nueve de la mañana. Hago el escalado hacia fuera agresivo y el de hacia dentro suave, porque estar brevemente sobreaprovisionado es mucho más barato que una caída, y el flapping es peor que ambas cosas. Y el escalado hacia dentro necesita drenaje de conexiones, si no terminas una instancia a mitad de petición y los usuarios ven errores que parecen un bug.