클라우드 환경이 다변화되면서, 단일 CSP(Cloud Service Provider)에 모든 워크로드를 올려두는 경우는 점점 줄어들고 있습니다. 실제 운영에서는 멀티 클라우드(Multi-Cloud) 전략을 통해 서비스 안정성을 높이고, 각 클라우드가 가진 강점을 활용하는 경우가 많습니다.
특히 각 CSP별로 제공되는 Generative AI 서비스가 상이하여 요구사항에 맞춰 여러 CSP를 사용할 수 밖에 없는 상황이 존재합니다.

이번 글에서는 GCP의 Vertex AI를 Private한 통신으로 안전하게 통신하고자 하는 요건을 맞추기 위해 사전에 필요한 작업인 VPN을 구성해보고자 합니다.

다만, 이번 글에서는 Azure에 어플리케이션이 존재하고 GCP의 Vertex AI를 호출하기 위함이므로 Azure와 GCP간의 VPN 구성을 소개합니다.

이번 글에서는 Azure와 GCP 간 Site-to-Site VPN을 실제로 구성한 과정을 정리합니다.
기본적으로 두 클라우드 모두 Hub-Spoke 네트워크 구조를 사용하고 있으며, 따라서 단순히 Hub ↔ Hub 만 연결하는 것뿐만 아니라, Azure의 Spoke에서 GCP의 Spoke까지 트래픽이 어떻게 전달되는지가 중요한 포인트가 됩니다.
그에 따라 각 CSP 내에서 Hub-Spoke를 위한 Peering에 대한 개념도 간단하게 설명합니다.

아키텍처

주요 특징은 아래와 같습니다.

• 각 Vnet, VPC 간 통신 여부를 점검하기 위해 각각 VM / Compute Engine을 배치하였습니다.
• GCP의 VPN은 Classic(BGP 미사용) 버젼으로 설계하였습니다.

Azure와 GCP간 VPN을 연결하기 위한 자원 배포 순서는 아래와 같습니다.

배포 순서

1. Azure의 Vnet & Sunbet, GCP의 VPC  & Subnet 생성
2. Azure VPN Gateway 생성
3. GCP 외부 IP(Public IP) 생성
4. Azure Local Network Gateway 생성
5. Azure Connection 생성
6. GCP VPN 연결(게이트웨이 & 터널) 생성
7. 연결 확인

---

1. Azure의 Vnet & Sunbet, GCP의 VPC  & Subnet 생성

본 글에서는 생성에 대한 것은 다루지 않으며 생성에 필요한 정보만 제공합니다.

• Azure Hub Vnet(10.0.0.0/.21)
  • GatewaySubnet(10.0.0.0/24) : VPN Gateway 사용
  • hub-app-snet(10.0.1.0/24) : VM 사용
• Azure Spoke1 Vnet(10.1.0.0/21)
  • spoke1-app-snet(10.1.0.0/24) : VM 사용
• Azure Spoke2 Vnet(10.2.0.0/21)
  • spoke2-app-snet(10.2.0.0/24) : VM 사용
• GCP Hub VPC(VPC는 대역 없음)
  • hub-snet(10.3.0.0/24) : 미사용
  • hub-app-snet(10.3.1.0/24) : Compute Engine 사용
• GCP Spoke VPC(VPC는 대역 없음)
  • spoke-app-snet(10.4.0.0/24) : Compute Engine 사용

2. Azure VPN Gateway 생성

Azure VPN Gateway는 아래와 같은 설정으로 생성합니다.

• 네트워크 : Hub Vnet의 GatewaySunbet 지정
• active-active 모드 / BGP 구성 : 사용 안함

3. GCP 외부 IP(Public IP) 생성

GCP 콘솔에서 GCP VPN Gateway로 사용할 외부 IP(Public IP)를 미리 생성합니다.
Azure Local Network Gateway 생성에 필요하여 사전에 생성하도록 합니다.

4. Azure Local Network Gateway 생성

• IP 주소 : GCP에서 생성한 외부 IP(Public IP)
• 주소 공간 : GCP Subnet 대역들(or Subnet을 포함하는 임의의 대역)

5. Azure Connection 생성 

• 연결 형식 : 사이트 간(IPsec)

• 위에서 생성한 VPN Gateway, Local Network Gateway를 선택
• 공유 키(PSK)는 임의의 값을 입력
• BGP 사용 : 체크 해제
• 그외 모두 기본 값을 적용

6. GCP VPN 연결(게이트웨이 & 터널) 생성

• 본 글에서는 기본(Classic) VPN으로 구성합니다.

• GCP의 Hub VPC를 선택
• IP 주소는 위에 3번에서 만든것을 선택합니다.

• 원격 피어 IP 주소 : Azure의 VPN Gateway의 Public IP 주소
• IKE 사전 공유 키 : Azure Connection 생성시 입력했던 것과 동일한 것 입력(여기서는 "Password!234")
• 원격 네트워크 IP 범위 : Azure의 Vnet IP 대역(여기서는 Hub IP 대역만 우선 입력)

7. 연결 확인

• 생성이 완료되면 GCP의 터널 정보에는 아래와 같이 상태에 "Tunnel is up and running"이 표시됩니다.

• Azure에서 만든 Connection에서 상태가 "연결됨"으로 VPN의 터널링 구성이 정상적임을 확인 할 수 있습니다.

이제 각 Vnet / VPC 에서 실제로 통신을 점검하기 위한 ping 테스트를 진행하며 자세하게 확인합니다.
 

---

각 통신 확인을 위한 VM들의 정보는 아래와 같습니다.

VM 정보

1. Azure Hub VM : 10.0.1.4
2. Azure Spoke1 VM : 10.1.0.4
3. Azure Spoke2 VM : 10.2.0.4
4. GCP Hub VM : 10.3.1.2
5. GCP Spoke VM : 10.4.0.2

테스트 시나리오

1. Azure Hub <> Spoke 간 통신 확인
2. GCP Hub <> Spoke 간 통신 확인
3. Azure Hub <> GCP Hub 간 통신 확인
4. Azure Spoke <> GCP Hub 간 통신 확인
5. GCP Spoke <> Azure Hub 간 통신 확인
6. Azure Spoke <> GCP Spoke 간 통신 확인

---

1. Azure Hub <> Spoke 간 통신 확인

• Hub와 Spoke는 현재 각각 논리적으로 분리된 Vnet이므로 연결(Peering)을 진행합니다.
• 왼쪽(hub Vnet)에 설정된 Peering 정보 / 오른쪽(Spoke1 Vnet)에 설정된 Peering 정보입니다.
  • Spoke2도 Hub와 마찬가지로 진행합니다.

• Hub -> Spoke1, Hub -> Spoke2 통신 확인 : 정상

• Spoke1 -> Hub, Spoke2 -> Hub 통신 확인 : 정상

2.GCP Hub <> Spoke 간 통신 확인

• GCP도 Azure와 마찬가지로 Hub와 Spoke VPC는 논리적으로 분리되어있으므로 연결(Peering)을 진행합니다.
• 각 VPC(Hub, Spoke)에 Peering을 모두 설정해야 아래와 같이 상태가 "활성"으로 표시되며 정상적인 상태가 됩니다.
  • 또한 Hub VPC에서 연결하는 피어링은 커스텀 경로를 "내보내기", Spoke VPC는 "가져오기"로 선택을 해야 추후 Azure와 통신 확인해서 문제 없이 진행 가능합니다.

• 다만, Azure와 다르게 명시적인 허용이 필요하여 각 VPC에 서로의 대역에 대해 ICMP를 허용하는 방화벽을 추가합니다.
• Spoke VPC에서는 Hub VPC의 일부인 Sunbet(10.3.1.0/24)에 대해 ICMP를 허용

• Hub VPC에서는 Spoke VPC의 일부인 Subnet(10.4.0.0/24)에 대해 ICMP를 허용

• Hub <> Spoke  통신 확인 : 정상

3. Azure Hub <> GCP Hub 간 통신 확인

• Azure의 NSG는 기본적으로 Vnet간 통신은 Allow되어있어 추가적인 설정은 불필요
• GCP의 Firewall에서 Azure Hub의 대역(10.0.0.0/24)에 대해서 ICMP 허용을 진행

• Azure Hub <> GCP Hub  통신 확인 : 정상

4. Azure Spoke <> GCP Hub 간 통신 확인

• 위에서 Azure의 Hub, Spoke Vnet간 피어링을 잘 설정했다면 관련해서는 추가 작업이 필요하지 않습니다.
• GCP의 경로에 Azure의 Spoke의 Vnet 대역을 아래와 같이 추가해야 합니다.
  • route-2, route-3과 같이 각각의 대역에 대해 다음 홉을 VPN Tunnel로 설정하여 생성합니다.

• GCP Hub <> Azure Spoke1 통신 확인 : 정상

• Azure Spoke2 > GCP Hub 통신 확인 : 정상

• GCP Hub >> Azure Spoke2 통신 확인 : 비정상

  • GCP Hub VPC의 방화벽에 Azure Spoke2 대역을 등록하지 않아서 통신 불가능

5. GCP Spoke <> Azure Hub 간 통신 확인

• 위와는 반대로 Azure에서 현재 GCP의 Spoke VPC 대역을 모르기 때문에 Local Network Gateway에 GCP VPC 대역을 추가합니다.

• 또한 GCP Peering을 위에서 잘 설정했다면 GCP Spoke VPC의 방화벽에 Azure Hub 대역에 대해서 ICMP를 허용합니다.

• GCP Spoke <> Azure Hub 통신 확인 : 정상

6. Azure Spoke <> GCP Spoke 간 통신 확인

• 1~5번까지 필요한 사항들을 모두 적용하면서 따라왔다면 추가 작업은 필요없으며 아래와 같은 결과를 확인 할 수 있습니다.

• GCP Spoke -> Azure Spoke1, Azure Spoke2 통신 확인 : 정상

• Azure Spoke1 -> GCP Spoke 통신 확인 : 정상

• Azure Spoke2 -> GCP Spoke 통신 확인 : 비정상

  • 위 4번과 마찬가지로 GCP Spoke의 VPC에서 Azure Spoke2에 대한 Vnet 대역에 ICMP를 허용하지 않아서 통신 비정상입니다.

요약

시나리오	정상 여부	필요한 설정
Azure Hub ↔ Azure Spoke	✅ 정상	Hub ↔ Spoke 간 VNet Peering 설정 Azure NSG는 기본적으로 허용되어 별도 방화벽 설정 불필요
GCP Hub ↔ Azure Spoke	✅ 정상	Hub ↔ Spoke 간 VPC Peering 설정 (양쪽 모두) Hub: 경로 내보내기 / Spoke: 경로 가져오기 설정 GCP 방화벽: Hub ↔ Spoke Subnet 대역에 대해 ICMP 허용
Azure Hub ↔ GCP Hub	✅ 정상	Azure: NSG 기본 허용으로 추가 설정 불필요 GCP 방화벽: Azure Hub 대역(10.0.0.0/24)에 대해 ICMP 허용
Azure Spoke ↔ GCP Hub	⚠️ 부분 정상	Azure: Hub ↔ Spoke Peering 설정 필요 GCP: Azure Spoke VNet 대역에 대한 경로(route) 추가 (다음 홉 = VPN Tunnel) GCP 방화벽에 Azure Spoke 대역 등록 필요 (누락 시 통신 불가)
GCP Spoke ↔ Azure Hub	✅ 정상	Azure: Local Network Gateway에 GCP Spoke VPC 대역 추가 GCP Spoke 방화벽: Azure Hub 대역에 ICMP 허용 GCP Hub ↔ Spoke Peering 정상 구성
Azure Spoke ↔ GCP Spoke	⚠️ 부분 정상	1~5번 조건 모두 충족 시 가능 추가로 GCP Spoke 방화벽에 Azure Spoke 대역(ICMP) 허용 필요 미설정 시 특정 Spoke ↔ Spoke 구간 통신 불가

 

---

마무리

이번 글에서는 Azure와 GCP 간 VPN 연결을 직접 구성하고, Hub-Spoke 네트워크 구조에서 트래픽이 어떻게 전달되는지까지 확인해 보았습니다.

• 기본적으로 Hub ↔ Hub 간 통신은 VPN 연결만으로 가능하지만,

• Spoke ↔ Spoke 간 통신은 각 CSP의 Peering 및 라우팅/방화벽 설정 여부에 따라 달라진다는 점이 중요한 포인트였습니다.

이를 통해 단순히 VPN 터널만 만든다고 해서 멀티 클라우드 환경 전체가 연결되는 것은 아니며, 네트워크 설계 단계에서의 아키텍처적 고려가 필수적임을 확인할 수 있었습니다.

이번 구성은 어디까지나 PoC 성격의 연결이지만, 실제 운영 환경에서는 다음과 같은 확장이 필요할 수 있습니다.

• 고가용성을 위한 Azure Active-Active VPN 혹은 GCP HA VPN 적용

• 대규모 트래픽 처리를 위한 전용 회선(ExpressRoute, Interconnect) 고려

• 보안 강화를 위한 방화벽 정책(FQDN, Deny Rule)과 UDR(User Defined Route) 설계

멀티 클라우드 환경에서는 결국 네트워크가 가장 큰 관건이 됩니다.
Azure ↔ GCP VPN을 직접 구성하면서 얻은 경험이, 유사한 환경을 설계하거나 검토하는 분들께 도움이 되길 바랍니다.