길리랩blog

AWS와 Google Cloud를 사설망으로 직접 연결하는 크로스 클라우드 네트워킹

AWS Interconnect for Multicloud GA 분석. BGP 자동화·MACsec 암호화로 AWS-Google Cloud VPC를 직접 잇는 원리와 멀티클라우드 네트워크 설계 패턴, 벤더 락인 해소 전략.

2026-08-12 · 최초 발행 2026-04-27

2026년 4월, AWS가 Google Cloud와의 네이티브 VPC 직접 연결 서비스 AWS Interconnect for Multicloud를 GA(정식 출시)하면서 퍼블릭 클라우드 간 네트워킹의 기본 전제가 바뀌었다. 별도 VPN 터널이나 서드파티 네트워크 장비 없이 두 CSP의 VPC를 관리형 사설 링크로 직접 잇는 이 서비스는, 멀티클라우드 채택률이 89%에 달하는 2026년 엔터프라이즈 환경에서 벤더 락인 해소의 핵심 인프라로 주목받고 있다.

왜 지금 크로스 클라우드 네이티브 네트워킹인가

기업이 멀티클라우드를 쓰는 이유는 제각각이다. AI/ML 워크로드는 Google Cloud의 TPU와 Vertex AI를, 엔터프라이즈 앱은 AWS의 넓은 서비스 생태계를, 규정 준수와 지역 데이터 주권 요건은 특정 CSP의 리전 커버리지를 요구한다. 문제는 늘 이 두 환경을 잇는 네트워크 레이어였다.

기존 방식은 크게 세 갈래였다. 퍼블릭 인터넷을 그대로 경유하는 방식은 가장 단순하지만 레이턴시를 예측할 수 없고 보안이 취약하며 트래픽 혼잡이 상존했다. IPsec VPN은 암호화는 되지만 처리량에 한계가 있고 터널 관리가 복잡하며 상태 기반 세션 유지 부담이 컸다. Direct Connect와 Cloud Interconnect를 조합한 전용선 방식은 성능과 보안은 좋았지만 물리적 배선 계약과 수개월의 프로비저닝 기간, 높은 비용이 발목을 잡았다. AWS Interconnect for Multicloud는 이 세 방식의 단점을 걷어내고, AWS 글로벌 백본과 Google Cloud 사설 네트워크를 소프트웨어 정의 방식으로 수 분 안에 연결한다.

간편한 프로비저닝

서비스 구성은 세 단계로 완결된다. AWS 콘솔이나 API에서 연결 대상을 Google Cloud로 지정하고, 지원되는 리전 쌍 중 워크로드와 지리적으로 가까운 쌍을 고른 다음, 온디맨드 전용 대역폭을 지정하면 자동 프로비저닝이 시작된다.

현재 지원되는 리전 쌍은 다음과 같다.

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

2026년 내로 Azure와 OCI가 추가될 예정이며, 이는 멀티CSP 메시 네트워크로의 진화를 예고한다.

VPC 피어링과 BGP 자동화의 핵심 원리

⤢✕BGP 세션MACsec 암호화전용 링크MACsec 암호화전용 링크BGP 세션API 기반자동 프로비저닝BGP 경로자동 수신AWS VPC(us-east-1)AWS 글로벌 백본엣지 노드크로스 클라우드인터커넥트 포인트Google Cloud사설 네트워크Google Cloud VPC(us-east4)AWS 라우트 테이블자동 업데이트Google Cloud라우트 광고공용 인터넷미경유 보장

BGP 라우팅 자동화

크로스 클라우드 VPC 피어링의 핵심은 BGP(Border Gateway Protocol) 세션 자동화다. 기존 Direct Connect나 Cloud Interconnect 환경에서는 양쪽 BGP 피어 설정, AS 번호 교환, 경로 필터 정책을 전부 수동으로 잡아야 했다. AWS Interconnect for Multicloud는 이 과정을 통째로 추상화한다. AWS VPC 라우트 테이블에 Google Cloud VPC CIDR이 자동 등록되고, Google Cloud 측에서도 AWS VPC CIDR이 BGP 경로로 자동 수신·광고된다. VPC 확장이나 서브넷 추가로 경로가 바뀌면 BGP 재광고도 자동으로 이뤄진다.

이건 단순한 편의성 문제가 아니다. 수동 BGP 구성의 오류는 비대칭 라우팅, 블랙홀, 루프 같은 심각한 네트워크 장애로 이어지는데, 자동화된 BGP 관리는 이런 운영 리스크를 원천 차단한다.

온디맨드 전용 대역폭

"dedicated bandwidth on-demand" 모델이 기존 전용선 서비스와 갈라지는 지점이다. 물리적 회선을 미리 계약하지 않고, 소프트웨어 정의 방식으로 필요한 시점에 원하는 대역폭을 즉시 할당한다. 트래픽 피크에 대역폭을 늘리고 유휴 시간에 줄이는 탄력적 운용이 가능해진다.

MACsec: 레이어 2 암호화가 갖는 의미

AWS Interconnect for Multicloud의 보안 핵심은 IEEE 802.1AE MACsec(Media Access Control Security) 암호화다. IPsec이나 TLS 같은 레이어 3/4 암호화와는 접근 자체가 다르다.

MACsec은 이더넷 물리 링크 레벨, 즉 레이어 2에서 작동한다. 여기서 얻는 이점이 세 가지다. 소프트웨어 기반 IPsec은 처리량이 늘수록 CPU 부하가 급격히 커지는데, MACsec은 전용 하드웨어 오프로드로 와이어 속도(line-rate)를 유지하면서 암호화한다. 레이어 2에서 동작하다 보니 패킷 헤더 재조립이나 터널 인캡슐레이션 오버헤드가 없어 레이턴시가 최소화되는데, 이는 데이터베이스 복제나 실시간 ML 추론 파이프라인처럼 레이턴시에 민감한 크로스 클라우드 워크로드에 결정적이다. 그리고 두 CSP 간 물리적 연결 지점에서의 도청 시도를 원천 차단한다. 암호화가 패킷이 물리 링크에 올라가기 직전에 적용되기 때문에, 중간 경로의 어떤 장비도 평문 트래픽을 볼 수 없다.

공용 인터넷 완전 배제

트래픽은 AWS 글로벌 백본과 Google Cloud 사설 네트워크만 통과한다. 공용 인터넷 구간이 아예 없기 때문에 DDoS, BGP 하이재킹, 경로 유출(route leak) 같은 인터넷 레벨 위협에서 완전히 격리된다. 금융, 헬스케어, 공공 부문처럼 규제가 엄격한 산업에서 멀티클라우드 네트워킹을 운용하려면 이 조건이 사실상 필수다.

성능의 핵심은 속도가 아니라 예측 가능성

엔터프라이즈 멀티클라우드 아키텍처에서 네트워크 성능의 핵심 지표는 절대적인 속도가 아니라 예측 가능성이다. 크로스 클라우드 데이터 파이프라인에서 레이턴시 편차(jitter)가 크면 상위 레이어 애플리케이션의 SLA 보장이 사실상 불가능해진다. AWS Interconnect for Multicloud가 제공하는 성능 보장은 세 축으로 이뤄진다. 공용 인터넷 경로 변동성을 배제해 레이턴시를 예측 가능하게 하고, 온디맨드 전용 대역폭으로 인접 트래픽 경합 없이 일관된 처리량을 유지하며, BGP 경로 불안정이나 피어링 포인트 혼잡과 무관하게 트래픽을 전달해 인터넷 혼잡에서 격리한다. ML 모델 학습을 위해 AWS S3의 학습 데이터를 Google Cloud의 TPU 클러스터로 스트리밍하거나, Google BigQuery의 분석 결과를 AWS RDS로 복제하는 하이브리드 데이터 플로우에서 이 차이는 특히 두드러진다.

이 연결로 무엇을 지을 수 있나: 설계 패턴

Kubernetes 기반 서비스 메시(Istio, Linkerd)를 AWS EKS와 Google Cloud GKE에 각각 배포하고, 크로스 클라우드 VPC 연결을 사설 mTLS 채널로 쓰는 것이 서비스 메시 확장 패턴이다. 서비스 디스커버리·트래픽 정책·옵저버빌리티가 두 클라우드에 걸쳐 단일 컨트롤 플레인으로 관리된다.

데이터 플레인 분리 패턴은 컴퓨트 워크로드(AWS Lambda, EC2)와 분석 워크로드(Google Cloud BigQuery, Dataflow)를 각 CSP의 강점에 맞춰 배치하고, 크로스 클라우드 VPC 링크를 ETL 파이프라인의 전용 데이터 채널로 쓴다. S3에서 BigQuery로 이어지는 실시간 CDC(Change Data Capture) 파이프라인이 대표적이다.

재해 복구(DR) 액티브-액티브 패턴은 동일 서비스를 AWS와 Google Cloud에 병렬 배포하고, 크로스 클라우드 VPC 링크로 세션·캐시·DB 복제 같은 상태 동기화를 수행한다. DNS 기반 글로벌 트래픽 분산과 결합하면 CSP 장애 시 수 초 안에 자동 페일오버가 가능한 액티브-액티브 DR 구성이 완성된다.

벤더 락인에서 벗어나는 다음 단계

멀티클라우드 채택의 주요 동기 중 하나가 특정 벤더 의존성 탈피인 만큼, AWS Interconnect for Multicloud가 이 전략에 기여하는 방식도 단순한 연결 그 이상이다.

AWS가 멀티클라우드 네트워크 상호 운용성을 위한 Open specification을 공표한 점은 눈여겨볼 만하다. 특정 벤더 독점 프로토콜이 아닌 업계 표준 기반 인터페이스를 정의함으로써, 향후 Azure와 OCI가 동일 스펙으로 연결되고 나아가 프라이빗 클라우드와 엣지 인프라까지 아우르는 범용 멀티클라우드 패브릭으로 확장될 기반이 마련된다.

크로스 클라우드 VPC 연결이 안정화되면 워크로드 이동성을 확보하는 다음 레이어 작업이 병행돼야 한다. Terraform의 멀티 프로바이더 구성으로 AWS와 Google Cloud 리소스를 단일 코드베이스에서 관리하면 프로바이더 모듈 교체만으로 동일 인프라를 다른 CSP에 재배포할 수 있다. Docker 컨테이너와 Kubernetes 매니페스트는 애초에 CSP 독립적이고, EKS와 GKE가 Kubernetes API 호환성을 유지하는 덕분에 애플리케이션 레이어의 CSP 이동 비용도 최소화된다. Apache Iceberg나 Delta Lake 같은 오픈 테이블 포맷을 중립 오브젝트 스토리지(AWS S3, Google Cloud Storage)에 저장하면 처리 엔진(Spark, Flink, BigQuery Omni)을 CSP 간에 유연하게 바꿀 수 있고, 크로스 클라우드 서비스 호출을 CSP 네이티브 SDK 직접 호출 대신 내부 API 게이트웨이 경유로 설계하면 백엔드 CSP 변경이 애플리케이션 코드에 투명해진다.

운영에서 새로 생기는 과제: 거버넌스와 옵저버빌리티

크로스 클라우드 VPC 연결은 기존 인터넷 이그레스 비용 구조와 다른 과금 모델을 갖는다. 온디맨드 전용 대역폭은 데이터 전송량이 아니라 대역폭 예약량 기준으로 과금될 가능성이 높기 때문에, 트래픽 패턴을 분석해 피크 대역폭과 평균 이용률의 비율을 산정하고 예약 대역폭을 최적화하는 FinOps 접근이 필요하다.

단일 클라우드에서 VPC Flow Logs, CloudWatch, Cloud Monitoring으로 나뉘어 있던 네트워크 가시성도 크로스 클라우드 링크에서는 통합 관점으로 다시 짜야 한다. AWS Network Manager와 Google Cloud Network Intelligence Center를 크로스 클라우드 링크 모니터링 데이터와 함께 Datadog, Grafana Cloud 같은 제3의 옵저버빌리티 플랫폼으로 집계하는 아키텍처가 권장된다.

두 CSP에 걸친 네트워크 보안 정책(Security Group, VPC Firewall Rules)의 일관성 관리도 새로운 운영 과제다. AWS Network Firewall과 Google Cloud Firewall Policies를 동기화하는 자동화 파이프라인을 구축하거나, Palo Alto Prisma Cloud·Wiz 같은 CSPM 솔루션의 크로스 클라우드 정책 관리 기능을 활용해야 한다.

CSP 경계가 흐려지는 지점

AWS Interconnect for Multicloud의 GA는 멀티클라우드를 단순한 벤더 분산 전략에서 아키텍처적으로 설계 가능한 실제 인프라로 끌어올린 전환점이다. MACsec 기반 물리 링크 암호화, BGP 자동화, 온디맨드 전용 대역폭이 결합된 이 서비스는 보안·성능·운영 복잡성 세 축 모두에서 기존 크로스 클라우드 연결 방식을 앞선다. 2026년 내 Azure와 OCI 지원이 추가되고 오픈 스펙이 업계 표준으로 자리 잡으면, CSP 간 네트워크 경계는 점점 흐려지고 워크로드의 CSP 이동성은 한 단계 더 올라갈 것이다.

Sources

멀티클라우드네트워킹BGPMACsec벤더락인