AWS와 GCP가 함께 만든 멀티클라우드 네트워킹 표준, 무엇이 바뀌나

두 하이퍼스케일러 사이를 연결하려면 지금까지는 물리적 교차 연결과 수일의 프로비저닝 시간이 필요했다. 기업의 76%가 멀티 퍼블릭 클라우드를 쓰고 있는데도 정작 클라우드 간 연결 자체가 병목이었던 셈이다. AWS와 Google Cloud는 2025년 11월 이 문제를 겨냥한 표준을 공동 설계해 공개했고, 2026년 초 일반 제공(GA)으로 전환했다. 업계 최초의 오픈 인터오퍼러빌리티 스펙(Open Interoperability Specification)이라는 게 두 회사의 설명이다.

스펙의 정체

표준의 이름은 Connection Coordinator API Specification, OpenAPI 3.0 기반이다. GitHub에 공개돼 있어 다른 클라우드 공급자도 자유롭게 채택할 수 있고, AWS 쪽 구현체는 Interconnect – multicloud, GCP 쪽은 Cross-Cloud Interconnect다. 2025년 11월 프리뷰로 시작해 2026년 초 GA에 이르렀다.

⤢✕

설계 원칙은 세 가지로 요약된다. 대칭 API(Symmetric API)라 양측 클라우드가 동일한 스펙을 구현하며 어느 방향에서든 연결을 시작할 수 있다. 물리적 인터커넥트, VLAN 어태치먼트, Cloud Router 인스턴스는 완전히 추상화돼 사용자에게 노출되지 않는다. 프로비저닝은 고객이 Google Cloud에서 transport 리소스를 만들면 AWS가 수락하는 단일 흐름으로 끝난다.

기술 사양

항목	사양
암호화	MACsec (라인 레이트, 상시 암호화, 엣지 라우터 간)
대역폭	최대 100 Gbps (GA 기준)
가용성	4중(quad) 중복 연결, 시설·엣지 라우터 이중화
프로비저닝	콘솔/API 클릭 수 번, 수분 내 완료 (기존 수일 소요)
연결 방식	AWS Transit Gateway, Cloud WAN, VPC ↔ Google Cloud VPC

초기 지원 리전 쌍은 5개다: 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.

어디까지 통합됐나 — 네트워크만이다

지금 완성된 건 네트워크 레이어의 제어 플레인 통합이다. 컴퓨트·스토리지 레이어까지 하나로 묶으려면 별도 솔루션을 더 조합해야 한다.

⤢✕

네트워크 레이어는 API 기반 자동 프로비저닝까지 완전히 표준화됐다. Kubernetes 워크로드는 Google Anthos Multi-Cloud나 GKE on AWS로 GCP 콘솔에서 AWS 리전의 GKE 클러스터를 통합 관리할 수 있는 수준이고, 데이터 레이어는 BigQuery Omni 같은 특화 서비스가 크로스클라우드 쿼리를 지원한다. 반면 컴퓨트 레이어는 아직 각 CSP의 네이티브 도구를 병행 운용해야 한다.

IAM·네트워킹·관측성은 여전히 브리지가 필요하다

완전한 제어 플레인 통합 전까지는 레이어마다 브리지 패턴을 따로 설계해야 한다. IAM 쪽에서는 GCP Workload Identity Federation과 AWS IAM 역할을 연동하고, Kubernetes RBAC 정책을 양쪽에 미러링하며, 크로스클라우드 이중 감사 트레일을 구성해야 한다. SCIM 기반 사용자·그룹 동기화로 아이덴티티 소스를 하나로 유지하는 것도 필요하다.

네트워킹 쪽은 AWS Transit Gateway와 GCP Cloud Router 사이 BGP 세션을 자동으로 세우되, 양측 서브넷의 CIDR 충돌을 막을 주소 공간 계획을 미리 짜야 한다. Istio 같은 서비스 메시를 확장해 크로스클라우드 트래픽 암호화·라우팅을 제어하는 것도 실무에서 필요한 작업이다. 관측성 쪽은 양측 엣지 라우터가 협조적으로 유지보수 상태를 공유하고, 한쪽에서 이상을 감지하면 반대쪽에 알림이 가는 구조를 만들어야 하며, Prometheus Federation이나 OpenTelemetry Collector로 메트릭을 한곳에 모아야 한다.

클라우드 간 워크로드를 어떻게 옮길 것인가

⤢✕

가용성을 최우선에 두면 양 클라우드가 실시간으로 트래픽을 나누는 Active-Active를 택하고 글로벌 로드 밸런서와 수초 이내 RTO를 요구하게 된다. 비용 절감과 복구를 동시에 노린다면 Active-Passive 크로스클라우드 페일오버가 RTO/RPO 기반 재해복구를 비용 효율적으로 지원한다. 각 클라우드의 강점만 골라 쓰려면 워크로드 특화 배분이 답인데, 예를 들어 AI 추론은 GCP Vertex AI로, 데이터 분석은 AWS로 보내고 API·이벤트 스트림으로 묶는 식이다.

이동 가능성을 실제로 확보하려면 네 가지가 선행돼야 한다. Docker·Kubernetes 기반 컨테이너화, 배포 타깃을 전환할 수 있는 클라우드 중립 CI/CD 파이프라인, S3 API 호환 등 오브젝트 스토리지 추상화, 그리고 Terraform 멀티프로바이더로 짠 클라우드 독립적 인프라 코드다.

거버넌스와 비용은 FinOps 프레임워크로

cost-center, environment, team 같은 공통 태그 스키마를 AWS·GCP 전반에 강제 적용하는 태깅 표준화가 출발점이다. 예산은 클라우드별 상한과 크로스클라우드 총예산을 이중으로 관리하고, CSPM(Cloud Security Posture Management) 도구로 멀티클라우드 컴플라이언스를 단일 뷰에서 확인한다. 적절한 사이징·자동화·거버넌스 조합이면 클라우드 비용을 20–30% 절감할 수 있다는 보고가 있고, AWS 스팟 인스턴스와 GCP Spot VM의 가격을 워크로드별로 비교하는 것, 동일 리전 쌍 안에서 통신하도록 설계해 데이터 이전(Egress) 비용을 최소화하는 것도 실무적으로 중요하다.

Azure·OCI까지 합류하면

공급자	합류 시점	의미
AWS	2025년 11월 (공동 창설)	인터커넥트 공급자
Google Cloud	2025년 11월 (공동 창설)	Cross-Cloud Interconnect
Microsoft Azure	2026년 중 확정	빅3 전부 동일 스펙 채택
Oracle Cloud (OCI)	2026년 하반기 예정	4대 클라우드 표준 통합

대다수 엔터프라이즈가 AWS·Azure·GCP 중 둘 이상을 혼용한다는 점에서 Azure 합류의 무게가 크다. 빅3가 전부 같은 스펙을 채택하면 사실상 업계 표준으로 고착되고, 멀티클라우드 네트워킹은 더 이상 특수한 엔지니어링 과제가 아니라 표준 인프라 옵션이 된다.

도입 전 체크리스트

AWS VPC와 GCP VPC 사이 CIDR 충돌을 막을 IP 주소 공간을 먼저 설계해야 하고, 두 클라우드의 권한 모델 차이를 브리지하는 데 드는 추가 운영 비용도 감안해야 한다. 양측 메트릭·로그를 통합하는 별도 파이프라인이 필요하고, 지원 리전이 현재 5개 쌍으로 제한돼 있으니 아시아태평양 리전 지원 일정도 확인이 필요하다. 크로스클라우드 트래픽에 양쪽 Egress 요금이 함께 붙을 가능성도 미리 검토해야 한다.