🚀 $1M 통합 절감: 우리가 AWS Transit Gateway로 전환한 이유

Source: Dev.to

The Stakes: 48 Hours to “The Swap”

우리는 대규모 통합을 위한 프로덕션 전환일이 이틀 남은 상황이었습니다. 이 통합은 우리 SaaS 플랫폼과 포춘 500대 유틸리티 제공업체 간의 것이었으며, 목표는 그들의 레거시 콜센터를 프라이빗 클라우드 환경으로 마이그레이션하는 것이었습니다.

통합에는 글로벌 커뮤니케이션 파트너와 고규제 유틸리티 환경이 포함되어 있었으며, AWS 환경과 대규모 프라이빗 클라우드 간의 브리지를 구축해야 했습니다.

충돌: 10.0.0.0/8 함정

우리 내부 환경은 표준 10.0.0.0/16을 사용했습니다. 이는 완벽하게 작동했지만, 클라이언트와 통신을 시도했을 때 문제가 발생했습니다.

파트너의 내부 네트워크는 전체 10.0.0.0/8 사설 주소 범위를 보유하고 있었습니다. /16(우리 VPC)이 /8(그들의 백본)보다 더 구체적이기 때문에, BGP는 해당 범위와 일치하는 트래픽에 대해 우리 VPC를 우선시했을 것입니다.

재앙 시나리오: 우리 10.0.0.0/16을 광고하면 파트너의 전 세계 내부 트래픽을 탈취하게 되어, 전 세계 사무실을 대상으로 하는 패킷이 블랙홀에 빠지게 되고, 전환 48시간 전 전 세계적인 장애가 발생할 수 있습니다.

전략: 보조 CIDR “브리지”

• 기존 VPC에 보조 CIDR 블록으로 172.16.0.0/16을 추가했습니다.
• 내부 서비스는 기존 10.0.0.0/16에서 계속 실행했습니다.
• 통합을 위해 새 서브넷 172.16.1.0/24를 프로비저닝했습니다.
• 서버가 파트너와 통신할 때 172.16.x.x 주소를 사용했으며, 이 범위는 파트너의 글로벌 백본과 충돌하지 않았습니다.

피벗: “터널”에서 “거버넌스”로

브리지를 작동시키기 위해 우리는 표준 Virtual Private Gateway (VGW) 에서 AWS Transit Gateway (TGW) 로 전환했습니다.

• VGW – 수동 파이프.
• Transit Gateway – 세분화된 제어를 제공하는 지능형 클라우드 라우터.

TGW를 사용하여 우리는:

• 10.0.0.0/16 억제 – 내부 범위가 VPN을 통해 절대 광고되지 않도록 했습니다.
• 172.16.1.0/24 삽입 – 파트너에게 새로운 “브리지” 범위만 광고했습니다.

기술 실행

# Example verification command
nc -zv 10.201.12.34 443   # test connectivity from 172.16.x.x to partner host

클라우드 아키텍트를 위한 교훈

• Scale dictates architecture – 간단한 site‑to‑site 연결에는 VGW만으로 충분하지만, 대규모 레거시 인프라를 가진 파트너와 연결할 때는 Transit Gateway가 라우트 필터링에 필수적이다.
• Don’t rebuild, extend – IP 충돌이 발생할 경우 전체 VPC 마이그레이션보다 Secondary CIDR을 추가하는 것이 더 빠르고 안전한 경우가 많다.
• Specific beats general – BGP에서는 가장 구체적인 경로가 항상 우선한다. 광고를 제어하지 않으면 작은 VPC가 전 세계 데이터 센터용 트래픽을 의도치 않게 차지할 수 있다.

Final Thoughts

우리는 “The Swap”을 일정에 맞춰 실행했습니다. Secondary CIDR로 전환하고 라우팅 관리를 위해 Transit Gateway를 사용함으로써 파트너의 전 세계적인 안정성을 위험에 빠뜨리지 않고 프로젝트를 진행할 수 있었습니다.

가장 훌륭한 DevSecOps 전쟁 이야기는 잘 타이밍을 맞춘 아키텍처 전환 덕분에 재해 자체가 발생하지 않는 경우입니다.