📋 Contenido
Pregunta de entrevista y de examen, y confusión eterna en la vida real: ¿security group o NACL? El security group es el portero de cada instancia, tiene memoria y solo sabe permitir; la NACL es la valla de la subred, no tiene memoria, y sabe permitir y vetar. El 90 por ciento de tu trabajo diario va en los security groups. La diferencia completa, en
El mapa primero: el security group envuelve a la instancia, a su tarjeta de red exactamente; la NACL envuelve a la subred entera. Uno es el portero de tu puerta; la otra, la valla del barrio. El tráfico cruza las dos.
| Security Group | NACL |
|---|---|
| El portero de LA INSTANCIA (su ENI) | La valla de LA SUBRED entera |
La memoria
La diferencia que importa: la memoria. El security group es stateful: si dejaste salir una petición, la respuesta entra sola, él se acuerda. La NACL es stateless: no se acuerda de nada, y la respuesta necesita su propia regla de vuelta por los puertos efímeros. Ahí nace el clásico: el ping sale, la respuesta nunca llega.
| SG · stateful | NACL · stateless |
|---|---|
| Dejé salir la petición → la respuesta ENTRA SOLA | La respuesta necesita SU regla de vuelta (efímeros) |
Permitir vs VETAR
Segunda diferencia: el security group solo sabe permitir: lo no permitido, no entra, pero no puedes escribir un veto. La NACL sí veta: reglas de permitir y denegar, evaluadas en orden por su número, y la primera que encaja, gana. Por eso el veto a una IP molesta se escribe en la NACL.
- SG: solo ALLOW (lo demás no entra, pero no hay veto explícito)
- NACL: ALLOW y DENY, por orden de número de regla.
¿Puertas abiertas?
El chequeo de un segundo para tu cuenta: buscar security groups con el 22 abierto al mundo. Y ahí está: uno, abierto a todo internet. Cada uno de esos es una puerta que alguien está probando ahora mismo con un script.
$ aws ec2 describe-security-groups --filters \
$ Name=ip-permission.cidr,Values=0.0.0.0/0 Name=ip-permission.from-port,Values=22
sg-0a31f · "legacy-web" · 22/tcp abierto al mundo
Alguien lo está probando AHORA con un script
¿Cuándo usar cada uno?
Las reglas de uso: el día a día, quién habla con quién, vive en los security groups, referenciándose entre ellos, el grupo de la web puede hablar con el de la base. La NACL, casi siempre en su valor por defecto, se toca para vetos gruesos: bloquear un rango de IPs, aislar una subred. Y nunca, en ninguno de los dos, el 22 abierto al mundo: para entrar a administrar existe Session Manager.
- Día a día → Security Groups (referenciados entre sí)
- Vetos gruesos (IPs, aislar subred) → NACL
- Nunca 22/RDP a 0.0.0.0/0 → SSM Session Manager
- Ponles NOMBRE: ‹sg-0a31f› no dice nada
Para la entrevista y para la vida: el security group decide quién entra a tu casa; la NACL decide quién entra al barrio. Y con esto cierras la serie de seguridad: responsabilidad compartida, los 10 fallos, la vigilancia y la red.
Preguntas frecuentes
¿Qué puede salir mal? Cuidado con las NACL
Advertencia antes de tocar una NACL: por defecto lo permiten todo, y ese default es sano. Una NACL editada con prisa y mal ordenada tumba la subred entera, incluida la regla que te permitía entrar a arreglarla. Se cambian con plan, no en caliente.
Su default (permitir todo) es sano. Mal ordenada, tumba la SUBRED entera — se toca con plan, no en caliente.
¿Por dónde empiezo?
Las reglas de uso: el día a día, quién habla con quién, vive en los security groups, referenciándose entre ellos, el grupo de la web puede hablar con el de la base. La NACL, casi siempre en su valor por defecto, se toca para vetos gruesos: bloquear un rango de IPs, aislar una subred. Y nunca, en ninguno de los dos, el 22 abierto al mundo: para entrar a administrar existe Session Manager.
¿Puedo usar solo security groups y olvidarme de las NACL?
Sí, y es lo que hace la mayoría. La NACL por defecto deja pasar todo y el trabajo fino se hace con security groups. Las NACL se tocan cuando quieres un bloqueo amplio a nivel de subred —vetar un rango de IP para todo lo que hay dentro, por ejemplo— o cuando una auditoría te pide dos capas.
¿Por qué mi regla de NACL no funciona?
Casi siempre por lo mismo: las NACL no tienen memoria de estado. Si abres la entrada pero no la salida del rango de puertos efímeros (los altos que usa el cliente para recibir la respuesta), la petición entra y la respuesta se queda bloqueada. Con security groups no pasa, porque sí recuerdan la conexión.