DEV Community

Cover image for SAA-Lab1 — Scaling en AWS (baseline): ALB + Auto Scaling + CloudFront
Luis Eduardo Lunar Guevara
Luis Eduardo Lunar Guevara

Posted on

SAA-Lab1 — Scaling en AWS (baseline): ALB + Auto Scaling + CloudFront

#aws #cloudskills #tutorial #cloudfront

Región: us-east-1

Duración estimada: 35–55 minutos

Costo-riesgo: Medio

Certificación: AWS Certified Solutions Architect - Associate (SAA-C03)

Dominio: Design Secure Architectures

Tarea 1.2: Design secure workloads and applications

Caso de uso

La plataforma de Digital Café Luna venía bastante estable… hasta que se les ocurrió hacer un evento especial de fin de semana. El tráfico sube, la aplicación empieza a sentirse lenta y Camilo se da cuenta que una sola instancia no es suficiente.

La Sra. Blanca no entiende de escalamiento vertical y horizontal, ella solo quiere algo:

“Que el sistema no se caiga justo cuando más estamos vendiendo.”

Este laboratorio es el salto de un servidor único a un baseline más realista: Application Load Balancer, Auto Scaling Group y CloudFront trabajando juntos para absorber variaciones de tráfico.

No vamos a montar una arquitectura perfecta y mucho menos lista para producción.

¿Qué vamos a construir?

En este laboratorio vas a crear:

  • Un Application Load Balancer como punto de entrada.
  • Un Target Group para enrutar tráfico hacia instancias EC2.
  • Un Launch Template con una app básica en NGINX.
  • Un Auto Scaling Group con capacidad mínima distribuida en dos subnets.
  • Una distribución de CloudFront apuntando al ALB.
  • Validaciones del flujo Usuario → CloudFront → ALB → EC2.
  • Cleanup completo.

Diagrama SAA-Lab1 — ALB + Auto Scaling + CloudFront

Figura 1 — CloudFront recibe la solicitud, la envía al ALB y el ALB distribuye tráfico hacia instancias EC2 administradas por Auto Scaling.

Nota de alcance

Usaremos la default VPC para hacer las cosas mas simple y enfocarnos en el objetivo principal.

En labs posteriores podemos madurar esto con SSM Session Manager, HTTPS end-to-end, WAF y controles más finos. Por ahora queremos entender el flujo base y verlo funcionando.

Ojo: en este baseline el ALB seguirá siendo público. CloudFront estará delante, pero no vamos a restringir todavía el ALB para aceptar tráfico únicamente desde CloudFront.

Convención de nombres

Recurso Nombre
ALB saa-lab1-alb
Target Group saa-lab1-tg
Launch Template saa-lab1-lt
Auto Scaling Group saa-lab1-asg
Security Group ALB saa-lab1-alb-sg
Security Group App/EC2 saa-lab1-app-sg
CloudFront Distribution saa-lab1-cf
Tag estándar Name=<recurso> y Lab=saa-lab1

Requisitos previos

  • Región us-east-1.
  • Permisos para EC2, Load Balancing, Auto Scaling y CloudFront.
  • Default VPC disponible.
  • Acceso a AWS Console y CloudShell o AWS CLI local.

Paso 1 — Identificar VPC y subnets

Necesitamos una VPC y al menos dos subnets en AZ distintas.

En AWS Console:

  • Ve a VPC → Your VPCs.
  • Verifica que estás en us-east-1.
  • Usa la Default VPC.
  • Ve a VPC → Subnets.
  • Identifica dos subnets en AZ distintas, por ejemplo us-east-1a y us-east-1b.

Checkpoint

Valida que:

  • Tienes una VPC en us-east-1.
  • Identificaste dos subnets en AZ distintas.

Paso 2 — Crear Security Groups

Crearemos dos Security Groups: uno para el ALB y otro para las instancias de aplicación.

Desde la consola

Security Group del ALB

  • Name: saa-lab1-alb-sg
  • Inbound: HTTP 80 desde 0.0.0.0/0
  • Outbound: default
  • Tags: Name=saa-lab1-alb-sg, Lab=saa-lab1

Security Group App/EC2

  • Name: saa-lab1-app-sg
  • Inbound: HTTP 80 desde el Security Group del ALB
  • Outbound: default
  • Tags: Name=saa-lab1-app-sg, Lab=saa-lab1

Mosca con esto: las instancias no deben recibir HTTP directo desde Internet, el tráfico debe entrar por el ALB.

Security Group del ALB
Figura 2 — Security Group del ALB.

Security Group App/EC2
Figura 3 — Security Group App/EC2.

Checkpoint

Valida que:

  • El ALB SG permite HTTP desde Internet.
  • El App SG permite HTTP solo desde el SG del ALB.

Paso 3 — Crear Target Group, Launch Template y Auto Scaling Group

El ALB enruta tráfico hacia un Target Group. El Auto Scaling Group registra ahí sus instancias.

Crear Target Group

En AWS Console:

  • Ve a EC2 → Target Groups → Create target group.
  • Target type: Instances
  • Name: saa-lab1-tg
  • Protocol/Port: HTTP : 80
  • VPC: default VPC
  • Health check path: /
  • Tags: Name=saa-lab1-tg, Lab=saa-lab1

Target Groups
Figura 4 — Target Groups.

Crear Launch Template

En EC2 → Launch Templates → Create launch template:

  • Name: saa-lab1-lt
  • AMI: Amazon Linux 2023
  • Instance type: t3.nano o t3.micro
  • Key pair: None
  • Subnet: Don’t include
  • Security group: saa-lab1-app-sg
  • Auto-assign public IP: Enable
  • Tags: Name=saa-lab1-lt, Lab=saa-lab1

User data:

#!/bin/bash
set -euo pipefail
dnf -y update
dnf -y install nginx

cat > /usr/share/nginx/html/index.html << HTML
<!doctype html>
<html>
<head><meta charset="utf-8"><title>Digital Cafe Luna</title></head>
<body>
<h2>Digital Cafe Luna - OK</h2>
<p>Host: $(hostname)</p>
<p>Time: $(date -u)</p>
</body>
</html>
HTML

systemctl enable --now nginx
Enter fullscreen mode Exit fullscreen mode

Launch Templates
Figura 5 — Launch Templates.

Crear Auto Scaling Group

En EC2 → Auto Scaling groups → Create:

  • Name: saa-lab1-asg
  • Launch template: saa-lab1-lt
  • VPC: default VPC
  • Subnets: dos subnets en AZ distintas
  • Attach to load balancer: Existing target group → saa-lab1-tg
  • Health checks: ELB
  • Grace period: 60–120s
  • Desired: 2
  • Min: 2
  • Max: 4
  • Tags: Name=saa-lab1-asg, Lab=saa-lab1

Auto Scaling groups
Figura 6 — Auto Scaling groups.

Checkpoint

Valida que:

  • El ASG tiene dos instancias.
  • El Target Group muestra targets healthy.
  • Las instancias solo reciben HTTP desde el ALB SG.

Paso 4 — Crear el Application Load Balancer

Ahora crearemos el ALB, que será el origin de CloudFront y distribuirá tráfico al Target Group.

En AWS Console:

  • Ve a EC2 → Load Balancers → Create load balancer.
  • Selecciona Application Load Balancer.
  • Name: saa-lab1-alb
  • Scheme: Internet-facing
  • IP address type: IPv4
  • VPC: default VPC
  • Mappings: dos subnets en AZ distintas
  • Security Group: saa-lab1-alb-sg
  • Listener: HTTP 80
  • Default action: Forward to saa-lab1-tg

Load Balancers
Figura 7 — Load Balancers.

Checkpoint

Valida que:

  • El ALB está Active.
  • El listener HTTP 80 envía tráfico a saa-lab1-tg.
  • El DNS del ALB muestra Digital Cafe Luna - OK.

Paso 5 — Crear CloudFront delante del ALB

Vamos a poner CloudFront delante del ALB para mostrar cómo una distribución global puede servir como entrada de la aplicación.

En este lab la carga no justifica CloudFront por sí sola, el objetivo de configurarlo es meramente didáctico.

Desde la consola

Ve a CloudFront → Distributions → Create distribution.

  • Plan: Pay as you go
  • Distribution name: saa-lab1-cf
  • Description: Digital Cafe Luna - scaling baseline
  • Distribution type: Single website or app
  • Domain: vacío, usaremos xxxxx.cloudfront.net
  • Origin type: Elastic Load Balancer
  • Origin: DNS del ALB
  • Origin protocol policy: HTTP only
  • HTTP port: 80
  • Cache settings: recommended/default
  • Security protections: deja lo incluido
  • Rate limiting: apagado para este lab

Ojo: Pay as you go no significa “gratis”. CloudFront puede generar costos por requests, transferencia y uso. Haz el cleanup y no pasa nada.

Ojo: HTTP only funciona porque el ALB escucha por HTTP. En producción, la mejora natural sería HTTPS end-to-end.

Checkpoint

Valida que:

  • La distribución pasa de Deploying a Enabled.
  • Tienes un dominio tipo xxxxx.cloudfront.net.
  • Al abrir https://xxxxx.cloudfront.net, ves Digital Cafe Luna - OK.

Paso 6 — Validación final

Confirma el flujo completo:

Usuario → CloudFront → ALB → Target Group → EC2 en Auto Scaling Group
Enter fullscreen mode Exit fullscreen mode

Desde tu terminal:

CF_DOMAIN="xxxxx.cloudfront.net"

curl -I "https://$CF_DOMAIN"
curl "https://$CF_DOMAIN"
Enter fullscreen mode Exit fullscreen mode

Checkpoint

Valida que:

  • CloudFront responde.
  • El ALB sigue activo.
  • El Target Group tiene targets healthy.
  • La página muestra Digital Cafe Luna - OK.

Clean up completo — SAA-Lab1

Elimina los recursos en este orden:

  1. CloudFront

    • Disable distribución saa-lab1-cf
    • Espera que despliegue el cambio
    • Delete distribution

  2. Auto Scaling

    • ASG saa-lab1-asg: Desired/Min = 0
    • Delete ASG
    • Delete Launch Template saa-lab1-lt

  3. Load Balancing

    • Delete ALB saa-lab1-alb
    • Delete Target Group saa-lab1-tg

  4. Security Groups

    • Delete saa-lab1-app-sg
    • Delete saa-lab1-alb-sg

Si un Security Group aparece “in use”, espera 2–3 minutos. Puede quedar una ENI pendiente.

Troubleshooting rápido

  • CloudFront da 504 pero el ALB responde: revisa el origin protocol. Si el ALB es HTTP, el origin debe usar HTTP.
  • Targets unhealthy: revisa user data, NGINX y que el App SG permita HTTP 80 desde el ALB SG.
  • CloudFront queda Deploying: paciencia. Puede tardar varios minutos.
  • SG in use al borrar: espera 2–3 minutos y reintenta.

Well-Architected lens: ¿Qué aplicamos aquí?

  • Reliability: ALB + health checks + ASG para tolerar fallos y sostener capacidad.
  • Performance Efficiency: CloudFront ayuda a reducir latencia y carga directa al origin.
  • Operational Excellence: naming, tags y checkpoints hacen el lab repetible.
  • Cost Optimization: arquitectura mínima y cleanup completo.
  • Security: las instancias no reciben tráfico directo desde Internet.

Resultado esperado

Al final del lab, Camilo cuenta con un baseline real de escalamiento para Digital Café Luna: un endpoint global con CloudFront, un origin estable con ALB y capacidad elástica con Auto Scaling Group.

Referencias oficiales

¿Qué viene en el próximo lab?

Camilo escuchó en su última clase el concepto de Data Protection y se quedó con esa sensación típica:

“La teoría está buena, pero quiero verlo funcionando.”

En el próximo laboratorio vamos a aterrizarlo en Digital Café Luna con un caso simple: proteger facturas y reportes en Amazon S3.

Vamos a crear un bucket privado, habilitar SSE-KMS, usar una KMS key administrada por el cliente y aplicar políticas que obliguen el uso de HTTPS.

También validaremos la evidencia por CLI, para que Camilo entienda mejor cómo se ve el manejo de KMS en la práctica, cuándo un objeto queda cifrado con aws:kms, qué key lo protegió y cómo comprobarlo sin quedarnos solo con lo que dice la consola.

Nos vemos en el próximo laboratorio de Digital Café Luna.

Top comments (0)