VPC 네트워크 설계: 서브넷(Subnet)을 퍼블릭/프라이빗으로 나누는 기준

 클라우드 보안의 시작, 네트워크 격리

클라우드 인프라를 구축할 때 가장 먼저 마주하는 용어 중 하나가 바로 VPC(Virtual Private Cloud)입니다. VPC는 클라우드 내에 만드는 우리만의 가상 데이터 센터입니다. 하지만 단순히 VPC를 만들었다고 끝이 아닙니다. 이 거대한 공간을 어떻게 쪼개고(Subnetting), 어떤 용도로 사용할지 결정하는 것이 보안과 효율성을 좌우합니다.

많은 초보 설계자가 범하는 실수는 모든 리소스를 인터넷에 노출된 하나의 서브넷에 몰아넣는 것입니다. 이는 마치 현관문 없이 금고를 길거리에 두는 것과 같습니다. 오늘은 안전하고 튼튼한 인프라를 위해 서브넷을 퍼블릭(Public)과 프라이빗(Private)으로 나누는 결정적 기준을 알아보겠습니다.


1. 서브넷 분리의 핵심 원리: 라우팅 테이블과 인터넷 게이트웨이

퍼블릭과 프라이빗을 나누는 기준은 물리적인 위치가 아닙니다. 바로 '인터넷과 직접 통신할 수 있는가?'입니다. 이를 기술적으로 결정하는 것은 라우팅 테이블(Routing Table) 설정입니다.

  • 퍼블릭 서브넷: 라우팅 테이블이 인터넷 게이트웨이(IGW, Internet Gateway)를 향해 열려 있습니다. 외부에서 들어오는 트래픽을 직접 받을 수 있고, 내부에서 밖으로 나갈 수도 있습니다.
  • 프라이빗 서브넷: 인터넷 게이트웨이로 가는 경로가 없습니다. 외부에서 직접 접근할 수 없으며, 내부IP(Private IP)로만 통신합니다.

2. 퍼블릭 서브넷(Public Subnet): 외부와 소통하는 접점

퍼블릭 서브넷은 외부 사용자의 요청을 가장 먼저 받아내는 '안내 데스크' 역할을 합니다. 따라서 반드시 외부 인터넷 접근이 필요한 리소스만 이곳에 배치해야 합니다.

퍼블릭 서브넷 배치 기준

  • 로드 밸런서 (Load Balancer, ALB/NLB): 사용자의 트래픽을 받아 뒷단의 서버로 분산시켜주는 역할을 하므로 반드시 공인 IP를 가지고 외부에 노출되어야 합니다.
  • 배스천 호스트 (Bastion Host): 관리자가 외부에서 내부 프라이빗 서버에 접속하기 위해 거쳐가는 '점프 서버'입니다. 보안을 위해 최소한의 포트만 열어두고 퍼블릭에 배치합니다.
  • NAT 게이트웨이 (NAT Gateway): 프라이빗 서브넷에 있는 서버들이 외부 인터넷(패치 다운로드 등)을 이용할 수 있도록 대리 접속을 수행하는 장비입니다.

주의할 점: 과거에는 웹 서버(Web Server)도 퍼블릭에 두었으나, 최근에는 웹 서버조차 프라이빗에 두고 로드 밸런서만 퍼블릭에 두는 아키텍처가 표준으로 자리 잡고 있습니다.


3. 프라이빗 서브넷(Private Subnet): 데이터와 로직의 안전지대

프라이빗 서브넷은 외부의 침입을 원천적으로 차단해야 하는 '금고'이자 '연구실'입니다. 비즈니스의 핵심 로직과 데이터는 모두 이곳에 숨겨야 합니다.

프라이빗 서브넷 배치 기준

  • 웹/애플리케이션 서버 (WAS, EC2): 실제 비즈니스 로직을 처리하는 서버들입니다. 로드 밸런서를 통해서만 트래픽을 전달받으며, 직접적인 인터넷 접속은 차단합니다.
  • 데이터베이스 (RDS, Aurora): 기업의 가장 중요한 자산인 데이터가 저장되는 곳입니다. 그 어떤 경우에도 DB가 공인 IP를 가지고 인터넷에 직접 노출되어서는 안 됩니다.
  • 백엔드 시스템 및 AI 모델 서버: 내부 처리를 담당하는 모든 시스템은 프라이빗 영역에서 보호받아야 합니다.

4. 프라이빗 서버는 어떻게 인터넷을 쓸까? (NAT와 연결성)

"프라이빗 서브넷은 인터넷이 안 된다면서요? 그럼 서버 업데이트나 패치 설치는 어떻게 하나요?"라는 의문이 생길 수 있습니다.

이때 사용하는 것이 바로 NAT 게이트웨이입니다. 프라이빗 서브넷의 서버가 외부로 나가야 할 때(Outbound), 트래픽은 퍼블릭 서브넷에 있는 NAT 게이트웨이를 거쳐서 나갑니다. 중요한 점은 나가는 것은 가능하지만, 외부에서 NAT를 뚫고 들어오는(Inbound) 것은 불가능하다는 것입니다. 이 단방향 통신 덕분에 보안성을 유지하면서도 필요한 업데이트를 수행할 수 있습니다.


5. 계층적 보안 설계 (Multi-Tier Architecture)

가장 이상적인 VPC 설계는 역할에 따라 서브넷을 3계층(Tier) 이상으로 나누는 것입니다.

  1. Presentation Tier (Public): 로드 밸런서 배치
  2. Application Tier (Private): 웹 서버, API 서버 배치
  3. Data Tier (Private): 데이터베이스 배치

이렇게 계층을 나누고 각 서브넷 사이에 보안 그룹(Security Group)과 네트워크 ACL(NACL)을 적용하면, 해커가 1차 방어선(Public)을 뚫더라도 2차, 3차 방어선에서 막히게 되어 데이터 유출 위험을 획기적으로 줄일 수 있습니다.


보안은 설계 단계에서 결정된다

VPC 네트워크 설계에서 서브넷을 나누는 것은 단순히 IP 주소를 관리하기 위함이 아닙니다. 그것은 '누구에게 무엇을 보여줄 것인가'를 결정하는 보안 정책의 실체화입니다.

지금 여러분의 클라우드 아키텍처를 점검해 보세요. 혹시 소중한 데이터베이스가 퍼블릭 서브넷에 덩그러니 놓여 있지는 않나요? 퍼블릭에는 최소한의 연결 통로만 남기고, 모든 핵심 자산은 프라이빗 서브넷으로 옮기는 것, 이것이 안전한 클라우드 운영의 첫걸음입니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

온프레미스 vs 클라우드: 인프라 아키텍처의 결정적 차이 5가지

기업의 운명을 가르는 선택, 인프라 아키텍처 디지털 전환(DX)이 가속화되면서 모든 기업은 중요한 기로에 서 있습니다. 바로 "데이터와 시스템을 어디에 둘 것인가?"라는 질문입니다. 과거에는 회사 내부에 서버실을 구축하는 것이 당연했지만, 이제는 클라우드가 강력한 대안으로 자리 잡았습니다. 하지만 무조건적인 클라우드 전환이 정답은 아닙니다. 이 글에서는 IT 인프라의 두 축인 온프레미스(On-Premise) 와 클라우드(Cloud) 의 개념을 명확히 하고, 의사 결정에 꼭 필요한 5가지 결정적 차이를 분석해 드립니다. 1. 개념의 차이: 소유할 것인가, 빌려 쓸 것인가? 본격적인 비교에 앞서 두 개념을 가장 쉽게 이해하는 방법은 '부동산'에 비유하는 것입니다. 온프레미스(On-Premise): 직접 땅을 사고 집을 짓는 '자가 주택'과 같습니다. 하드웨어부터 네트워크, 운영체제까지 기업이 직접 구매하여 사내 전산실이나 데이터 센터 에 구축하고 운용합니다. 모든 통제권이 나에게 있습니다. 클라우드(Cloud): 필요한 만큼 공간을 빌려 쓰는 '호텔'이나 '공유 오피스'와 같습니다. AWS, Azure, Google Cloud 같은 공급자가 구축해 둔 거대한 인프라 자원을 인터넷을 통해 필요한 만큼 빌려 쓰고, 쓴 만큼 비용을 지불합니다. 2. 비용 구조: 초기 투자비용(CAPEX) vs 운영 비용(OPEX) 가장 큰 차이는 돈을 쓰는 방식에 있습니다. 온프레미스: 초기 투자 중심 (CAPEX) 온프레미스는 시스템 구축 초기에 막대한 자본적 지출(CAPEX)이 발생합니다. 서버, 스토리지, 네트워크 장비를 직접 구매해야 하며, 이를 설치할 공간과 전력, 냉각 시스템도 갖춰야 합니다. 구축 후에는 감가상각을 통해 비용을 처리합니다. 장기적으로 시스템 변경이 거의 없다면 총비용 면에서 유리할 수 있습니다. 클라우드: 운영 비용 중심 (OPEX) 클라우드는 초기 구축비...
자세한 내용 보기

로드 밸런서(ELB/ALB)의 알고리즘: 라운드 로빈 vs 리스트 커넥션

  트래픽 폭주, 서버가 버티는 비결 웹 서비스 운영 중 사용자가 급격히 늘어날 때, 단 한 대의 서버로는 모든 요청을 처리할 수 없습니다. 이때 등장하는 구세주가 바로 로드 밸런서(Load Balancer) 입니다. AWS의 ELB(Elastic Load Balancing)나 ALB(Application Load Balancer)가 대표적인 예입니다. 로드 밸런서는 들어오는 트래픽을 여러 대의 서버(EC2 등)에 골고루 나눠주는 교통경찰 역할을 합니다. 하지만 무턱대고 나누는 것이 아닙니다. ' 어떤 규칙'으로 나눌 것인가 에 따라 서비스의 안정성과 속도가 완전히 달라집니다. 오늘은 가장 대표적인 두 가지 알고리즘, 라운드 로빈(Round Robin) 과 리스트 커넥션(Least Connection) 을 비교 분석해 봅니다. 1. 라운드 로빈(Round Robin): 공평하게 순서대로 가장 기본적이고 직관적인 방식입니다. ' 순차적 분산' 이라고도 부릅니다. 작동 원리 마치 카드 게임에서 딜러가 플레이어들에게 카드를 한 장씩 순서대로 나눠주는 것과 같습니다. 서버가 A, B, C 세 대가 있다면, 첫 번째 요청은 A, 두 번째는 B, 세 번째는 C, 네 번째는 다시 A에게 보냅니다. 현재 서버의 상태나 부하량은 고려하지 않고 오직 순서 에만 입각해 트래픽을 배분합니다. 장점 단순함: 구현이 매우 쉽고 이해하기 편합니다. 리소스 소모 적음: 로드 밸런서가 복잡한 계산을 할 필요가 없어 자체 부하가 적습니다. 동일 환경에 유리: 모든 서버의 스펙이 동일하고, 처리해야 할 요청의 성격(처리 시간)이 비슷할 때 가장 효율적입니다. 단점 부하 불균형: 어떤 요청은 1초 만에 끝나지만, 어떤 요청은 1분이 걸릴 수 있습니다. 라운드 로빈은 이를 무시하고 계속 요청을 보내기 때문에, 운 나쁘게 무거운 작업만 할당받은 특정 서버가 과부하로 뻗어버릴 수 있습니다. 2. 리스트 커넥션(Least Con...
자세한 내용 보기