# AWS 네트워크 ACL과 보안 그룹의 규칙 화면 나란히 읽기

> VPC를 만들 때 함께 생기는 기본 네트워크 ACL과 기본 보안 그룹만 있는 계정에서 네트워크 ACL의 인바운드와 아웃바운드 규칙, 연결된 서브넷, 기본 보안 그룹의 규칙 요약을 읽고 두 방화벽 기능이 화면에서 어떻게 다르게 보이는지 정리합니다. 조회만 하는 실습입니다.

- 주소: https://copyandrun.com/blog/aws-vpc-nacl-vs-security-group/
- 분야: 클라우드
- 발행일: 2026-10-18
- 태그: AWS, VPC, 네트워크 ACL, 보안 그룹, 방화벽

AWS VPC에는 트래픽을 걸러 내는 대표적인 기능이 두 가지 있습니다. 서브넷 단위의 네트워크 ACL과 인스턴스 단위의 보안 그룹입니다. 이름이 비슷해서 헷갈리지만 콘솔 화면에서 규칙을 읽어 보면 모양이 꽤 다릅니다. 이 글은 조회만 하는 실습입니다. 아무것도 만들거나 바꾸지 않습니다. 보안 그룹을 직접 만들어 보는 과정은 [보안 그룹 인바운드 규칙 글](/blog/aws-security-group-inbound-rules-console/)에 있습니다.

## 준비물

| 항목 | 내용 |
| --- | --- |
| AWS 계정 | 실습용 IAM 사용자. VPC 콘솔을 조회할 수 있는 권한 필요(예: AWS 관리형 정책 `AmazonVPCReadOnlyAccess`) |
| 리전 | 아시아 태평양(서울) ap-northeast-2 |
| 예상 소요 시간 | 약 15분(예상치입니다) |
| 변경 사항 | 없음 |

화면의 계정 ID, 사용자 이름, 이 계정의 VPC와 서브넷 이름은 가렸습니다. 이 실습 계정에는 네트워크 ACL과 보안 그룹이 각각 기본 항목 1개뿐이었습니다. 서브넷 CIDR이 10.50.0.0/20부터 시작하는 직접 만든 VPC였으므로, AWS 기본 VPC를 쓰는 계정은 서브넷 수와 CIDR이 다르게 보입니다. 기본값을 바꾼 계정이라면 화면이 다를 수 있습니다.

## 1. 네트워크 ACL 목록과 세부 정보

콘솔 위쪽 검색창에 `VPC`를 입력해 VPC 콘솔을 열고 오른쪽 위에서 리전을 서울로 맞춥니다. 왼쪽 메뉴 `보안`의 `네트워크 ACL`을 엽니다. 목록에서 항목 하나를 선택하면 아래에 세부 정보가 나타납니다.

![네트워크 ACL 목록에 항목 1개가 선택되어 있고 연결 대상 4개 서브넷, 기본값 예, 인바운드 규칙 수 2가 보이며 아래 세부 정보 탭에 네트워크 ACL ID가 표시된 것을 확인합니다.](https://copyandrun.com/img/aws-vpc-nacl-vs-security-group/01-acl-details.png)

목록에는 네트워크 ACL이 1개 있었고 `기본값` 열이 `예`, `연결 대상`이 `4 서브넷`이었습니다. 기본 네트워크 ACL은 VPC를 만들 때 자동으로 생기고 다른 네트워크 ACL을 연결하지 않은 서브넷이 여기에 연결되는 것으로 알려져 있습니다. 이 실습에서는 4개 서브넷이 이 항목에 연결된 것만 확인했습니다.

## 2. 인바운드와 아웃바운드 규칙 읽기

세부 정보의 `인바운드 규칙` 탭을 엽니다.

![네트워크 ACL 인바운드 규칙 표에 규칙 100은 모든 트래픽 Allow, 별표 규칙은 모든 트래픽 Deny로 표시된 화면](https://copyandrun.com/img/aws-vpc-nacl-vs-security-group/02-acl-inbound.png)

규칙은 두 개였습니다.

| 규칙 번호 | 유형 | 프로토콜 | 포트 범위 | 소스 | 허용/거부 |
| --- | --- | --- | --- | --- | --- |
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | Allow |
| `*` | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | Deny |

`아웃바운드 규칙` 탭도 같은 구성이었고 `소스` 자리가 `대상`으로 바뀌어 표시됩니다.

![네트워크 ACL 아웃바운드 규칙 표에 규칙 100은 모든 트래픽 Allow, 별표 규칙은 모든 트래픽 Deny로 표시된 화면](https://copyandrun.com/img/aws-vpc-nacl-vs-security-group/03-acl-outbound.png)

화면과 AWS 문서에서 읽을 수 있는 네트워크 ACL의 특징은 세 가지입니다.

- **규칙 번호가 있습니다.** 100번 규칙이 모든 트래픽을 Allow하고, 맨 마지막 `*` 규칙이 모든 트래픽을 Deny합니다. 규칙은 번호가 작은 것부터 평가되고 처음 일치하는 규칙이 적용되는 것으로 알려져 있습니다. 이 실습에서 순서를 시험한 것은 아닙니다.
- **허용(Allow)과 거부(Deny)가 모두 있습니다.** 화면에서는 모두 허용 규칙 하나와 모두 거부 규칙 하나를 봤고, 특정 IP를 명시적으로 거부하는 규칙을 넣을 수 있다는 점은 문서 기준입니다.
- **인바운드와 아웃바운드를 따로 정합니다.** 기본값에서는 양쪽 모두 모든 트래픽이 허용입니다. 따라서 이 계정은 기본 상태에서는 네트워크 ACL이 아무것도 막지 않습니다.

## 3. 어느 서브넷에 적용되는지 보기

`서브넷 연결` 탭을 엽니다.

![서브넷 4개가 모두 같은 네트워크 ACL에 연결된 서브넷 연결 탭 화면](https://copyandrun.com/img/aws-vpc-nacl-vs-security-group/04-acl-subnets.png)

네트워크 ACL은 서브넷 단위로 적용됩니다. 이 계정에서는 서브넷 4개(가용 영역 두 곳에 2개씩, CIDR 10.50.0.0/20 부터 10.50.48.0/20)가 모두 같은 기본 네트워크 ACL에 연결되어 있었습니다. 이 서브넷 안의 모든 인스턴스가 같은 규칙을 적용받습니다.

## 4. 기본 보안 그룹의 요약 읽기

이제 `보안 그룹`을 엽니다. 목록에는 `default` 보안 그룹 1개가 있었습니다.

![보안 그룹 목록에서 default 보안 그룹이 선택되어 있고 세부 정보에 보안 그룹 이름 default, 설명 default VPC security group, 인바운드 규칙 수 1 권한 항목, 아웃바운드 규칙 수 1 권한 항목이 표시된 것을 확인합니다.](https://copyandrun.com/img/aws-vpc-nacl-vs-security-group/05-sg-details.png)

기본 보안 그룹은 인바운드와 아웃바운드 규칙이 각각 1개씩이었습니다. 아웃바운드 규칙 탭에서는 다음을 봅니다.

![아웃바운드 규칙 1개가 표시되고 보안 그룹 규칙 ID, IP 버전 IPv4, 유형 모든 트래픽, 프로토콜 전체, 포트 범위 전체인 것을 확인합니다.](https://copyandrun.com/img/aws-vpc-nacl-vs-security-group/06-sg-outbound.png)

아웃바운드는 IPv4, 모든 트래픽, 프로토콜 전체, 포트 범위 전체였습니다. 오른쪽 `대상` 열은 화면 폭 때문에 잘려 이미지에서는 읽지 못했습니다. 인바운드 규칙의 내용은 이번에 열어 보지 못했고 개수(1개)만 확인했습니다. 기본 보안 그룹의 인바운드가 같은 보안 그룹에서 오는 트래픽만 허용하는 것으로 알려져 있으나 이 실습에서 화면으로 확인한 것은 아닙니다.

## 두 화면의 차이 정리

아래 표에서 `화면`으로 표시한 칸은 이 실습에서 직접 본 것이고, `문서`로 표시한 칸은 AWS 문서에 근거한 설명이며 이 실습에서 시험하지 않았습니다.

| 비교 | 네트워크 ACL | 보안 그룹 |
| --- | --- | --- |
| 적용 단위 | 서브넷(화면) | 인스턴스의 네트워크 인터페이스(문서) |
| 규칙 구성 | 번호가 있는 규칙, Allow와 Deny가 모두 있음(화면) | 번호가 없고 허용 규칙만 있는 것으로 알려져 있음(문서). 이 실습의 화면에서 확인한 것은 규칙 개수와 아웃바운드 항목뿐 |
| 기본 상태 | 인바운드와 아웃바운드 모두 모든 트래픽 Allow(화면) | 아웃바운드는 모든 트래픽 허용(화면), 인바운드는 규칙 1개(내용 미확인) |
| 응답 트래픽 | 규칙에서 따로 허용해야 하는 것으로 알려져 있음(문서) | 요청이 허용되면 응답은 자동으로 허용되는 것으로 알려져 있음(문서) |

마지막 줄이 헷갈리기 쉬운 부분입니다. 네트워크 ACL은 응답 트래픽도 규칙으로 열어 줘야 하고, 보안 그룹은 그렇지 않다고 알려져 있습니다. 이 차이를 직접 시험해 보는 것은 아래 "이어서 해 볼 것"에 적었습니다.

아래 표의 `문서` 칸은 다음 AWS 문서를 근거로 한 설명입니다: [네트워크 ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html), [보안 그룹 규칙](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html), [기본 보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/default-security-group.html). 이 실습에서 직접 대조하지는 않았으니 링크의 최신 내용을 함께 확인하시기 바랍니다.

## 자주 막히는 곳

- **보안 그룹은 열었는데 접속이 안 되는 경우**: 보안 그룹 규칙이 맞는데도 막힌다면 서브넷의 네트워크 ACL 규칙도 함께 봅니다. 라우팅 테이블과 인스턴스 안의 방화벽도 확인할 항목입니다. 이 계정처럼 기본 네트워크 ACL은 모두 허용이라 막지 않지만, 규칙을 바꾼 환경에서는 다를 수 있습니다.
- **규칙 번호를 100 단위로 띄우기**: 번호는 평가 순서를 정합니다. 나중에 규칙을 끼워 넣을 수 있도록 100, 200, 300처럼 간격을 두라고 AWS 문서가 권장합니다(직접 확인한 것은 아님).
- **화면이 잘려 보이는 경우**: 아래 세부 정보 칸이 좁아 열이 잘리면 아래 칸을 스크롤하거나 구분선을 위로 끌어 올리거나 브라우저 폭을 늘립니다. 이 글의 스크린샷도 아래 칸을 스크롤한 상태입니다. 이 글에서 보안 그룹 대상 열이 잘렸던 것도 같은 이유입니다.

## 이어서 해 볼 것

- 기본 보안 그룹 인바운드 규칙의 소스가 무엇인지 열어 보기
- 사용 중이지 않은 테스트용 서브넷을 하나 준비합니다. 새로 만든 네트워크 ACL은 규칙을 추가하기 전까지 모든 트래픽을 거부하는 것으로 알려져 있어 사용 중인 서브넷에 연결하면 그 서브넷의 통신이 끊깁니다. 이 테스트용 네트워크 ACL을 만들어 그 서브넷에만 연결하고, 기본 거부(`*`) 규칙 때문에 모든 트래픽이 막히는지 확인한 뒤 원래대로 되돌리기
- 인스턴스의 보안 그룹은 모두 허용으로 두고 네트워크 ACL에서 응답 포트 범위를 막아 보며 두 기능의 응답 처리 차이를 확인하기
- [VPC 퍼블릭과 프라이빗 서브넷 글](/blog/aws-vpc-public-private-subnets-console/)의 서브넷 구성과 이 글의 서브넷 연결 화면을 대조하기

## 확인한 범위와 확인하지 않은 것

- 확인한 것: 기본 네트워크 ACL의 인바운드와 아웃바운드 규칙, 연결된 서브넷 4개, 기본 보안 그룹의 규칙 개수와 아웃바운드 규칙의 유형과 프로토콜과 포트 범위.
- 확인하지 않은 것: 기본 보안 그룹 인바운드 규칙의 내용, 규칙 평가 순서, 응답 트래픽 처리 방식, 두 기능을 함께 쓸 때의 실제 차단 동작. 표의 `문서` 칸은 AWS 문서의 설명이며 직접 시험하지 않았습니다.