AWS — GCP간 VPN 연결 방법

멀티 클라우드 환경에서의 VPN

멀티 클라우드 환경에서 효율적인 데이터 통신과 보안을 유지하기 위해서는 각 클라우드 간에 안전하고 신뢰할 수 있는 연결이 필요합니다. 이를 위해 VPN(Virtual Private Network)은 중요한 역할을 합니다. VPN을 사용하면 AWS와 GCP 같은 멀티 클라우드 환경 간에 암호화된 연결을 구축하여 데이터를 안전하게 전송할 수 있습니다. 이러한 AWS와 GCP간 site-to-site VPN 연결 방법을 아주 쉽게 설명해보려 하고, 이 글 외에도 각 클라우드 환경에서 도메인 쿼리 하는 방법들에 대해서도 아래 글로 함께 정리했고 순서대로 읽어주시면 좋을 것 같습니다.

1. AWS-GCP VPN 연결 방법
2. GCP Private Service Connect와 GCP Private Access방법들
3. AWS에서 GCP Cloud DNS 사용
4. GCP에서 AWS Route53 사용

VPN 연결의 장점

• 안전한 연결: site-to-site VPN은 인터넷을 통해 암호화된 터널을 생성하여 네트워크 간의 통신을 보호합니다. 이를 통해 데이터가 인터넷을 통해 전송되는 동안 안전하게 유지됩니다.
• 데이터 보안: site-to-site VPN은 데이터 전송을 암호화하여 외부로부터의 무단 액세스와 데이터 유출을 방지합니다. 이는 비즈니스 데이터의 보안을 강화하고 중요한 정보가 노출되지 않도록 보호합니다.
• 효율적인 데이터 통신: 각 CSP(Cloud Service Provider)의 격리된 VPC를 연동하여, 직접 사설 통신이 가능하게 하고, CSP의 Managed Service와 통신할 때도, 공인 IP를 이용하지 않고 직접 통신할 수 있습니다.
• 비용 절감: 사용 형태에 따라 다르지만, 보안을 위해 도입한 VPN이 오히려 비용 절감의 효과를 불러일으킬 수 있습니다.

Architecture

• 위 AWS — GCP 간 아키텍처는 AWS 서버에서 Google API(googleapis.com)에 대해 요청을 보냈을 때의 예시입니다. (이번 글에서는 VPN 연동 방법만 설명하고, 다음 글에서 하나씩 자세히 설명하겠습니다.)
• 모든 워크로드를 하나의 Cloud Provider에서 운영하는 경우도 있지만, 기업의 필요에 따라 멀티 클라우드를 사용하는 경우도 많습니다.
• 예를 들어, 대고객 서비스용 워크로드는 AWS에서 운영하고, 분석용 워크로드는 GCP에서 운영하는 형태 등 워크로드별로 여러 Cloud Provider들을 사용하기도 합니다.
• VPN 연동과, 각 클라우드 서비스 간 DNS Forwarding 작업 등이 이루어지면, AWS -> GCP api로의 요청, GCP -> AWS api로의 요청, 또는 서로 다른 클라우드 환경에 있는 각 서버끼리의 직접 사설 통신이 가능하게 됩니다. 따라서, AWS와 GCP에 구성한 별개의 Network 환경이 하나의 Network 환경에 있는 것과 똑같이 통신될 수 있습니다.
• AWS Route53과 GCP Cloud DNS의 Private Zone이 있다면, 기본적으로는 연결된 VPC에서만 도메인 룩업을 할 수 있습니다. 하지만 AWS에서 Cloud DNS Private Zone, 그리고 GCP에서 Route53 Private Zone에 도메인 룩업하는 방법은 다른 블로그 글에서 자세히 설명해보겠습니다.
• 기본적으로는 AWS — GCP간 VPN연동을 할 경우, 물리적인 거리가 있기 때문에 CSP끼리 최대한 근접한 리전에 VPN을 각각 구성해야, 불필요한 통신 지연을 방지할 수 있습니다.
• e.g) AWS ap-northeast-2(Seoul) — GCP asia-northeast3(Seoul)
• AWS에서 VPC는 Region이 제한되어 있는 리소스이고, GCP VPC는 global리소스 입니다. 또한 AWS에서 Subnet은 Zone이 제한되어 있는 리소스이고, GCP Subnet은 Region만 제한되어 있는 리소스 입니다. 따라서 GCP는 한 VPC 내에 여러 리전의 서브넷을 가질 수 있습니다.

AWS — GCP간 VPN 연동 시나리오

AWS — GCP 간 연동을 했을 때 얻을 수 있는 이점들에 대해서 위에서 간략히 설명했지만, 이를 VPN 연동 전과 연동 후를 비교해가면서 어떤 이점들이 있는 지 간략한 가상의 시나리오를 통해 말씀드리겠습니다.

[비용 절감] AWS에서 서비스를 운영하지만 주기적으로 GCP로 대량의 데이터를 보내는 경우

• 위 그림과 같이 AWS에서 발생한 수많은 데이터를 GCP BigQuery에서 분석하기 위해 AWS에서 GCP로 보낸다고 가정해봅시다.
• VPN이 연동되어 있지 않다면, BigQuery로 데이터를 보낼 때마다, AWS VM -> NAT Gateway -> 인터넷 -> GCP BigQuery 의 경로로 트래픽이 흐를 것입니다.
• 위 트래픽 플로우 상 발생하는 네트워크 트래픽 관련 비용은 아래와 같습니다(서울 기준). NAT Gateway에서 처리되는 Data당 요금: $0.059(GB 당) Outbound 데이터 전송 요금: $0.126(GB 당)
• 하지만 분석용으로 보내는 수많은 데이터들이 NAT Gateway를 통해 인터넷 환경으로 egress되어서 나갈 경우, 데이터 크기에 따라서 과금 되는 비용이 Outbound 데이터 전송 요금 $0.059(GB 당), NAT Gateway에서 처리되는 Data당 요금 $0.126(GB 당) 이 중복으로 과금됩니다. 만일 몇십~몇백 TB 단위 이상으로 데이터를 보낼 경우 꽤 큰 양의 데이터 비용이 과금될 것입니다.

• 하지만 위 그림과 같이 AWS에서 Google APIs를 사용할 때, NAT Gateway 구간을 거치지 않고 VPN 구간을 통해 트래픽이 이동하면, BigQuery로 보낼 때 발생하는 네트워크 트래픽 관련 비용이 감소할 것입니다.
• VPN 연동이 된다면, BigQuery로 데이터를 보낼 때마다, AWS VM -> TGW -> VPN 터널 -> GCP Private Service Connect(PSC) -> GCP BigQuery의 경로로 트래픽이 흐를 것입니다.
• 위 트래픽 플로우 상 발생하는 네트워크 트래픽 관련 비용은 아래와 같습니다(서울 기준). TGW에서 처리되는 Data당 요금: $0.02(GB 당) Outbound 데이터 전송 요금: $0.126(GB 당)
• 물론 Outbound 데이터 전송 요금은 그대로지만, Gateway가 NAT GW -> TGW로 변경되면서 Gateway에서 발생하는 처리 비용이 거의 1/3으로 줄게됩니다(데이터 전송 요금도 절감하고 싶다면, VPN이 아닌 Direct Connect를 고려해보시길 바랍니다.).

[보안 강화] GCP에서 AWS 서버와 직접 통신해야 하는 경우

• 위 그림과 같이 GCP 서버에서 AWS에 구축한 서버의 api에 접근해야 하는 경우가 있는데, 해당 api가 같은 AWS VPC 환경이나 내부에서만 사용할 수 있는 api라고 가정해봅시다.
• 그렇게 되면 해당 서버를 직접 public 인터넷 환경에서 사용할 수 있게 만들거나 사용하려는 api path만 예외적으로 public 인터넷 환경에 노출시키지 않으면 GCP에서 사용할 방법이 없습니다.

• 만일 VPN 연동으로 GCP 서브넷과도 비공개 통신을 할 수 있게 한다면, 별도로 private하게 사용되는 api를 public하게 노출시키지 않고도 GCP 서버에서 AWS 서버의 api를 사용할 수 있게 됩니다.
• 그리고 VPN 터널을 통해서 트래픽이 이동하므로 안전한 통신을 보장할 수 있습니다.
• 또한 해당 api에 대한 도메인이 연결된 AWS VPC에서만 질의될 수 있는 AWS Route53 Private Hosted Zone에 있다고 하더라도, GCP Cloud DNS와 Route53을 연동해서 GCP VM에서도 도메인 쿼리가 가능하게 설정할 수도 있습니다.

VPN 연동 방법

AWS VPN 세팅 방법

1. GCP VPN Gateway 설정

• AWS Customer Gateway 설정에는 상대측(GCP) Gatway의 external IP 설정이 필요하기 때문에, 먼저 GCP에서 VPN Gateway를 생성합니다.

• 자동으로 발급된 external ip를 확인합니다.
• 해당 external ip가 외부에 노출되지 않도록 주의합니다.
• 해당 VPN 서비스에 대한 권한은 Network를 담당하는 사람만 확인할 수 있게 제어합니다.
• vpn 세팅을 terraform 등 code로 관리한다면 secret manager에 public ip를 넣고 code에서는 해당 리소스를 참조하는 형태로 사용하는 것을 권장합니다.

2. AWS Customer Gateway 생성

• AWS VPC에서 Customer Gateway를 생성해줍니다.
• BGP ASN은 GCP측 ASN으로 설정해줍니다.
• GCP Cloud Router에서 확인할 수 있습니다.
• GCP ASN은 16550, 64512~65534, 4200000000~4294967294 사이의 숫자만 선택할 수 있으므로 아직 GCP Cloud Router를 구성하지 않고 Customer Gateway를 설정할 경우, 언급한 범위의 ASN 중에서 연동된 Network가 사용하는 ASN과 겹치지 않은 ASN을 설정합니다.
• IP address는 GCP VPN Gateway에서 할당 받은 IP로 설정합니다.
• 상용 환경에서는 high availability를 위해 2개의 Customer Gateway를 생성합니다.

3. VPN Connection 생성

• Customer Gateway 1개당 VPN Connection을 1개씩 만듭니다. 따라서 총 2개의 VPN Connection을 만들어줍니다.
• Target Gateway type은 VGW(Virtual Private Gateway)와 TGW(Transit Gateway)가 있습니다. 여기서는 TGW를 Target Gateway로 설정하겠습니다.
• VGW로 연동하면 VPN Connection이 2개가 있어도 Active/Standby로 사용해야 합니다.
• TGW로 연동하면 VPN Connection을 Active/Active 구조로 사용할 수 있습니다. 하지만 해당 TGW에서 처리하는 Data에 대한 GB당 요금($0.02)이 별도 청구됩니다. (참고)

• VPN Connection이 모두 만들어졌고, connection당 Tunnel이 2개씩 세팅되었습니다.
• 각 Tunnel이 생성되면서 위에서 GCP VPN Gateway만들어줬을 때와 마찬가지로 outside IP address가 하나씩 할당 됩니다.
• 해당 public ip도 해당 VPN을 운영하는 Network 관리자 외에는 볼 수 없도록 권한 제어를 합니다.
• 또한 Tunnel별로 /30짜리 inside ip도 할당 됩니다.
• 당연한 얘기지만, 아직 GCP측에서 Tunnel Setting을 해주지 않았기 때문에, IPSEC Tunnel은 Down상태입니다.
• Tunnel별 세부 Option설정도 할 수 있지만, 여기서는 연동 테스트가 목적이므로 별도로 추가 설정은 하지 않겠습니다.
• 우측 상단에 Download configuration을 클릭하면, VPN connection에 대한 configuration파일을 다운로드 할 수 있습니다.

4. VPN Connection configuration 저장

• VPN Connection을 선택하고 Download configuration을 클릭하면 configuration을 다운로드 받을 수 있습니다. On-Premise 장비와 연동하는 것이 아니므로 Vendor는 유명하고 익숙한 Cisco 장비를 선택해서 다운로드 받겠습니다. PC에 VPN ID 이름의 .txt 파일이 생성될 것입니다.

• 해당 txt파일을 확인해보면, 방금 AWS 콘솔에서 확인한 Outside/Inside IP Address뿐만 아니라 pre-shared-key 등을 볼 수 있습니다. 해당 값들은 모두 GCP VPN Connection을 만들 때 사용되므로 저장해놓습니다.
• pre-shared-key도 secret한 값으로 관리되어야 하기 때문에 유출되지 않게 조심합니다.

GCP VPN 세팅 방법

1. Peer VPN Gateway 생성

• AWS에서 Customer Gateway를 생성해줬듯이 GCP측에서도 Peer VPN Gateway를 생성합니다.

• AWS VPN Connection 생성할 때 할당된 Outside IP address를 입력해줍니다.
• AWS에서 2개의 CGW를 생성했고, 각 CGW당 VPN connection을 생성할 때, VPN connection별로 2개의 Tunnel을 만들어줬으므로 각 터널당 할당된 IP address 4개를 입력합니다.

2. Cloud Router 생성 (이미 있다면 생략)

• VPN Tunnel을 생성하기 위해서는 Cloud Router가 있어야 합니다.
• 만일 VPN 연동할 리전에 기존에 운영하던 Cloud Router가 있다면 별도로 생성하지 않아도 되지만, Cloud Router가 없다면 직접 생성해주세요.
• Advertised routes에서 연결된 모든 Subnet들을 광고하도록 설정할 수도 있고, Subnet외의 다른 GCP 대역들도 Custom하게 광고할 수 있습니다.

3. VPN Tunnels 생성

• 맨 처음에 생성한 VPN Gateway에서 ADD VPN TUNNEL 으로 VPN Tunnel을 구성합니다.
• 3–1. VPN Tunnels 생성

• Peer VPN gateway는 이미 생성한 AWS vpn gateway를 선택해서 넣습니다.
• High availability는 AWS와 연동하는 것이므로 Create 4 VPN tunnels를 선택합니다.
• Cloud Router는 방금 전 과정에서 생성한 Router를 입력하거나, 기존에 Cloud Router가 있다면 선택합니다.
• VPN Tunnel(4개)에 대한 정보들을 입력해넣어야 합니다. AWS VPN Connection configuration파일을 참고해서 필요한 값들을 입력합니다.
• Associated peer VPN gateway interface는 GCP Peer VPN Gateway생성할 때 입력했던 interface를 하나씩 입력해 넣습니다.
• IKE version은 AWS VPN Connection만들 때 설정한 값으로 입력합니다.
• IKE pre-shared key는 configuration파일에서 참고해서 입력합니다.
• connection이 4개나 되므로 헷갈릴 수 있지만, connection별로 알맞은 값을 입력하도록 합니다.

3–2. BGP Sessions 구성

• Tunnel을 구성하고 나면, Tunnel별로 BGP serssions를 구성해야 합니다.
• Tunnel별로 일일히 세팅해줘야 합니다.

• Peer ASN은 AWS측 ASN을 의미하므로 AWS에서 사용하는 ASN을 입력해줍니다.
• AWS VPN Connection 생성할 때, Target Gateway를 Transit Gateway 입력했는데, 해당 TGW의 detail을 확인해보면 설정된 ASN값을 확인할 수 있습니다.
• BGP IPv4 address는 AWS VPN Connections의 Tunnel 생성할 때 할당된 /30대역의 Inside IPv4 CIDR을 의미합니다.
• /30 대역의 IP이므로 실제로는 2개의 IP를 할당할 수 있는데, AWS측에서 해당 BGP IP(Inside IPv4 CIDR)을 구성했으므로, 순서가 빠른(=숫자가 작은) ip를 AWS IP(BGP peer IPv4 address)로 설정합니다.
• 나머지 순서가 느린(=숫자가 큰) ip를 GCP IP(Cloud Router BGP IPv4 address)로 설정합니다.

• AWS VPN Connections의 첫 번째 Tunnel의 Inside IPv4 CIDR 대역을 참고했습니다.
• 나머지 BGP Sessions도 일일히 설정해줍니다.

VPN Tunnel status 확인

• GCP VPN Tunnel/BGP Status를 확인할 수 있습니다.

• AWS에서도 마찬가지로 확인할 수 있습니다.

통신 테스트

aws subnet과 gcp subnet에 테스트용 vm을 하나씩 세팅해서 통신 테스트를 진행할 수 있습니다. 하지만 위 구성만 진행하고, vm간 ping 등으로 통신테스트를 바로 진행하면, 통신이 되지 않을 수 있습니다. 자주 빠뜨리거나 실수하는 부분을 아래에 정리하겠습니다.

통신 테스트 전 확인 및 추가 설정해야 하는 것들

1. aws subnet route table에 GCP CIDR 대역에 대해 TGW로 static routing 설정

위 VPN 연동을 통해 AWS TGW은 GCP CIDR 대역은 대해서 GCP로부터 대역을 광고 받기 때문에, 라우팅 경로를 이해하고 있지만, 실제 통신 테스트를 해야하는 VPC Subnet의 Route Table에서는 GCP CIDR 대역에 대한 Target이 따로 없기 때문에, 정상적인 경로를 찾아갈 수 없습니다. 따라서 반드시 통신이 필요한 Subnet의 Route Table에 GCP CIDR 대역을 Destination으로, Target은 TGW로 지정해서 라우팅 경로를 만들어줘야 통신이 될 것입니다.

그리고 통신되어야 하는 GCP CIDR가 여러 개일 경우, 해당 대역들을 AWS Managed Prefix List를 등록해서 관리하면, CIDR을 편하게 관리할 수 있습니다(참고).

2. GCP Firewall, AWS Security Group/ACL 등에서 상대측 대역을 허용

통신 테스트를 해야하는 VM을 AWS와 GCP에서 설정할 경우, 방화벽 설정도 함께할 것입니다. 해당 방화벽 설정에서 상대측 CIDR대역을 허용해줘야 통신 테스트를 정상적으로 수행할 수 있습니다.

통신 테스트(일반 인터넷 vs VPN)

1. 일반 인터넷 (from aws to gcp)

• 서울의 aws ec2에서 서울/오레곤/아이오와의 gcp vm에 ping한 결과 (일반 인터넷)
• seoul -> seoul avg: 3.3ms
• seoul -> oregon avg: 119.1ms
• seoul -> Iowa avg: 174.9ms

• 2. VPN (from aws to gcp)
• 서울의 aws ec2에서 서울/오레곤/아이오와의 gcp vm에 ping한 결과 (VPN 적용)
• seoul -> seoul avg: 5.4ms
• seoul -> oregon avg: 119.4ms
• seoul -> Iowa avg: 175.4ms 속도의 차이는 거의 없었고 반대로 GCP -> AWS로 통신테스트 했을 때도, 비슷합니다.

이렇게 AWS — GCP VPN 연동 방법을 알아봤고, 이를 IaC 도구인 Terraform으로 템플릿화하여 빠르게 세팅할 수도 있습니다. 물론 이렇게 AWS — GCP VPN 연동만 한다고, AWS와 GCP간 워크로드가 완벽하게 연결되는 것은 아닙니다. 실제로 AWS에서 GCP 서버를 호출한다고 했을 때, ip기반이 아닌 도메인 기반으로 호출할 것입니다. 그래서 상대측 DNS서비스에서 도메인 룩업을 하는 방법에 대해서도 별도 글로 정리하겠습니다. 그리고 이렇게 VPN 연결을 하게 되면, AWS에서 GCP Managed Service를 private ip(Private Service Connect)만 활용해서 호출하거나, GCP에서 AWS Managed Service를 private ip(VPC Endpoints)만 호출할 수도 있습니다. 이에 대한 내용도 별도의 글로 정리해보겠습니다.