안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번에는 VPC Peering 시 중첩되는 CIDR 문제, 무엇이 문제인지 정리해 봤습니다.
VPC 생성
일반적으로 할당할 VPC IP 주소 혹은 CIDR가 정해진 상태라면 큰 고민 없이 VPC를 포함한 네트워크 구성을 구축할 수 있습니다.
하지만, VPC의 CIDR와 Subnet의 CIDR를 직접 나누는 경우에는 생각할 부분이 많아집니다.
먼저 아래와 같은 IP 주소를 고객으로부터 할당 받았을 경우를 상정해서 VPC Peering를 시도해 보겠습니다.
- 172.100.0.0/16
- test-a-vpc : 172.100.16.0/20
- test-b-vpc : 172.100.17.0/24
할당 받은 IP 주소를 바탕으로 IP 주소를 나누어 2개의 VPC를 만들었습니다.
아무런 문제 없다고 생각하고서 VPC Peering를 시도해 보면 다음과 같은 에러 메시지를 확인할 수 있습니다.
- 중첩되는 CIDR이 있는 2개의 VPC 사이에서 피어링 연결을 생성할 수 없습니다. 별도의 CIDR이 있는 VPC 2개를 선택하십시오.
즉, 현재 생성한 두 개의 VPC의 CIDR가 중복되어 발생하는 에러입니다.
수락자 VPC는 사용자 또는 다른 AWS 계정에서 소유할 수 있으며, 요청자 VPC의 CIDR 블록과 중첩되는 CIDR 블록은 사용할 수 없습니다.
AWS 공식 문서를 확인해 보면, 다음과 같이 중첩되는 CIDR 블록은 사용할 수 없다고 안내하고 있습니다.
CIDR는 어떻게 나누어야 할까?
먼저 할당받은 IP 주소를 바탕으로 VPC CIDR를 나누기에 앞서, 현재 환경에서 몇 개의 Subnet을 생성해야 할지 생각해야 합니다.
예를 들어 하나의 VPC에 8개의 Subnet을 생성하고 싶다면 아래와 같이 설정한다면 정확하게 8개의 Subnet으로 나눌 수 있습니다.
- VPC : 172.100.16.0/24
하지만 8개의 Subnet으로 나누고 싶다고 해서 /27 로 설정을 해버린다면, 추후 Subnet을 추가하고 싶은 경우, 추가할 수 없는 상황이 발생하기 때문에 항상 여유분을 생각하고 CIDR를 만들어두는 것이 좋습니다.
다음과 같이 Subnet의 CIDR를 /28로 설정하여 여유분을 가지고 만들어두는 것이 좋습니다.
Subnet 여유분까지 생각해서 Subnet CIDR 까지 고려했다면 VPC CIDR를 생각할 차례입니다.
- test-a-vpc : 172.100.16.0/20
상기 test-a-vpc 에서 사용하고 있는 CIDR의 범위를 계산해 보면 다음과 같습니다.
- 172.100.16.0 ~ 172.100.31.240
여기서 주목할 곳은 세 번째 옥탯입니다.
VPC CIDR를 /20 으로 설정했기 때문에 16 ~ 31까지 해당 VPC의 범위가 되어버리기 때문에 세 번째 옥탯을 16 ~ 31 사이로 지정한다면 CIDR 중복이 발생해버립니다.
- test-a-vpc : 172.100.16.0/20
- test-b-vpc : 172.100.17.0/24
상기 VPC에서 Peering 설정 시 CIDR 중복이 발생하는 것도 같은 이유입니다.
그러므로 VPC CIDR를 지정할 때도 이미 생성 되어있는 VPC CIDR 범위와 겹치지 중복되지 않는지, 혹은 Subnet 여유분이 충분한지, 낭비되는 IP 주소가 없는지를 체크해야합니다.
참고로 Subnet의 CIDR 블록 중 아래 5개는 사용할 수 없습니다.
- 10.94.4.0 : 네트워크 주소입니다.
- 10.94.4.1 : AWS가 VPC 라우터용으로 예약했습니다.
- 10.94.4.2 : AWS에서 예약
- 10.94.4.3 : 향후 사용을 위해 AWS에서 예약합니다.
- 10.94.4.255 : 네트워크 브로드캐스트 주소입니다.
이 외에, IP 사용이 필요하게 되는 케이스는 다음과 같습니다.
- EC2 인스턴스 생성
- Elastic IP 할당
- NAT 게이트웨이 생성
- VPC Endpoint 생성
이번에는 CIDR 중복 범위를 피해서 VPC를 생성했습니다.
- test-a-vpc : 172.100.16.0/20
- test-c-vpc : 172.100.32.0/24
VPC CIDR 중복 범위를 피해 VPC를 생성하고 Peering을 시도하니 문제 없이 두 VPC간 Peering 연결이 활성화된 것을 확인할 수 있습니다.
마지막으로
어떻게 보면 별 것 아닌 VPC 생성이지만, 여러 방면으로 생각하여 신중하게 설계, 구축할 필요가 있다고 생각합니다.
구축 초기 단계라면 잘못 설계되어진 VPC의 경우 삭제하고 다시 생성하면 되겠지만, 실제 환경에서 이용하고 있거나, 많은 리소스를 사용하고 있는 경우 되돌리기 힘든점이 있기 때문에 VPC 설계 단계에서 꼼꼼히 체크할 필요가 있습니다.
본 블로그 게시글을 보시고 문의 사항이 있으신 분들은 클래스메소드코리아 (info@classmethod.kr)로 연락 주시면 빠른 시일 내 담당자가 회신 드릴 수 있도록 하겠습니다 !
0
