들어가며
이번 실습은 서로 격리되어있는 VPC 사이에 네트워크를 연결하는 서비스에 대해 공부할 것이다.
VPC Peering 를 실습을 통해 VPC 간 통신을 하는 흐름을 이해하는것을 목표로하였다.
VPC Peering
VPC Peering 이란 서로 격리된 2개의 VPC 를 사설망 기준으로 연결해 내부망처럼 통신하게 만드는 연결선이다.
AWS 에서는 항상 비용이 중요하다. 비용을 알아보면
Peering 연결 리소스 자체는 무료
데이터 전송은 위치에 따라 다르다.
즉 같은 리전 + 같은 AZ 안에서 사용해야 과금을 피할 수 있는 구조이다.
VPC Peering 은 개념자체는 어렵지않아 바로 실습으로 흐름을 이해하는것이 중요하다.
실습

실습은 서울 리전에 (VPC1, VPC2) 과 서울 리전(VPC 1) 과 프랑크푸르트 리전(VPC) 을 Peering 으로 연결해보는것을 진행할 것 이다. (사진은 버지니아지만 프랑크푸르트로 진행)
VPC → 피어링 연결 → 피어링 연결 생성

피어링 연결을 생성하면 받는쪽에서 요청 수락을 해야한다.

통신하기 위해 RT 변경 (VPC 1)

통신하기 위해 RT 변경 (VPC 2)

이때
VPC 1 = 10.0.0.0/16
VPC 2 = 10.10.0.0/16
네트워크 확인

인바운드 규칙 변경 (VPC1 source의 모든 트래픽 허용)

ping 으로 확인

프랑크푸르트 리전 VPC ID 확인 (vpc-0f613a7f6701219bf)
서울 리전 -> VPC 콘솔 -> 피어링 연결 -> 피어링 연결 생성

VPC Peering 수락
VPC 콘솔 메인 화면 → 피어링 연결 리소스 탭
서울 리전 RT 수정
라우팅 추가 버튼 클릭
변경 사항 저장 버튼 클릭
프랑크푸르트 리전 RT 수정
라우팅 추가 버튼 클릭
변경 사항 저장 버튼 클릭
ping (프랑크푸르트 vpc 내 ec2 서버 ip = 10.30.40.115)

서울 VPC1 ↔ 서울 VPC2 피어링
서울 VPC1 ↔ 프랑크푸르트 VPC3 피어링
이때 VPC2 → VPC3(프랑크푸르트) 를 VPC1을 경유해서 바로 가는 것 = 전이적(Transitive) 통신이라 한다. AWS 에서는 전이적 라우팅을 지원하는지 확인해 볼 것이다.
Routing Table 수정
서울 리전 -> VPC -> 라우팅 테이블 -> 라우팅 편집
라우팅 추가 버튼 클릭
프랑크푸르트 리전 -> VPC -> 라우팅 테이블 -> 라우팅 편집
라우팅 추가 버튼 클릭
확인을 위해 프랑크푸르트 리전 네트워크 서버에 접속

Session Manager 란?
System Manager에서 지원하는 기능으로 웹 브라우저에서 EC2 Server의 Terminal 접속이 가능하게 해준다.
SSM 은 키페어가 아닌 AWS 내부적으로 구성된 기술에 의해 웹브라우저를 통해 들어간다.
즉 키페어를 분실하는 급한 상황에서 사용한다.
연결테스트(ping) - 서울 리전 VPC 2 (10.10.40.228)

통신이 안되는것을 볼 수 있다. 즉 AWS 에서는 전이적 피어링을 지원하지않는다.
AWS 공식문서를 확인하면 AWS 가 막는 이유는
1. 보안 신뢰 경계를 명시적으로 강제하려고
2. 라우팅/운영 복잡도 폭증 방지
3. 'Edge-to-edge routing’ 금지 정책과 같은 철학
으로 확인할 수 있다.
만약 연결하고 싶으면 vpc2 와 vpc eu 1 을 서로 피어링해야한다.
마무리
이번 시간에는 VPC Peering 에 대해 알아보고 실습으로 진행하였다. 개발이 되었든 AWS 가 되었든 모든 통신은 네트워크를 통해 진행되는것이라 이번 개념이 중요하다고 느꼈다. 현재는 실습이라 비용을 생각하지않고 기능을 익히는것을 목표로 하였지만 실제로 프로젝트에서는 비용을 우선 시 하는것이 중요한거같다.