AWS 보안그룹 Source를 CIDR에서 Security Group 참조로 변경 시 오류 해결

1. 상황

MariaDB Galera Cluster를 구성하면서 DB 노드 간 내부 통신을 위해 보안그룹 인바운드 규칙을 설정하고 있었다.

Galera Cluster는 노드 간 동기화와 상태 전송을 위해 다음 포트를 사용한다.

초기 검증 단계에서는 빠른 연결 확인을 위해 Source를 0.0.0.0/0으로 열어두었다.

하지만 DB 노드 간 통신은 외부 전체에 열려 있을 필요가 없기 때문에, 이후 보안을 강화하기 위해 Source를 DB 보안그룹 자기 참조로 변경하려고 했다.

목표는 다음과 같았다.

기존:
Source = 0.0.0.0/0

변경:
Source = SG-DB-2A

즉, 같은 DB 보안그룹에 속한 EC2 인스턴스끼리만 Galera 내부 통신 포트에 접근할 수 있도록 제한하려고 했다.

2. 발생한 오류

AWS Console에서 기존 인바운드 규칙의 Source를 0.0.0.0/0에서 DB 보안그룹 ID로 수정하려고 하자 다음 오류가 발생했다.

기존 IPv4 CIDR 규칙에 참조된 그룹 ID를 지정할 수 없습니다.

스크린샷 기준으로는 Source 입력란에 보안그룹 ID를 넣었지만, 기존 규칙이 IPv4 CIDR 규칙으로 생성되어 있어 저장이 되지 않았다.

3. 원인

원인은 AWS 보안그룹 규칙의 Source 타입 차이였다.

AWS 보안그룹 인바운드 규칙은 겉으로 보기에는 Source 값만 바꾸는 것처럼 보이지만, 내부적으로는 다음 규칙이 서로 다른 타입으로 구분된다.

1. IPv4 CIDR 기반 규칙
   예: 0.0.0.0/0
   예: 10.250.0.0/16

2. Security Group 참조 기반 규칙
   예: sg-099a2091e71e69f8f

즉, 기존에 0.0.0.0/0로 생성된 규칙은 IPv4 CIDR 규칙이다.

이 규칙을 편집 화면에서 그대로 수정하면서 Source만 sg-... 형태의 보안그룹 ID로 바꾸려고 하면, AWS는 기존 IPv4 CIDR 규칙에 보안그룹 참조 값을 넣는 것으로 판단한다.

그래서 다음과 같은 오류가 발생한다.

기존 IPv4 CIDR 규칙에 참조된 그룹 ID를 지정할 수 없습니다.

정리하면, 기존 CIDR 규칙을 직접 수정해서 Security Group 참조 규칙으로 바꿀 수 없다.

4. 해결 방법

해결 방법은 기존 CIDR 규칙을 수정하는 것이 아니라, 삭제 후 새 규칙으로 다시 생성하는 것이다.

4.1 기존 규칙 삭제

먼저 기존에 0.0.0.0/0 또는 다른 CIDR로 열려 있던 Galera 관련 규칙을 삭제한다.

삭제 대상 예시는 다음과 같다.

4.2 Security Group 참조 규칙 새로 추가

기존 CIDR 규칙을 삭제한 뒤, 같은 포트를 Security Group 참조 방식으로 새로 추가한다.

예시:

이렇게 설정하면 같은 DB 보안그룹에 속한 EC2 인스턴스끼리만 Galera 내부 통신 포트에 접근할 수 있다.

5. 왜 Security Group 자기 참조를 사용하는가?

DB 클러스터 내부 통신은 외부 인터넷이나 전체 VPC 대역에 열 필요가 없다.

Galera Cluster의 DB 노드들은 서로 통신해야 하지만, 그 대상은 같은 클러스터에 속한 DB 인스턴스로 제한되어야 한다.

Security Group 자기 참조를 사용하면 다음과 같은 장점이 있다.

1. 같은 보안그룹에 속한 인스턴스끼리만 통신 허용
2. DB 노드가 추가되어도 같은 보안그룹만 붙이면 통신 가능
3. IP 변경이나 인스턴스 교체에 영향을 덜 받음
4. 0.0.0.0/0보다 훨씬 안전함
5. VPC CIDR 전체 허용보다 접근 범위를 더 좁힐 수 있음

즉, DB 노드 간 통신에는 CIDR보다 Security Group 참조 방식이 더 적절하다.

6. 임시 대안

콘솔에서 Security Group 참조 선택이 계속 실패하거나, 실습 검증 단계에서 빠르게 제한 범위를 줄여야 한다면 VPC CIDR로 제한할 수 있다.

예시 VPC CIDR:

10.250.0.0/16

임시 설정 예시는 다음과 같다.

이 방식은 0.0.0.0/0보다 안전하다.

하지만 VPC 내부 전체 대역에서 접근이 가능하므로, DB 보안그룹 자기 참조보다 접근 범위가 넓다.

따라서 운영 기준으로는 임시 대안으로만 사용하고, 최종적으로는 Security Group 자기 참조 방식으로 좁히는 것이 좋다.

7. AWS CLI로 설정하는 방법

콘솔에서 수정이 불편할 경우 AWS CLI로도 규칙을 추가할 수 있다.

예시 보안그룹 ID:

SG-DB-2A = sg-099a2091e71e69f8f

7.1 TCP 4567 추가

aws ec2 authorize-security-group-ingress \
  --region ap-northeast-2 \
  --group-id sg-099a2091e71e69f8f \
  --protocol tcp \
  --port 4567 \
  --source-group sg-099a2091e71e69f8f

7.2 UDP 4567 추가

aws ec2 authorize-security-group-ingress \
  --region ap-northeast-2 \
  --group-id sg-099a2091e71e69f8f \
  --protocol udp \
  --port 4567 \
  --source-group sg-099a2091e71e69f8f

7.3 TCP 4568 추가

aws ec2 authorize-security-group-ingress \
  --region ap-northeast-2 \
  --group-id sg-099a2091e71e69f8f \
  --protocol tcp \
  --port 4568 \
  --source-group sg-099a2091e71e69f8f

7.4 TCP 4444 추가

aws ec2 authorize-security-group-ingress \
  --region ap-northeast-2 \
  --group-id sg-099a2091e71e69f8f \
  --protocol tcp \
  --port 4444 \
  --source-group sg-099a2091e71e69f8f

주의할 점은 기존 CIDR 규칙이 남아 있으면 접근 범위가 여전히 넓게 열려 있을 수 있다는 것이다.

따라서 새 Security Group 참조 규칙을 추가한 뒤에는 기존 0.0.0.0/0 규칙을 삭제해야 한다.

8. 설정 후 확인 방법

보안그룹 규칙이 정상적으로 들어갔는지 확인한다.

aws ec2 describe-security-group-rules \
  --region ap-northeast-2 \
  --filters Name=group-id,Values=sg-099a2091e71e69f8f

확인할 항목은 다음과 같다.

- FromPort / ToPort가 4567, 4568, 4444인지 확인
- IpProtocol이 tcp 또는 udp인지 확인
- CidrIpv4가 아니라 ReferencedGroupInfo가 들어갔는지 확인
- 참조된 GroupId가 DB 보안그룹 ID인지 확인

정상적인 Security Group 참조 규칙은 개념적으로 다음과 같은 형태다.

{
  "IpProtocol": "tcp",
  "FromPort": 4567,
  "ToPort": 4567,
  "ReferencedGroupInfo": {
    "GroupId": "sg-099a2091e71e69f8f"
  }
}

반면 CIDR 기반 규칙은 다음처럼 CidrIpv4가 표시된다.

{
  "IpProtocol": "tcp",
  "FromPort": 4567,
  "ToPort": 4567,
  "CidrIpv4": "0.0.0.0/0"
}

운영 기준에서는 Galera 내부 통신 포트에 0.0.0.0/0이 남아 있지 않은지 반드시 확인해야 한다.

9. Galera Cluster 상태 확인

보안그룹 수정 후에는 DB 노드 간 통신이 정상인지 확인해야 한다.

MariaDB 컨테이너 또는 DB 서버에 접속한 뒤 다음 명령을 실행한다.

SHOW STATUS WHERE Variable_name IN (
  'wsrep_local_state_comment',
  'wsrep_cluster_size',
  'wsrep_ready',
  'wsrep_cluster_status'
);

정상 예시는 다음과 같다.

+---------------------------+---------+
| Variable_name             | Value   |
+---------------------------+---------+
| wsrep_local_state_comment | Synced  |
| wsrep_cluster_size        | 3       |
| wsrep_cluster_status      | Primary |
| wsrep_ready               | ON      |
+---------------------------+---------+

확인 기준은 다음과 같다.

wsrep_local_state_comment = Synced
wsrep_cluster_size = 3
wsrep_cluster_status = Primary
wsrep_ready = ON

이 값이 정상이라면 보안그룹을 Security Group 자기 참조로 변경한 뒤에도 Galera 노드 간 통신이 정상적으로 유지되고 있는 것이다.

10. 정리

이번 문제는 AWS 보안그룹에서 Source 값을 단순히 변경하는 과정에서 발생했다.

처음에는 0.0.0.0/0을 sg-... 값으로 바꾸면 될 것처럼 보였지만, AWS 보안그룹 규칙은 내부적으로 CIDR 기반 규칙과 Security Group 참조 규칙을 구분한다.

따라서 기존 IPv4 CIDR 규칙을 직접 수정해서 Security Group 참조 규칙으로 바꿀 수 없다.

해결 방법은 명확하다.

1. 기존 CIDR 규칙 삭제
2. Security Group 참조 규칙 새로 생성
3. 기존 0.0.0.0/0 규칙이 남아 있지 않은지 확인
4. Galera Cluster 상태 확인

Galera Cluster처럼 같은 역할의 DB 노드끼리 내부 통신이 필요한 경우에는 Security Group 자기 참조 방식이 적절하다.

이를 통해 DB 노드 간 통신은 허용하면서도 외부 또는 불필요한 내부 대역으로부터의 접근은 차단할 수 있다.

11. 배운 점

이번 트러블슈팅을 통해 AWS 보안그룹 규칙은 화면상 Source 값만 바꾸는 것처럼 보여도, 내부적으로는 규칙 타입이 다르게 관리된다는 점을 확인했다.

특히 다음 차이를 명확히 이해할 수 있었다.

CIDR 기반 Source:
- 0.0.0.0/0
- 10.250.0.0/16

Security Group 참조 기반 Source:
- sg-xxxxxxxx

보안그룹을 운영할 때는 단순히 포트가 열려 있는지만 보는 것이 아니라, 어떤 Source에서 접근 가능한지를 함께 확인해야 한다.

특히 DB, WAS, 내부 클러스터 통신처럼 외부에 노출될 필요가 없는 포트는 가능한 한 다음 순서로 접근 범위를 좁히는 것이 좋다.

0.0.0.0/0 사용 지양
-> VPC CIDR로 임시 제한
-> Security Group 참조로 최소 권한 구성

이번 경험을 통해 클라우드 보안 설정에서는 “통신이 되는가”뿐 아니라 “필요한 대상에게만 열려 있는가”를 함께 확인해야 한다는 점을 배웠다.