[AWS] AWS VPC 설계 실수, 이대로 괜찮을까? 사례로 보는 개선 방안

목차

• AWS VPC 설계 실수, 왜 초반에 바로잡아야 할까
• 핵심 개념 정리: VPC 최적화는 주소 체계와 경계 설계부터
• 1. CIDR(Classless Inter-Domain Routing, IP 주소 범위)
• 2. Public Subnet과 Private Subnet
• 3. Route Table과 Egress(이그레스, 외부로 나가는 트래픽)
• 4. Security Group과 NACL
• 사례 연구: 처음엔 단순했지만 점점 위험해진 VPC 구조
• 실전 구현: 개선된 VPC 구조를 단계별로 설계해보겠습니다
• 1. 주소 체계부터 나눕니다
• 2. 서브넷은 역할 기준으로 분리합니다
• 3. 보안 그룹은 역할 기반으로 단순하게
• 4. NAT Gateway는 필요한 경로만 태웁니다
• ⚠️ 트러블슈팅: 제가 실제로 겪었던 흔한 문제들
• 문제 1. 프라이빗 서브넷인데 외부 통신이 안 됩니다
• 문제 2. 보안 그룹은 열었는데 접속이 안 됩니다
• 문제 3. VPC 피어링을 하려는데 주소가 겹칩니다
• 문제 4. 운영 서버에 직접 SSH만 열어둔 상태였습니다
• 검증: 설계가 잘 됐는지 어떻게 확인할까
• 자주 묻는 질문: AWS VPC 설계 실수, 어디부터 고치면 될까요?
• Q1. 이미 운영 중인데 VPC를 새로 나눠야 하나요?
• Q2. NACL도 세밀하게 다 설정해야 하나요?
• Q3. 서브넷을 많이 나누면 무조건 좋은가요?
• 정리: 좋은 클라우드 인프라 설계는 나중에 덜 고생하는 구조입니다

[AWS] AWS VPC 설계 실수, 이대로 괜찮을까? 사례로 보는 개선 방안

AWS 환경을 처음 설계할 때는 EC2(Elastic Compute Cloud), RDS(Relational Database Service), ALB(Application Load Balancer)부터 눈에 들어오는데요. 실제 운영에서는 결국 AWS VPC 설계 실수가 가장 오래 발목을 잡곤 합니다. 저도 처음엔 서브넷(Subnet, 네트워크를 잘게 나눈 구간)만 잘 나누면 끝인 줄 알았는데, 막상 운영에 들어가니 라우팅(Routing), NAT Gateway(사설망 인터넷 출구), 보안 그룹(Security Group), NACL(Network ACL)에서 삽질을 꽤 했습니다. 특히 서비스가 커질수록 VPC 최적화와 네트워크 보안은 나중에 덧대는 방식으로는 한계가 분명하더라고요.

이번 글에서는 제가 실제로 자주 봤던 패턴을 바탕으로, 흔한 실수와 개선 방안을 사례 중심으로 풀어보겠습니다. 혹시 지금 VPC를 하나만 만들고 모든 워크로드를 몰아넣고 계신가요? 그렇다면 여기서 소개할 핵심 포인트, 한 번 점검해보셔야 합니다.

퍼블릭 서브넷, 프라이빗 서브넷, NAT Gateway, IGW(Internet Gateway), ALB, 애플리케이션 서버가 구분된 전체 구조 예시입니다.

AWS VPC 설계 실수, 왜 초반에 바로잡아야 할까

쉽게 말해 VPC(Virtual Private Cloud)는 AWS 안에서 내가 직접 설계하는 가상 네트워크입니다. 온프레미스에서 VLAN, 방화벽, 라우터를 나눠 설계하듯이 클라우드에서도 같은 감각이 필요하거든요. 근데 차이가 하나 있습니다. 클라우드는 너무 쉽게 만들어진다는 점이죠. 클릭 몇 번이면 VPC 하나, 서브넷 몇 개, 보안 그룹 몇 개가 금방 생깁니다. 문제는 그 쉬움이 설계를 대충하게 만든다는 거예요.

제가 직접 해보니 초기에 대충 만든 VPC는 나중에 이런 식으로 문제를 일으켰습니다.

• 개발, 운영, 배치 서버가 한 VPC 안에서 서로 과하게 통신함
• 퍼블릭 서브넷과 프라이빗 서브넷 구분은 했지만 라우팅 테이블이 뒤섞임
• NAT Gateway 비용이 예상보다 커짐
• 보안 그룹 규칙이 누더기처럼 늘어나서 추적이 어려워짐
• VPC 피어링(VPC Peering)과 Transit Gateway 전환 시 주소 대역이 충돌함

결국 클라우드 인프라 설계의 핵심은 리소스를 만드는 속도가 아니라, 나중에 덜 고생하는 구조를 만드는 데 있었습니다.

핵심 개념 정리: VPC 최적화는 주소 체계와 경계 설계부터

저도 처음엔 헷갈렸는데, VPC 설계를 이해하려면 아래 4가지만 먼저 잡으시면 됩니다.

1. CIDR(Classless Inter-Domain Routing, IP 주소 범위)

VPC를 만들 때 정하는 주소 대역입니다. 예를 들어 10.0.0.0/16 같은 식이죠. 여기서 실수 많이 납니다. 당장 서버 몇 대 안 쓴다고 너무 작게 잡아버리면, 나중에 확장하거나 다른 VPC와 연결할 때 주소가 겹쳐서 골치 아파집니다.

2. Public Subnet과 Private Subnet

퍼블릭 서브넷(Public Subnet)은 IGW로 직접 나갈 수 있는 구간이고, 프라이빗 서브넷(Private Subnet)은 외부에서 직접 진입하지 못하는 구간입니다. ALB나 Bastion Host를 어디에 둘지, 애플리케이션 서버와 DB를 어디에 둘지 여기서 갈립니다.

3. Route Table과 Egress(이그레스, 외부로 나가는 트래픽)

서브넷을 나눴다고 끝이 아닙니다. 어떤 트래픽이 어디로 나가는지 라우팅이 정확해야 합니다. NAT Gateway는 프라이빗 서브넷의 인터넷 아웃바운드 용도로 쓰지만, 모든 트래픽을 NAT 뒤로 몰아넣으면 비용과 복잡성이 같이 올라갑니다.

4. Security Group과 NACL

Security Group은 인스턴스 단위의 상태 저장(Stateful) 방화벽이고, NACL은 서브넷 단위의 비상태 저장(Stateless) 제어입니다. 실무에서는 대부분 Security Group 중심으로 운영하고, NACL은 정말 필요한 차단 정책에만 제한적으로 쓰는 편이 관리가 편하더라고요.

항목	권장 접근	흔한 실수
CIDR	확장과 연동을 고려해 여유 있게 설계	당장 필요한 크기만 보고 너무 작게 설정
서브넷	역할 기준으로 분리	퍼블릭/프라이빗만 나누고 운영 경계는 미분리
라우팅	서브넷별 목적지 명확화	기본 라우트를 무분별하게 재사용
보안	SG 중심 최소 권한	0.0.0.0/0 과도 허용

사례 연구: 처음엔 단순했지만 점점 위험해진 VPC 구조

예를 들어 이런 구조가 있었다고 해보겠습니다.

1. VPC 하나 생성: 10.0.0.0/16
2. 가용 영역(AZ, Availability Zone) 2개에 퍼블릭/프라이빗 서브넷 생성
3. ALB, EC2, RDS를 모두 같은 보안 그룹 체계 안에서 빠르게 연결
4. 배치 서버와 운영 서버도 같은 프라이빗 서브넷에 배치

초반에는 잘 돌아갑니다. 문제는 서비스가 늘면서 생깁니다. 개발팀이 테스트 서버를 추가하고, 외부 API 연동을 붙이고, 운영팀이 모니터링 서버를 얹고, 보안팀이 접속 통제를 요구하기 시작하거든요. 그러면 보안 그룹 규칙은 계속 늘어나고, 어느 서버가 어느 서버에 왜 열려 있는지 설명이 안 되는 순간이 옵니다. 이때부터가 진짜 무섭습니다.

AWS VPC 설계 실수는 보통 장애보다 먼저 운영 피로도로 옵니다. 변경이 무섭고, 누가 뭘 열었는지 모르고, 결국 그냥 둔 채로 서비스만 붙게 되죠.

실전 구현: 개선된 VPC 구조를 단계별로 설계해보겠습니다

제가 실제로 써보니까, 처음부터 거창한 구조보다 기준이 명확한 설계가 더 중요했습니다. 아래는 비교적 무난하면서도 운영성이 좋은 패턴입니다.

1. 주소 체계부터 나눕니다

# 예시용 CIDR 계획
Production VPC: 10.10.0.0/16
Staging VPC:    10.20.0.0/16
Shared VPC:     10.30.0.0/16

운영, 스테이징, 공용 서비스 영역을 아예 분리하면 나중에 피어링이나 Transit Gateway 검토할 때 훨씬 편합니다. 처음엔 이게 과한가 싶었는데, 실제로 써보니 분리의 이점이 정말 크더라고요.

2. 서브넷은 역할 기준으로 분리합니다

vpc:
  cidr: 10.10.0.0/16
  subnets:
    public-a:
      cidr: 10.10.0.0/24
      az: ap-northeast-2a
    public-c:
      cidr: 10.10.1.0/24
      az: ap-northeast-2c
    app-private-a:
      cidr: 10.10.10.0/24
      az: ap-northeast-2a
    app-private-c:
      cidr: 10.10.11.0/24
      az: ap-northeast-2c
    db-private-a:
      cidr: 10.10.20.0/24
      az: ap-northeast-2a
    db-private-c:
      cidr: 10.10.21.0/24
      az: ap-northeast-2c

포인트는 애플리케이션과 데이터베이스를 같은 프라이빗 서브넷에 두지 않는 거예요. 장애 분석, 접근 통제, 감사 대응까지 생각하면 분리하는 게 맞습니다.

가용 영역별로 퍼블릭, 앱 프라이빗, DB 프라이빗 서브넷이 분리된 구조를 보여주는 구성도입니다.

3. 보안 그룹은 역할 기반으로 단순하게

# ALB SG
Inbound:  443 from 0.0.0.0/0
Outbound: 80 to app-sg

# APP SG
Inbound:  80 from alb-sg
Outbound: 3306 to db-sg
Outbound: 443 to patch/proxy endpoints

# DB SG
Inbound:  3306 from app-sg

IP를 직접 넣기보다 보안 그룹 참조(Security Group Reference)를 쓰면 관계가 훨씬 명확해집니다. 여기서 중요한 포인트! DB에 0.0.0.0/0는 물론이고, 사내망 전체 허용도 습관적으로 넣지 않는 게 좋습니다.

4. NAT Gateway는 필요한 경로만 태웁니다

모든 프라이빗 서브넷이 무조건 NAT Gateway를 타게 두면 편하긴 한데, 비용과 제어 측면에서 아쉬움이 남습니다. S3는 VPC Endpoint(엔드포인트), Systems Manager도 가능하면 프라이빗 경로를 활용하는 식으로 줄여야 합니다. 이게 바로 실무형 VPC 최적화입니다.

# 점검 포인트 예시
- S3 access: Gateway Endpoint 검토
- EC2 patching: Systems Manager Session Manager 활용
- 외부 패키지 다운로드: 필요한 구간만 NAT 사용

⚠️ 트러블슈팅: 제가 실제로 겪었던 흔한 문제들

문제 1. 프라이빗 서브넷인데 외부 통신이 안 됩니다

처음엔 인스턴스 문제인 줄 알았는데, 알고 보니 라우팅 테이블이 NAT Gateway로 안 붙어 있었습니다. 프라이빗 서브넷이라고 자동으로 인터넷 아웃바운드가 되는 게 아니더라고요.

• 확인 1: 프라이빗 서브넷 라우트에 0.0.0.0/0 -> nat-xxxx 존재 여부
• 확인 2: NAT Gateway가 퍼블릭 서브넷에 있는지
• 확인 3: 퍼블릭 서브넷 라우트에 0.0.0.0/0 -> igw-xxxx 존재 여부

문제 2. 보안 그룹은 열었는데 접속이 안 됩니다

이건 NACL이 막고 있는 경우가 있었습니다. 저도 한참 헤맸네요. 특히 에페메럴 포트(Ephemeral Port, 임시 클라이언트 포트) 반환 트래픽이 막히면 연결은 시도되는데 응답이 안 옵니다.

문제 3. VPC 피어링을 하려는데 주소가 겹칩니다

이건 초반 CIDR 설계 실수입니다. 나중에 계정 분리, 조직 확장, 공유 서비스망 구성을 생각하면 주소 체계는 정말 대충 잡으면 안 됩니다. 한 번 잘못 잡으면 재구성이 꽤 커집니다.

문제 4. 운영 서버에 직접 SSH만 열어둔 상태였습니다

예전엔 Bastion Host를 많이 썼는데, 요즘은 가능하면 Session Manager 같은 대안을 먼저 검토하는 편입니다. Ingress(인그레스, 외부 트래픽 진입점)를 줄이는 것만으로도 네트워크 보안 수준이 체감될 정도로 좋아집니다.

보안 그룹 참조, 라우팅 테이블, NAT 연결 여부를 점검하는 운영자 시점의 다이어그램입니다.

검증: 설계가 잘 됐는지 어떻게 확인할까

구성을 바꿨으면 꼭 검증해야 합니다. 저는 아래 순서로 확인하거든요.

1. ALB에서 앱 서버로 정상 전달되는지 확인
2. 앱 서버에서 DB 포트만 열려 있는지 확인
3. 앱 서버가 필요한 외부 목적지로만 나가는지 확인
4. 운영 접근 경로가 공개 인터넷에 노출되지 않았는지 확인
5. VPC Flow Logs(플로우 로그)와 CloudWatch 로그로 차단/허용 패턴 확인

# 인스턴스 내부 점검 예시
curl -I http://internal-service
nc -zv db.internal 3306
ip route
nslookup s3.amazonaws.com

완성된 결과는 보통 이렇게 보입니다.

• ✅ 퍼블릭 노출 대상이 ALB 등 꼭 필요한 엔드포인트로 제한됨
• ✅ 애플리케이션과 DB의 보안 경계가 명확해짐
• ✅ 운영 접속 경로가 단순해지고 감사 대응이 쉬워짐
• ✅ NAT 비용과 불필요한 인터넷 경유가 줄어듦

드디어 됐다 싶었던 순간이 이런 때였습니다. 구조가 깔끔해지니까 장애 대응 속도도 확실히 좋아지더라고요.

허용/차단 트래픽, 서브넷 경계, 운영 접근 경로 검증 결과를 한눈에 보여주는 대시보드 이미지입니다.

자주 묻는 질문: AWS VPC 설계 실수, 어디부터 고치면 될까요?

Q1. 이미 운영 중인데 VPC를 새로 나눠야 하나요?

무조건은 아닙니다. 다만 주소 충돌, 보안 경계 불명확, 환경 혼재가 심하면 단계적으로 분리하는 게 낫습니다. 한 번에 갈아엎기보다 신규 워크로드부터 기준을 적용하는 방식이 현실적입니다.

Q2. NACL도 세밀하게 다 설정해야 하나요?

대부분은 아닙니다. Security Group 중심으로 최소 권한을 지키고, NACL은 광범위 차단이나 특별한 요구가 있을 때만 쓰는 편이 운영성이 좋았습니다.

Q3. 서브넷을 많이 나누면 무조건 좋은가요?

아닙니다. 의미 없는 분리는 관리 포인트만 늘립니다. 역할, 보안 경계, 라우팅 목적이 다를 때 나누는 게 맞습니다.

정리: 좋은 클라우드 인프라 설계는 나중에 덜 고생하는 구조입니다

이번 내용을 한 줄로 정리하면 이겁니다. AWS VPC 설계 실수는 처음엔 티가 안 나지만, 운영이 붙는 순간 비용, 보안, 변경 리스크로 돌아옵니다. 그래서 CIDR, 서브넷, 라우팅, 보안 그룹 기준을 초반에 잡아두는 게 정말 중요하죠.

제가 13년 넘게 인프라를 다루면서 느낀 건, 네트워크는 결국 경계와 의도를 명확히 하는 작업이라는 점입니다. 화려한 아키텍처보다, 왜 이 서브넷이 필요한지, 왜 이 포트가 열려 있는지 설명 가능한 구조가 더 오래 갑니다. 이거 진짜 중요하더라고요.

다음 글에서는 Transit Gateway와 VPC Peering을 언제 어떻게 선택하면 좋은지, 운영 관점에서 이어서 다뤄볼 예정입니다. 이전 글에서 다뤘던 보안 그룹 운영 기준과 함께 보시면 더 이해가 잘 되실 거예요.

흔한 실수, 개선 포인트, 검증 체크리스트를 한 장으로 정리한 요약 인포그래픽입니다.

📚 함께 읽으면 좋은 글

• FinOps 클라우드 비용 관리 베스트 프랙티스 체크리스트 10가지
• Vercel에서 GitLab CI/CD로 마이그레이션: 실제 경험과 고려사항
• Ansible을 활용한 프라이빗 네트워킹 자동화 구축 사례