AWS · Infrastruttura · ficha YoctoIT

Elasticità

La elasticidad de verdad del cloud: balanceadores gestionados y capacidad que sigue la carga — la disponibilidad multi-AZ como configuración, no como proyecto.

FOCUS · ALTA DISPONIBILIDADMulti-AZ by design: la aplicación que sobrevive al fallo de un data center entero
Material YoctoIT para clientes y partners · AWS e i nomi dei servizi sono marchi di Amazon.com, Inc.
01 · Qué es

Elastic Load Balancing & Auto Scaling, en claro.

ALB para el tráfico HTTP moderno, NLB para el TCP intenso, Gateway LB para las appliances: los balanceadores de AWS son gestionados, escalan solos y distribuyen entre varias Availability Zones. Con los Auto Scaling Groups las instancias nacen y mueren siguiendo las métricas.

3 AZ
el mínimo sindical de nuestras arquitecturas: el fallo de zona no es un incidente
Health check
el tráfico va solo a quien está bien: el failover es automático
Cero pre-provisioning
la capacidad sigue la carga: sin hierro dimensionado para el pico
Icona ufficiale AWS — Elastic Load Balancing & Auto Scaling
ICONO OFICIAL AWS · Elasticità
02 · Cómo usarlo bien

Las cosas que marcan la diferencia.

El flujo del tráfico

Usuarios / aplicacionesla carga entrante
ALB · HTTP/S
NLB · TCP/UDP
Gateway LB
el balanceador correcto por protocolo
Target groups multi-AZlas instancias distribuidas entre zonas
Auto Scaling Groupscale-out en los picos, scale-in de noche
De la petición a la instancia, sin single points

Application Load Balancer

Routing por path y host, TLS gestionado, WAF integrable: el front-end de las aplicaciones web.

Network Load Balancer

Millones de conexiones a latencia mínima: el balanceador de las cargas TCP serias.

Políticas de escalado

Target tracking sobre las métricas correctas: la CPU no siempre es la que cuenta.

Warm pool & lifecycle

Instancias precalentadas y hooks de ciclo de vida: el scale-out listo incluso para los arranques lentos.

03 · En profundidad

ALB, NLB y el escalado que anticipa

ALB trabaja en L7 (routing por host/path, WebSocket, gRPC, OIDC integrado), NLB en L4 con millones de conexiones e IP estáticas, Gateway LB inserta appliances de seguridad en línea. El Auto Scaling group une health checks, warm pools y políticas: target tracking (mantén la CPU al 60%), step y predictive scaling que aprende los patrones. El secreto es el grace period correcto y AMI inmutables para escalar en segundos.

  • ALB L7 — routing por host/path/header, autenticación OIDC delante de las apps
  • NLB L4 — IP estáticas, TLS passthrough y millones de conexiones: la carga bruta
  • Target tracking — 'mantén la CPU al 60%': la política que se calibra sola
  • Predictive scaling — ML sobre los patrones históricos: la capacidad lista ANTES del pico
  • Warm pool — instancias preinicializadas: el scale-out en segundos, no minutos
  • Health check — ELB + EC2 combinados: el nodo enfermo sale antes de hacer daño
04 · Números y ciclo de vida

Los números que cuentan.

L4/L7
los dos planos: NLB para el tráfico bruto, ALB para lo aplicativo
60 s
el scale-out típico con AMI inmutables y warm pools
0
downtime en los deploys con rolling + connection draining
3 AZ
el estándar de distribución de los targets
La elasticidad es disciplina: imágenes inmutables, health checks honestos y políticas calibradas sobre TUS patrones — la configuramos y la ponemos a prueba.
05 · Casos de uso

Dónde rinde de verdad.

E-commerce bajo pico

El Black Friday sin dimensionar el año por un día: capacidad elástica y factura honesta.

API mission-critical

El backend que no conoce mantenimientos: rolling updates detrás del balanceador.

Batches nocturnos

Flotas que nacen a las 2 y mueren a las 5: el trabajo hecho, el coste a cero.

Diseñamos multi-AZ por defecto: el fallo de zona es un no-evento — y lo demostramos en las pruebas de failover.