VPC, 서브넷을 구성,운영하다보면 VPC 간 연결이 필요할 때가 있다.
연결할 VPC 는 다른 리전 또는 다른 계정의 VPC, 같은 계정의 VPC 가 될 수 있댜.
이렇게 VPC 끼리 서로 연결, 통신해야할 때 VPC Peering 서비스를 이용한다.
1.VPC Peering 기본사항
- 연결할 VPC 의 CIDR 이 달라야 한다.
- 2개의 VPC만 서로 연결된다. (전이되지 않는다 라고도 표현함)
예를 들어 A,B,C VPC 가 있고, A-B , B-C 로 피어링이 되어있다고 가정하면, 피어링 구성이 안된 A-C 로도 통신이 될거라 생각할 수 있다.
그러나 A-C VPC는 피어링이 구성되지 않았기에 A-C VPC 는 서로 통신할 수 없다.
A-C VPC를 서로 통신하게 하려면 A-C VPC 간 피어링 구성을 해야 한다.
즉 A,B,C VPC 모두 서로 통신을 위해서, 피어링을 각각 따로 구성(A-B, A-C, B-C)해야 한다.
- 피어링 구성 후 연결할 각각 VPC의 서브넷에 연결된 라우팅 테이블을 수정해야 한다.
어찌 됐든 다른 대역의 네트워크와 통신하기 때문에 연결할 VPC 서브넷의 라우팅 테이블을 수정해야 한다.
- 다른 계정의 VPC와 연결 시 리전을 넘나들 수 있다.
(서비스에 따라서 다른 리전과의 통신 시 비용이 발생할 수 있으므로 유의할 필요가 있다.)
- VPC 피어링은 같은 리전의 보안그룹을 참조할 수 있다.
(같은 리전에서 피어링된 VPC의 보안그룹 참조 가능, 같은 리전이라면 계정에 관계 없이 참조 가능)
2.VPC Peering 구성
구성 자체는 그리 어렵지 않다.
VPC 피어링 서비스 로 연결할 VPC 를 지정한 후, 연결할 VPC 서브넷 각각의 라우팅 테이블을 수정해주면 끝이다.
(A VPC 와 B VPC 를 연결하면, A VPC 서브넷 라우팅 테이블과 B VPC 서브넷 라우팅 테이블
두개 모두를 수정해야 한다.)
구성하기 전에 NACL 이 생성되어 있다면 생성한 NACL 을 삭제하고 디폴트 NACL을 인바운드, 아웃바운드 ANY로 허용해야 한다. 마찬가지로 각 인스턴스의 보안그룹도 허용정책이 있는지 점검한다. (NACL, 보안그룹 실습한 것을 그대로 수행하면 안될 수 있기 때문)
우선 두개의 VPC 가 필요하므로 테스트용 VPC와 디폴트 VPC 두개를 사용한다.
디폴트 VPC 에 서브넷을 별도로 추가해준다.
VPC 피어링은 Peering connections 라는 메뉴이다. VPC Peering 이라고 되어 있지 않으니 유의 해야 한다.
Create peering connection 으로 peering connection 을 생성한다.
requester 와 accepter VPC 가 있는데 연결하고자 하는 VPC 두개 중 어떤 것을 requester/accepter로 설정해도 차이가 없다. 즉 A,B VPC 가 있으면
requester (A VPC), accepter (B VPC) 설정이나, requester (B VPC), accepter (A VPC) 설정이나 둘 다 같은 연결이기 때문이다.
VPC 피어링은 하나의 연결만 구성하면 양방향 통신이 가능하다.
그렇기 때문에 requester (A VPC), accepter (B VPC) 연결을 만들고
requester (B VPC), accepter (A VPC) 연결을 만들 수 없다. 어차피 두개의 연결은 같은 것이기 때문에 중복된다고 보는 것이다.
나머지 account 는 같은 계정의 VPC 인 경우 MY account를 , 다른 계정인 경우 Another account 를 선택하고, 연결할 VPC 가 있는 계정을 입력,선택한다.
Region 은 같은 리전의 경우 this region , 다른 리전의 경우 another 리전을 체크 후 연결할 VPC 가 있는 리전을 선택한다.
그렇게 피어링 연결을 생성하면, pending acceptance 라고 되어 있는데, 이것은 수락을 기다린다는 의미이다. 수락을 해야 active 로 활성화 되어 사용가능하다.
수락을 위해선 우측 action 의 accept request 를 선택하고 accept request 를 클릭한다.
디폴트 vpc ec2 생성하는데 VPC는 디폴트, 서브넷은 생성한 서브넷을 선택한다.
이미 선택되어 있어서 하단의 보안그룹 allow ssh traffic, allow http traffic 만 체크했다. curl 명령어를 테스트 위함이다.
curl 명령어를 테스트해야 하므로 아파치 웹 서버 설치 명령어를 userdata로 저장한다.
디폴트 VPC의 디폴트 라우팅을, 생성한 디폴트 VPC 서브넷에 연결한다.
그리고 디폴트 VPC 라우팅 테이블에, 생성한 피어링 연결을 추가해야 한다.
목적지는 다른 VPC 의 사설 IP 대역을 입력한다.(특정 서브넷으로만 제한하고 싶다면
서브넷 IP 대역을 입력해도 된다.) target 은 Peering Connection 으로 하고 생성해둔 peering connection을 선택한다.
그리고 디폴트 VPC가 외부 인터넷에 연결해야 하므로 목적지 0.0.0.0/0, 타겟 Internet gateway(디폴트 인터넷 게이트웨이를 선택한다) 인 라우팅을 추가한다.
(이미지에서는 이미 추가되어 있다.) 그리고 save change로 저장 한다.
저장 후 결과를 보면 모두 active 로 잘 되어 있는 것을 볼 수 있다.
그런데 간혹 blackhole 로 되어 있는 경우가 있는데 이것은 라우팅 레코드가 유효하지 않다는
의미이다. 지정한 타켓이 비활성화 되어 있거나, 통신 문제 등이 원인인 경우 blackhole 로 표시된다. 이런 경우 설정한 라우팅 레코드를 수정해서 active 로 활성화해야한다.
반대쪽 테스트용 VPC 라우팅 테이블도 수정해야 한다.
타켓은 동일하게 지정하고, 목적지는 연결 대상의 VPC 로 바꿔주면 된다.
여기는 디폴트 VPC 사설대역이므로 172.31.0.0/16을 입력했다.
설정 후 라우팅 레코드가 active (정상)임을 확인한다.
피어링 연결 및 각 vpc 의 라우팅 테이블을 수정했으니 테스트를 해볼 차례다
디폴트 VPC의 EC2 인스턴스에서 테스트 VPC EC2 인스턴스로 CURL 명령어를 사용하면, 결과가 정상 출력된다.
반대로 테스트 VPC의 EC2 인스턴스에서 디폴트 VPC EC2 인스턴스로 CURL 명령어를 사용하면, 결과가 정상 출력됨을 볼 수 잇다.
보안그룹에 ICMP 정책이 없으니 PING 은 안될 것이다 PING 테스트를 하고 싶으면 보안그룹에 ICMP ALL 정책을 추가한다.
PING 테스트도 잘 된다.
이번 과정을 구성도로 그려보면 위와 같다.
두개의 VPC가 VPC Peering 에 의해 연결되어 있다.
