Today Keys : nat, snat, source nat, gateway, managed, aws, cloud, network, forward, 클라우드
AWS의 Private Subnet에서 인터넷으로 나가기 위해서 사용 가능한, Managed Service로 NAT Gateway가 있습니다.
NAT Gateway를 AWS 내 사설 IP에서 인터넷으로 가기 위한 용도 뿐 아니라,
On-Premise등 또 다른 사설로 가기 위한 Managed NAT로도 사용할 수도 있습니다.
이번 포스팅에서 NAT Gateway를 이용해서 VPC에서 다른 Private으로 가기 위한 Managed NAT로 사용해보는 예제입니다.
이번 포스팅에서 테스트를 위해서 만든 테스트 환경입니다.
왼쪽의 ZIGI-VPC에는 ZIGI-VPC1-Sub1이라는 10.0.0.0/25 대역을 가진 서브넷과
ZIGI-VPC1-Sub2에는 10.0.1.0/25 대역을 가진 서브넷이 있습니다.
오른쪽 ZIGI-VPC2에는 ZIGI-VPC2-Sub1이라는 10.1.0.0/24 대역을 가진 서브넷이 있습니다.
ZIGI-VPC1-Sub1과 ZIGI-VPC2-Sub1에는 각각 EC2 인스턴스가 있고,
ZIGI-VPC1-Sub2에는 이 둘 사이를 연결해줄 NAT Gateway가 있습니다.
ZIGI-VPC1-Sub1의 EC2는 ZIGI-VPC2-Sub1와 통신을 하기 위해서 NAT Gateway를 통해서 통신 할 예정입니다.
각각의 설정 정보입니다.
2개의 VPC Cidr을 확인할 수 있습니다.
ZIGI-VPC1-Sub1의 서브넷 정보와 라우팅 테잉블입니다.
목적지 EC2가 있는 10.1.0.0/24에 대해서는 NAT Gateway로 라우팅을 잡았습니다.
NAT Gateway가 있는 ZIGI-VPC1-Sub2에는 ZIGI-VPC2-Sub1의 EC2와 통신하기 위한 라우팅이 잡혀 있습니다.
VPC1과 VPC2는 Peering을 맺고, ZIGI-VPC1-Sub2와 ZIGI-VPC2-Sub1 간에만 라우팅을 잡았습니다.
ZIGI-VPC2-Sub1에는 앞서 말한 것처럼 ZIGI-VPC1-Sub2에 대해서만 피어링으로 라우팅이 잡혀 있습니다.
즉, VPC1과 VPC2는 피어링을 맺었지만, 실제 VPC1의 Sub1에 대한 라우팅이 VPC2의 Sub1에는 라우팅이 없기 떄문에
통신할 수 있는 경로가 존재하지 않습니다.
NAT Gateway 정보를 보면, Private IP주소로
ZIGI-VPC1-Sub2의 대역인 10.0.1.0/25 대의 주소인 10.0.1.25를 갖고 있는 것을 확인 할 수 있습니다.
자 이제 설정 정보까지 모두 확인하였습니다.
ZIGI-VPC1-Sub1의 대역은 ZIGI-VPC2-Sub1과 연결 포인트가 없습니다.
하지만, ZIGI-VPC1-Sub1의 EC2(10.0.0.11)에서 ZIGI-VPC2-Sub1의 EC2(10.1.0.127)으로
ping 테스트를 하면 정상적으로 통신이 되는 것을 볼 수 있습니다.
ZIGI-VPC2-Sub1의 EC2(10.1.0.127)에서 tcpdump로 확인해 보면,
출발지가 10.0.0.11이 아닌 NAT Gateway가 갖고 있는
10.0.1.25로 출발지가 IP가 NAT 되서 통신이 된 것을 확인할 수 있습니다.
이러한 NAT Gateway를 사용하면, 각 회사의 환경에서 제한적인 VPC IP addressing을 조금은 해소하면서
별도의 NAT Instance를 관리해야 하는 부분 대신에 Managed Service인 NAT Gateway를 사용해서
조금은 유연하게 설계 해 볼 수 있을 것 같습니다.
(물론 일반적인 케이스는 아니라고 생각하긴 합니다. ^^)
