AWS에서 VPC 설계: 실제 패턴(허브‑스포크, 메시, 멀티 계정)

Source: Dev.to

VPC 설계 시 가장 흔한 오류

AWS에서 아키텍처를 설계할 때 가장 흔한 실수는 VPC를 독립된 기술 컴포넌트로만 생각하는 것입니다.
실제로 VPC는 시스템 전체의 보안, 연결성, 확장성이 구축되는 기반이 됩니다.
이 오류는 첫날 나타나지는 않으며, 플랫폼이 성장하고 여러 팀, 환경(dev, qa, prod), 엄격한 보안 요구사항 또는 하이브리드 연결이 등장할 때 드러납니다.

실제 현장에서 쓰이는 VPC 패턴

정답은 하나가 없습니다. 아래에 가장 많이 쓰이는 패턴들을 정리했습니다.

1. Hub‑and‑Spoke (엔터프라이즈 환경에서 가장 많이 사용)

• 동작 방식
  • Spoke: 애플리케이션, 마이크로서비스 또는 격리된 환경을 담는 VPC들.
  • Hub: Spoke 간, 그리고 온프레미스와의 연결을 관리하는 중앙 VPC(또는 Transit Gateway).
• 사용 시점
  • 트래픽 규모를 예측할 수 있고, 트래픽 검사가 설계 단계부터 계획될 때.
• 트레이드‑오프
  • 트래픽 증가량을 정확히 예측하고 검사를 처음부터 포함한다면 매우 잘 작동합니다. 사후에 검사를 추가하려 하면 복잡해집니다.

2. Full Mesh (모두가 서로 연결)

• 동작 방식: 각 VPC가 VPC 피어링을 통해 직접 다른 모든 VPC와 연결됩니다. 중앙 집중점은 없습니다.
• 사용 시점
  • 3‑4개의 VPC만 보유한 스타트업에 적합합니다.
• 실제 문제점
  • 엔터프라이즈 환경에서는 피어링 수가 기하급수적으로 늘어나 관리가 불가능해집니다.

3. Multi‑Account (패턴이라기보다 전략)

• 개념: 인프라를 여러 AWS 계정으로 분리합니다.
  • 신뢰 경계, 거버넌스, blast radius(영향 범위)를 정의합니다.
• 장점
  • 팀이 서로 간섭 없이 빠르게 움직일 수 있습니다.
• 트레이드‑오프
  • 일정 규모가 넘으면 선택이 아니라 필수가 됩니다.
• 보완 관계
  • Multi‑Account와 Hub‑and‑Spoke는 서로 배타적이지 않으며, 많은 엔터프라이즈 아키텍처에서 함께 사용됩니다.

실제로 중요한 결정들

어떤 패턴을 선택하든, 아래 네 가지 결정이 설계가 성장에 견디는지를 좌우합니다.

1. 트래픽을 어디서 검사할 것인가?
2. 인터넷으로 나가는 경로는 어떻게 할 것인가?
3. 어떻게 세그멘테이션을 할 것인가?
4. 6개월 후에 이 구조는 어떻게 확장될 것인가?

실제 사례 (단순화)

결제 서비스 프로젝트에서 3개의 팀과 8개의 AWS 계정을 운영하던 중, 한 개발 팀이 공유 라우트 테이블을 수정하면서 프로덕션 연결이 40분간 끊기는 사고가 발생했습니다. 이는 기술적인 문제가 아니라 거버넌스 문제였습니다.

적용한 해결책

• 네트워킹 전용 계정을 별도로 분리.
• TGW(Transit Gateway)의 라우트 테이블 소유권을 전담 팀에 이전.
• 모든 네트워크 변경은 IaC 파이프라인을 통한 필수 승인 절차를 도입.

결과: 8개월 동안 네트워크 변경으로 인한 사고 0건 달성.

아키텍처 전형적인 진화 단계

1. 시작 – 1개의 VPC, 모든 것이 내부에 존재, 정상 작동.
2. 성장 – 서비스가 늘어나면서 보안·제어 문제가 발생.
3. 진화 – Multi‑Account + Hub‑and‑Spoke + 중앙 네트워킹 도입.
4. 결과 – 제어력·보안 향상, 복잡도 증가(불가피하지만 설계가 잘 되면 관리 가능).

결론

VPC 설계는 단순히 서브넷을 만드는 것이 아니라 시스템 간 통신 방식, 격리 방법, 확장 전략, 운영 비용을 결정하는 일입니다. 오늘은 동작하지만 내일은 무너질 수 있는 설계를 피하는 것이 핵심이죠.

정답 패턴은 존재하지 않습니다. 팀 수, 격리 수준, 트래픽 양에 따라 달라집니다. 다이어그램보다 위 질문들을 먼저 고민하세요.

Happy learning on AWS 🚀