보안 그룹과 네트워크 ACL 차이 상태 저장 방식으로 이해하는 방화벽 규칙 설정

보안 그룹과 네트워크 ACL 차이는 AWS에서 서버 접근을 제어할 때 반드시 구분해야 하는 개념입니다. 둘 다 트래픽을 허용하거나 막는 방화벽 역할을 하기 때문에 같은 기능처럼 보이지만, 적용 위치와 동작 방식이 다릅니다. 이 차이를 모르고 규칙을 설정하면 분명 포트를 열었는데 접속이 안 되거나, 반대로 막았다고 생각한 트래픽이 그대로 통과하는 상황이 생길 수 있습니다.

 

보안 그룹과 네트워크 ACL 차이 상태 저장 방식으로 이해하는 방화벽 규칙 설정

저도 예전에는 서버에 접속이 안 될 때마다 보안 그룹만 계속 수정했습니다. 인바운드 규칙에 포트를 분명히 추가했는데도 연결이 되지 않아 한참을 헤맸는데, 원인은 서브넷에 적용된 네트워크 ACL에서 응답 트래픽이 나가는 포트 범위를 막고 있었기 때문이었습니다. 그때 상태 저장과 상태 비저장이라는 차이를 제대로 이해하게 되었습니다.

 

오늘 제가 준비한 포스팅에서는 보안 그룹과 네트워크 ACL 차이를 중심으로 각각의 적용 범위, 상태 저장 방식의 의미, 규칙 평가 방식, 기본 설정 상태, 그리고 실제로 안전하게 규칙을 설계하는 방법과 접속 문제를 점검하는 순서까지 차근차근 정리해보겠습니다.

 

핵심만 먼저 말씀드리면 보안 그룹은 인스턴스 단위에 적용되고 허용 규칙만 있으며 응답 트래픽을 자동으로 허용하는 상태 저장 방화벽입니다. 네트워크 ACL은 서브넷 단위에 적용되고 허용과 거부 규칙을 모두 가지며 들어오고 나가는 트래픽을 각각 따로 검사하는 상태 비저장 방화벽입니다.

 

보안 그룹은 인스턴스에 붙는 상태 저장 방화벽입니다

보안 그룹(Security Group)은 EC2 인스턴스나 RDS 데이터베이스, 로드 밸런서 같은 리소스의 네트워크 인터페이스에 연결되는 가상 방화벽입니다. 하나의 인스턴스에 여러 보안 그룹을 연결할 수 있고, 하나의 보안 그룹을 여러 인스턴스가 함께 사용할 수도 있습니다.

 

보안 그룹의 가장 중요한 특징은 상태 저장(Stateful) 방식이라는 점입니다. 인바운드 규칙으로 허용된 요청이 들어오면, 그 요청에 대한 응답은 아웃바운드 규칙과 관계없이 자동으로 나갈 수 있습니다. 반대로 서버가 밖으로 보낸 요청에 대한 응답도 인바운드 규칙과 관계없이 들어올 수 있습니다. 연결 상태를 기억하고 있기 때문입니다.

 

보안 그룹에는 허용 규칙만 존재하고 거부 규칙은 만들 수 없습니다. 규칙에 명시적으로 허용되지 않은 트래픽은 모두 차단됩니다. 여러 규칙이 있을 때는 순서와 관계없이 모든 규칙을 함께 평가해 하나라도 허용하면 통과시킵니다.

 

새로 만든 보안 그룹은 기본적으로 인바운드 규칙이 비어 있어 들어오는 트래픽을 모두 막고, 아웃바운드는 모든 트래픽을 허용하는 규칙이 들어 있습니다. 그래서 서버를 만든 뒤 필요한 포트만 인바운드 규칙에 추가하는 방식으로 사용합니다.

 

보안 그룹은 허용 규칙만 가지는 상태 저장 방화벽이므로, 요청을 허용하면 응답은 자동으로 통과하고 명시하지 않은 트래픽은 모두 차단됩니다.

 

네트워크 ACL은 서브넷 경계에 적용되는 상태 비저장 방화벽입니다

네트워크 ACL(Network Access Control List)은 서브넷 단위로 적용되는 방화벽입니다. 서브넷에 들어오고 나가는 모든 트래픽이 네트워크 ACL을 거치기 때문에, 그 서브넷 안의 모든 인스턴스에 공통으로 영향을 줍니다. 하나의 서브넷에는 하나의 네트워크 ACL만 연결할 수 있습니다.

 

네트워크 ACL은 상태 비저장(Stateless) 방식입니다. 들어오는 요청을 허용했더라도 나가는 응답을 따로 허용하지 않으면 응답이 차단됩니다. 그래서 인바운드와 아웃바운드 규칙을 항상 짝을 맞춰 설계해야 합니다.

 

특히 응답 트래픽은 클라이언트가 임의로 정한 임시 포트(Ephemeral port)로 돌아갑니다. 운영체제마다 범위가 다르지만 넓게는 1024번부터 65535번까지 사용될 수 있습니다. 네트워크 ACL의 아웃바운드 규칙에서 이 범위를 허용하지 않으면 웹 서버의 응답이 사용자에게 돌아가지 못합니다.

 

네트워크 ACL에는 허용과 거부 규칙을 모두 만들 수 있고, 각 규칙에는 번호가 붙습니다. 번호가 작은 규칙부터 순서대로 평가하다가 트래픽과 일치하는 첫 번째 규칙이 적용되면 나머지 규칙은 보지 않습니다. 따라서 특정 IP를 차단하려면 허용 규칙보다 작은 번호로 거부 규칙을 넣어야 합니다.

 

VPC에 기본으로 제공되는 네트워크 ACL은 모든 인바운드와 아웃바운드 트래픽을 허용하도록 설정되어 있습니다. 반면 사용자가 새로 만든 사용자 지정 네트워크 ACL은 규칙을 추가하기 전까지 모든 트래픽을 거부합니다.

 

네트워크 ACL은 번호 순서대로 평가되는 상태 비저장 방화벽이므로 응답용 임시 포트 범위를 아웃바운드에서 허용해야 하고, 차단 규칙은 허용 규칙보다 작은 번호로 넣어야 합니다.

 

보안 그룹과 네트워크 ACL 핵심 차이 비교

두 기능의 차이를 정리하면 다음과 같습니다. 제가 만든 아래 표를 참고해보세요.

 

비교 항목	보안 그룹	네트워크 ACL
적용 범위	인스턴스(네트워크 인터페이스) 단위	서브넷 단위
상태 추적	상태 저장 (응답 자동 허용)	상태 비저장 (응답도 규칙 필요)
규칙 종류	허용 규칙만 가능	허용·거부 규칙 모두 가능
평가 방식	모든 규칙을 함께 평가	번호 순서대로 첫 일치 규칙 적용
기본 동작	새 그룹: 인바운드 차단, 아웃바운드 전체 허용	기본 ACL: 전체 허용 / 사용자 지정 ACL: 전체 거부
주요 용도	서버별 세밀한 접근 제어	서브넷 전체 차단, 특정 IP 대역 거부

 

트래픽이 인터넷에서 인스턴스로 들어올 때는 먼저 서브넷의 네트워크 ACL을 통과하고, 그다음 인스턴스의 보안 그룹을 통과합니다. 두 단계 중 하나라도 막으면 연결은 성립하지 않습니다.

 

보안 그룹 규칙을 안전하게 설계하는 방법

첫 번째 원칙은 필요한 포트와 출발지만 여는 것입니다. 웹 서버라면 HTTP 80번과 HTTPS 443번은 모든 IP에 열 수 있지만, SSH 22번이나 원격 데스크톱 3389번 같은 관리 포트를 0.0.0.0/0으로 열어두는 것은 피해야 합니다. 관리 포트가 필요하다면 사무실이나 집의 고정 IP 대역으로 제한하거나, 포트를 열지 않고 Systems Manager Session Manager를 사용하는 방법이 안전합니다.

 

두 번째는 IP 대신 보안 그룹을 출발지로 지정하는 방법입니다. 예를 들어 데이터베이스 보안 그룹의 인바운드 규칙에 애플리케이션 서버의 보안 그룹을 출발지로 넣으면, 그 보안 그룹이 연결된 서버만 데이터베이스에 접근할 수 있습니다. 서버 IP가 바뀌거나 서버가 늘어나도 규칙을 수정할 필요가 없습니다.

 

세 번째는 역할별로 보안 그룹을 나누는 것입니다. 로드 밸런서용, 웹 서버용, 데이터베이스용 보안 그룹을 따로 만들고 계층 사이에 필요한 연결만 허용하면 한 서버가 침해되더라도 피해가 다른 계층으로 번지는 것을 줄일 수 있습니다. 규칙 설명란에 용도를 적어두면 나중에 관리하기도 훨씬 쉽습니다.

 

관리 포트를 전체 IP에 열지 말고, 계층 간 연결은 IP 대신 보안 그룹을 출발지로 지정하는 것이 규칙을 안전하고 관리하기 쉽게 만드는 핵심입니다.

 

네트워크 ACL은 언제 활용하면 좋을까요

대부분의 환경에서는 보안 그룹만으로도 충분한 접근 제어가 가능합니다. 그래서 네트워크 ACL은 기본 설정인 전체 허용 상태로 두고, 보안 그룹을 주요 방어 수단으로 사용하는 경우가 많습니다. 네트워크 ACL을 복잡하게 설정하면 오히려 원인을 찾기 어려운 연결 문제가 생기기 쉽기 때문입니다.

 

네트워크 ACL이 유용한 대표적인 경우는 특정 IP 대역을 명시적으로 차단해야 할 때입니다. 보안 그룹은 거부 규칙이 없기 때문에 공격이 들어오는 IP를 막으려면 네트워크 ACL에 거부 규칙을 추가해야 합니다. 또한 규정상 서브넷 단위의 추가 방어 계층이 요구되는 경우에도 활용됩니다.

 

네트워크 ACL을 수정할 때는 한 번에 여러 규칙을 바꾸기보다 하나씩 변경하고 연결을 확인하는 것이 좋습니다. 특히 임시 포트 범위를 빠뜨리는 실수가 가장 흔하므로, 인바운드 규칙을 추가할 때마다 대응하는 아웃바운드 규칙을 함께 확인해야 합니다.

 

접속이 안 될 때 점검하는 순서

서버 접속이 되지 않는다면 바깥에서 안쪽 순서로 확인하는 것이 효율적입니다. 먼저 인스턴스에 퍼블릭 IP가 있는지, 서브넷의 라우팅 테이블에 인터넷 게이트웨이 경로가 있는지 확인합니다. 다음으로 서브넷의 네트워크 ACL에서 인바운드 포트와 아웃바운드 임시 포트가 허용되어 있는지 봅니다.

 

그다음 인스턴스의 보안 그룹에 해당 포트와 내 IP가 허용되어 있는지 확인하고, 마지막으로 서버 운영체제 내부의 방화벽이나 서비스가 실제로 해당 포트에서 실행 중인지 점검합니다. VPC Reachability Analyzer를 사용하면 출발지와 목적지 사이의 경로를 분석해 어느 단계에서 막히는지 알려주므로 원인을 빠르게 찾을 수 있습니다.

 

접속 문제는 라우팅, 네트워크 ACL, 보안 그룹, 운영체제 방화벽 순서로 바깥에서 안쪽으로 점검하면 원인을 가장 빠르게 찾을 수 있습니다.

 

보안 그룹과 네트워크 ACL 차이 총정리

보안 그룹은 인스턴스 단위, 허용 규칙만 존재, 응답을 자동 허용하는 상태 저장 방화벽이고, 네트워크 ACL은 서브넷 단위, 허용과 거부 규칙이 있으며 번호 순서로 평가되는 상태 비저장 방화벽입니다. 일상적인 접근 제어는 보안 그룹으로 세밀하게 하고, 특정 IP 차단처럼 거부가 필요한 경우 네트워크 ACL을 보조로 활용하는 것이 일반적입니다. 관리 포트 제한과 보안 그룹 참조 방식을 적용하면 규칙을 안전하게 유지할 수 있습니다.

 

질문 QnA

보안 그룹에서 특정 IP만 차단할 수 있나요?

보안 그룹은 거부 규칙을 지원하지 않으므로 특정 IP만 차단할 수 없습니다. 이 경우 네트워크 ACL에 거부 규칙을 추가하거나 AWS WAF 같은 서비스를 함께 사용해야 합니다.

보안 그룹 규칙을 수정하면 서버를 재시작해야 적용되나요?

아니요, 보안 그룹 규칙 변경은 연결된 리소스에 곧바로 적용됩니다. 다만 이미 맺어진 연결은 상태 추적 방식에 따라 즉시 끊기지 않을 수 있습니다.

아웃바운드 규칙도 제한하는 것이 좋을까요?

보안 요구 수준이 높다면 필요한 목적지와 포트만 허용하도록 줄이는 것이 좋습니다. 다만 업데이트 서버나 외부 API 접근이 막히지 않도록 필요한 통신 목록을 먼저 파악한 뒤 적용해야 합니다.

하나의 서버에 보안 그룹을 몇 개까지 연결할 수 있나요?

네트워크 인터페이스당 연결할 수 있는 보안 그룹 수에는 기본 한도가 있으며, 서비스 할당량에서 조정할 수 있습니다. 정확한 기본값은 VPC 할당량 문서에서 확인하는 것이 좋습니다.

 

보안 그룹과 네트워크 ACL은 클라우드 네트워크 보안의 두 겹 울타리입니다. 각각이 어디에 적용되고 어떻게 판단하는지 이해하면 불필요하게 넓게 열린 규칙을 줄이고, 접속 문제가 생겼을 때도 당황하지 않고 원인을 찾을 수 있습니다.

 

지금 EC2 콘솔의 보안 그룹 메뉴를 열어 인바운드 규칙에 0.0.0.0/0으로 열려 있는 22번이나 3389번 포트가 있는지 검색해보세요. 발견된다면 내 IP 대역으로 좁히거나 Session Manager로 전환하는 것만으로도 서버 보안 수준을 크게 높일 수 있습니다.

 

※ 본 글은 2026년 9월 기준 Amazon VPC 보안 그룹 및 네트워크 ACL 공식 문서를 참고해 작성했으며, 기본 동작과 할당량은 변경될 수 있으니 최신 내용은 AWS 공식 페이지에서 확인해 주세요.