보안 그룹과 네트워크 ACL은 둘 다 VPC 안에서 트래픽을 제어한다는 점 때문에 같이 외우기 쉽습니다. 그런데 SAA-C03 문제에서는 둘의 공통점보다 차이가 더 자주 단서가 됩니다. 보기에서 무엇을 고를지 흔들린다면, 먼저 “어디에 적용되는가”와 “응답 트래픽을 어떻게 다루는가”를 분리해서 보면 됩니다.
먼저 적용 위치를 본다
보안 그룹은 리소스에 붙는 제어에 가깝습니다. EC2 인스턴스 자체라기보다 인스턴스의 네트워크 인터페이스에 연결되어, 해당 리소스로 들어오고 나가는 트래픽을 제어합니다. 그래서 문제에서 “특정 인스턴스”, “특정 애플리케이션 서버”, “로드 밸런서 뒤의 대상”처럼 개별 리소스 단위의 접근 제어가 강조되면 보안 그룹을 먼저 떠올릴 수 있습니다.
네트워크 ACL은 서브넷 단위입니다. 서브넷으로 들어오거나 나가는 트래픽을 필터링합니다. 그래서 문제에서 “서브넷 전체”, “여러 인스턴스에 공통으로 적용”, “특정 CIDR을 서브넷 경계에서 차단” 같은 표현이 나오면 NACL 쪽 조건인지 확인해야 합니다.
stateful과 stateless 차이를 확인한다
보안 그룹은 stateful입니다. 허용된 요청에 대한 응답 트래픽은 별도의 반대 방향 규칙을 하나하나 열지 않아도 흐름이 이어질 수 있습니다. 이 특징 때문에 시험 문제에서 “응답 트래픽까지 별도로 허용해야 하는가”가 핵심 단서라면 보안 그룹과 NACL을 구분하기 쉬워집니다.
NACL은 stateless입니다. 들어오는 규칙과 나가는 규칙을 각각 봅니다. 예를 들어 외부 클라이언트가 웹 서버에 접근하는 흐름을 생각하면, inbound와 outbound 방향을 따로 확인해야 합니다. 특히 ephemeral port가 얽히는 문제에서는 NACL이 stateless라는 점 때문에 보기의 조건이 복잡해질 수 있습니다.
allow만 필요한지, deny가 필요한지 본다
보안 그룹 규칙은 허용할 트래픽을 정의하는 방식으로 이해하면 편합니다. 반대로 “이 특정 IP 대역은 명시적으로 막아야 한다”처럼 deny가 선택지의 핵심이면 NACL이 더 자연스러운 후보가 됩니다. NACL은 allow와 deny 규칙을 둘 다 가질 수 있고, 번호가 낮은 규칙부터 평가됩니다.
다만 모든 차단 요구사항을 NACL로 풀어야 한다는 뜻은 아닙니다. 리소스 단위 접근 제어라면 보안 그룹 설계가 더 단순할 수 있고, 서브넷 경계에서 넓게 막아야 하는 조건이라면 NACL이 맞을 수 있습니다. 시험에서는 보통 이 적용 범위를 같이 줍니다.
문제에서 먼저 볼 단서
선택지가 헷갈릴 때는 다음 순서로 조건을 압축해보면 좋습니다.
- 제어 대상이 리소스인가, 서브넷인가?
- 응답 트래픽을 자동으로 따라가도 되는가, 양방향 규칙을 따로 봐야 하는가?
- 허용만 정의하면 되는가, 명시적 deny가 필요한가?
- 한두 인스턴스의 보안 설정인가, 서브넷 전체의 공통 필터인가?
이 네 가지 질문에 답하면 보안 그룹과 NACL 중 어느 쪽을 먼저 검토해야 하는지 대부분 좁힐 수 있습니다.
학습할 때의 주의점
보안 그룹과 NACL은 서로를 완전히 대체하는 기능이라기보다 서로 다른 위치에서 작동하는 계층입니다. 그래서 “어느 것이 더 안전한가”처럼 외우기보다, 문제의 제어 위치와 트래픽 흐름을 먼저 그려보는 편이 낫습니다.
공식 문서 기준으로 보안 그룹은 VPC 리소스의 트래픽을 제어하고, 네트워크 ACL은 서브넷 트래픽을 제어하는 기능으로 설명됩니다. 실제 설계에서는 둘을 함께 쓰는 경우도 있지만, 시험 문제에서는 보통 한쪽의 특성이 더 명확하게 드러나도록 조건이 주어집니다.
참고한 공식 문서
- AWS VPC security groups: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html
- AWS VPC network ACLs: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html