AWS VPC 이해하기
많은 팀이 다음과 같은 문제를 겪습니다.
퍼블릭과 프라이빗 서브넷이 제대로 분리되지 않아 데이터베이스가 외부에 노출된 채 운영됨
NAT Gateway 사용이 과도하게 누적되어 월말에 예기치 않은 네트워크 요금 폭탄 발생
AZ 간 데이터 흐름을 고려하지 않아 지역 간 전송 비용이 누적
VPC는 단순한 네트워크 환경을 구성하는 기능이 아닙니다. 보안을 통제하고, 서비스의 경계를 나누며, 비용을 절감할 수 있는 AWS의 핵심 설계 단위입니다.
VPC란 무엇인가?
VPC(Virtual Private Cloud)는 AWS에서 제공하는 사용자만의 독립된 가상 네트워크 환경을 말합니다. 쉽게 말해, 퍼블릭 클라우드 안에 자신만의 사설 네트워크를 만드는 것이라고 이해할 수 있습니다.
이 VPC는 네트워크를 격리해 외부로부터의 접근을 차단하거나 허용하는 보안의 경계를 설정하고, 자신이 원하는 네트워크 구조를 직접 설계해 나갈 수 있는 보안 도메인(Security Domain)의 역할을 합니다.
VPC를 사용하면 퍼블릭 서브넷과 프라이빗 서브넷을 나누어 웹 서버는 인터넷에 노출시키고, 데이터베이스 서버는 외부에서 접근하지 못하도록 하는 식의 안전하고 분리된 아키텍처를 구현할 수 있습니다. 또한, 보안 그룹(SG)과 네트워크 ACL(NACL)을 통해 인스턴스와 리소스 간 통신을 세밀하게 제어할 수 있으며, VPN이나 Direct Connect를 통해 온프레미스 네트워크와 안전하게 연결하는 것도 가능합니다.
결국, VPC는 AWS 클라우드에서 제공하는 리소스들을 위한 기본 네트워크 환경이자 보안의 첫 번째 울타리로, 모든 서비스는 VPC 안에서 동작하고, 이 VPC의 구조에 따라 서비스의 성능과 보안, 그리고 비용까지 결정된다고 할 수 있습니다.
VPC 구성 요소
VPC는 단일 네트워크 공간이지만, 이를 구성하는 여러 요소들이 조합되어 하나의 네트워크 아키텍처를 형성합니다. 각 요소는 고유의 역할을 가지며, 함께 사용될 때 네트워크의 동작 방식과 보안 정책, 데이터 흐름을 결정하게 됩니다.
Subnet
VPC 안에서 IP 주소 범위를 잘라서 만든 네트워크의 작은 구역입니다. 퍼블릭 서브넷과 프라이빗 서브넷으로 구분하여, 인터넷과의 연결 여부에 따라 서비스 역할을 분리할 수 있습니다. 예를 들어, 웹 서버는 퍼블릭 서브넷, 데이터베이스 서버는 프라이빗 서브넷에 배치하는 것이 일반적입니다.
Route Table
서브넷 내부의 트래픽이 어디로 전달될지를 정의합니다. 인터넷으로 나갈지, 다른 VPC로 보낼지, NAT Gateway를 통해 우회할지 등 목적지별 경로를 명시합니다. 모든 서브넷은 반드시 하나의 라우팅 테이블과 연결되어야 하며, 이 설정에 따라 네트워크의 흐름이 결정됩니다.
NACL (Network ACL)
VPC의 서브넷 단위에서 동작하는 네트워크 레벨의 방화벽입니다. Inbound(들어오는 트래픽)와 Outbound(나가는 트래픽)에 대한 허용/차단 규칙을 설정할 수 있으며, 서브넷에 적용됩니다. Stateless 방식을 사용하므로, 들어올 때와 나갈 때의 네트워크 트래픽을 완전히 별개의 것으로 취급합니다. 따라서 Inbound와 Outbound 규칙을 각각 설정해야 하는 특징이 있습니다.
Security Group
인스턴스 단위에서 동작하는 가상 방화벽입니다. EC2, RDS 등 AWS 리소스에 직접 적용되며, 인스턴스에 도착하거나 나가는 트래픽을 필터링합니다. NACL과 달리 Stateful 방식으로 동작하기 때문에, 트래픽이 들어왔을 때의 규칙을 나갈 때도 기억하고 있습니다. Inbound 규칙만 설정해도 해당 세션의 Outbound 트래픽은 자동으로 허용됩니다.
Internet Gateway (인터넷 게이트웨이)
VPC를 외부 인터넷과 연결해주는 관문 역할을 하는 리소스입니다. 퍼블릭 서브넷의 인스턴스가 인터넷에 접근하거나, 인터넷에서 퍼블릭 서브넷의 리소스에 접근할 수 있도록 연결 통로를 제공합니다.
NAT Gateway (NAT 게이트웨이)
프라이빗 서브넷에 있는 리소스들이 인터넷으로 나가는 요청(예: 소프트웨어 패키지 다운로드 등)을 가능하게 해주는 네트워크 장치입니다. 프라이빗 서브넷의 인스턴스는 외부로 나가는 요청은 할 수 있지만, 외부에서 직접 접속은 불가능한 보안성을 유지할 수 있도록 해줍니다.
VPC Endpoint
AWS 서비스(S3, DynamoDB 등) 또는 다른 VPC 리소스에 프라이빗 네트워크 경로를 통해 접근할 수 있게 해주는 기능입니다. 이를 통해 인터넷 게이트웨이나 NAT Gateway를 거치지 않고, 내부 네트워크를 통해 안전하고 빠르게 데이터를 주고받을 수 있습니다. VPC Endpoint는 두 가지 유형으로 구분되며, Interface Endpoint는 ENI를 통해 특정 서비스와의 통신을 가능하게 하고, Gateway Endpoint는 S3나 DynamoDB와 같은 서비스 전용 접근을 제공합니다.
VPC Peering
두 개의 VPC를 직접 연결해주는 방식으로, 서로 다른 VPC 간에 프라이빗 IP를 사용해 통신할 수 있도록 합니다. Peering 연결은 리전 내 혹은 리전 간에도 구성할 수 있으며, 주로 간단한 네트워크 연결이나 소규모 환경에서 많이 사용됩니다. 다만, 연결되는 VPC마다 Peering을 별도로 설정해야 하며, 대규모 네트워크에서는 관리가 복잡해질 수 있습니다.
Transit Gateway
여러 VPC와 온프레미스 네트워크를 중앙에서 연결해주는 허브 역할을 하는 서비스입니다. 기존의 Peering 구조처럼 1:1 관계로 연결하는 대신, Transit Gateway를 중심으로 여러 네트워크를 중앙집중식으로 관리할 수 있어 복잡한 네트워크 토폴로지를 단순화할 수 있습니다. 대규모 멀티 VPC 아키텍처나 하이브리드 클라우드 환경에서는 Transit Gateway를 활용하는 것이 유리합니다.
Direct Connect
온프레미스 데이터센터와 AWS 클라우드 간에 전용 네트워크 회선을 구성해주는 서비스입니다. 이를 통해 일반 인터넷을 통한 접근보다 안정적이고 지연이 적은 네트워크 연결이 가능하며, 데이터 전송 요금도 절감할 수 있습니다. 대용량 데이터 전송이나 고속 통신이 필요한 금융, 미디어, 게임 등의 분야에서 많이 사용됩니다.
VPC 사용 목적과 주요 활용 사례
VPC 사용목적
VPC는 AWS에서 나만의 네트워크를 만드는 공간입니다. 이 네트워크를 통해 내 서버, 데이터베이스, 애플리케이션들이 안전하게 통신하고, 외부로부터 보호받을 수 있게 됩니다. VPC를 쓰는 목적은 크게 두 가지입니다:
보안 강화
내 서버와 서비스가 외부 인터넷과 분리되어, 외부 공격으로부터 안전해집니다.
필요한 경우에만 인터넷과 연결되도록 설정해 보안을 더 단단하게 할 수 있습니다.
안정적인 서비스 운영
서버 간 통신을 세밀하게 관리할 수 있어, 필요한 서비스끼리만 연결되게 만들 수 있습니다.
트래픽이 많아져도 빠르고 안정적인 네트워크를 유지할 수 있습니다.
즉, VPC는 AWS 클라우드에서 안전한 울타리를 만들어주고, 그 안에서 서버들이 안전하고 빠르게 일을 잘할 수 있게 도와주는 역할을 합니다.
VPC의 대표적인 활용 사례
퍼블릭 네트워크 구성 (Public Subnet)
인터넷에서 접근 가능한 서비스(예: 웹 서버, API 서버)를 운영할 때 사용합니다.
퍼블릭 서브넷에 배치된 EC2 인스턴스는 인터넷 게이트웨이(IGW)를 통해 외부와 통신할 수 있습니다.
예: 웹사이트의 프론트엔드 서버, ALB(Application Load Balancer), API Gateway의 백엔드 서버
프라이빗 네트워크 구성 (Private Subnet)
외부 접근이 필요 없는 백엔드 서비스(예: DB 서버, 내부 API 서버)는 프라이빗 서브넷에 배치합니다.
퍼블릭 인터넷과는 직접 연결되지 않으며, 필요 시 NAT Gateway를 통해 외부로 나가는 요청만 제한적으로 허용합니다.
예: RDS, ElastiCache, 내부 마이크로서비스, 배치 처리 서버
하이브리드 클라우드 연결
온프레미스 데이터센터와 AWS를 연결할 때 VPC를 사용합니다.
VPN 또는 Direct Connect를 통해 온프레미스 네트워크와 AWS VPC를 안전하게 연결하여, 사내 시스템과 클라우드 리소스를 통합 운영할 수 있습니다.
보안 및 접근 제어
보안 그룹과 네트워크 ACL을 통해 인스턴스 간, 서비스 간 통신을 세밀하게 제어할 수 있습니다.
예: 특정 서브넷 내에서만 허용된 관리용 SSH 접속, DB 서버는 앱 서버에서만 접근 허용
데이터 전송 및 비용 최적화
S3, DynamoDB와 같은 AWS 서비스와의 통신을 VPC Endpoint로 처리하여 데이터 전송 비용과 보안 리스크를 줄일 수 있습니다.
Cross-AZ 트래픽 발생을 최소화하여 네트워크 비용을 절감하는 설계에도 활용됩니다.
VPC는 AWS 환경에서 네트워크를 자유자재로 설계하고, 보안과 트래픽을 통제하며, 효율적인 클라우드 인프라를 구축하기 위한 기본 설계 단위라고 볼 수 있습니다. 퍼블릭과 프라이빗 서브넷의 조합, 그리고 각종 보안 구성은 클라우드 인프라의 기본기이며, VPC를 이해하고 잘 다루는 것이 AWS 비용 절감과 운영 효율화의 출발점입니다.
비용절감 관점에서의 VPC 최적화
AWS VPC(Virtual Private Cloud)는 클라우드 인프라의 기본 네트워크 환경이자 보안의 첫 번째 울타리입니다. 하지만 단순히 인프라를 구축하는 것을 넘어, 비용절감 관점에서 VPC를 최적화하는 것은 예상치 못한 네트워크 비용을 절감하고 클라우드 자원의 효율성을 극대화하는 데 결정적인 역할을 합니다. 네트워크는 종종 숨겨진 비용 발생원이 되기 쉬우므로, 세심한 접근이 필요합니다.
VPC 설계가 비용에 미치는 영향
VPC를 어떻게 설계하느냐에 따라 네트워크 비용은 크게 달라질 수 있습니다. 아래에 두 가지 예시를 들어보겠습니다.
불필요한 AZ(가용 영역) 간 트래픽
AWS는 동일 리전 내에서도 다른 가용 영역(AZ) 간의 데이터 전송에 대해 비용을 부과합니다(DataTransfer-Regional-Bytes). 애플리케이션의 구성 요소들이 여러 AZ에 분산 배치되어 있지만, 이들 간에 데이터 통신이 매우 잦고 비효율적이라면 AZ 간 데이터 전송 비용이 예상보다 크게 발생할 수 있습니다. 예를 들어, 웹 서버와 데이터베이스가 서로 다른 AZ에 있지만, 모든 요청마다 대량의 데이터를 주고받는 경우입니다.
자주 통신하는 구성 요소들은 최대한 동일 AZ 내에 배치하여 AZ 간 트래픽을 최소화해야 합니다. 또한 데이터베이스나 백엔드 서비스의 데이터를 애플리케이션 계층에서 캐싱하여 반복적인 AZ 간 호출을 줄입니다. 대용량 데이터 전송이 필요한 작업은 AZ 내에서 완료되도록 설계하거나, 배치 처리 주기를 최적화하는 방법을 활용할 수 있습니다.
과도한 NAT Gateway 사용
프라이빗 서브넷의 리소스가 인터넷으로 아웃바운드 통신을 할 때 NAT Gateway를 사용합니다. NAT Gateway는 시간당 요금과 처리되는 데이터량에 따라 과금됩니다. 프라이빗 서브넷의 모든 인스턴스가 불필요하게 대량의 아웃바운드 트래픽을 발생시키거나, 여러 AZ에 NAT Gateway를 비효율적으로 배치하면 비용이 급증할 수 있습니다. 예를 들어, 주기적으로 대용량 패키지를 다운로드하는 인스턴스가 많거나, 각 AZ마다 NAT Gateway를 생성했지만 특정 AZ의 트래픽이 미미한 경우입니다.
S3, DynamoDB 등 AWS 서비스로 향하는 트래픽은 NAT Gateway 대신 VPC Endpoin를 사용하여 사설망을 통해 통신하게 함으로써 NAT Gateway 데이터 처리 비용과 인터넷 데이터 전송 비용을 절감합니다. 그리고 트래픽 패턴을 분석하여 특정 AZ에만 NAT Gateway를 배치하고, 다른 AZ의 프라이빗 서브넷은 라우팅 테이블을 통해 해당 NAT Gateway를 사용하도록 구성하여 리소스 수를 최적화합니다. 이 경우 AZ 간 데이터 전송 비용이 발생할 수 있으므로 트래픽 양에 따른 상쇄 효과를 계산해야 합니다. 그리고 소프트웨어 패키지나 업데이트를 AWS 내부 S3 버킷에 미러링하여 다운로드 트래픽을 NAT Gateway 외부로 유도할 수 있습니다.
결론
VPC는 AWS에서 보안과 연결을 동시에 책임지는 보이지 않는 프레임워크입니다. 인스턴스를 잘 띄우는 것만큼, 그 인스턴스를 어디에, 어떻게 연결할지를 고민하는 것이 중요합니다.
트래픽이 몰리는 서브넷이 과연 지금의 구조로 충분한지
프라이빗 리소스가 정말 안전하게 격리되어 있는지
NAT Gateway와 AZ 간 데이터 흐름이 의도한 대로 설계되어 있는지
VPC Endpoints, Direct Connect, Transit Gateway가 비용과 성능 측면에서 제대로 활용되고 있는지
이 모든 것은 결국 “잘 보이지 않는 영역을 얼마나 설계하고 통제하느냐”의 문제입니다. 좋은 VPC 설계는 문제를 예방하고, 나쁜 설계는 결국 비용으로 돌아옵니다.
