VPC·서브넷·보안 그룹으로 네트워크 설계하기

요약: 가상 네트워크(VPC)에서 퍼블릭·프라이빗 서브넷과 보안 그룹으로 트래픽을 최소 허용하는 뼈대를 잡는다.

---

1. 언제 VPC를 직접 짜는가

VPC는 Virtual Private Cloud, 계정 안의 격리된 가상 네트워크다. 기본 VPC로도 실험은 된다. 다만 앱·DB·로드밸런서를 오래 운영하려면 퍼블릭/프라이빗을 나눈 작은 설계가 필요하다.

직접 짜는 경우:

• 웹 앱 + 데이터베이스를 같은 계정에 둘 때
• 인터넷에 열 것과 열지 않을 것을 구분해야 할 때
• 보안 그룹으로 티어 간 포트를 제한해야 할 때

기본 VPC에 전부 퍼블릭으로 올리는 구성은 튜토리얼용으로만 둔다. 실무 기본선은 ALB만 퍼블릭, 앱과 DB는 프라이빗이다. ALB는 Application Load Balancer, HTTP 로드밸런서다.

CIDR이 회사 네트워크·다른 VPC와 겹치면 나중에 VPN·피어링이 고통이다. 팀 표준이 있으면 따른다. 없으면 10.0.0.0/16으로 시작하고 문서에 적는다. CIDR은 Classless Inter-Domain Routing, 주소 블록 표기다.

---

2. 핵심 개념

서브넷은 VPC를 가용 영역(AZ)에 나눈 조각이다. AZ는 Availability Zone, 리전 안의 분리된 데이터센터 그룹이다. 한 AZ만 쓰면 그 AZ 장애에 전체가 멈춘다. 시작부터 서브넷을 두 AZ 이상에 둔다.

구분	특징	예
퍼블릭 서브넷	인터넷 게이트웨이(IGW) 경로, 공인 IP 가능	ALB, NAT, 배스천
프라이빗 서브넷	인터넷으로 직접 나가지 않음	앱 EC2, RDS

IGW는 Internet Gateway, VPC를 인터넷에 붙이는 문이다. 라우트 테이블에 0.0.0.0/0 → IGW가 있으면 그 서브넷은 퍼블릭 후보다. 인스턴스에 공인 IP가 있어야 실제로 열린다.

보안 그룹(SG) 은 인스턴스·ENI에 붙는 방화벽이다. stateful이다. 들어온 응답은 나간다. 허용 규칙 위주로 쓴다. ENI는 Elastic Network Interface, 가상 망 카드다.

NACL은 Network ACL, 서브넷 방화벽이다. stateless다. 실무에서는 SG를 주 통제로 두고, NACL은 기본 allow로 두는 경우가 많다. 둘 다 막으면 디버깅이 어렵다.

NAT Gateway는 프라이빗에서 아웃바운드(패키지 설치, 외부 API)를 낼 때 쓴다. 편하지만 시간당·데이터 요금이 난다. S3·DynamoDB는 VPC 엔드포인트가 더 싸거나 더 안전한 경우가 많다.

---

3. 최소 뼈대 예

리전 하나, AZ 두 개.

VPC  10.0.0.0/16
  public-a   10.0.0.0/24     AZ-a   ← ALB, NAT
  public-b   10.0.1.0/24     AZ-b
  private-a  10.0.10.0/24    AZ-a   ← 앱, RDS
  private-b  10.0.11.0/24    AZ-b

보안 그룹은 CIDR을 넓게 열지 않는다. 소스에 다른 SG ID를 넣는다.

ALB SG  : 0.0.0.0/0 → 443만
App SG  : ALB SG   → 앱 포트(예: 8080)
DB SG   : App SG   → 5432 또는 3306

SSH(22)를 0.0.0.0/0으로 열지 않는다. 운영 접속은 SSM Session Manager를 우선한다. SSM은 AWS Systems Manager다. 꼭 SSH가 필요하면 배스천 SG만, 내 IP만 잠시 연다.

확인 명령 예:

aws ec2 describe-vpcs --query "Vpcs[].{id:VpcId,cidr:CidrBlock}"
aws ec2 describe-security-groups --group-ids sg-YOUR_APP_SG

기본 라우트와 IGW 연결을 콘솔에서 한 번 눈으로 본다. 서브넷이 퍼블릭인데 라우트가 없으면 ALB가 안 뜬다.

---

4. 운영 시 주의

연결. 앱이 DB에 못 붙으면 대부분 SG·서브넷·라우트다. 포트만 열고 소스가 0.0.0.0/0이면 보안이 빈 것이다. 반대로 소스를 인스턴스 IP로 고정하면 스케일 때 깨진다. SG ID를 쓴다.

비용. NAT Gateway는 AZ마다 두면 고가용과 함께 요금이 는다. 개발은 NAT 하나 또는 VPC 엔드포인트로 줄인다. 트래픽이 많은 로그 업로드는 NAT를 거치지 않게 S3 엔드포인트를 검토한다.

보안. 퍼블릭 서브넷에 RDS를 두지 않는다. 퍼블릭 액세스 체크를 끈다. 관리형 DB·캐시도 프라이빗 서브넷 + SG.

IP 고갈. /24는 251개 근처다. ENI·로드밸런서가 주소를 먹는다. 앱이 커질 것 같으면 서브넷을 넉넉히 잡는다. 나중에 바꾸기 어렵다.

피어링·PrivateLink. 다른 VPC와 붙일 때 CIDR 겹침을 먼저 본다. 막 피어링하고 SG를 전부 열지 않는다.

기본 VPC. 계정에 기본 VPC가 있다. 빠르게 실험할 수는 있다. CIDR이 172.31.0.0/16인 경우가 많고, 퍼블릭 서브넷 위주다. 팀 서비스는 커스텀 VPC를 만들고 기본 VPC는 쓰이지 않게 표시한다. 기본 보안 그룹의 자기 자신 전체 허용을 앱 규칙으로 오해하지 않는다.

VPC Flow Logs. ENI 트래픽 허용/거부를 S3 또는 CloudWatch에 남긴다. 디버깅에 도움이 된다. 전 트래픽·전 서브넷을 상시 켜면 로그 비용이 난다. 의심 구간만, 보존을 짧게.

DNS. VPC 안에서 RDS·ALB 이름은 Route 53 private hosted zone 또는 AWS 제공 DNS로 푼다. 인스턴스 IP를 앱 설정에 하드코딩하면 재시작·페일오버 때 깨진다.

---

5. 정리

네트워크는 “일단 다 연다”가 아니다. 계층(퍼블릭/프라이빗) + SG 최소 허용으로 시작한다. 두 AZ, ALB만 인터넷, DB는 앱 SG만 허용이면 초반 설계로는 충분하다.

체크리스트

• VPC CIDR과 서브넷을 문서에 남긴다. 겹치면 나중에 VPN이 실패한다.
• 퍼블릭/프라이빗을 나누고 앱·DB는 프라이빗에 둔다. 공인 IP 앱 서버는 공격면이 넓다.
• SG 소스에 다른 SG ID를 쓴다. 0.0.0.0/0 DB 포트는 사고다.
• 22번을 인터넷에 상시 열지 않는다. SSM이 더 안전하다.
• NAT·엔드포인트 비용을 알고 켠다. 개발 계정에서 NAT만으로 월 요금이 나올 수 있다.

연습

1. 위 주소 계획으로 서브넷 네 개를 그리고 어떤 자원이 어디에 가는지 적는다.
2. ALB → 앱 → DB SG 규칙을 표로 만든다. 인터넷이 DB에 직접 닿는지 검사한다.
3. describe-security-groups로 실제 인바운드가 의도한 소스인지 확인한다.

라우트 테이블을 말로 적으면 실수가 줄어든다.

서브넷	목적지	타깃
public-*	10.0.0.0/16	local
public-*	0.0.0.0/0	igw-…
private-*	10.0.0.0/16	local
private-*	0.0.0.0/0	nat-… (필요할 때만)

프라이빗에 IGW를 붙이면 그 순간 퍼블릭과 다를 바 없다. NAT 없이 프라이빗이 패키지를 못 받는 것은 정상이다. 그때 엔드포인트나 잠시 퍼블릭 실험 서브넷을 쓴다. 운영 DB는 실험 서브넷에 두지 않는다.

IPv4만으로 시작해도 된다. 퍼블릭 IPv4 주소는 이제 시간당 요금이 있다. ALB·NAT가 주소를 들고 있으면 컴퓨트와 별도로 나온다. IPv6는 팀 준비가 되면 추가한다. 처음부터 듀얼 스택을 강제할 필요는 없다.

보안 그룹은 인바운드만 신경 쓰다 아웃바운드 0.0.0.0/0을 잊는다. 기본 전 허용이면 인스턴스가 아무 곳으로나 나간다. 민감 환경은 아웃바운드도 443·DB 포트처럼 필요한 것만 연다.

배스천을 둘 때 배스천 서브넷만 퍼블릭으로 두고, 배스천 SG는 내 IP 또는 VPN만 22에 허용한다. 배스천에서 앱 SG로 SSH가 열리면 앱은 여전히 인터넷에 안 열린다. 배스천 OS 패치를 앱과 같은 주기로 본다.

---

---