AWS Interconnect, 라스트 마일 연결을 단순화하는 새로운 옵션과 함께 정식 출시

오늘 AWS Interconnect – 멀티 클라우드가 정식 출시되었습니다. 이 제품은 Amazon Virtual Private Cloud(Amazon VPC)를 다른 클라우드 제공업체의 VPC에 직접 연결하는 관리형 프라이빗 연결 서비스입니다. 또한 기존 네트워크 제공업체를 통해 지사, 데이터 센터 및 원격 위치에서 AWS로 고속 프라이빗 연결을 설정하는 방법을 단순화하는 새로운 기능인 AWS Interconnect – 라스트 마일도 도입했습니다.

대기업의 경우 전문 서비스를 사용하든, 데이터 레지던시 요구 사항을 충족하든, 다른 제공업체에서 표준화된 팀을 지원하든 다양한 상황에서 워크로드가 여러 클라우드 제공업체로 분산되어 실행되는 사례가 점점 더 많아지고 있습니다. 지금까지 이러한 환경을 신뢰할 수 있는 안전한 방식으로 연결하려면 VPN 터널 관리, 콜로케이션 시설 활용, 서드 파티 네트워크 패브릭 구성과 같은 상당한 조정이 필요했습니다. 그 결과 네트워킹 팀은 비즈니스에 중요한 애플리케이션에 집중하는 대신 차별화되지 않은 과중한 작업에 시간을 낭비합니다.

AWS Interconnect는 이러한 문제를 해결해 줍니다. 이 제품은 AWS로의 연결을 단순화하는 관리형 연결 서비스입니다. Interconnect를 통해 하이브리드 및 멀티 클라우드 환경에서 AWS와의 전용 대역폭을 사용하여 프라이빗 고속 네트워크 연결을 설정할 수 있습니다. AWS Console에서 위치, 파트너 또는 클라우드 제공업체, 선호 리전 및 대역폭 요구 사항을 선택하여 클릭 몇 번으로 복원력이 뛰어난 엔드투엔드 연결을 쉽게 구성할 수 있으므로 파트너를 찾는 데 따르는 불편함과 수동 네트워크 구성의 복잡성을 해소할 수 있습니다.

그리고 AWS와 다른 클라우드 제공업체 간 멀티 클라우드 연결 및 AWS와 프라이빗 온프레미스 네트워크 간 라스트 마일 연결이라는 두 가지 기능을 제공합니다. 두 기능 모두 팀의 인프라 복잡성을 없애는 완전관리형 턴키 환경이라는 동일한 원칙에 따라 구축되었습니다.

AWS Interconnect – 멀티 클라우드
AWS Interconnect – 멀티 클라우드는 AWS 환경과 다른 클라우드 제공업체 간 프라이빗 관리형 레이어 3 연결을 제공합니다. 다른 제공업체로 Google Cloud를 먼저 지원하며, 2026년에 Microsoft Azure도 지원할 예정입니다. 트래픽은 전적으로 AWS 글로벌 백본과 파트너 클라우드의 프라이빗 네트워크를 통해 전달되므로 퍼블릭 인터넷을 통과하지 않습니다. 즉, 물리적 인프라를 직접 관리하지 않고도 예측 가능한 지연 시간과 일관된 처리량을 지원하고 인터넷 혼잡으로부터 격리할 수 있습니다.

보안은 기본적으로 제공됩니다. 모든 연결은 AWS 라우터와 상호 연결 시설에 있는 파트너 클라우드 제공업체의 라우터 간 물리적 링크에서 IEEE 802.1AE MACsec 암호화를 사용합니다. 이 기능을 별도로 구성하지 않아도 됩니다. 각 클라우드 제공업체는 자체 백본에서 암호화를 독립적으로 관리하므로, 사용자가 특정 배포에 대한 암호화 설명서를 검토하여 규정 준수 요구 사항을 충족하는지 확인해야 합니다. 복원력도 기본 제공됩니다. 각 연결은 최소 두 개의 물리적 시설에서 여러 논리적 링크에 분산되어 있으므로 단일 디바이스 또는 시설의 장애로 인해 연결이 중단되지 않습니다.

모니터링을 위해 AWS Interconnect – 멀티 클라우드는 Amazon CloudWatch에 통합됩니다. 각 연결에 포함된 Network Synthetic Monitor를 통해 왕복 지연 시간 및 패킷 손실을 추적하고 대역폭 사용률 지표를 사용하여 용량 계획을 지원합니다.

AWS는 GitHub에 기본 사양을 게시합니다. 이는 Apache 2.0 라이선스에 따르며, 모든 클라우드 서비스 제공업체에 AWS Interconnect – 멀티 클라우드를 사용해 협력할 수 있는 기회를 제공합니다. AWS Interconnect 파트너가 되려면 클라우드 제공업체는 기술 사양을 구현하고 복원력 표준, 지원 약정, 서비스 수준 계약을 비롯한 AWS 운영 요구 사항을 충족해야 합니다.

작동 방식
연결을 프로비저닝하는 데 몇 분 정도 걸립니다. AWS Direct Connect 콘솔에서 연결을 생성합니다. 먼저 AWS Interconnect 섹션에서 Google Cloud를 제공업체로 선택합니다. 소스와 대상 리전을 선택합니다. 대역폭을 지정하고 Google Cloud 프로젝트 ID를 제공합니다. AWS에서 활성화 키를 생성합니다. 이를 사용하여 Google Cloud 측에서 연결을 완료합니다. 경로는 양방향으로 자동으로 전파되며, 워크로드는 얼마 지나지 않아 데이터 교환을 시작할 수 있습니다.

이 데모에서는 단일 VPC로 시작하고 이를 Google Cloud VPC에 연결합니다. Direct Connect 게이트웨이를 사용합니다. 한 번의 연결 설정과 연결 작업을 사용하는 가장 간단한 경로입니다. 양쪽에 있는 워크로드가 몇 분 만에 서로 통신을 시작할 수 있습니다.

1단계: AWS Management Console에서 상호 연결 요청

AWS Direct Connect, AWS Interconnect로 이동하고 생성을 선택합니다. 먼저 연결하려는 클라우드 제공업체를 선택합니다. 이 예제에서는 Google Cloud입니다.

AWS 리전(eu-central-1) 및 Google Cloud 리전(europe-west3)을 선택합니다.

3단계에서 설명을 입력하고 대역폭, 연결할 Direct Connect 게이트웨이, Google Cloud 프로젝트의 ID를 선택합니다.

요청을 검토하고 확인한 후에 콘솔에서 활성화 키를 제공합니다. 이 키를 사용하여 Google Cloud 측에서 요청을 검증합니다.

2단계: Google Cloud Platform(GCP) 계정에서 전송 및 VPC 피어링 리소스 생성

활성화 키가 있으므로 이제 GCP 측에서 프로세스를 계속합니다. 이 블로그를 작성하던 시점에는 웹 기반 콘솔이 없었습니다. 그래서 대신 GCP 명령줄(CLI)을 사용했습니다. europe-west3 리전에서 GCP VPC 서브넷의 CIDR 범위를 기록합니다. 터미널을 열고 다음을 입력합니다.

gcloud network-connectivity transports create aws-news-blog \
    --region=europe-west3  \
    --activation-key=${ACTIVATION_KEY} \
    --network=default \
    --advertised-routes=10.156.0.0/20

Create request issued for: [aws-news-blog]
...
peeringNetwork: projects/oxxxp-tp/global/networks/transport-9xxxf-vpc
...
state: PENDING_CONFIG
updateTime: '2026-03-19T09:30:51.103979219Z'

명령을 완료하는 데 몇 분 정도 걸립니다. 명령에서 결과를 반환하면 GCP VPC와 방금 생성한 새 전송 사이에서 피어링을 생성합니다. GCP 콘솔이나 gcloud 명령줄에서 이 작업을 수행할 수 있습니다. 이전 명령에서 터미널을 사용했으므로 계속 명령줄을 사용했습니다.

gcloud compute networks peerings create aws-news-blog \
      --network=default \
      --peer-network=projects/oxxxp-tp/global/networks/transport-9xxxf-vpc \
      --import-custom-routes \
      --export-custom-routes

네트워크 이름은 GCP VPC의 이름입니다. 피어 네트워크는 이전 명령의 출력에 제공되었습니다.

완료되면 GCP 콘솔에서 피어링을 확인할 수 있습니다.

AWS Interconnect 콘솔에서 사용 가능 상태인지 확인합니다.

AWS Direct Connect 콘솔의 Direct Connect 게이트웨이에 새 상호 연결에 대한 연결이 표시됩니다.

3단계: AWS 측에서 새 게이트웨이 연결

게이트웨이 연결을 선택하고 게이트웨이 연결을 선택하여 이 데모를 시작하기 전에 생성한 가상 프라이빗 게이트웨이(VGW)를 연결합니다. 이때 상호 연결과 동일한 AWS 리전에서 VGW를 사용합니다.

GCP 측에서 네트워크 라우팅을 구성하지 않아도 됩니다. AWS에 마지막 단계를 수행합니다. VPC 라우팅 테이블에 경로 항목을 추가하여 가상 게이트웨이를 통해 모든 트래픽을 GCP IP 주소 범위로 전송합니다.

네트워크 설정이 완료되면 두 개의 컴퓨팅 인스턴스를 시작합니다. AWS와 GCP에 하나씩 있습니다.

AWS에서 보안 그룹이 TCP:8080의 송신 트래픽을 수락하는지 확인합니다. 머신에 연결하고 최소 웹 서버를 시작합니다.

python3 -c \
"from http.server import HTTPServer, BaseHTTPRequestHandler 
class H(BaseHTTPRequestHandler):
   def do_GET(self):
      self.send_response(200);self.end_headers()
      self.wfile.write(b'Hello AWS World!\n\n')
HTTPServer(('',8080),H).serve_forever()"

GCP 측에서 머신에 대한 SSH 세션을 열고 프라이빗 IP 주소로 AWS 웹 서버를 직접 호출합니다.

짠! 두 네트워크 사이에 두 클라우드 서비스 제공업체가 전적으로 관리하는 프라이빗 네트워크 경로가 설정되었습니다.

알아야 할 사항
다음과 같은 몇 가지 구성 옵션을 염두에 두어야 합니다.

• 네트워크를 연결할 때 양쪽의 IP 주소 범위에 주의하세요. GCP와 AWS VPC 범위는 중복될 수 없습니다. 이 데모에서 AWS의 기본 범위는 172.31.0.0/16이고 GCP의 기본 범위는 10.156.0.0/20입니다. 이 기본값으로 계속 진행할 수 있었습니다.
• 양쪽에서 IPV4, IPV6 또는 둘 다를 구성할 수 있습니다. 양쪽에서 동일한 옵션을 선택해야 합니다.
• 최대 전송 단위(MTU)는 두 VPC에서 동일해야 합니다. 하지만 AWS VPC와 GCP VPC의 기본값이 동일하지 않습니다. MTU는 네트워크 인터페이스가 조각화하지 않고 전송할 수 있는 최대 패킷 크기(바이트)입니다. 피어링된 VPC 간 MTU 크기가 일치하지 않으면 패킷 손실 또는 조각화가 발생하여 자동 데이터 손실, 처리량 저하, 상호 연결 전반에서 연결 끊김이 발생합니다.
• 자세한 내용은 GCP Partner Cross Cloud Interconnect 및 AWS Interconnect 사용 설명서를 참조하세요.

참조 아키텍처
배포 규모가 커지고 단일 리전에 VPC가 여러 개 있는 경우 AWS Transit Gateway는 단일 Interconnect 연결을 통해 모두를 연결하는 중앙 집중식 라우팅 허브를 제공합니다. 여러 환경에서 트래픽을 분할하고, 일관된 라우팅 정책을 적용하며, 클라우드 경계를 넘는 항목을 검사해야 하는 경우 AWS Network Firewall을 통합할 수 있습니다.

워크로드가 여러 AWS 리전과 여러 Google Cloud 환경에 분산된 글로벌 규모에서 운영하는 경우, AWS Cloud WAN은 동일한 모델을 전 세계로 확장합니다. 중앙 집중식 정책 관리 및 사업을 운영하는 모든 위치에서 일관되게 적용되는 세그먼트 기반 라우팅을 통해 네트워크의 모든 리전에서 전 세계 모든 Interconnect 연결에 도달할 수 있습니다.

동료인 Alexandra와 Santiago는 이들의 블로그 게시물(Build resilient and scalable multicloud connectivity architectures with AWS Interconnect – multicloud)에서 이러한 참조 아키텍처를 설명합니다.

AWS Interconnect – 라스트 마일
AWS Interconnect – 라스트 마일은 AWS Interconnect – 멀티 클라우드와 동일한 아키텍처 및 설계를 기반으로 하며, 참여 네트워크 제공업체의 라스트 마일 인프라를 통해 AWS Management Console에서 직접 온프레미스 또는 원격 위치를 AWS에 연결하는 기능을 제공합니다.

온보딩 프로세스는 AWS Interconnect – 멀티 클라우드를 미러링합니다. 제공업체를 선택하고 인증한 후 연결 엔드포인트와 대역폭을 지정합니다. AWS에서 활성화 키를 생성하고, 사용자는 제공업체 콘솔에 이 키를 제공하여 구성을 완료합니다. AWS Interconnect – 라스트 마일은 두 물리적 위치에서 4개의 중복 연결을 자동으로 프로비저닝하고, BGP 라우팅을 구성하며, MACsec 암호화 및 Jumbo Frames를 기본적으로 활성화합니다. 그 결과 네트워킹 구성 요소를 수동으로 구성하지 않고도 모범 사례에 부합하는 AWS에 대한 탄력적인 프라이빗 연결이 가능합니다.

AWS Interconnect – 라스트 마일은 1Gbps에서 100Gbps까지의 대역폭을 지원하며, 사용자는 다시 프로비저닝하지 않고도 콘솔에서 대역폭을 조정할 수 있습니다. 이 서비스는 Direct Connect 포트로의 최대 99.99%의 가용성 SLA를 포함하며, 연결 상태 모니터링을 위한 CloudWatch Network Synthetic Monitor를 번들로 제공합니다. AWS Interconnect – 라스트 마일은 AWS Interconnect – 멀티 클라우드와 마찬가지로 Direct Connect 게이트웨이에 연결되며, 이는 사용자 측의 가상 프라이빗 게이트웨이, 전송 게이트웨이 또는 AWS Cloud WAN 배포에 연결됩니다. 자세한 내용은 AWS Interconnect 사용 설명서를 참조하세요.

Lumen Technologies의 Product SVP인 Scott Yow는 이렇게 말합니다.

AWS Interconnect – 라스트 마일을 Lumen 파이버 네트워크 및 Cloud Interconnect와 결합하여 클라우드 채택을 지연시키는 라스트 마일의 복잡성을 단순화하고 고객이 AWS로 더 빠르고 탄력적으로 전환할 수 있도록 지원합니다.

요금 및 가용성
AWS Interconnect – 멀티 클라우드 및 AWS Interconnect – 라스트 마일 요금은 요청한 용량에 대해 시간당 고정 요금에 기반하며, 시간당 비례 할당으로 청구됩니다. 워크로드 요구 사항에 맞는 대역폭 티어를 선택합니다.

AWS Interconnect – 멀티 클라우드 요금은 리전 페어에 따라 다릅니다. 미국 동부(버지니아 북부) 및 Google Cloud 버지니아 북부 간 연결은 미국 동부(버지니아 북부) 및 더 먼 리전 간 연결과 다르게 요금이 책정됩니다. AWS Cloud WAN을 사용하는 경우 임의의 글로벌 라우팅 모델은 트래픽이 여러 리전을 통과할 수 있음을 의미하며, 이는 배포의 총 비용에 영향을 미칩니다. 연결 규모를 조정하기 전에 리전 페어 및 용량 티어별 전체 요금 카드에 대해 AWS Interconnect 멀티 클라우드 요금 페이지를 검토하는 것이 좋습니다.

AWS Interconnect – 멀티 클라우드는 현재 미국 동부(버지니아 북부)에서 Google Cloud 버지니아 북부, 미국 서부(캘리포니아 북부)에서 Google Cloud 로스앤젤레스, 미국 서부(오리건)에서 Google Cloud 오리건, 유럽(런던)에서 Google Cloud 런던, 유럽(프랑크푸르트)에서 Google Cloud 프랑크푸르트와 같이 5개 리전 페어에서 사용 가능합니다. Microsoft Azure는 2026년 후반에 지원될 에정입니다.

AWS Interconnect – 라스트 마일은 Lumen을 초기 파트너로 삼아 미국 동부(버지니아 북부)에서 출시됩니다. AT&T 및 Megaport를 비롯한 추가 파트너도 진행 중이며 추가 리전도 계획되어 있습니다.

AWS Interconnect를 시작하려면 AWS Direct Connect 콘솔로 이동하여 탐색 메뉴에서 AWS Interconnect를 선택합니다.

여러분의 환경에서 AWS Interconnect를 어떻게 사용하고 있는지 알고 싶습니다. 아래에 의견을 남기거나 AWS re:Post 커뮤니티를 통해 연락해 주세요.

– seb