AWS와 Google Cloud VPC 직접 연결 설계

AWS와 Google Cloud 사이에 남아 있던 연결 문제

2026년 4월 AWS와 Google Cloud가 AWS Interconnect – multicloud의 일반 공개(GA)를 공동 발표했다. VPN 없이 VPC 수준에서 직접 연결되는 네이티브 경로가 열린 것이다. 멀티클라우드 도입률이 89%에 이르는 환경에서, 이 변화는 운영 복잡성을 낮출 수 있는 인프라 선택지로 볼 수 있다.

그동안 두 클라우드 사이의 데이터 전송은 대체로 세 경로에 의존했다. 퍼블릭 인터넷은 구성이 단순하지만 보안, 레이턴시, 대역폭의 예측 가능성이 낮다. IPsec VPN은 인터넷 직접 연결보다 안전하지만 설정 복잡성과 암호화 오버헤드가 따른다. Equinix나 Megaport 같은 서드파티 네트워크 교환 서비스를 거치는 방식은 추가 비용과 단일 장애점(Single Point of Failure) 위험을 안는다.

AWS Interconnect – multicloud는 이 경로들을 대체할 수 있는 네이티브 레이어 3 전용 연결을 제공하며, 설정 시간은 기존 며칠에서 수 분으로 단축됐다.

BGP가 VPC 경로를 교환하는 방식

연결의 중심에는 BGP(Border Gateway Protocol) 기반 동적 라우트 교환과 AWS 글로벌 백본을 통한 프라이빗 경로가 있다.

작은 워크로드나 단일 VPC 구성은 다음과 같은 경로로 연결할 수 있다.

[AWS VPC]
    │
[Virtual Private Gateway (VGW)]
    │
[Direct Connect Gateway]
    │
[Multicloud Interconnect 연결 시설]
    │
[Google Cloud Router]
    │
[Google Cloud VPC]

VGW는 Amazon VPC의 IPv4·IPv6 프리픽스를 Direct Connect Gateway에 자동 전파한다. Direct Connect Gateway는 이를 BGP로 Google Cloud Router에 동적으로 광고한다. 이때 트래픽은 AWS 글로벌 백본과 Google Cloud 프라이빗 네트워크만 통과하므로 퍼블릭 인터넷에 노출되지 않는다.

멀티리전 환경에서는 AWS Transit Gateway와 Google Cloud Network Connectivity Center(NCC)를 각각 허브로 두는 구조가 권장된다.

⤢✕

AWS Transit Gateway는 AWS 측 네트워크 허브 역할을 하고, Google Cloud NCC는 Google 측 중앙 연결 제어 평면을 맡는다. NCC의 VPC 스포크 구성은 VPC 피어링의 페어와이즈(pairwise) 관리 복잡성을 줄이고 중앙화된 연결 모델을 제공한다.

연결은 API 호출로도 프로비저닝할 수 있다. AWS 콘솔 또는 CLI에서 파트너 클라우드로 Google Cloud를 지정하고 1 Gbps ~ 100 Gbps 대역폭을 선택하면, 두 클라우드 에지 라우터 간 BGP 세션 수립, MACsec 활성화, 점프 프레임 설정이 자동 처리된다.

MACsec과 프라이빗 경로로 보는 보안 경계

AWS와 Google Cloud 간 연결에는 IEEE 802.1AE MACsec 암호화가 물리 링크 레벨에서 항상 활성화된다. 소프트웨어 레이어가 아닌 하드웨어 레이어의 line-rate 암호화이므로, 성능 저하 없이 도청과 변조를 차단하는 구조다.

데이터는 AWS 글로벌 백본과 Google Cloud 프라이빗 네트워크 내부로만 흐른다. 퍼블릭 인터넷 라우팅 테이블에 노출되지 않으므로 BGP 하이재킹과 중간자 공격(Man-in-the-Middle) 위협을 구조적으로 제거한다.

보안 요소	구현 방식	효과
암호화	MACsec (IEEE 802.1AE)	물리 레이어 line-rate 보호
경로 격리	프라이빗 백본 전용	퍼블릭 인터넷 노출 제거
이중화	두 물리 위치에 4개 이중화 연결 자동 프로비저닝	고가용성 보장

레이턴시와 비용을 같은 설계 문제로 다루기

전용 프라이빗 연결은 퍼블릭 인터넷보다 일관된 레이턴시를 제공한다. 동일 도시권 연결이 가능한 리전 페어는 5개이며, AWS US East (N. Virginia)와 Google Cloud N. Virginia 사이는 물리적으로 인접한 상호 연결 시설(Interconnection Facility)을 통해 단 자리 수 밀리초 레이턴시를 목표로 한다.

지원되는 지역 쌍은 다음과 같다.

US East (N. Virginia) ↔ Google Cloud N. Virginia
US West (N. California) ↔ Google Cloud Los Angeles
US West (Oregon) ↔ Google Cloud Oregon
Europe (London) ↔ Google Cloud London
Europe (Frankfurt) ↔ Google Cloud Frankfurt

비용은 포트 비용, 데이터 전송 비용, 경우에 따라 Transit Gateway 처리 비용이 함께 적용된다. 따라서 연결 여부는 네트워크 구성만이 아니라 트래픽 패턴과 운영 목적을 기준으로 판단해야 한다.

낮은 트래픽에서 1 Gbps 전용선은 비용 효율이 낮다. 지속적이고 대용량인 크로스 클라우드 트래픽이 있을 때 경제성이 높아진다. AWS와 Google Cloud는 모두 클라우드 밖으로 데이터를 내보낼 때 이그레스(Egress) 비용을 부과한다. Interconnect 연결은 인터넷 이그레스 비용을 절감할 수 있지만 전용선 포트 비용이 발생하므로, 사전에 트래픽 패턴을 분석해야 한다.

멀티클라우드를 단순 백업용으로 쓰는 경우에는 고가 전용선보다 VPN이 경제적일 수 있다. 반대로 실시간 또는 준실시간 데이터 동기화가 필요한 액티브-액티브 구성에서는 전용 연결의 가치가 커진다.

상호운용성 표준이 벤더 락인에 미치는 영향

AWS와 Google Cloud의 협력은 단일 서비스 출시를 넘어 시장 구조에도 영향을 준다. 두 하이퍼스케일러는 2026년 초 개방형 상호운용성 스펙(Open Interoperability Specification)을 공동 공개했고, Microsoft Azure도 2026년 내 이 표준을 채택하겠다고 확인했다.

⤢✕

표준 기반 연결은 특정 클라우드의 독점 기술이 아닌 이식성(Portability)을 제도화한다. 향후 클라우드 구성을 바꿀 때 전환 비용(Switching Cost)을 낮추는 근거가 된다.

데이터 중력(Data Gravity)도 함께 검토할 대상이다. 데이터가 한 클라우드에 집중될수록 이동 비용이 커지고 락인은 심화된다. 네이티브 크로스 클라우드 연결은 데이터를 원래 위치에 두면서 다른 클라우드에서 접근·처리할 수 있게 한다. Google이 2026년 전략에서 “데이터는 원위치에 두고 Google Cloud를 쿼리·추론 레이어로 활용”하는 방향으로 전환한 것도 같은 맥락이다.

AWS Transit Gateway와 Google Cloud NCC를 결합하면 양쪽 VPC 관리를 중앙화할 수 있다. 이 추상화 레이어를 통해 특정 클라우드의 네트워킹 세부 사항에 덜 종속되는 운영 모델을 구성할 수 있다. AI/ML 워크로드에서도 MCP(Model Context Protocol) 호환 인프라처럼 특정 벤더 생태계에 묶이지 않는 표준 기반 구성 요소를 선택하는 원칙이 멀티클라우드 전략 전반에 적용돼야 한다.

전환 과정에서 확인할 운영 조건

기존 VPN 기반 환경에서 네이티브 연결로 옮길 때는 블루-그린(Blue-Green) 방식의 단계적 전환이 권장된다. VPN과 Interconnect를 병렬 운영하고, 트래픽을 점진적으로 이전한 뒤 레이턴시·처리량·비용을 실측 비교해 최종 전환하는 접근이다.

가시성도 별도 설계가 필요하다. AWS와 Google Cloud는 로깅·모니터링 체계가 다르므로 CloudQuery 같은 멀티클라우드 가시성 도구를 도입하거나, 양쪽의 VPC Flow Logs를 중앙 SIEM으로 집계하는 파이프라인을 구성해야 한다.

데이터가 두 클라우드 사이를 흐르는 구조는 GDPR, 금융 규제, 공공 데이터 주권 요건에서도 검토해야 한다. 지역 쌍을 설계할 때 데이터가 국경을 넘지 않도록 리전 페어를 선택하고, 전송 중 암호화 증적인 MACsec 로그를 규정 준수 근거로 유지해야 한다.

AWS와 Google Cloud의 네이티브 VPC 상호 연동은 멀티클라우드를 도입 선언에서 실제 운영 가능한 아키텍처로 옮기는 기반이다. BGP 동적 라우팅, MACsec 물리 레이어 암호화, API 기반 자동 프로비저닝은 VPN과 서드파티 교환 경로의 복잡성 및 성능 한계를 함께 다룬다. 개방형 상호운용성 스펙은 Azure와 OCI를 포함한 하이퍼스케일러 전반의 네트워크 표준화로 이어질 전망이며, 장기적으로는 엔터프라이즈의 벤더 협상력과 클라우드 이식성에 영향을 준다.