[AWS Network] Transitive and non-transitive scenarios
AWS Advanced Networking에 대해서 공부하다가, Transitive 한 서비스와 그렇지 않은 서비스들을 구분하는 것이 꽤 자주 나왔고, 그것이 여러 시나리오에서 굉장히 중요한 개념이라는 것을 알게 되었습니다.
- VPC Peering vs Transit Gateway
- VPC Gateway Endpoint vs VPC Interface Endpoint (PrivateLink)
- Site-to-Site VPN Connection
등 많은 서비스에서 Transitive에 대한 개념이 등장합니다.
What is 'transitive'?
그림으로 설명하자면 다음과 같습니다. 해당 그림에서 Network 1과 Network 2는 연결되어 있습니다. 또, Network 2와 Network 3은 연결되어 있는데요, 이 상황에서 Network 1에서 Network 3으로 직접 연결할 수 있을까요? 직접 연결이 가능한 경우 Transitive 하다고 하며, 그렇지 않은 것을 Non-transitive 하다고 말합니다. 먼저 몇가지 앞전에 소개한 예시들을 보며 서비스들이 Transitive 한지 살펴보도록 하겠습니다.
1. VPC Peering vs Transit Gateway
VPC Peering은 위 그림과 같이 두 개의 AWS Virtual Private Cloud를 연결하는 서비스입니다. peering connection을 통해 두 VPC가 서로의 private subnet에 있는 리소스에 연결할 수 있습니다.
그렇다면 다음과 같은 시나리오에서는 어떨까요? VPC B - VPC A, VPC A - VPC C은 peering connection이 활성화 되어 있습니다. 하지만 다음과 같은 경우 VPC B는 VPC C의 private subnet에 위치한 리소스에 직접 연결할 수 없습니다. 즉, VPC Peering connection은 Non-transitive 합니다.
Transit Gateway는 VPC간의 복잡한 피어링 관계를 피하기 위하여 AWS가 제공하는 관리형 라우팅 서비스입니다. Transit Gateway는 VPC에 TGW ENI (Transit Gateway의 Elastic Network Interface)를 만듭니다. 서브넷 안의 리소스는 이 ENI를 통해 Transit Gateway로 요청을 보내고, Transit Gateway의 Routing policy에 따라 다른 VPC 또는 On-premise 네트워크로 연결할 수 있습니다.
그림에서도 볼 수 있듯(이름도 그렇듯이) Transit Gateway는 Transitive 합니다. 모든 네트워크가 서로 다른 네트워크에 연결할 수 있도록 구성이 가능합니다.
2. VPC Gateway Endpoint vs VPC Interface Endpoint (PrivateLink)
VPC Gateway Endpoint는 VPC 내부의 리소스가 AWS의 리소스(S3, DynamoDB)들에 연결할 때 Internet을 거치지 않고 AWS 내부 네트워크를 거쳐서 통신이 이루어질 수 있도록 도와주는 서비스입니다. 다음과 같이 Gateway를 생성하여 이것을 통해 private 한 connectivity를 가지게 됩니다.
해당 그림에서 VPC A는 VPC에 peering connection을 하고 있는데요, VPC A의 리소스는 VPC Gateway Endpoint를 통해 우측의 S3와 DDB에 직접 연결할 수 있을까요? 정답은 아닙니다. VPC Gateway Endpoint는 Non-transitive 하기 때문에, 해당 아키텍처에서 VPC A의 리소스가 Gateway Endpoint에 접근하려면 VPC의 리소스에 요청하여 대신 요청을 해달라고 하는 등 다른 방법을 사용해야 합니다.
VPC Interface Endpoint (PrivateLink)는 VPC Gateway Endpoint와 비슷하지만, VPC에 ENI를 프로비전하여 이를 통해 AWS 네트워크를 거쳐 다른 AWS 리소스들에 연결할 수 있도록 도와주는 서비스입니다.
VPC A가 VPC와 peering connection을 가지고 있습니다. 이 경우 VPC A의 리소스는 VPC의 ENI Interface Endpoint로 route 함으로써 AWS 네트워크를 거쳐 다른 AWS 리소스들에 연결할 수 있습니다. 따라서 이 경우 Transitive 하다고 말할 수 있습니다.
3. Site-to-Site VPN Connection
VPN은 remote network에서 VPC의 private subnet에 있는 리소스에 접근할 때 사용합니다. Site-to-Site VPN은 호스트들이(보통 VPC와 On-premise network) 암호화된 형태로 Internet을 거쳐 통신할 수 있게 해주는 서비스입니다. VGW(Virtual private gateway)에서부터 CGW(Customer gateway)까지 IPsec connection을 지원하여 Internet을 거치는 동안 안전한 통신이 가능하게끔 도와줍니다.
그림에서 X를 그려두어서 바로 눈치채셨겠지만, On-premise 네트워크에서 VGW - IGW(Internet Gateway)를 거쳐 직접 Internet과 통신하는 시나리오는 불가능합니다. VGW는 Gateway로, Non-transitive 하기 때문에 해당 연결을 이행할 수 없습니다.
만약 VPC의 IGW를 거쳐 Internet과 통신하고 싶다면 다음과 같이 NAT Instance를 배치하여 이를 거쳐 지나가도록 구성해야 합니다. NAT Instance는 ENI를 프로비전합니다. (NAT Gateway를 사용하는 경우엔 NAT Gateway의 restriction 때문에 통신이 불가합니다.)
지금까지 다양한 시나리오에서의 Transitive, Non-transitive 시나리오를 알아보았는데요, 왜 이런 차이가 생기는걸까요?
핵심은 ENI에 있었습니다. 지금까지 알아본 Transitive 한 시나리오에서, 저희는 ENI를 통해 트래픽을 송신하였습니다! 저희가 알아본 예제들에서 ENI는 저희가 거쳐가는 중간 VPC에 프로비전되어 최종 목적지로의 트래픽을 받아주는 네트워크 출장 서비스를 해주고 있습니다. 반면에 Non-transitive 한 시나리오들을 생각해보면 Gateway를 거쳐서 가는 시나리오였죠.
그런데 사실 Transitive 한 서비스들의 공통점이 있는데요, 비용이 상승한다는 점입니다. 실제로 VPC Peering, VPC Gateway Endpoint는 무료인 반면, Transit Gateway와 VPC Interface Endpoint는 비용이 청구되는 서비스입니다. 따라서 무조건 Transitive 한 구성이 좋다고 말할 순 없습니다. 오늘도 역시 결론은 "Tradeoff가 있다" 군요.
이상으로 다양한 아키텍처 상황에서의 네트워크 구성에 대한 제약사항에 대해 알아보았습니다. 읽어주셔서 감사합니다!