AWS VPC에는 트래픽을 걸러 내는 대표적인 기능이 두 가지 있습니다. 서브넷 단위의 네트워크 ACL과 인스턴스 단위의 보안 그룹입니다. 이름이 비슷해서 헷갈리지만 콘솔 화면에서 규칙을 읽어 보면 모양이 꽤 다릅니다. 이 글은 조회만 하는 실습입니다. 아무것도 만들거나 바꾸지 않습니다. 보안 그룹을 직접 만들어 보는 과정은 보안 그룹 인바운드 규칙 글에 있습니다.
준비물
| 항목 | 내용 |
|---|---|
| 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 서브넷이었습니다. 기본 네트워크 ACL은 VPC를 만들 때 자동으로 생기고 다른 네트워크 ACL을 연결하지 않은 서브넷이 여기에 연결되는 것으로 알려져 있습니다. 이 실습에서는 4개 서브넷이 이 항목에 연결된 것만 확인했습니다.
2. 인바운드와 아웃바운드 규칙 읽기
세부 정보의 인바운드 규칙 탭을 엽니다.
규칙은 두 개였습니다.
| 규칙 번호 | 유형 | 프로토콜 | 포트 범위 | 소스 | 허용/거부 |
|---|---|---|---|---|---|
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | Allow |
* |
모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | Deny |
아웃바운드 규칙 탭도 같은 구성이었고 소스 자리가 대상으로 바뀌어 표시됩니다.
화면과 AWS 문서에서 읽을 수 있는 네트워크 ACL의 특징은 세 가지입니다.
- 규칙 번호가 있습니다. 100번 규칙이 모든 트래픽을 Allow하고, 맨 마지막
*규칙이 모든 트래픽을 Deny합니다. 규칙은 번호가 작은 것부터 평가되고 처음 일치하는 규칙이 적용되는 것으로 알려져 있습니다. 이 실습에서 순서를 시험한 것은 아닙니다. - 허용(Allow)과 거부(Deny)가 모두 있습니다. 화면에서는 모두 허용 규칙 하나와 모두 거부 규칙 하나를 봤고, 특정 IP를 명시적으로 거부하는 규칙을 넣을 수 있다는 점은 문서 기준입니다.
- 인바운드와 아웃바운드를 따로 정합니다. 기본값에서는 양쪽 모두 모든 트래픽이 허용입니다. 따라서 이 계정은 기본 상태에서는 네트워크 ACL이 아무것도 막지 않습니다.
3. 어느 서브넷에 적용되는지 보기
서브넷 연결 탭을 엽니다.
네트워크 ACL은 서브넷 단위로 적용됩니다. 이 계정에서는 서브넷 4개(가용 영역 두 곳에 2개씩, CIDR 10.50.0.0/20 부터 10.50.48.0/20)가 모두 같은 기본 네트워크 ACL에 연결되어 있었습니다. 이 서브넷 안의 모든 인스턴스가 같은 규칙을 적용받습니다.
4. 기본 보안 그룹의 요약 읽기
이제 보안 그룹을 엽니다. 목록에는 default 보안 그룹 1개가 있었습니다.
기본 보안 그룹은 인바운드와 아웃바운드 규칙이 각각 1개씩이었습니다. 아웃바운드 규칙 탭에서는 다음을 봅니다.
아웃바운드는 IPv4, 모든 트래픽, 프로토콜 전체, 포트 범위 전체였습니다. 오른쪽 대상 열은 화면 폭 때문에 잘려 이미지에서는 읽지 못했습니다. 인바운드 규칙의 내용은 이번에 열어 보지 못했고 개수(1개)만 확인했습니다. 기본 보안 그룹의 인바운드가 같은 보안 그룹에서 오는 트래픽만 허용하는 것으로 알려져 있으나 이 실습에서 화면으로 확인한 것은 아닙니다.
두 화면의 차이 정리
아래 표에서 화면으로 표시한 칸은 이 실습에서 직접 본 것이고, 문서로 표시한 칸은 AWS 문서에 근거한 설명이며 이 실습에서 시험하지 않았습니다.
| 비교 | 네트워크 ACL | 보안 그룹 |
|---|---|---|
| 적용 단위 | 서브넷(화면) | 인스턴스의 네트워크 인터페이스(문서) |
| 규칙 구성 | 번호가 있는 규칙, Allow와 Deny가 모두 있음(화면) | 번호가 없고 허용 규칙만 있는 것으로 알려져 있음(문서). 이 실습의 화면에서 확인한 것은 규칙 개수와 아웃바운드 항목뿐 |
| 기본 상태 | 인바운드와 아웃바운드 모두 모든 트래픽 Allow(화면) | 아웃바운드는 모든 트래픽 허용(화면), 인바운드는 규칙 1개(내용 미확인) |
| 응답 트래픽 | 규칙에서 따로 허용해야 하는 것으로 알려져 있음(문서) | 요청이 허용되면 응답은 자동으로 허용되는 것으로 알려져 있음(문서) |
마지막 줄이 헷갈리기 쉬운 부분입니다. 네트워크 ACL은 응답 트래픽도 규칙으로 열어 줘야 하고, 보안 그룹은 그렇지 않다고 알려져 있습니다. 이 차이를 직접 시험해 보는 것은 아래 "이어서 해 볼 것"에 적었습니다.
아래 표의 문서 칸은 다음 AWS 문서를 근거로 한 설명입니다: 네트워크 ACL, 보안 그룹 규칙, 기본 보안 그룹. 이 실습에서 직접 대조하지는 않았으니 링크의 최신 내용을 함께 확인하시기 바랍니다.
자주 막히는 곳
- 보안 그룹은 열었는데 접속이 안 되는 경우: 보안 그룹 규칙이 맞는데도 막힌다면 서브넷의 네트워크 ACL 규칙도 함께 봅니다. 라우팅 테이블과 인스턴스 안의 방화벽도 확인할 항목입니다. 이 계정처럼 기본 네트워크 ACL은 모두 허용이라 막지 않지만, 규칙을 바꾼 환경에서는 다를 수 있습니다.
- 규칙 번호를 100 단위로 띄우기: 번호는 평가 순서를 정합니다. 나중에 규칙을 끼워 넣을 수 있도록 100, 200, 300처럼 간격을 두라고 AWS 문서가 권장합니다(직접 확인한 것은 아님).
- 화면이 잘려 보이는 경우: 아래 세부 정보 칸이 좁아 열이 잘리면 아래 칸을 스크롤하거나 구분선을 위로 끌어 올리거나 브라우저 폭을 늘립니다. 이 글의 스크린샷도 아래 칸을 스크롤한 상태입니다. 이 글에서 보안 그룹 대상 열이 잘렸던 것도 같은 이유입니다.
이어서 해 볼 것
- 기본 보안 그룹 인바운드 규칙의 소스가 무엇인지 열어 보기
- 사용 중이지 않은 테스트용 서브넷을 하나 준비합니다. 새로 만든 네트워크 ACL은 규칙을 추가하기 전까지 모든 트래픽을 거부하는 것으로 알려져 있어 사용 중인 서브넷에 연결하면 그 서브넷의 통신이 끊깁니다. 이 테스트용 네트워크 ACL을 만들어 그 서브넷에만 연결하고, 기본 거부(
*) 규칙 때문에 모든 트래픽이 막히는지 확인한 뒤 원래대로 되돌리기 - 인스턴스의 보안 그룹은 모두 허용으로 두고 네트워크 ACL에서 응답 포트 범위를 막아 보며 두 기능의 응답 처리 차이를 확인하기
- VPC 퍼블릭과 프라이빗 서브넷 글의 서브넷 구성과 이 글의 서브넷 연결 화면을 대조하기
확인한 범위와 확인하지 않은 것
- 확인한 것: 기본 네트워크 ACL의 인바운드와 아웃바운드 규칙, 연결된 서브넷 4개, 기본 보안 그룹의 규칙 개수와 아웃바운드 규칙의 유형과 프로토콜과 포트 범위.
- 확인하지 않은 것: 기본 보안 그룹 인바운드 규칙의 내용, 규칙 평가 순서, 응답 트래픽 처리 방식, 두 기능을 함께 쓸 때의 실제 차단 동작. 표의
문서칸은 AWS 문서의 설명이며 직접 시험하지 않았습니다.
이 글의 다음 단계
- AWS CloudTrail 이벤트 기록에서 누가 언제 무엇을 했는지 읽기CloudTrail 이벤트 기록 화면에서 최근 변경 이벤트를 보고, 리소스 이름으로 걸러 한 보안 그룹의 생성부터 삭제까지를 추적합니다. 이벤트 상세와 JSON 레코드에서 사용자, 시각, 호출 내용, MFA 여부를 읽는 방법을 정리합니다.
- AWS 콘솔에서 EC2에 IAM 역할을 연결해 액세스 키 없이 S3 읽기 권한 주기IAM 콘솔에서 EC2용 역할 cr-demo-ec2-s3-read-role을 만들고 AmazonS3ReadOnlyAccess를 붙인 뒤, EC2 시작 화면의 고급 세부 정보에서 인스턴스에 연결합니다. 신뢰 정책과 권한 정책의 역할을 읽고, 인스턴스와 역할을 삭제해 정리합니다.