보안 그룹은 AWS 인스턴스(EC2, RDS, Lambda 등)로 유입되거나 나가는 트래픽을 제어하는 가상 방화벽이다. 백엔드 개발자에게는 누가 우리 서버의 API 포트에 접근할 수 있는가?를 결정하는 가장 중요한 통제 수단이다.

1. 핵심 동작 원리

1.1. 인스턴스 단위의 보호

• 네트워크 ACL(NACL)이 서브넷 입구를 지킨다면, 보안 그룹은 각 인스턴스 바로 앞에서 트래픽을 검사한다.
• 같은 서브넷 안에 있는 두 서버라도 보안 그룹 설정이 다르면 서로 통신할 수 없다.

1.2. 상태 저장 방식 (Stateful)

• 가장 중요한 특징으로 인바운드(Inbound) 규칙으로 허용된 요청이 들어오면, 그에 대한 응답(Outbound)은 보안 그룹 규칙과 상관없이 자동으로 허용된다.
• 반대로 서버가 외부로 먼저 요청을 보낸 경우(Outbound), 그 응답이 돌아오는 것 역시 자동으로 허용된다.

1.3. 기본 정책: 모두 거부, 명시적 허용

• 보안 그룹은 기본적으로 모든 트래픽을 차단합니다. 허용하고 싶은 트래픽만 Allow 규칙으로 추가해야 한다 (Deny 규칙을 따로 만들 수는 없다).

2. 보안 그룹 설정 구성 요소

항목	설명	예시
Type	사용할 프로토콜 종류	HTTP, HTTPS, SSH, Custom TCP
Protocol	통신 프로토콜	TCP, UDP, ICMP
Port Range	허용할 포트 번호	80, 443, 8080, 3306
Source/Dest	트래픽의 출발지 또는 목적지	IP 주소, CIDR 대역, 다른 보안 그룹 ID

3. 백엔드 개발자를 위한 실무 활용 패턴

3.1. "보안 그룹 참조" 방식

IP 주소(10.0.1.5/32)를 일일이 입력하는 대신 보안 그룹 ID 자체를 Source로 지정할 수 있다.

• 시나리오: API 서버가 DB에 접속해야 할 때
• 설정: DB의 보안 그룹 인바운드 규칙에 Source: sg-12345 (API 서버 보안 그룹)를 추가한다.
• 장점: 오토스케일링으로 API 서버의 IP가 계속 변해도, 동일한 보안 그룹을 가진 서버라면 설정 변경 없이 DB 접속이 가능하다.

3.2. 계층별 분리 (Tiered Security)

이렇게 설정하면 외부 사용자는 절대 DB나 App 서버에 직접 요청을 할 수 없다.

1. Web/ALB SG: 0.0.0.0/0 (모든 곳)에서 80, 443 포트 허용.
2. App SG: 오직 Web/ALB SG로부터 오는 8080 포트만 허용.
3. DB SG: 오직 App SG로부터 오는 3306 포트만 허용.

4. 흔히 하는 실수와 주의사항

1. 0.0.0.0/0의 남용: 테스트를 위해 SSH(22포트)나 DB(3306포트)를 모든 IP에 개방하는 것은 매우 위험하다. 반드시 본인의 사무실/집 IP 혹은 Bastion Host의 보안 그룹만 허용해야 한다.
2. 아웃바운드(Outbound) 규칙 삭제: 기본적으로 보안 그룹 생성 시 아웃바운드는 '모든 트래픽 허용'이다. 이를 무심코 지우면 서버에서 외부 API(결제 모듈, 공공 데이터 등)를 호출할 수 없게 된다.
3. 규칙 수 제한: 하나의 보안 그룹에는 최대 60개(기본값)의 규칙만 넣을 수 있다. 너무 세분화하면 관리가 힘들고 한도에 걸릴 수 있으므로 '보안 그룹 참조'를 적극 활용해야 한다.

5. 요약: 백엔드 개발자 체크리스트

• 내 API 서버의 포트(예: 8080)가 Load Balancer에게만 열려 있는가?
• DB 보안 그룹이 내 로컬 IP나 App 서버 보안 그룹 외에 개방되어 있지는 않은가?
• 외부 API를 호출해야 하는데 연결이 안 된다면 Outbound 규칙을 확인했는가?
• SSH 접속은 지정된 Bastion Host 혹은 VPN IP를 통해서만 가능한가?