ALB와 EC2 인스턴스 사이 보안그룹 설계: 실무 사례와 체크리스트

1) 트래픽 흐름을 이해해야 규칙이 보입니다

인터넷(클라이언트) → ALB(리스너 80/443) → 타깃그룹 → EC2(앱 포트)
보안그룹(SG) 은 상태 저장(stateful)입니다. 한쪽 방향으로 허용되면 응답은 자동 허용됩니다.
ALB는 자신의 ENI IP로 EC2에 접속합니다. 즉, EC2의 Inbound는 “ALB의 보안그룹”을 소스로 제한하는 것이 가장 안전합니다.

2) 표준 구성(인터넷 노출형 ALB → 프라이빗 EC2)

가정

ALB는 퍼블릭 서브넷(IGW 연결), EC2는 프라이빗 서브넷(NAT 또는 egress만 필요).
ALB에서 TLS 종료(443), EC2는 내부 HTTP(예: 8000)로 서비스.
타깃그룹: HTTP:8000, 헬스체크 경로 /healthz.

보안그룹 규칙 예시

ALB-SG

인바운드
- TCP 443, 소스: 0.0.0.0/0 (필요시 ::/0도 추가하여 IPv6 클라이언트 허용)
- (선택) TCP 80, 소스: 0.0.0.0/0 (HTTP → 443 리다이렉트용)
아웃바운드
- TCP 8000, 대상: EC2-SG (원칙적으로 최소권한. 실무에선 “All traffic to 0.0.0.0/0”이 기본값인 경우가 많으나, 가능하면 타깃 포트/타깃 SG로 좁히십시오.)

EC2-SG

인바운드
- TCP 8000, 소스: ALB-SG (클라이언트 IP가 아니라 ALB의 SG가 소스로 찍히는 점이 핵심)
아웃바운드
- 기본 허용(예: 0.0.0.0/0) 또는 운영 정책에 따라 업데이트 리포지토리/외부 API만 선별 허용

헬스체크 주의

타깃그룹 헬스체크 포트가 서비스 포트와 다르면, EC2-SG에 해당 포트도 ALB-SG 소스로 열어야 합니다.
헬스체크 경로가 인증/리다이렉트로 막히지 않도록 /healthz 같은 공개 경로 유지가 안전합니다.

3) 변형 ①: 여러 서비스(포트)로 라우팅 하는 경우

예) /api/* → 8000, /admin/* → 8001
ALB-SG 아웃바운드: TCP 8000, 8001 → EC2-SG
EC2-SG 인바운드: TCP 8000, 8001 ← ALB-SG
애플리케이션이 포트를 나눠 쓰면 SG도 동일하게 포트 단위로 열어야 합니다.

4) 변형 ②: 블루/그린 배포(두 타깃그룹)

타깃그룹 A(그린) → EC2-GREEN-SG, 타깃그룹 B(블루) → EC2-BLUE-SG
ALB-SG 아웃바운드
- TCP 8000 → EC2-GREEN-SG
- TCP 8000 → EC2-BLUE-SG
각 EC2-SG 인바운드
- TCP 8000 ← ALB-SG
전환은 ALB의 타깃그룹 연결(가중치/리스너 규칙 전환)로 처리하고, 보안그룹은 상시 두 그룹 모두 허용해 두면 무중단 전환이 수월합니다.

5) 변형 ③: 내부 ALB(Internal) + 사내망/VPN

ALB-SG 인바운드: TCP 443, 소스를 사내 CIDR(예: 10.0.0.0/8) 또는 “게이트웨이/프록시의 SG”로 제한
EC2-SG 인바운드: 서비스 포트(TCP 8000) ← ALB-SG
외부 노출이 없으므로 퍼블릭 서브넷이 아닌 프라이빗 서브넷에 ALB를 두는 구성이 일반적입니다(Internal ALB).

6) NLB와의 차이 간단 정리

NLB는 보안그룹이 없습니다. (Subnet/NACL, 인스턴스 SG로 제어)
NLB 뒤 EC2의 Inbound 소스는 클라이언트 IP가 들어올 수 있어, ALB처럼 ‘ALB-SG를 소스로’ 제한하는 방식이 불가능합니다.
본 글의 “소스=ALB-SG” 설계는 ALB에 한정된 강력한 최소권한 패턴입니다.

7) IPv6 고려 포인트

ALB 리스너를 dual-stack(IPv4/IPv6)로 연다면 ALB-SG 인바운드에 ::/0 추가가 필요합니다.
ALB→EC2 구간은 여전히 VPC 내부 IPv4로 연결되는 점이 일반적이므로, EC2-SG는 IPv4 기준으로 ALB-SG 소스 허용이면 충분합니다.

8) 자주 발생하는 오작동 원인 8가지

EC2 인바운드의 소스를 0.0.0.0/0로 개방
— ALB를 둔 의미가 약화됩니다. 소스를 반드시 ALB-SG로 제한하십시오.
헬스체크 포트를 안 열음
— 타깃이 지속적으로 unhealthy. 헬스체크 포트·경로 확인.
타깃그룹 포트와 애플리케이션 리스닝 포트 불일치
— 예: TG는 8000인데 앱은 8080으로 대기. SG가 아니라 애플리케이션 설정 문제.
ALB SG 아웃바운드를 과도 제한/미설정
— 타깃 포트로 나가는 규칙이 없으면 연결 실패. TCP 서비스 포트를 명시.
OS 방화벽(ufw/firewalld, Windows Defender) 미해제
— SG만 보고 막혔다고 판단하기 쉽습니다. OS 레벨도 허용해야 합니다.
프라이빗 서브넷에 EC2를 두고, 공인 IP로 접속을 시도
— 라우팅/IGW가 없어 직접 접속 불가. ALB DNS로 접속해야 정상.
NACL에서 에페머럴 포트 차단
— SG는 상태저장이라 문제없어 보이는데 NACL은 양방향 허용이 필요합니다(보통 1024–65535).
인스턴스 타깃 대신 IP 타깃 사용
— 외부망 IP를 대상에 넣은 뒤 EC2-SG에서 ALB-SG 참조로 막을 수 있다고 오해. IP 타깃은 SG 참조가 통하지 않습니다.

9) 콘솔·CLI 설정 예시

콘솔(요지)

ALB-SG 생성
- 인바운드: 443(및 80 선택) ← 0.0.0.0/0(필요시 ::/0)
- 아웃바운드: TCP 8000 → 대상 EC2-SG
EC2-SG 생성
- 인바운드: TCP 8000 ← 소스 ALB-SG
- 아웃바운드: 기본 허용 또는 정책별 제한
타깃그룹: 프로토콜/포트(HTTP:8000), 헬스체크 경로 /healthz
ALB 리스너(443) → 타깃그룹 연결, 필요시 80→443 리다이렉트 규칙 추가

AWS CLI(핵심 한 줄)

# EC2 인바운드: 앱 포트 8000을 ALB-SG로부터 허용
aws ec2 authorize-security-group-ingress \
  --group-id ${EC2_SG_ID} \
  --protocol tcp --port 8000 \
  --source-group ${ALB_SG_ID}

# ALB 아웃바운드: 앱 포트 8000을 EC2-SG로만 허용(최소권한)
aws ec2 authorize-security-group-egress \
  --group-id ${ALB_SG_ID} \
  --protocol tcp --port 8000 \
  --destination-group ${EC2_SG_ID}

참고: 기본 생성 SG는 egress “All traffic”이 열려 있습니다. 가능하면 위처럼 타깃 포트/SG로 축소하십시오.

10) 점검 체크리스트(문제 원인 신속 진단)

ALB DNS로 접속하는가? (프라이빗 EC2에 공인 IP 접속 시도는 실패)
타깃그룹 상태가 healthy 인가? (아니면 헬스체크 포트/경로 먼저 확인)
EC2-SG 인바운드가 앱 포트 ← ALB-SG로 정확히 설정됐는가?
ALB-SG 아웃바운드가 앱 포트 → EC2-SG로 제한/허용됐는가?
OS 방화벽(ufw/firewalld/Windows)에서 앱 포트가 허용됐는가?
NACL에서 80/443/앱 포트, 에페머럴 포트(1024–65535)를 양방향 허용했는가?
라우팅: ALB는 퍼블릭 서브넷(IGW), EC2는 프라이빗 서브넷(NAT) 배치가 맞는가?
로그/도구: ALB 액세스 로그, VPC Reachability Analyzer로 경로를 시각적으로 검증했는가?

11) 한눈에 보는 “정답 패턴”

EC2 인바운드 = “앱포트 ← ALB-SG”
ALB 아웃바운드 = “앱포트 → EC2-SG”
헬스체크 포트/경로 일치
공개는 ALB만, EC2는 프라이빗
NACL은 가급적 기본 허용(관리 복잡 시 SG 중심)

위 패턴을 지키면, ALB–EC2 사이 보안 경계가 선명해지고, 오작동 원인도 빠르게 좁힐 수 있습니다. 블루/그린, 멀티포트 라우팅, 내부 ALB 등으로 확장할 때도 “소스=ALB-SG, 포트=정확히”라는 원칙만 유지하면 됩니다.

저작자표시 (새창열림)