10년 넘게 서버를 운영하면서 네트워크 설계 실수로 인한 보안 사고를 직간접적으로 여러 번 목격했습니다. 그 사고들의 공통점을 돌아보면 대부분 VPC 설계를 대충 넘겼거나 디폴트 설정을 그대로 쓴 케이스였습니다. 오늘은 AWS VPC가 왜 필요한지, 그리고 어떤 구조로 동작하는지 실무 경험을 바탕으로 정리해 보겠습니다.
1. AWS VPC, 왜 반드시 필요한가
초기 AWS EC2-Classic 환경에서는 가상 서버를 생성하면 전용 격리 네트워크 없이 퍼블릭 풀에 인스턴스가 그냥 배포됐습니다. 빠르게 서버를 올릴 수는 있었지만 엔터프라이즈 환경이 요구하는 네트워크 보안 컴플라이언스를 전혀 만족할 수 없는 구조였습니다. VPC는 그 한계를 극복하기 위해 등장했고, 지금은 AWS 인프라 설계의 가장 첫 단추입니다.
VPC가 반드시 필요한 이유는 크게 세 가지입니다.
첫째, 논리적 격리를 통한 보안 위협 차단입니다. VPC는 AWS 글로벌 인프라 안에서 사용자만을 위한 완벽히 격리된 가상 네트워크를 생성합니다. 서브넷, 라우팅 테이블, 보안 그룹, 네트워크 ACL을 통해 유입·유출되는 모든 트래픽을 레이어별로 정밀하게 제어할 수 있습니다.
둘째, 온프레미스와 동일한 네트워크 토폴로지 제어입니다. 사설 IP 주소 범위(CIDR 블록)를 직접 정의하고, 서브넷을 나눠 가용 영역에 배치하며, 인터넷 연결 여부를 결정하는 라우팅을 직접 제어할 수 있습니다. 가상 환경 위에 온프레미스 데이터센터와 동일한 수준의 네트워크 토폴로지를 재현하는 것이 가능합니다.
셋째, 안정적인 하이브리드 클라우드 확장입니다. VPC는 AWS Site-to-Site VPN 또는 AWS Direct Connect와의 연동을 전제로 설계되어 있습니다. 기업 내부망을 AWS 클라우드 공간까지 안전하게 확장하는 터널링 인프라의 기반이 바로 VPC입니다.
2. 퍼블릭 서브넷과 프라이빗 서브넷의 분리
VPC 내부는 트래픽의 성격에 따라 다층적인 네트워크 레이어로 구성됩니다. 처음 VPC를 설계할 때 이 분리를 제대로 하지 않으면 나중에 전체 구조를 뒤엎어야 하는 상황이 생깁니다. 직접 겪어본 이야기입니다.
퍼블릭 서브넷은 인터넷 게이트웨이(IGW)로 향하는 라우팅 경로가 포함된 서브넷입니다. 외부 유저의 접근을 직접 수용하는 ALB, 배스천 호스트 같은 인프라가 여기에 배치됩니다.
프라이빗 서브넷은 인터넷 게이트웨이로의 직접 라우팅이 원천 차단된 서브넷입니다. 외부 인터넷에서 이 영역의 인스턴스 사설 IP로 직접 접근할 수 없기 때문에 핵심 데이터베이스(RDS)나 백엔드 애플리케이션이 위치합니다. 프라이빗 인스턴스가 패치 등을 위해 외부에 아웃바운드 요청을 보낼 때는 퍼블릭 서브넷에 위치한 NAT 게이트웨이를 경유하는 구조를 취합니다.
3. 보안 그룹과 네트워크 ACL, 이중 방화벽 구조
VPC는 두 가지 가상 방화벽을 상호 보완적으로 운영합니다. 이 둘의 차이를 정확히 이해하지 못하면 트래픽이 왜 막히는지 원인을 찾는 데 몇 시간이 날아갑니다. 저도 초반에 네트워크 ACL의 Stateless 특성을 몰라서 인바운드는 열었는데 응답이 안 나가는 상황을 만든 적이 있습니다.
| 비교 항목 | 보안 그룹 | 네트워크 ACL |
|---|---|---|
| 적용 대상 | 인스턴스 레벨 (NIC 단위) | 서브넷 레벨 (Subnet 경계선 단위) |
| 상태 유지 | Stateful (상태 유지) | Stateless (상태 비유지) |
| 규칙 유형 | 허용(Allow) 규칙만 정의 가능 | 허용(Allow) 및 차단(Deny) 모두 명시 가능 |
| 규칙 평가 | 모든 규칙을 종합 평가 | 번호 순서대로 순차 평가, 첫 매칭 규칙 적용 |
4. 현장에서 자주 받는 질문들
Q. 디폴트 VPC가 있는데 왜 커스텀 VPC를 따로 만들어야 하나요?
AWS 계정 생성 시 자동으로 제공되는 디폴트 VPC는 모든 서브넷이 인터넷 게이트웨이에 연결된 퍼블릭 서브넷 구조입니다. 데이터베이스나 코어 API를 안전하게 보호할 수 없는 구조이고, 나중에 온프레미스 네트워크와 IP 대역이 겹쳐 하이브리드 연결 시 IP 충돌 사고가 납니다. 프로덕션 환경에서는 반드시 사전에 기획된 커스텀 VPC를 구축해야 합니다.
Q. 보안 그룹의 Stateful과 네트워크 ACL의 Stateless가 실제로 어떻게 다른가요?
Stateful인 보안 그룹은 인바운드 트래픽이 허용되면 그에 대한 아웃바운드 응답은 규칙 설정과 무관하게 자동으로 통과시킵니다. Stateless인 네트워크 ACL은 들어오는 문과 나가는 문을 완전히 별개로 취급합니다. 80포트 인바운드를 허용했더라도 응답이 나갈 때 쓰는 임시 포트(Ephemeral Ports, 1024~65535)에 대한 아웃바운드 허용 규칙이 없으면 서브넷 경계에서 패킷이 차단됩니다.
Q. 프라이빗 서브넷 인스턴스가 외부와 통신하려면 왜 NAT 게이트웨이가 필요한가요?
프라이빗 서브넷 인스턴스는 공인 IP 없이 사설 IP만 가집니다. 외부 패키지 서버 등과 통신하려면 사설 IP를 공인 IP로 변환해주는 NAT 메커니즘이 필수입니다. NAT 게이트웨이는 외부에서 안으로 들어오는 인바운드 연결은 차단하면서 내부에서 나가는 아웃바운드 트래픽만 중계해주는 구조입니다.
Q. VPC 피어링과 Transit Gateway는 어떤 기준으로 선택하나요?
VPC 피어링은 두 VPC 간 1:1 직접 연결입니다. 연결할 VPC 수가 소수일 때는 괜찮지만 수십 개의 VPC를 상호 연결하려면 N(N-1)/2개의 피어링 연결이 필요해서 관리 복잡성이 기하급수적으로 증가합니다. AWS Transit Gateway는 중앙 집중식 라우팅 허브로 수백 개의 VPC와 온프레미스 인프라를 스타(Star) 토폴로지로 단순화해서 중앙 제어할 수 있습니다. VPC가 5개 이상 넘어가기 시작하면 Transit Gateway 도입을 진지하게 고려해야 합니다.
Q. VPC 엔드포인트를 쓰면 어떤 이점이 있나요?
S3나 DynamoDB 같은 AWS 서비스들은 기본적으로 VPC 외부 퍼블릭 영역에 있습니다. VPC 내부 인스턴스가 이 서비스와 통신하려면 NAT 게이트웨이를 타고 인터넷 백본을 거쳐야 해서 데이터 전송 비용과 보안 취약점이 생깁니다. VPC 엔드포인트를 생성하면 트래픽이 인터넷으로 나가지 않고 AWS 내부 프라이빗 백본망을 통해 직접 도달합니다. 보안성이 올라가고 NAT 게이트웨이 데이터 처리 비용도 절감됩니다.
Q. 보안 그룹 소스에 IP 대신 다른 보안 그룹 ID를 지정하는 이유가 무엇인가요?
IP 기반 제어는 Auto Scaling으로 인스턴스가 늘어나거나 IP가 바뀔 때마다 방화벽 규칙을 매번 수정해야 합니다. 웹 서버 보안 그룹 ID를 WAS 보안 그룹의 인바운드 소스로 지정하면 웹 서버 보안 그룹이 부여된 인스턴스는 IP가 뭐든 자동으로 접근 권한이 부여됩니다. 동적으로 확장되는 마이크로서비스 환경에서 관리 부담이 크게 줄어듭니다.
Q. 서브넷 CIDR 블록 크기를 넉넉하게 잡아야 하는 이유가 있나요?
AWS VPC 서브넷은 사용자가 지정한 IP 범위 중 첫 4개와 마지막 1개, 총 5개 IP를 라우터·DNS·게이트웨이 전용으로 자동 예약합니다. /28 서브넷을 만들면 이론상 16개 IP지만 실제 사용 가능한 건 11개뿐입니다. EKS 컨테이너 환경이나 대규모 EC2 스케일아웃이 발생하면 IP 고갈로 인스턴스 프로비저닝 자체가 실패합니다. 초기 설계 시 /24 이상을 확보하는 걸 강력히 권장합니다.
Q. 프라이빗 서브넷의 DB 서버를 유지보수할 때 Bastion Host는 어떻게 동작하나요?
Bastion Host는 퍼블릭 서브넷에 배치되는 특수 목적 서버입니다. 엔지니어는 먼저 SSH 키 페어 인증과 사내 고정 IP 제한으로 보호된 Bastion Host에 1차 접속합니다. 그 후 Bastion Host 내부에서 프라이빗 서브넷 DB 서버의 사설 IP로 2차 터널링(SSH Forwarding) 접속을 합니다. 외부 공격 노출 표면을 Bastion Host 단 하나로 좁혀 보안 통제력을 높이는 구조입니다.
Q. VPC 플로우 로그는 어떤 상황에서 활용하나요?
VPC 플로우 로그는 VPC 내부 네트워크 인터페이스를 통과하는 IP 트래픽의 수신·발신 정보를 캡처하는 기능입니다. 소스 IP, 목적지 IP, 포트, 프로토콜, 패킷 크기와 함께 보안 그룹이나 NACL에 의해 허용(ACCEPT)됐는지 차단(REJECT)됐는지가 기록됩니다. CloudWatch Logs나 S3로 전송해서 SIEM 솔루션과 연동하면 침해 시도와 네트워크 병목을 정밀 진단할 수 있습니다. 실제로 저도 이상 트래픽 분석할 때 플로우 로그가 결정적인 단서가 된 경험이 있습니다.
Q. VPC 피어링 대신 AWS PrivateLink를 쓰는 경우는 언제인가요?
VPC 피어링은 두 네트워크 공간을 통째로 연결하기 때문에 CIDR 블록이 겹치면 아예 성립이 안 되고 상대방 VPC의 다른 인프라까지 노출되는 리스크가 있습니다. AWS PrivateLink는 전체 네트워크를 연결하지 않고 특정 서비스 엔드포인트만 상대방 VPC 내부에 가상 네트워크 인터페이스 형태로 노출시킵니다. IP 대역이 충돌하더라도 상관없이 특정 API 서비스만 안전하게 연결할 수 있습니다. 서드파티 서비스나 다른 계정의 특정 서비스와 연결할 때 PrivateLink가 훨씬 안전하고 깔끔한 선택입니다.
마무리
VPC 구축은 단순히 서버를 담는 바구니를 만드는 작업이 아닙니다. 비즈니스 자산을 보호하는 가상 경계선과 경비 시스템을 설계하는 일입니다.
VPC를 부실하게 설계한 인프라는 외부 위협에 상시 노출될 뿐만 아니라 가용성 확장이나 하이브리드 연결 시 전체 아키텍처를 처음부터 다시 짜야 하는 상황이 생깁니다. 레이어별 격리 메커니즘과 가상 방화벽 체계를 처음 설계 단계에서 제대로 잡아두는 것이 나중에 수십 배의 공수를 아끼는 길입니다.