Un laboratorio breve que muestra exactamente cómo subredes, zonas de disponibilidad y grupos de seguridad trabajan juntos mientras lanzas un servidor web real de forma correcta.
Nota de terminología: en AWS se llaman Security Groups SGs. Network Security Group NSG es el término de Azure. Usaremos SG en todo el artículo.
Qué vas a construir: un servidor Nginx público en Amazon EC2 ubicado en una zona de disponibilidad y en una subred específicas, protegido por un Security Group restrictivo. Demostrarás que las reglas del SG controlan el acceso alternando el acceso HTTP.
Mini arquitectura: Internet -> Internet Gateway -> VPC -> Subnet pública en una AZ -> instancia EC2 con IPv4 pública -> Security Group que permite SSH 22 desde Mi IP y HTTP 80 desde el mundo.
Paso 0 Planifica tu ubicación Region AZ Subnet
Por qué importa: las subredes existen dentro de una sola Availability Zone. Elegir una subred implica elegir la AZ. No puedes mover una instancia a otra AZ después del lanzamiento. En la consola AWS ve a VPC Subnets e identifica una subred pública en la AZ objetivo por ejemplo us-east-1a.
Verifica que sea pública: la Route Table tiene una ruta a 0.0.0.0/0 vía un Internet Gateway igw-xxxx. La opción Auto-assign public IPv4 de la subred está Enabled o planea adjuntar una Elastic IP después. Anota el Subnet ID y la AZ, los necesitarás al lanzar la instancia.
Si no tienes una subred pública crea una VPC, adjunta un Internet Gateway, crea una subred pública en la AZ elegida y actualiza la Route Table con una ruta 0.0.0.0/0 hacia igw-xxxx. Después habilita auto-assign public IPv4 en esa subred.
Paso 1 Crea un Security Group restrictivo
Un Security Group es un firewall virtual stateful para tu instancia. En la consola EC2 ve a Network Security Security Groups y crea un security group.
Nombre: ec2-nginx-sg. VPC: elige la VPC que contiene tu subred objetivo.
Reglas inbound recomendadas: SSH 22 Source My IP recomendado. HTTP 80 Source 0.0.0.0/0 y añade ::/0 si usas IPv6. Regla outbound: deja el valor por defecto All traffic 0.0.0.0/0 necesario para instalar paquetes y actualizar.
Paso 2 Lanza la instancia EC2 en la subred AZ elegida
En EC2 Instances Launch instances.
Nombre: nginx-lab. AMI: elige Ubuntu 22.04 usuario ubuntu o Amazon Linux 2023/2 usuario ec2-user. Tipo de instancia: t2.micro o t3.micro Free Tier elegible donde aplique. Key pair: crea o selecciona un par .pem y guarda el fichero de forma segura.
Network settings: VPC seleccionada, Subnet: elige la subred pública exacta en la AZ planificada por ejemplo us-east-1a. Auto-assign public IP debe estar Enabled o planea asociar una Elastic IP tras el lanzamiento. Firewall security groups: selecciona el SG ec2-nginx-sg. Storage: acepta los valores por defecto. Lanza la instancia.
Paso 3 Conéctate por SSH
Desde tu terminal local ejecuta chmod 400 my-key.pem. Para Ubuntu usa ssh -i my-key.pem ubuntu@direccion_publica_de_tu_instancia reemplazando direccion_publica_de_tu_instancia por la IP o DNS público de la instancia.
Paso 4 Instala y ejecuta Nginx
Actualiza e instala Nginx: sudo apt update && sudo apt install nginx -y. Inicia y habilita el servicio: sudo systemctl start nginx y sudo systemctl enable nginx.
Paso 5 Prueba HTTP
Copia la Public IPv4 o Public DNS de la instancia y visita https://direccion_publica_de_tu_instancia en tu navegador. Deberías ver la página de bienvenida de Nginx si todo está configurado correctamente.
Paso 6 Demuestra que los SGs controlan el acceso
En la consola AWS abre el Security Group ec2-nginx-sg asociado a la instancia. Elimina o desactiva la regla inbound de HTTP 80. Refresca el navegador la página dejará de cargarse mostrando timeouts o conexión rechazada. Vuelve a añadir la regla HTTP 80 para restaurar el acceso.
Hardening e mejoras opcionales
SSH con menor privilegio: limita SSH a My IP solamente. Considera usar Session Manager de AWS Systems Manager para evitar exponer SSH. IP estática: asigna y adjunta una Elastic IP para mantener una IP pública persistente. HTTPS: añade un Load Balancer con certificado ACM o usa Lets Encrypt en la instancia para TLS. Automatización: recrea la arquitectura con Terraform o Ansible para reproducibilidad.
NACLs vs SGs: Network ACLs son stateless y se aplican a nivel de subred. Security Groups son stateful y se aplican al ENI o instancia. Para empezar usa SGs ya que son más sencillos y poderosos a nivel de instancia.
Errores comunes
Elegir la subred equivocada privada sin ruta a IGW implica no poder acceder por SSH o HTTP desde Internet. No tener IPv4 público si auto-assign está deshabilitado y no se asoció EIP impide el acceso público. Usar el nombre de usuario SSH incorrecto ubuntu vs ec2-user impide el login. Firewalls locales o ISP bloqueando salida por puerto 22 pueden causar problemas de conexión.
Limpieza
Termina la instancia cuando hayas terminado. Libera la Elastic IP si la usaste. Elimina Security Groups y pares de claves no utilizados para mantener la cuenta limpia.
Sobre Q2BSTUDIO
Q2BSTUDIO es una empresa de desarrollo de software y aplicaciones a medida especializada en inteligencia artificial y ciberseguridad. Ofrecemos servicios cloud AWS y Azure, servicios inteligencia de negocio y soluciones de ia para empresas incluyendo agentes IA y Power BI para transformar datos en decisiones. Si buscas software a medida o aplicaciones a medida para proyectos que requieren seguridad, escalabilidad y capacidades de inteligencia artificial nuestra experiencia cubre desde arquitectura cloud hasta implementación y mantenimiento. Podemos automatizar infraestructuras como la descrita usando Terraform o Ansible y asegurar despliegues con buenas prácticas de ciberseguridad.
Palabras clave para mejorar posicionamiento SEO: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi.
Si quieres que Q2BSTUDIO implemente este laboratorio en tu entorno, automatice la infraestructura o añada autenticación y cifrado hablá con nuestro equipo para una propuesta a medida y segura.