AWS Transit Gateway 구조 개선

기존 구조와 문제점

입사 당시, 각 VPC는 이미 Transit Gateway에 연결되어 있었고, Route Propagation도 활성화된 상태였다.
모든 계정이 TGW를 중심으로 성 구조(star topology)로 연결되어 있어, 계정 간 통신이 자유롭게 이루어지는 구조였다.

처음엔 잘 짜인 구성이라 생각했지만, 구조를 파악할수록 모든 계정을 연결할 필요는 없지 않을까? 하는 의문이 생겼다.
특히 dev, stage, prod 환경 간에도 제약 없이 통신이 가능한 점에서, 보안 측면의 경계가 모호하다는 점이 눈에 띄었다.

보안상 적절한 구조인지 확인이 필요하다고 판단해, 보안 담당자님께 논의를 제안했고
당시 AWS 인프라에 대한 배경지식이나 접근 권한이 없으셨던 터라, 계정 간 통신 방식과 TGW 연결 구조를 직접 정리해 설명드렸다.

 

이 과정을 통해 나 역시 구조를 더 깊이 이해하게 되었고, 단순히 "작동하는 구조"에서 벗어나 "확장성과 보안을 고려한 구조"에 대해 고민하게 되었다.
그렇게 이 작업을 본격적으로 시작하게 되었다.

 

네트워크 구조 설계

1. 필요한 CIDR 범위 파악
dev, stage, prod 환경과 management, node 계정 간 실제 통신에 필요한 CIDR 대역만 선별했다.

2. TGW 라우팅 테이블의 Route Propagation 세분화
기존에는 모든 VPC CIDR이 각 계정 라우팅 테이블에 전파되었으나 이를 개별 VPC CIDR 단위로 세밀하게 제한하여 불필요한 네트워크 노출을 최소화했다.

Gateway 전파 기능 정리

사실 난 입사 후 인프라 구조를 분석하면서 Gateway Route Propagation이라는 개념을 처음 알게 되었다.

간단히 설명하면,
Gateway 전파는 TGW에 연결된 각 VPC의 CIDR 정보를 자동으로 TGW 라우팅 테이블에 반영해 주는 기능이다.
덕분에 각 VPC별로 라우팅 경로를 일일이 수동으로 등록하지 않아도 통신 경로가 자동으로 구성되어 매우 편리하다.

하지만 모든 계정 간 전파가 무분별하게 활성화되면, 의도하지 않은 트래픽이 흐를 위험이 있어 보안상 문제가 될 수 있다.
그래서 나는 환경별로 전파 범위를 제한하고, 실제로 통신이 필요한 계정 간에만 전파가 허용되도록 구조를 개선한 것이다.

 

NACL 설정 강화

또한, TGW를 통해 연결된 네트워크 경로에 대해 NACL(Network Access Control List) 설정도 강화했다.

기존에는 각 환경(dev, stage, prod)별 서브넷 단위의 인·아웃바운드 트래픽이 전체적으로 개방되어 있었으나, 이를 허용된 CIDR 범위 내에서 특정 서비스 포트로만 접근 가능하도록 제한했다.

이처럼 NACL을 활용해 TGW 전파로 인해 열려 있는 경로라도, 의도치 않은 네트워크 접근이나 외부 공격을 막을 수 있는 이중 방어 체계를 구축했다.

 

장단점

장점

- 계정 간 네트워크 경계가 명확해져 보안 강화

- 새로운 계정 추가 시 일관된 정책 하에서 확장 가능

- TGW 전파 기능 덕분에 라우팅 관리가 비교적 간소화됨

 

단점 및 개선 해야할 것

- TGW는 리전 단위로 비용이 발생하며, 트래픽량이 많아지면 비용 부담이 커질 수 있음

- TGW 라우팅 테이블이 많아질수록 관리 복잡도가 증가

  현재 우리 회사 구조만 해도 엮어서 관리하는 AWS 계정만 12개다. 

- CIDR 중복 방지를 위한 체계적인 IP 주소 관리(IPAM) 정책 필요

 

마무리

"왜 이렇게 설계했는가"

 

입사 초기에는 기존 구조를 이해하는 데 집중하느라 바빴지만, 점차 적응하면서 서비스 확장과 보안 요구에 맞춰 TGW 전파 설정과 통신 구조를 직접 재설계하는 작업을 수행했다. 이를 통해 네트워크 설계 역량과 이해도가 크게 향상되었다.

단순히 리소스를 만드는 데 그치지 않고,
‘왜 이렇게 설계되었는가’, ‘이 구조가 갖는 보안적 의미는 무엇인가’ 를 고민했던 경험이 나에게는 소중한 배움이었다.