통신 흐름을 간단히 설명하자면 EC2 가 있는 서브넷의 라우팅 테이블에서 목적지를 확인 후 NAT 쪽으로 라우팅이 될 것이고, NAT 에서는 변환된 Private IP를 통해 TGW를 거쳐 라우팅 테이블을 확인 후 On-Prem 쪽으로 트래픽이 넘어가게 된다.
참고 : AWS, 프라이빗 통신을 위한 인터넷 게이트웨이에 대한 NAT 게이트웨이의 종속성 제거
위는 Private NAT 가 위치할 nat subnet 을 추가로 생성하였다.
app subnet 의 라우팅 테이블
해당 서브넷 중 특정 IP 들이 NAT 를 통해 하나의 IP 로 통신이 되어야 하기에 라우팅은 위와 같다.
nat subnet 의 라우팅 테이블
또한, local 대역 이외에는 TGW 에서 라우팅 처리를 하였기에 통신할 각 대역을 넣지는 않고, 0.0.0.0/0 으로 라우팅을 작업하였다.
# IP는 민감한 사항으로 가린 결과를 출력
[root@ec2 ~]# ping 10.181.x.x
PING 10.181.x.x (10.181.x.x) 56(84) bytes of data.
64 bytes from 10.181.x.x: icmp_seq=1 ttl=242 time=13.3 ms
64 bytes from 10.181.x.x: icmp_seq=2 ttl=242 time=8.10 ms
64 bytes from 10.181.x.x: icmp_seq=3 ttl=242 time=9.35 ms
64 bytes from 10.181.x.x: icmp_seq=4 ttl=242 time=8.87 ms
64 bytes from 10.181.x.x: icmp_seq=5 ttl=242 time=7.58 ms
^C
--- 10.181.x.x ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 11013ms
rtt min/avg/max/mdev = 7.579/10.425/15.147/2.495 ms
위는 인스턴스에 Attach 된 ENI VPC Flowlogs
위는 NAT 의 ENI VPC Flowlogs
로그가 남는데 시간이 걸리지만, 구성한 아키텍처로 정상적으로 통신이 되는 것을 확인할 수 있었다.
NAT GW를 프라이빗한 용도로 잘 사용하지는 않을 것이다.
위와 같은 아키텍처에서 온프렘의 라우터 장비에서 N:1 로 NAT 가 된다면 문제가 없겠지만, 아무래도 범용적으로 사용보단 특수한 상황(개요에서 언급했던 하나의 IP로만 특정 IP와 통신이 이뤄져야 함)일 때 고려해볼 수 있을 것으로 생각한다.