Día 7: Alta Disponibilidad - Balanceo de Carga con Application Load Balancer (ALB)

2 minute read

⚖️ Día 7: Distribuyendo el Tráfico con ALB

En el Día 2 conectamos nuestra instancia directamente a internet usando una Elastic IP. Sin embargo, en el mundo real, no quieres que tus usuarios hablen directamente con el servidor. Hoy aprenderemos a configurar un Application Load Balancer (ALB), el componente que recibe el tráfico y lo reparte de forma inteligente.

¿Por qué usar un ALB en lugar de una IP directa?

Abstracción: Si tu servidor falla y creas uno nuevo, la URL del balanceador no cambia.
Health Checks: El ALB deja de enviar tráfico a servidores que están “enfermos”.
Seguridad: Tu EC2 puede estar en una red privada sin IP pública, recibiendo tráfico solo desde el balanceador.
Escalabilidad: Es la base para tener 2, 10 o 100 servidores atendiendo la misma web.

🛠️ El Código (CloudFormation)

Vamos a extender nuestro template del Día 2. Agregaremos el Balanceador, un Listener (el “oído”) y un Target Group (el “objetivo”).

1. El Target Group y Health Check

Aquí definimos a dónde debe ir el tráfico y cómo saber si el servidor funciona:

  MiTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: !Sub "${Environment}-TG"
      VpcId: !Ref VpcId
      Protocol: HTTP
      Port: 80
      TargetType: instance
      Targets:
        - Id: !Ref MyInstance1 # Primera instancia
        - Id: !Ref MyInstance2 # Segunda instancia
      HealthCheckProtocol: HTTP
      HealthCheckPath: /
      HealthCheckIntervalSeconds: 30

2. El Application Load Balancer (ALB)

Este es el recurso físico que vive en tus subnets públicas:

  MiLoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: !Sub "${Environment}-ALB"
      Subnets: 
        - !Ref SubnetId
        - !Ref SubnetId2 # El ALB requiere al menos 2 subnets en distintas AZ
      SecurityGroups:
        - !Ref ALBSecurityGroup
      Scheme: internet-facing

3. El Listener (Puerto 80)

Es la regla que dice: “Si alguien llega por el puerto 80, mándalo al Target Group”:

  ALBListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !Ref MiLoadBalancer
      Port: 80
      Protocol: HTTP
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref MiTargetGroup

📚 Conceptos Nuevos Explicados

1. Target Group (Grupo de Destino)

Es un inventario de servidores. En este post, solo tenemos una instancia (MyInstance), pero aquí es donde registrarías más servidores en el futuro.

2. Health Checks (Pruebas de Vida)

El balanceador envía un “ping” (por ejemplo, a la ruta /) cada 30 segundos. Si el servidor no responde con un código 200 OK, el ALB lo marca como Unhealthy y deja de enviarle usuarios.

3. Listener (Escuchador)

Es el proceso que verifica solicitudes de conexión. Puedes tener uno para el puerto 80 (HTTP) y otro para el 443 (HTTPS) en el mismo balanceador.

4. Seguridad en Capas

A diferencia del Día 2, ahora el tráfico fluye así: Usuario ➔ ALB Security Group ➔ ALB ➔ EC2 Security Group ➔ EC2 Esto permite que tu EC2 solo acepte tráfico que venga del balanceador, bloqueando cualquier otro acceso externo.

🚀 Cómo Desplegarlo

Para que el ALB funcione, asegúrate de pasarle dos IDs de Subnets diferentes (deben estar en distintas Zonas de Disponibilidad).

aws cloudformation update-stack \
  --stack-name Mi-Infra-Con-ALB \
  --template-body file://15-ec2-with-alb.yaml \
  --parameters \
    ParameterKey=VpcId,ParameterValue=vpc-xxxxx \
    ParameterKey=SubnetId,ParameterValue=subnet-111 \
    ParameterKey=SubnetId2,ParameterValue=subnet-222

📂 Código Adjunto

He actualizado el repositorio con el template que incluye la EC2 del Día 2 + el nuevo ALB: Ver archivo en GitHub

🎥 Video Tutorial

Mira el proceso paso a paso en video:

Rodrigo Salgado