Azure와 AWS를 잇는 전용선: 멀티클라우드 인터커넥트가 바꾸는 것

Azure와 AWS를 잇는 게 왜 그렇게 어려웠을까요?

각 클라우드의 전용 회선과 라우터, BGP, 암호화를 서로 다른 팀이 직접 엮어야 했기 때문입니다. 한쪽에는 Azure ExpressRoute 회선을, 다른 쪽에는 AWS Direct Connect 회선을 만들고, 둘을 잇기 위해 연결 공급자나 코로케이션 공간을 확보한 뒤, 라우터와 BGP 피어링, 암호화를 직접 구성하고 유지해야 했죠.

문제는 이 조각들이 저마다 다른 팀이나 벤더의 소유라는 점입니다. 전체 경로의 신뢰도는 가장 관리가 덜 된 구간에 맞춰지고, 장애가 나면 Microsoft와 AWS, 네트워크 공급자, 자체 운영팀을 오가며 원인을 찾아야 하니 복구가 늦어집니다. 용량 계획도 까다로워요. 대개 피크에 맞춰 대역폭을 잡아 두고 놀리다가, 새 AI나 데이터 프로젝트로 늘려야 할 때는 몇 주가 걸리기도 합니다.

멀티클라우드 인터커넥트는 무엇을 바꾸나요?

여러 회선과 라우터, BGP 세션, 암호화를 직접 짜 맞추던 일을 단일 관리형 리소스 하나로 대체합니다. Microsoft와 AWS가 함께 설계한 완전 관리형 서비스로, 인터커넥트 리소스 하나를 만들면 Azure와 AWS 사이에 프라이빗 전용 경로가 생기죠. 프로비저닝과 라우팅, 암호화는 양 클라우드가 뒤에서 공동으로 처리합니다.

새로 검증되지 않은 경로가 아니라는 점도 중요해요. 이 서비스는 기업이 이미 신뢰하는 Azure ExpressRoute와 AWS Direct Connect 위에 구축됩니다. 그래서 각 클라우드에서 쓰던 연결 모델과 도구, 운영 방식에 자연스럽게 들어맞죠. 결국 여러 구성 요소로 쌓아 올리던 연결이 하나의 리소스로 단순해지는 것입니다.

어떻게 설계됐나: 쿼드 리던던시와 MACsec

이 서비스는 프로덕션과 AI 규모의 트래픽을 염두에 두고 가용성과 성능을 우선해 설계됐습니다. 핵심은 이중, 삼중을 넘어선 쿼드 리던던시예요. 데이터 경로가 Azure MSEE 라우터 4대와 AWS 라우터 4대에 걸쳐 서로 다른 사이트로 나뉘어, 단일 장애 지점이 없도록 구성됩니다.

여기에 대용량 LAG 기반의 400G급 백본이 대규모 데이터 이동과 분산 AI 트래픽을 감당할 여유를 줍니다. 대역폭은 피크에 묶어 두지 않고 수요에 따라 늘리고 줄이는 탄력 구조죠. 클라우드 사이 트래픽은 MACsec 링크계층 암호화가 기본으로 걸려 별도 설정 없이 보호되고, IPv6를 지원하며 99.99% 가용성 SLA를 목표로 합니다. 라우팅과 프로비저닝을 플랫폼이 맞춰 주기 때문에, BGP 설정 불일치나 암호화 설정 차이, 취약한 장애 조치 경로 같은 흔한 실수도 함께 줄어듭니다.

지금 쓸 수 있나요? 평가판 현황

Azure 연결은 아직 공개 평가판 단계이고, 제공 리전은 네 곳뿐입니다. 미국 동부(버지니아 북부), 미국 서부(캘리포니아 북부), 아시아 태평양(시드니), 유럽(프랑크푸르트)에서 Azure를 통한 평가판으로 제공되죠. 한국 리전은 아직 포함되지 않습니다. 평가판 인터커넥트는 AWS 관리 콘솔이나 CLI, API로 만들 수 있어요.

범위를 넓혀 보면 흐름이 보입니다. AWS는 re:Invent 2025에서 이 멀티클라우드 인터커넥트를 처음 선보이며 상호운용성을 위한 개방형 사양을 공개했고, Azure는 그 사양을 채택한 최신 클라우드 사업자입니다. AWS 기준으로 OCI와 Google Cloud는 이미 정식 버전, Microsoft Azure는 평가판이죠. 한국 리전이 빠져 있어 국내에서 당장 적용하기는 이르지만, 클라우드 사이를 잇는 네트워크가 직접 구축에서 관리형 서비스로 옮겨 가는 방향은 분명합니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)