AWS Transit Gateway와 Site-to-Site VPN을 이용한 오피스 네트워크 구성
원티드 VPC 구성에 사용한 AWS Transit Gateway와 Site-to-Site VPN 서비스에 대해 작성해보았습니다.
목차
- 배경
- Transit gateway 란?
- Site-to-Site VPN 이란?
- 원티드 네트워크 구성의 변화
- 마치며
배경
- 사내에서는 VPN 연결 없이 AWS 리소스에 접근하고 싶다.
이전에는 공유 오피스의 무선 네트워크를 사용 중이어서 AWS 의 가상 네트워크인 VPC와 내부 네트워크 간 연결이 힘들었습니다. 그래서 AWS 인프라에 OpenVPN 서버를 직접 운영하였고 VPN 연결을 통해 AWS 리소스에 접근해왔습니다.
최근 사무실이 이사하게 되면서 전용 네트워크를 구축하게 되었고, 내부 네트워크와 AWS VPC를 연결해 사내에서는 바로 AWS 리소스에 접근이 가능하면 좋겠다고 생각했습니다.
- 여러 VPC 간의 효율적인 연결이 필요하다.
서로 다른 VPC 내 리소스에 접근 및 데이터 전송이 가능하게 하려면 각 VPC 간의 연결이 필요합니다. 이전에는 각 VPC마다 OpenVPN 클라이언트를 구성하고 OpenVPN 서버를 통해 트래픽을 라우팅해왔습니다. 그러다 보니 새 VPC가 생길 때마다 OpenVPN 서버 설정을 수정하고 서비스를 재시작해야 하는 번거로움이 있었습니다. 또한, OpenVPN 용도로만 사용해서 저렴한 서버를 이용했었는데 서버의 유형이 네트워크 성능에 영향을 미치는 이슈도 있었습니다. 이에 원티드 AWS 인프라 내 다수의 VPC를 조금 더 효율적으로 연결할 수 있으면 좋겠다고 생각했습니다.
위의 두 가지 니즈로 AWS Transit Gateway와 Site-to-Site VPN 서비스를 사용하게 되었습니다.
Transit Gateway 란?
먼저 Transit Gateway를 설명하기에 앞서, 두 VPC 간에 트래픽을 라우팅 할 수 있도록 연결해주는 기능으로는 VPC 피어링이 있습니다. VPC 피어링을 하게 되면 두 VPC가 서로 동일한 네트워크에 속하는 것처럼 통신할 수 있습니다. 하지만 VPC 피어링은 상호 연결이기 때문에 VPC A 와 VPC B가 피어링되어있고 VPC B와 VPC C가 피어링되어있을때, VPC A에서 VPC C로의 전이적인 트래픽 전달은 불가합니다.
따라서 n개의 VPC를 모두 연결하기 위해서는 n(n-1)/2개의 피어링 연결이 필요하게 되고, VPN 연결을 하기 위해서도 모든 VPC마다 VPN 터널링이 필요합니다. VPC A와 B가 피어링이 되어있다고 해도 사용자는 VPC A에 대한 VPN 연결을 통해 VPC B에 직접 액세스할 수 없기 때문입니다.
그러면 아래의 그림2처럼 아키텍처가 복잡해질 뿐만 아니라 새 VPC를 연결할때마다 매번 다른 VPC들과 피어링 연결을 해주어야 하고, 사용자들은 접근하려는 VPC 마다 매번 다른 VPN 연결을 해야하는 과정이 매우 번거롭습니다.
이러한 문제점을 해결하기 위해서 Transit Gateway를 사용하게 되었습니다. VPC의 수가 늘어남에 따라 구성이 복잡해지는 VPC 피어링과는 달리, Transit Gateway는 단일 연결로 다수의 VPC 또는 VPN 간의 트래픽을 관리할 수 있습니다. 그림2의 구성과 그림3의 구성은 동일한 기능을 제공하지만, 그림3처럼 Transit Gateway를 이용하면 여러 VPC를 효율적으로 연결하고 관리할 수 있게 됩니다.
Site-to-Site VPN 이란?
Site-to-Site VPN은 자체 네트워크와 AWS VPC를 연결해주는 VPN 서비스입니다. 자체 네트워크의 고객 게이트웨이(Customer Gateway)와 AWS Transit Gateway를 연결하는 라우팅을 구성하여 자체 네트워크와 AWS VPC 간의 트래픽 전달이 가능하게 합니다. Site-to-Site VPN을 통해 사내에서는 VPN 연결 없이 바로 AWS 리소스에 접근할 수 있게 됩니다.
Transit Gateway에서 VPN 연결을 설정하면 Site-to-Site VPN 구성이 자동으로 생성되며, Transit Gateway를 생성하고 설정하는 방법은 아래 도큐먼트에서 자세히 확인 가능합니다.
원티드 네트워크 구성의 변화
기존에는 OpenVPN 서버와 클라이언트 서버를 이용해 VPC 간의 트래픽을 라우팅했고, 사용자들은 VPN 연결을 통해서만 AWS 리소스에 접근할 수 있었습니다. OpenVPN 서버 운영을 위해서 t3a.small 인스턴스 4대를 사용하였고, 한 달에 약 54 달러의 비용이 발생하고 있었습니다.
Transit Gateway와 Site-to-Site VPN 서비스를 사용함으로써, 사내 전용 네트워크와 각 AWS VPC가 하나의 네트워크에 속하는 것처럼 통신 가능하게 되었습니다. Transit Gateway의 경우 연결 하나당 약 50달러 * 4개의 연결로 한 달에 약 200달러, Site-to-site VPN은 한 달에 약 40달러 정도로 총 240달러의 비용이 발생하고 있습니다. (데이터 처리 비용은 별도로 발생합니다.)
Transit Gateway와 Site-to-Site VPN 서비스를 이용함으로써 비용은 4배 정도 증가하였지만, 기존의 네트워크 구성을 유지하기 위해서 서버의 유지관리와 모니터링에 꽤 많은 시간과 인적 비용이 들었다는 점을 생각해보았을때 크게 비싼 비용은 아니라는 생각이 듭니다.
마치며
AWS VPC를 관리해야하는 입장에서 Transit Gateway와 Site-to-Site VPN 서비스를 이용해 오피스 네트워크를 구성하고 직접 사용해보았을때, 여러 VPC와 VPN 서버를 운영하면서 발생하던 서버 설정 수정이라거나 모니터링과 같은 관리 포인트가 줄어들어 편했습니다.
혹시 VPC 운영과 관리에 시간과 노력이 많이 들고 있다면, Transit Gateway와 Site-to-Site VPN 같은 관리형 서비스를 활용해보아도 좋을 것 같습니다.
다음에는 Contactless(언택트) 시대! 재택 근무하는 직원들을 위한 외부에서 원티드 인프라에 접근하는 방법에 대해 작성해보겠습니다.
감사합니다.
References
https://docs.aws.amazon.com/ko_kr/vpc/latest/peering/invalid-peering-configurations.html
https://docs.aws.amazon.com/ko_kr/vpn/latest/s2svpn/VPC_VPN.html
