AWS와 Google Cloud를 잇는 멀티클라우드 프라이빗 네트워크

AWS와 Google Cloud 사이의 전용 경로

AWS는 Google Cloud를 첫 파트너로 AWS Interconnect – multicloud를 정식 출시(GA)했다. 이 서비스는 2025년 12월 re:Invent에서 프리뷰로 공개됐고, 2026년 4월 GA에 도달했다. Microsoft Azure와 Oracle Cloud Infrastructure(OCI) 연동도 2026년 내 추가될 예정이다.

AWS Interconnect – multicloud는 AWS와 다른 클라우드 서비스 제공자(CSP)를 사설 관리형 Layer 3로 연결하는 네트워킹 서비스다. 퍼블릭 인터넷을 거치지 않는 전용 고속 연결을 통해, 멀티클라우드 환경에서 CSP 간 네트워크를 구성하고 운영하는 복잡성을 줄이는 데 목적이 있다.

기업의 89%가 둘 이상의 클라우드 제공자를 사용하는 상황에서 CSP 간 연결은 통신사에 의존하고, 수주 단위의 프로비저닝 대기와 수동 구성을 요구해 왔다. 이 서비스는 양사가 공동 엔지니어링한 최초의 CSP 간 네이티브 네트워크 연동 서비스라는 점에서 기존 방식과 구분된다.

⤢✕

AWS 환경은 Transit Gateway, Cloud WAN, Amazon VPC와 통합되며 Interconnect Facility를 통해 Google Cloud에 직접 연결된다.

연결 생성부터 트래픽 전달까지

기존 멀티클라우드 연결은 수주~수개월의 회선 프로비저닝을 요구했지만, AWS Interconnect – multicloud에서는 콘솔 또는 CLI로 3단계 안에 수분 내 연결을 구성한다. 연결 대상 CSP를 선택하고, 상대 CSP의 목적지 리전을 지정한 뒤, 필요한 전용 대역폭을 설정하는 흐름이다.

AWS Console, CLI, CloudFormation, Terraform 등 IaC 도구로 프로비저닝할 수 있다. 전용 대역폭은 온디맨드로 프로비저닝할 수 있으며, AWS 측 또는 Google Cloud Console의 Cross-Cloud Interconnect에서 양방향으로 구성할 수 있다.

트래픽은 AWS 글로벌 백본과 파트너 CSP의 프라이빗 네트워크를 통해 전달된다. 퍼블릭 인터넷 혼잡에서 격리되므로 예측 가능한 지연시간과 일관된 처리량을 제공하며, 인터커넥트 시설의 물리 인프라는 AWS와 Google Cloud가 사전 프로비저닝하고 운영한다.

⤢✕

AWS에서 Google Cloud로 향하는 경로 전체는 프라이빗 네트워크로 구성되며, Interconnect Facility 구간에는 MACsec 암호화가 적용된다.

물리 구간의 암호화와 장애 대비

MACsec은 IEEE 802.1AE 표준을 사용해 물리 계층에서 회선 속도(line-rate)의 하드웨어 기반 암호화를 제공한다. AWS 에지 라우터와 Google Cloud 에지 라우터 사이의 모든 물리 연결에 적용돼 데이터 기밀성과 무결성을 보호한다.

키 로테이션은 양 CSP가 자동으로 관리한다. 하드웨어 기반 암호화이므로 소프트웨어 암호화와 달리 처리량 저하가 없다.

가용성 측면에서는 물리적으로 분리된 인터커넥트 시설과 라우터에 걸친 4방향 리던던시를 사용한다. AWS와 Google Cloud는 별도의 물리적 건물에 쿼드 리던던트 인프라를 사전 프로비저닝하며, AWS 측에서는 99.99% 가용성 SLA를 제공한다. 단일 시설 또는 라우터에 장애가 발생하면 대체 경로로 자동 전환된다.

보안/가용성 항목	사양
암호화 표준	IEEE 802.1AE MACsec
암호화 계층	물리 계층(Layer 1)
키 관리	양 CSP 자동 로테이션
리던던시 수준	쿼드(4중) 이중화
가용성 SLA	99.99%
트래픽 경로	퍼블릭 인터넷 미경유

서비스가 제공되는 리전과 확장 계획

GA 시점에는 5개 리전 페어에서 서비스를 제공한다.

AWS 리전	Google Cloud 리전
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

2025년 12월에는 AWS re:Invent에서 Google Cloud를 첫 파트너로 프리뷰가 공개됐고, 2026년 4월 정식 출시(GA)를 달성했다. 2026년 하반기에는 Microsoft Azure 및 Oracle OCI 연동이 추가될 예정이다.

이 서비스를 위해 개발된 네트워크 상호운용성 API 사양은 오픈 스펙으로 공개돼 다른 CSP와 파트너도 채택할 수 있다.

데이터와 워크로드를 나누는 방식

대규모 데이터를 옮기지 않고 멀티클라우드 환경에서 분석과 처리를 수행하려면 데이터 페더레이션 아키텍처를 고려할 수 있다. BigQuery Omni(Google Cloud)에서 AWS S3 데이터를 직접 쿼리하거나, Amazon Athena에서 외부 데이터 소스를 페더레이티드 쿼리하는 방식이 여기에 해당한다.

비동기 워크플로는 Amazon EventBridge와 Google Cloud Pub/Sub 사이의 이벤트 브리지로 구현할 수 있다. 실시간 데이터 스트리밍에는 Apache Kafka(MirrorMaker 2), Amazon MSK, Google Cloud Dataflow를 사용하고, AWS Glue Data Catalog과 Google Cloud Dataplex를 연동해 메타데이터를 통합 관리할 수 있다.

워크로드는 CSP별 특성에 따라 배치한다. AI/ML 훈련에는 Google Cloud TPU 또는 AWS Trainium을 활용하고, 추론은 비용 효율적 CSP를 선택하거나 온프레미스 엣지에 배포한다. 데이터 파이프라인의 전처리는 데이터 소재지와 가까운 CSP에서 수행한다.

규제 준수도 배치 기준이 된다. EU GDPR 대상 데이터는 유럽 리전에 고정하고, 금융·의료 데이터는 인증된 CSP 리전에 둔다. Policy-as-Code로는 OPA, AWS Config, Google Cloud Organization Policy를 활용해 준수 여부를 자동 검증할 수 있다.

비용 관리에서는 FinOps 도구로 CSP별 비용을 가시화하고, Reserved/Committed Use 할인과 Spot/Preemptible 인스턴스를 혼합한다. 데이터 지역성을 설계에 반영해 네트워크 이그레스 비용도 최소화해야 한다.

통신사 회선 방식과 달라지는 운영 경계

항목	기존 방식(타사 회선)	AWS Interconnect – multicloud
프로비저닝 시간	수주~수개월	수분
관리 주체	고객 + 통신사	AWS + 파트너 CSP
물리 인프라	고객 관리 필요	CSP 사전 프로비저닝
암호화	별도 구성 필요	MACsec 기본 내장
리던던시	고객 설계 필요	쿼드 리던던시 기본
SLA	통신사 의존	99.99% (AWS)
구성 방식	수동 + 별도 포털	콘솔/CLI/IaC 통합
비용 모델	회선 약정 + 설치비	온디맨드 대역폭
오픈 표준	벤더 종속	오픈 API 사양 공개

아키텍처에 반영할 운영 조건

현재 지원 범위는 5개 리전 페어이므로 워크로드의 지역 요구사항과 사용 가능한 리전 페어를 미리 매핑해야 한다. 대역폭은 온디맨드로 프로비저닝할 수 있지만, 피크 트래픽과 버스트 패턴을 고려한 계획이 필요하다.

멀티클라우드 서비스 간 통신을 위해서는 Route 53과 Cloud DNS 연동을 포함한 DNS 및 서비스 디스커버리 전략을 마련한다. CloudWatch와 Google Cloud Monitoring을 통합하는 중앙 집중식 관측 플랫폼으로 Datadog, Grafana 등을 구축하는 방안도 검토 대상이다.

CSP 간 데이터 전송 비용을 고려한 FinOps 거버넌스가 필요하며, 2026년 하반기 Azure와 OCI 연동이 추가될 때의 확장도 설계 단계에서 함께 고려해야 한다.

AWS Interconnect – multicloud는 CSP 간 네이티브 프라이빗 연결을 제공한다. 수분 내 프로비저닝, MACsec 기반 하드웨어 암호화, 쿼드 리던던시와 99.99% SLA를 바탕으로 멀티클라우드 네트워크 운영의 경계를 재구성한다. Azure와 OCI 연동이 예정된 만큼, 기존 타사 회선 의존 아키텍처도 CSP 네이티브 연동 관점에서 검토할 수 있다.