sudo apt-get update
sudo apt-get upgrade -y
¡Vamos a armarlo paso a paso! Contexto rápido: AWS Site-to-Site VPN usa IPsec. OpenVPN (SSL) no sirve para esto. En tu Debian usa strongSwan (o libreswan) como customer gateway. Abajo te dejo los pasos de consola (lado AWS, en us-west-1) y luego la configuración en tu EC2 Debian en us-east-2 con strongSwan. (Corrijo el typo: la región es us-west-1). ([AWS Documentation][1])
- Prepara el VPC destino Identifica el VPC CIDR (por ej. 10.50.0.0/16) donde quieres que termine la VPN.
Aquí tienes un procedimiento claro y mínimo para instalar y dejar listo strongSwan en una instancia EC2 con AMI Debian (Bullseye/Bookworm). Incluye los pasos de sistema, servicios y archivos base para que puedas conectar después con AWS Site-to-Site VPN.
-
Elastic IP asociada a tu EC2 (será tu “public IP” del Customer Gateway).
-
Security Group de la instancia:
-
Permite UDP 500 (IKE) y UDP 4500 (NAT-T) desde las IPs de los túneles de AWS o “Anywhere” temporalmente para pruebas.
una arquitectura sencilla de 3 capas sobre AWS: Frontend en EC2 + Nginx sirviendo un HTML estático (guess.html
), Backend en EC2 + Flask exponiendo /guess
y /health
, y PostgreSQL en EC2 para persistir cada intento (UUID, timestamp, número propuesto, número secreto y resultado). Se puede empaquetar en AMIs y poner detrás de NLB + Auto Scaling, y el frontend puede leer la URL del backend desde Parameter Store para evitar configuraciones “hardcodeadas”.
- Instalar y habilitar Nginx en Amazon Linux 2023.
Guía paso a paso para actualizar el sistema, instalar Nginx con
dnf
, habilitar el servicio consystemctl
, abrir puertos 80/443 en el Security Group y verificar la página por defecto. Es la base para servir el HTML del juego. ([Gist][1])
Modelo de Arquitectura 2: frontend y backend desacoplados que se comunican exclusivamente vía SQS. El frontend agrega un control web en Node.js (sirve el HTML estático y usa el SDK de AWS para publicar/leer mensajes). El backend (Flask) consume de SQS, evalúa y publica el resultado en otra cola. Se conservan NLB/ASG si ya los tenías, pero aquí me centro en el flujo app⇄colas.
Usuarios Web
│
▼
1️⃣ Código del backend Flask ajustado para guardar resultados de cada intento en PostgreSQL.
2️⃣ Instrucciones para levantar la instancia EC2 con PostgreSQL (AMI ami-postgresql-al220777
), crear esquema, usuario, tabla y permisos necesarios.
┌──────────────────────────────────────────────┐
│ Usuarios Web │
│ Navegador accede a http://NLB-Frontend │
└──────────────────────────────────────────────┘
│
▼
Perfecto 💪 — aquí tienes un instructivo completo y claro, paso a paso, para montar una instancia EC2 de prueba de volumen y ejecutar pruebas automáticas con Apache Bench (ab) sobre tu servicio Flask (endpoint /health
).
Objetivo: Simular cada 5 minutos una ráfaga de 500 usuarios concurrentes contra el endpoint /health
del servicio Flask desplegado en AWS.
Se va a evolucionar la Arquitectura Modelo 1 para hacerla más profesional y parametrizable, de modo que Nginx (Frontend) ya no tenga el endpoint del backend Flask escrito en el HTML, sino que obtenga dinámicamente ese valor desde AWS Systems Manager Parameter Store.
Esto permite mantener la misma AMI para distintos entornos (dev, QA, prod) sin modificar el código.
Usuarios ─► NLB Frontend (puerto 80)
instrucciones detalladas para crear dos Auto Scaling Groups (ASG) —uno para frontend (Nginx) y otro para backend (Flask)— usando tus AMIs del Modelo 1, cada uno detrás de su propio Network Load Balancer (NLB), ambos escuchando en puerto 80.
Incluyo además cómo agregar un endpoint de health check en Flask y qué usar para Nginx.
Usuarios ─► NLB Frontend (puerto 80)