AWS와 Google Cloud 멀티클라우드 운영, 단일 제어 플레인 설계

AWS는 2025년 12월 re:Invent에서 Google Cloud를 첫 파트너로 하는 AWS Interconnect – multicloud를 프리뷰로 공개했다. 2026년 4월에는 GA 단계로 전환했고, Azure·OCI를 연내 편입하겠다고 밝혔다. 하이퍼스케일러가 오랫동안 각자의 벽정원(walled garden)을 유지해 온 흐름을 고려하면, 타 CSP와 제어 플레인(Control Plane) 수준에서 브리지를 제공하는 첫 공식 시도다.

엔터프라이즈 워크로드의 89%가 멀티클라우드를 채택했지만, 실제 운영은 CSP별 콘솔과 API가 분리된 상태였다. 이 서비스는 수 주가 걸리던 회선 프로비저닝을 수 분 단위 API 호출로 바꾸고, 공개 프로토콜을 통해 상호운용성의 범위를 넓히는 데 초점을 둔다.

CSP 네이티브 자원을 잇는 제어 플레인

기존 SaaS형 멀티클라우드 도구인 Nutanix, Morpheus 등이 관리 계층을 별도로 제공했다면, 이 구조는 각 CSP의 네이티브 자원을 직접 오케스트레이션하는 얇은 브리지 레이어에 가깝다. AWS에서는 Direct Connect Gateway가 어태치 포인트가 되고, Google Cloud에서는 Cloud Router가 대응한다.

물리 링크는 상호 인터커넥션 시설의 교환 지점에서 이어지며, 전 구간에는 IEEE 802.1AE MACsec 암호화가 적용된다.

⤢✕

양 CSP가 동일한 개방형 API 스펙을 구현한다는 점이 이 구조의 핵심이다. 고객이 한쪽 콘솔에서만 프로비저닝을 요청해도 대칭 자원이 자동 생성되며, AWS는 이 사양을 다른 프로바이더에도 개방해 산업 표준화를 추진하고 있다.

권한·라우팅·텔레메트리가 만나는 경계

IAM 연동은 AWS IAM과 Google Workload Identity Federation 사이에 OIDC 기반 신뢰 체인을 두는 방식이다. 키 발급 없이 타 CSP 리소스에 접근할 수 있다. 기업 IdP인 Okta 또는 Entra ID는 SCIM + SAML로 양쪽 CSP에 동시에 연동해 조직 단위 RBAC를 일관되게 유지할 수 있다. 다만 크로스 클라우드 호출에는 최소권한 원칙(Least Privilege)을 강제할 조건부 정책이 필요하다.

네트워크 계층에서는 Direct Connect Gateway와 Cloud Router가 프라이빗 ASN으로 BGP 피어링을 구성한다. AWS 9001, GCP 1460의 기본 MTU 차이로 단편화가 발생하지 않도록 MTU·MSS를 정렬해야 한다. 대역폭은 50Mbps~100Gbps 범위에서 분 단위로 조정할 수 있다.

관측성은 CloudWatch Network Synthetic Monitor로 연결별 왕복 지연과 패킷 손실을 자동 측정하는 형태다. 대역폭 사용률 메트릭은 용량 계획을 위한 시계열 지표로 CloudWatch에 통합되며, OpenTelemetry 기반 Cross-Cloud Trace는 AWS ↔ GCP 요청 경로를 추적한다.

거버넌스 구조를 연결 방식에 맞추기

Transit Gateway를 허브로 두고 GCP VPC를 스포크로 연결하는 Hub-and-Spoke with Central Policy에서는 모든 크로스 클라우드 트래픽이 AWS Network Firewall과 Security Hub를 지나도록 강제한다. 정책 관리는 Terraform, Pulumi 같은 Infrastructure-as-Code로 수행한다.

Cell-Based Isolation은 비즈니스 도메인별 AWS Account와 GCP Project를 1:1로 매핑하고, 셀마다 Interconnect를 분리해 운영한다. 한 셀의 장애가 다른 셀로 전파되는 Blast Radius를 줄이는 방식이다.

Data Gravity 기반 배치는 데이터 저장소를 한 CSP에 고정한 뒤, AI 훈련이나 분석처럼 계산 집약적인 워크로드를 가장 경제적인 CSP에 배치한다. Interconnect는 이때 데이터 중력을 상쇄하는 연결 경로가 된다.

전용선 중심 운영과 달라지는 지점

항목	기존 방식	AWS Interconnect – multicloud
프로비저닝 시간	수 주 (전용선 계약)	수 분 (API 호출)
대역폭 변경	회선 재계약	온디맨드 조정
암호화	사용자 VPN 구성	MACsec 기본 내장
관측 가능성	서드파티 툴 필요	CloudWatch 네이티브
API 표준	CSP별 독자 규격	개방형 스펙

규제와 데이터 이동이 연결 요구를 만든 사례

글로벌 금융사는 규제 때문에 EU 데이터를 Google Cloud Frankfurt에 두고, 분석 엔진은 AWS Ireland에 배치했다. Interconnect로 TGW ↔ Cloud Router를 연결하고 모든 트래픽에 MACsec을 강제한 결과, 월 지연 평균은 2.1ms였고 회선 비용은 38% 절감됐다.

대형 미디어 기업은 Vertex AI에서 추천 모델을 학습한 뒤 AWS Bedrock과 S3에서 추론·배포했다. GCS → S3 전송을 Interconnect 기반으로 전환하면서 데이터 이동 시간은 62% 단축됐고, 이그레스 비용은 45% 절감됐다.

운영 전에 확인할 조건

Interconnect 기반 경로는 기존 퍼블릭 이그레스보다 저렴하지만, 과금 구조는 CSP별로 다르다. FinOps 팀이 비용 시뮬레이션을 수행해야 한다.

권한도 별도 경계로 다뤄야 한다. 한 CSP에서 부여한 권한이 다른 CSP 자원에 의도치 않은 영향을 주지 않도록 Condition, IAM Context 기반 정책을 설계한다. Interconnect 자체 장애에는 퍼블릭 VPN이나 Transit VPC 같은 폴백 경로를 준비한다.

통합이 쉬워질수록 워크로드를 물리적으로 분산할 동기는 약해질 수 있다. 가격 협상력과 규제 대응처럼 멀티클라우드를 택한 본래 목적을 주기적으로 다시 점검할 필요가 있다.

확장되는 연결 범위

Azure·OCI는 2026년 하반기 GA가 예정돼 있으며, 4대 CSP 사이의 완전 메시 토폴로지가 현실화되고 있다. Trainium3 기반 AWS 훈련과 TPU 기반 GCP 서빙처럼 이기종 AI 파이프라인을 나누는 흐름도 부상하고 있다. Open Network User Group(ONUG)을 중심으로는 Interconnect API 표준 제정 논의가 이어지고 있다.