11장. VPC 네트워크 구성

이미지를 창고(ECR)에 넣었으니, 이제 그 이미지로 컨테이너를 실행할 차례 같지만, 그 전에 한 가지가 더 필요합니다. 컨테이너들이 살아갈 공간, 즉 네트워크입니다. 서버, 데이터베이스, 로드밸런서가 서로 안전하게 대화 하려면 잘 설계된 네트워크가 먼저 있어야 합니다.

이 장은 이 책에서 가장 개념이 많은 편입니다. 하지만 하나하나가 "담장", "동(棟)", "문", "이정표"처럼 현실에 빗댈 수 있어서, 아파트 단지 하나를 떠올리며 읽으면 어렵지 않습니다. 천천히 따라오세요.

[지금 여기]

우리는 22단계를 거쳐 "라이브 투표 서비스"를 만들고, 컨테이너에 담아, AWS에 배포합니다. 지금은 11단계, 서비스가 살 네트워크를 만들 차례입니다.

1. 1장개발 환경 준비 (터미널 / Node.js / Git / GitHub / VS Code / Claude Code)
2. 2장Claude Code 사용법 익히기
3. 3장무엇을 만들지 기획 (라이브 투표 서비스)
4. 4장로컬에서 서비스 만들기 (React + Express + PostgreSQL)
5. 5장Docker 개념
6. 6장Dockerfile 작성
7. 7장컨테이너 빌드·실행
8. 8장AWS 시작 (계정 / IAM / 리전 / 비용)
9. 9장이미지 태깅
10. 10장ECR에 이미지 올리기
11. 11장VPC 네트워크 구성
12. 12장RDS 데이터베이스 생성
13. 13장SSM 터널로 RDS 초기화
14. 14장ECS Fargate + ALB로 배포 (기본 완성)
15. 15장CI/CD (GitHub Actions)
16. 16장IaC (Terraform)
17. 17장배포 자동화 연결
18. 18장현업 운영 구조 이해
19. 19장무중단 배포
20. 20장신규 버전 배포 & 롤백
21. 21장(심화) 프론트를 Vercel로 분리 배포
22. 22장마무리 (회고 + 리소스 삭제)

• 방금 끝낸 것: 10장에서 우리 서비스 이미지(vote-api, vote-web)를 AWS의 이미지 창고인 ECR에 올렸습니다. 이제 배포에 쓸 재료(이미지)가 클라우드에 준비돼 있습니다.
• 이번 장에서 하는 것: 그 컨테이너들이 실제로 살아갈 사설 네트워크 (VPC)를 콘솔 마법사로 한 번에 만듭니다. 서브넷, 게이트웨이, 라우팅까지 갖춰진 "네트워크 집"을 짓고, 각 리소스를 지킬 보안 그룹의 설계를 이해합니다.

이번 장에서 완성되는 것

한 문장으로: 우리 서비스만의 격리된 네트워크 vote-vpc가 AWS에 만들어지고, 그 안에 두 개 가용영역으로 나뉜 퍼블릭·프라이빗 서브넷과 인터넷 통로(IGW·NAT)까지 갖춰집니다.

이렇게 되면 성공입니다: VPC 콘솔의 리소스 맵(Resource map)에서 vote-vpc 하나 아래에 퍼블릭 서브넷 2개, 프라이빗 서브넷 2개, 인터넷 게이트웨이 1개, NAT 게이트웨이 1개, 라우팅 테이블들이 선으로 연결된 그림이 보입니다.

사전 조건

이 장은 8~10장에서 준비한 AWS 환경 위에서 시작합니다. 아래가 갖춰져 있어야 합니다.

• AWS 계정에 로그인돼 있고, 리전이 서울(ap-northeast-2)로 맞춰져 있다. (8장에서 만든 계정. 오른쪽 위 리전 표시가 "서울 ap-northeast-2"인지 이 장을 시작할 때 다시 확인합니다.)
• 10장까지 마쳐 이미지가 ECR에 올라가 있다. VPC 자체는 ECR과 직접 연결돼 있진 않지만, 이 장의 네트워크가 완성돼야 12장(RDS)·14장(ECS)에서 그 이미지를 실제로 배포할 수 있습니다. 즉 지금은 "배포될 집"을 먼저 짓는 단계입니다.

이 장에서는 AWS 콘솔(웹 화면)만 씁니다. VS Code나 터미널은 쓰지 않습니다.

11.1 왜 VPC가 필요한가 — 아파트 단지 비유

(1) 개념

우리 서비스는 여러 부품(웹 서버, API 서버, DB)으로 이루어집니다. 이들을 아무 울타리 없이 인터넷에 그냥 두면 어떻게 될까요? 특히 데이터베이스가 인터넷에 그대로 노출되면, 전 세계 누구나 접속을 시도할 수 있어 매우 위험합니다. 그래서 우리 부품들만의 격리된 사설 네트워크가 필요합니다. 그게 VPC입니다.

아파트 단지로 비유하면

VPC를 하나의 아파트 단지라고 생각해 봅시다. 이 비유는 이 장 끝까지 계속 쓰이니 머릿속에 그림을 하나 그려 두세요.

• VPC = 단지 전체 — 담장으로 둘러싸인 우리 영역.
• 서브넷 = 단지 안의 각 동(棟) — 어떤 동은 외부인이 드나드는 상가동, 어떤 동은 주민만 쓰는 주거동입니다.
• 가용영역(AZ) = 서로 떨어진 부지 — 한 곳에 사고가 나도 다른 곳은 멀쩡하도록, 동들을 떨어진 위치에 나눠 짓습니다.

핵심 용어를 먼저 정리합니다.

(2) 활용 사례 — VPC를 실무에서 어디에 쓰나

VPC는 우리 투표 서비스에만 쓰는 게 아니라, 클라우드를 쓰는 거의 모든 회사가 기본으로 쓰는 구조입니다. 대표적인 쓰임새 몇 가지를 봅시다.

• 사내 격리망 만들기. 회사 내부에서만 쓰는 관리자 도구, 사내 위키, 경리 시스템 같은 것을 VPC 안에 두고 인터넷에서 아예 안 보이게 합니다. 건물 안에서만 열리는 문처럼, 회사 네트워크(또는 VPN)를 통해서만 접근하게 만드는 것이죠.
• 여러 팀·여러 환경을 분리. 개발용(dev), 테스트용(staging), 실서비스용 (production)을 각각 별도 VPC로 나눕니다. 그러면 개발자가 dev에서 실수로 뭔가 망가뜨려도 실서비스 VPC는 담장 밖이라 영향을 받지 않습니다. 팀별로 VPC를 나눠 서로의 서버에 함부로 못 들어가게 하기도 합니다.
• 다단계 보안(계층 방어). 바깥에서 온 요청은 맨 앞 계층(퍼블릭)까지만 닿게 하고, 그 뒤의 서버·DB는 안쪽 계층(프라이빗)에 숨깁니다. 한 겹을 뚫려도 그 안에 또 담장이 있어, 진짜 중요한 데이터까지 가기 어렵게 만드는 구조입니다. 이게 바로 우리가 이 장에서 만들 구조입니다.
• 프라이빗 서브넷에 DB 숨기기. 은행·쇼핑몰처럼 민감한 데이터를 다루는 곳은 데이터베이스를 반드시 프라이빗 서브넷에 둡니다. DB에는 인터넷에서 오는 길 자체가 없어서, 설령 비밀번호가 새어 나가도 바깥에서는 접속 시도 조차 할 수 없습니다.

한마디로, "무엇을 바깥에 보이게 하고 무엇을 숨길지"를 네트워크 수준에서 정하는 도구가 VPC입니다.

(3) 맛보기 — 이미 있는 기본 VPC 구경하기

VPC를 새로 만들기 전에, 사실 여러분의 AWS 계정에는 이미 기본 VPC (default VPC)가 하나 들어 있습니다. AWS가 계정을 만들 때 리전마다 하나씩 자동으로 넣어 준 것입니다. 이걸 눈으로 구경하면, 우리가 곧 만들 것이 어떤 모습인지 미리 감이 잡힙니다. 읽기만 하고 아무것도 만들지 않으니 요금도 들지 않습니다.

1. 콘솔 상단 검색창에 VPC를 입력하고, 나온 VPC 서비스를 클릭합니다.
2. 왼쪽 메뉴에서 Your VPCs(내 VPC)를 클릭합니다. 목록에 VPC가 하나 보이고, 이름은 비어 있거나 default이며 CIDR이 대개 172.31.0.0/16 입니다. 이게 AWS가 미리 넣어 둔 기본 VPC입니다.
3. 왼쪽 메뉴에서 Subnets(서브넷)를 클릭합니다. 그 기본 VPC에 딸린 서브넷 여러 개가 보이고, 각각 다른 가용영역(Availability Zone) 값 (ap-northeast-2a, ap-northeast-2c 등)을 갖고 있습니다. 바로 이게 "동을 떨어진 부지에 나눠 지었다"는 그 AZ입니다.
4. 왼쪽 메뉴에서 Route tables(라우팅 테이블)를 클릭해, 표 같은 게 있다는 것만 눈으로 확인합니다. (뜻은 11.5에서 설명합니다.)

지금은 이 화면들이 "이런 게 있구나" 정도로만 보여도 충분합니다. 방금 본 기본 VPC는 그대로 두고(지우지 마세요), 다음 절부터 우리 서비스 전용 VPC를 새로 만듭니다.

(4) 우리 프로젝트 적용은 11.3절에서 합니다. 그 전에 서브넷의 두 종류부터 확실히 구분하고 갑시다.

11.2 퍼블릭 서브넷 vs 프라이빗 서브넷

서브넷은 크게 두 종류로 나뉩니다. 이 구분이 보안의 핵심입니다.

우리 서비스의 배치는 이렇게 됩니다.

• 퍼블릭 서브넷에 둘 것: ALB(로드밸런서). 사용자의 요청을 인터넷에서 직접 받아야 하니까요. (ALB는 14장에서 만듭니다.)
• 프라이빗 서브넷에 둘 것: API 서버 컨테이너(ECS), 데이터베이스(RDS). 이들은 인터넷에 직접 노출되면 안 되고, ALB를 통해서만 접근되게 합니다.

이렇게 두면, 사용자는 오직 ALB(상가동)까지만 닿을 수 있고, 정작 중요한 서버와 DB(주거동)는 인터넷에서 직접 보이지 않습니다. 11.1의 활용 사례에서 본 "프라이빗 서브넷에 DB 숨기기"를 우리도 그대로 하는 것입니다.

11.3 VPC 만들기 — 마법사로 한 번에 (우리 프로젝트)

이제 우리 서비스 전용 VPC를 실제로 만듭니다. 예전에는 VPC, 서브넷, 게이트웨이, 라우팅을 하나하나 손으로 만들어야 했습니다. 지금은 AWS 콘솔의 마법사가 이 모든 걸 한 번에 만들어 줍니다. 초보자에게는 이 방식이 훨씬 안전하고 빠릅니다.

[콘솔] VPC 생성 (VPC and more)

1. 상단 검색창에 VPC를 입력해 VPC 서비스로 들어갑니다.
2. 오른쪽 위 VPC 생성(Create VPC) 버튼을 누릅니다.
3. 화면 위쪽 생성할 리소스(Resources to create)에서 VPC 등 (VPC and more) 을 선택합니다.
   • [주의] 여기서 반드시 VPC 등(VPC and more) 을 고르세요. 이 옵션이 서브넷·게이트웨이·라우팅까지 한꺼번에 만들어 주는 마법사입니다. "VPC만(VPC only)" 을 고르면 나머지를 전부 직접 만들어야 해서 초보자가 막히기 쉽습니다.
4. 설정을 아래 값 그대로 입력합니다.
   • 이름 태그 자동 생성(Name tag auto-generation): 켠 채로 두고, 입력칸에 vote 라고 적습니다. (여기서 정한 이름이 모든 구성요소 앞에 붙어 vote-vpc, vote-subnet-public1-ap-northeast-2a 처럼 이름이 자동으로 정해집니다.)
   • IPv4 CIDR 블록(IPv4 CIDR block): 10.0.0.0/16 (기본값 그대로).
   • IPv6 CIDR 블록: 없음(No IPv6 CIDR block) — 기본값 그대로 둡니다.
   • 테넌시(Tenancy): 기본값(Default) — 그대로 둡니다.
   • 가용영역(AZ) 수(Number of Availability Zones): 2
   • 퍼블릭 서브넷 수(Number of public subnets): 2
   • 프라이빗 서브넷 수(Number of private subnets): 2
   • NAT 게이트웨이(NAT gateways): 1개 AZ(In 1 AZ) 를 선택
     • [주의] NAT는 켜 두면 시간당 요금이 나옵니다. "AZ마다(1 per AZ)"로 하면 더 튼튼하지만 비용이 배로 듭니다. 실습에서는 비용을 아끼려고 1개 AZ로 충분합니다. (실습이 다 끝나면 22장에서 VPC와 함께 지워 과금을 멈춥니다.)
   • VPC 엔드포인트(VPC endpoints): 없음(None) 을 선택합니다. (기본값은 S3 게이트웨이인데, 우리 실습에는 필요 없으니 없음으로 둡니다.)
   • DNS 옵션(DNS options): 두 개(도메인 이름 확인/DNS 호스트 이름) 모두 체크된 기본값 그대로 둡니다.
5. 오른쪽 미리보기(Preview) 창에 네트워크 구조가 그림으로 표시됩니다. AZ 2개(ap-northeast-2a, ap-northeast-2c)에 퍼블릭·프라이빗 서브넷이 나뉘고, 인터넷 게이트웨이와 NAT 게이트웨이가 선으로 연결된 모습이 보이면 설정이 제대로 된 것입니다.
6. 아래 VPC 생성(Create VPC) 을 누릅니다. 여러 구성요소가 순서대로 만들어지며, 완료까지 1~2분 걸립니다. 각 항목 옆에 초록 체크가 모두 뜨고 "성공(Success)" 화면이 나오면 완료입니다.

아래처럼 보이면 성공입니다. 서브넷 4개가 두 가용영역(ap-northeast-2a, ap-northeast-2c)에 나뉘고, 퍼블릭 쪽은 인터넷 게이트웨이(vote-vpc-igw)로, 프라이빗 쪽은 NAT(vote-nat)로 이어져 있습니다.

11.4 서브넷을 2개 AZ에 나누는 이유

마법사에서 AZ를 2개로 정했더니, 퍼블릭·프라이빗 서브넷이 각각 두 AZ에 하나씩 놓였습니다. 왜 굳이 둘로 나눴을까요?

이유는 튼튼함(고가용성) 때문입니다. 만약 모든 걸 한 AZ에만 뒀는데 그 AZ에 장애가 나면 서비스 전체가 멈춥니다. 두 AZ에 나눠 두면, 한 AZ가 문제가 생겨도 다른 AZ에서 서비스가 계속됩니다.

또한 뒤에서 만들 RDS(데이터베이스)와 ALB(로드밸런서)는 규칙상 최소 2개 AZ의 서브넷을 요구합니다. 그래서 지금 2개 AZ로 만들어 둔 것이 이후 실습(12·14장)의 전제가 됩니다. 만약 AZ를 1개로 만들었다면 12장에서 막혔을 겁니다.

11.5 인터넷 게이트웨이 · NAT · 라우팅 테이블

마법사가 함께 만든 세 가지를 짚습니다. 이름은 어렵지만 "문"과 "이정표"로 이해하면 쉽습니다.

정리하면, 퍼블릭 서브넷 = IGW로 직접 인터넷과 오감, 프라이빗 서브넷 = NAT로 나가기만 가능, 직접 진입 불가입니다. 이 차이가 곧 11.2에서 말한 "상가동 vs 주거동"의 실제 구현입니다.

11.6 보안 그룹 설계 — 리소스별 방화벽

서브넷이 "구역(동)"이라면, 보안 그룹은 각 리소스(서버, DB 등) 앞에 세우는 "경비원"입니다.

보안 그룹은 실무에서 이렇게 쓰입니다

보안 그룹은 클라우드 서버를 지키는 가장 기본적인 방어선이라, 쓰임새가 아주 흔합니다. 예를 들어, 관리자용 접속(SSH 22번 포트)은 회사 사무실 IP에서 오는 요청만 허용해 두는 식으로 씁니다. 웹 서버는 80/443번만 열고 나머지는 다 막습니다. 데이터베이스는 아예 "우리 앱 서버에서 오는 것만" 허용해 인터넷에서는 접속조차 못 하게 잠급니다. 지금 우리가 설계할 것도 바로 이 마지막 패턴입니다.

우리 서비스에는 세 종류의 리소스가 있으니, 보안 그룹도 세 개를 설계합니다. 지금은 "이렇게 설계한다"는 계획만 세우고, 실제 생성은 각 리소스를 만들 때(12장 RDS, 14장 ALB·ECS) 함께 합니다.

• ALB 보안 그룹 (로드밸런서 앞 경비원) — vote-alb-sg

  • 허용: 인터넷 누구나(0.0.0.0/0) → 포트 80(HTTP)
  • 사용자가 웹으로 접속해야 하니, 바깥에서 오는 HTTP를 엽니다.

• ECS 보안 그룹 (컨테이너 앞 경비원) — vote-ecs-sg

  • 허용: ALB 보안 그룹에서 오는 요청만 → 포트 80
  • ALB는 우리 태스크의 web(Nginx) 컨테이너 80번으로 요청을 보내고, Nginx가 그 안에서 /api를 api 컨테이너(localhost:3000)로 넘깁니다. 그래서 바깥에서 여는 포트는 80 하나면 됩니다.
  • 인터넷에서 직접이 아니라, 오직 ALB를 거친 요청만 받습니다.

• RDS 보안 그룹 (데이터베이스 앞 경비원) — vote-db-sg

  • 허용: ECS 보안 그룹에서 오는 요청만 → 포트 5432(PostgreSQL)
  • 그리고 나중에 13장에서 로컬 접속(SSM 터널)을 위해 별도 통로를 잠깐 엽니다.
  • DB는 오직 우리 서버(ECS)만 접근할 수 있게, 가장 엄격하게 잠급니다.

이 설계를 한 문장으로: 사용자 → (80) → ALB → (80) → ECS(web) → (5432) → RDS. 각 단계는 바로 앞 단계에서 온 요청만 받습니다. 한 겹씩 안으로 들어갈수록 더 엄격해지는 구조입니다. 11.1에서 본 "다단계 보안"이 바로 이것입니다.

11.7 네트워크 구조 한눈에 보기

지금까지 만든 것을 한 장의 그림으로 정리합니다. 앞으로 12·14장에서 이 그림의 빈칸(RDS, ECS, ALB)을 하나씩 채워 나갈 겁니다.

[확인]

이번 장이 제대로 끝났는지 콘솔에서 눈으로 확인합니다.

1. VPC 콘솔 → Your VPCs(내 VPC) 에 vote-vpc가 보이고 CIDR이 10.0.0.0/16이다.
2. vote-vpc를 클릭 → 위쪽 리소스 맵(Resource map) 탭에서, VPC 하나 아래에 퍼블릭 서브넷 2개 + 프라이빗 서브넷 2개, 인터넷 게이트웨이 1개, NAT 게이트웨이 1개가 선으로 이어져 있다.
3. 퍼블릭 서브넷들은 인터넷 게이트웨이 쪽으로, 프라이빗 서브넷들은 NAT 게이트웨이 쪽으로 연결돼 있다.

세 가지가 모두 보이면 우리 서비스가 살 네트워크 집이 완성된 것입니다.

막히면

이 장에서 자주 나는 문제와 대처법입니다.

• VPC 생성 화면이 원본과 달라 보인다. AWS 콘솔 UI는 수시로 조금씩 바뀝니다. 버튼 위치나 문구가 이 책과 달라도, VPC 생성 → VPC 등(VPC and more) 선택 → 이름 vote, CIDR 10.0.0.0/16, AZ 2, 퍼블릭 2, 프라이빗 2, NAT 1개 AZ 라는 핵심 값만 같으면 됩니다. 화면 구성이 달라도 이 값들을 찾아 넣으세요.

• "VPC 등(VPC and more)"이 안 보이고 서브넷 설정 칸이 없다. 맨 위 생성할 리소스(Resources to create) 에서 실수로 VPC만 (VPC only) 이 선택된 경우입니다. VPC 등(VPC and more) 으로 바꾸면 서브넷·NAT 설정 칸이 나타납니다.

• 미리보기에 서브넷이 2개씩(총 4개)이 아니라 다르게 보인다. 가용영역 수, 퍼블릭 서브넷 수, 프라이빗 서브넷 수가 각각 2로 돼 있는지 다시 확인하세요. 셋 다 2여야 퍼블릭 2 + 프라이빗 2 = 총 4개 서브넷이 두 AZ에 나뉘어 만들어집니다.

• 생성 도중 일부 항목에 빨간 오류가 뜬다. 대개 리전이 서울이 아니거나, NAT용 탄력적 IP(Elastic IP) 한도에 걸린 경우입니다. 오른쪽 위 리전이 서울(ap-northeast-2) 인지 먼저 확인하고, 한도 문제라면 잠시 후 다시 시도하거나 계정의 EIP 한도를 확인합니다.

• 실수로 VPC를 두 번 만들었다. 같은 설정으로 VPC가 두 개 생겨도 당장 문제는 없지만, NAT 게이트웨이가 두 배로 과금됩니다. VPC 콘솔 → Your VPCs에서 잘못 만든 쪽을 선택해 삭제(Delete VPC) 하세요. (삭제 시 그 VPC에 딸린 서브넷·NAT도 함께 지워집니다.)

[체크리스트]

아래가 모두 됐는지 확인하세요. 하나라도 안 됐다면 해당 절로 돌아갑니다.

• □ VPC가 왜 필요한지(격리)를 아파트 단지 비유로 설명할 수 있다
• □ 서브넷 / AZ / CIDR / 퍼블릭·프라이빗의 뜻을 안다
• □ 리전이 서울(ap-northeast-2)로 맞춰져 있다
• □ 마법사(VPC and more)로 이름 vote, CIDR 10.0.0.0/16, 2개 AZ, 퍼블릭 2·프라이빗 2, NAT 1개 AZ로 vote-vpc를 만들었다
• □ 리소스 맵에서 서브넷 4개 + IGW 1개 + NAT 1개가 연결된 걸 확인했다
• □ IGW / NAT / 라우팅 테이블이 각각 무슨 문·이정표인지 설명할 수 있다
• □ 보안 그룹 3개(ALB·ECS·RDS)의 통신 규칙 설계를 이해했다

우리 서비스가 살 네트워크 집이 마련됐습니다.