아웃바운드를 열었는데 왜 안 되나

한 줄 요약

보안그룹은 상태를 기억하고(stateful), NACL 은 기억하지 않습니다(stateless).
이 한 가지 차이에서 나머지 모든 차이가 나옵니다.

왜 이게 필요했나

보안그룹에서 인바운드 80만 열어 두면 응답은 알아서 나갑니다. 요청이
들어온 것을 기억했다가 그 응답을 자동으로 허용하기 때문입니다.

NACL 은 다릅니다. 들어온 것을 기억하지 않으므로, **응답이 나가는 것도
따로 허용**해야 합니다. 그리고 응답은 임시 포트(1024~65535)로 나가므로
그 범위를 아웃바운드에 열어야 합니다.

이걸 모르면 "인바운드는 열었는데 응답이 안 온다" 는 현상을 몇 시간 봅니다.

나란히 놓고 보기

| | 보안그룹 | 네트워크 ACL |
| --- | --- | --- |
| 적용 대상 | 인스턴스(ENI) | 서브넷 전체 |
| 상태 | 저장 — 응답 자동 허용 | 비저장 — 양방향 각각 필요 |
| 규칙 | 허용만 | 허용 + 거부 |
| 평가 | 모든 규칙을 본 뒤 허용 하나면 통과 | 번호 순서대로, 처음 맞는 규칙 적용 |
| 기본값 | 인바운드 전부 차단, 아웃바운드 전부 허용 | 기본은 전부 허용 |
| 개수 | 인스턴스당 여러 개 적용 가능 | 서브넷당 하나 |

NACL 의 순서 규칙이 만드는 함정

번호  타입      동작100   전체      ALLOW200   TCP 22    DENY      ← 절대 적용되지 않는다

100번에서 이미 허용되어 끝났기 때문에 200번은 볼 일이 없습니다.
보안그룹처럼 "거부가 우선" 이 아닙니다. **번호가 작은 것부터, 처음 맞는
규칙에서 끝**입니다.

그래서 NACL 규칙 번호는 100, 200, 300 처럼 띄어서 매깁니다 — 나중에
사이에 끼워 넣을 자리를 남기기 위해서입니다.

보안그룹의 강력한 기능 — 그룹 참조

보안그룹 규칙의 출발지에 다른 보안그룹을 지정할 수 있습니다.

DB 보안그룹 인바운드:  5432 ←  sg-app  (앱 서버 보안그룹)

IP 를 쓰지 않았다는 점이 중요합니다. 앱 서버가 몇 대든, 오토스케일링으로
늘고 줄든, IP 가 바뀌든 규칙을 고칠 필요가 없습니다. **역할로 규칙을 쓰는
것**이라 클라우드에서 가장 실용적인 패턴입니다.

어떻게 나눠 쓰나

실무에서는 대개 이렇게 정리됩니다.

• 보안그룹을 주력으로 씁니다. 세밀하고, 그룹 참조가 되고, 실수가 적습니다.
• NACL 은 서브넷 전체에 거는 넓은 가드레일로만 씁니다. 예: 특정

악성 IP 대역 차단, 데이터 서브넷에서 인터넷으로 나가는 것 자체를 봉쇄.

NACL 로 세밀한 제어를 하려 들면 임시 포트와 순서 규칙 때문에 곧 엉킵니다.

흔한 실수 다섯 가지

1. 0.0.0.0/0 에 22번(SSH) 개방 — 스캐너가 몇 분 안에 찾습니다.
2. 아웃바운드를 전부 열어 둠 — 침해 후 데이터 반출 경로가 됩니다.
3. NACL 에서 임시 포트 아웃바운드를 안 열어 응답이 막힘.
4. NACL 규칙 번호를 1, 2, 3 으로 붙여 나중에 끼워 넣을 자리가 없음.
5. 보안그룹 설명(description)을 안 적어 6개월 뒤 아무도 이유를 모름.

5번이 의외로 아픕니다. 지워도 되는지 알 수 없어서 규칙이 계속 쌓입니다.

현장에서 만나는 모습

• 인바운드는 되는데 응답이 안 옴 → NACL 아웃바운드 임시 포트.
• 오토스케일링 후 DB 접속 실패 → IP 로 규칙을 썼다. 그룹 참조로 바꿔야 한다.
• 보안그룹이 40개까지 늘어남 → 정리 기준이 없었다. 설명을 필수로.

다음에 볼 것

프라이빗 자원이 밖으로 나가는 세 가지 길과 각각의 값.