¿Cuál es la diferencia entre los security groups y las network ACL?

Esta es una pregunta clásica de redes en la nube, y la respuesta gira en torno a una palabra: con estado frente a sin estado. Los candidatos que confunden estas escribirán reglas defectuosas.

Security groups — con estado, a nivel de instancia

Un security group se adjunta a una instancia o interfaz de red y actúa como un cortafuegos con estado:

• Contiene solo reglas de permitir (no hay denegación explícita — todo lo que no se permite se deniega implícitamente).
• Como es con estado, si permites una solicitud entrante, el tráfico de retorno correspondiente se autoriza automáticamente. No escribes una regla para la respuesta.
• Es el control principal y de grano fino — lo acotas a puertos concretos y a security groups de origen o CIDR.

Network ACL — sin estado, a nivel de subred

Una network ACL se sitúa en el límite de la subred y es sin estado:

• Tiene reglas numeradas y ordenadas evaluadas de menor a mayor, y admite tanto permitir como denegar — útil para bloquear un rango de IP malicioso concreto en toda una subred.
• Como es sin estado, no recuerda las conexiones. Si permites tráfico entrante, también debes permitir explícitamente el tráfico de retorno saliente en los puertos efímeros (y viceversa). Olvidar esto es el bug número uno de las NACL.

Cómo se combinan

El tráfico a una instancia debe pasar por ambos: la NACL de la subred y el security group de la instancia. Se evalúan juntos, y una denegación en cualquiera de las capas descarta el paquete. En la práctica, usa security groups para casi todo y reserva las NACL para barreras gruesas a nivel de subred.

Qué buscan los entrevistadores

La distinción con estado frente a sin estado expresada con claridad, la consecuencia (reglas de tráfico de retorno para las NACL), la diferencia solo permitir frente a permitir/denegar, y que ambas capas se aplican a un paquete.