AWS 핵심 인프라 개념 정리

hahhhm·2026년 2월 8일

AWS를 사용하고 있지만, VPC나 서브넷 같은 네트워크 개념이 정확히 와닿지 않을 때가 있었다. 마침 『스타트업 서비스 설계는 처음인데요』를 읽게 되어, 이 기회에 AWS 핵심 인프라 개념을 쿠팡의 가상 아키텍처 예시와 함께 정리해보았다.

클라우드 vs 온프레미스

온프레미스(On-Premise)는 물리적 서버를 직접 구매하고, 설치하고, 유지보수하는 방식이다. 반면 클라우드는 AWS, GCP, Azure 같은 업체가 인프라를 관리하고, 사용자는 필요한 자원을 API 요청으로 사용한다.

예를 들어 이미지를 저장한다고 하면:

온프레미스: 서버 구매 → 하드디스크 장착 → 파일 시스템 설정 → 스토리지 서버 구축 → 백업 설정 → 저장
클라우드(S3): PUT 요청 한 번이면 끝

핵심은 인프라 관리를 클라우드 업체에 위임하고, 개발에만 집중할 수 있다는 점이다.

왜 VPC와 네트워크를 이해해야 하는가

서버를 띄우고 코드를 배포하는 것 자체는 어렵지 않다. 클라우드 환경에서 네트워크를 이해해야 하는 진짜 이유는 실제 서비스는 혼자 완결되지 않기 때문이다. 외부 시스템과 연동할 때 VPN, 전용선, IP 화이트리스트 같은 네트워크 조건을 마주치게 되며, 이를 제대로 설정하려면 VPC 구조를 정확히 이해해야 한다.

실무에서 마주치는 상황들

1. 특정 IP에서만 통신 허용 (IP 화이트리스트)

PG사(토스페이먼츠, KG이니시스 등)와 결제 연동을 한다고 가정하자. PG사 입장에서는 아무 서버에서나 결제 API를 호출하면 안 되므로, 다음과 같이 요구한다:

"결제 API를 호출할 서버의 고정 IP를 등록해주세요.
등록된 IP에서 오는 요청만 허용합니다."

이때 우리 백엔드가 프라이빗 서브넷에 있다면, 외부로 나갈 때 NAT 게이트웨이를 거친다. PG사에 등록할 IP는 NAT 게이트웨이에 붙은 Elastic IP이다.

백엔드 EC2 (10.0.2.20)
    → NAT 게이트웨이 (Elastic IP: 3.35.100.50)
    → 인터넷
    → 토스페이먼츠 API

토스 관리자 콘솔 → 허용 IP: [ 3.35.100.50 ]

반대로 PG사가 결제 결과를 우리에게 알려주는 웹훅(Webhook)도 있다. 이때는 우리 쪽 보안 그룹에 PG사의 서버 IP만 인바운드 허용해야 한다. 즉 양방향 모두 IP 기반 접근 제어가 필요하다.

2. VPN / 전용선 연결

쿠팡이 CJ대한통운 물류 시스템과 연동한다고 하자. CJ 입장에서 내부 물류 시스템을 인터넷에 공개할 수는 없으므로 다음과 같이 요구한다:

"우리 시스템은 인터넷에 열려 있지 않습니다.
VPN 또는 전용선으로 연결해주세요."

VPN (Virtual Private Network): 인터넷을 경유하지만 암호화된 터널로 통신. 비용이 저렴하다.
전용선 (AWS Direct Connect): 물리적 전용 회선을 설치하여 연결. 비용이 높지만 속도와 안정성이 뛰어나다.

이 연결을 설정하려면 VPC 피어링, 라우팅 테이블 구성 등 네트워크 구조에 대한 이해가 필수적이다.

3. 사내 시스템 접근 제어

개발자가 재택근무 중 회사 DB에 접근하려면, DB가 위치한 프라이빗 서브넷에 인터넷으로 직접 들어갈 수 없다. 회사 VPN에 접속해야만 프라이빗 네트워크에 진입할 수 있다.

개인 프로젝트 vs 실제 서비스

개인 프로젝트:
  유저 → 내 서버 → 내 DB (전부 내 것, 네트워크 고민 거의 없음)

실제 서비스:
  유저 → 내 서버 → PG사 결제 서버    (특정 IP만 허용)
                 → 물류 시스템        (VPN/전용선 필요)
                 → 카카오 알림톡 API  (아웃바운드 IP 등록 필요)
                 → 사내 레거시 시스템  (프라이빗 네트워크)

외부 시스템마다 "이 IP에서만 요청해라", "이 네트워크로만 연결해라" 같은 조건을 걸기 때문에, 서버를 띄우는 것보다 다른 시스템과 안전하게 연결하는 것이 실무의 핵심이다. 이것이 VPC, 서브넷, 라우팅, NAT, Elastic IP를 정확히 이해해야 하는 이유이다.

데이터 단위 — bit, Byte, KB, MB, GB

컴퓨터는 모든 데이터를 0과 1로 저장한다. 이 0 또는 1 하나가 1bit이며, 영문 글자 1개를 저장하는 데 필요한 크기가 1Byte(= 8bit)이다.

1 KB = 2^10 = 1,024 Byte
1 MB = 2^20 = 1,048,576 Byte
1 GB = 2^30 = 1,073,741,824 Byte
1 TB = 2^40

컴퓨터가 2진수로 동작하므로, 10진수의 1,000이 아닌 2의 거듭제곱 중 1,000에 가장 가까운 2^10 = 1,024를 기준 단위로 사용한다. 이후 단위는 10승씩 올라간다.

개발자 관점에서의 체감 크기:

단위	크기	예시
KB	영문 약 1,024자	JSON API 응답, 코드 파일 하나
MB	약 100만 Byte	JPEG 이미지, Next.js 빌드 번들
GB	약 10억 Byte	영화 한 편, DB 전체 용량
TB	약 1조 Byte	노트북 SSD 용량, 대규모 서비스 로그

프론트엔드에서 주의할 점: 이미지 5MB를 최적화 없이 올리면 로딩이 느려지고, JS 번들이 1MB를 넘으면 성능 문제를 의심해야 한다. API 응답이 10MB를 넘으면 설계를 재검토할 필요가 있다.

참고로, 하드디스크 제조사는 1KB = 1,000 Byte(10진수 기준)로 계산해서 판매한다. 그래서 "1TB SSD"를 구매하면 OS에서는 약 931GB로 표시되는데, 제조사는 1,000 기준, OS는 1,024 기준으로 계산하기 때문이다.

IP 주소 — 네트워크상의 기기 식별자

인터넷에 연결된 모든 기기는 IP 주소라는 고유한 식별자를 갖는다. IPv4 주소는 8bit씩 4자리로 구성된 총 32bit 체계이다.
IP 주소 한 칸 = 0~255 (00000000 ~ 11111111 = 2^8)

XXX . XXX . XXX . XXX
8bit  8bit  8bit  8bit = 총 32bit

각 자리: 0 ~ 255 (2^8 = 256개)
총 주소 수: 2^32 = 4,294,967,296개 (약 43억)

전 세계 인구(약 80억)보다 적기 때문에, 모든 기기에 고유한 IP를 부여할 수 없다. 이를 해결하기 위해 IP 주소를 퍼블릭과 프라이빗으로 나누어 사용한다.

퍼블릭 IP vs 프라이빗 IP

퍼블릭 IP = 건물 주소, 프라이빗 IP = 건물 안의 방 번호

퍼블릭 IP (221.163.50.1) ← 공유기 (대문)
├── 192.168.0.2  (폰)
├── 192.168.0.3  (노트북)
├── 192.168.0.4  (TV)
└── 192.168.0.5  (패드)

외부에서는 건물 주소(퍼블릭 IP)만 보이고, 건물 안에서 어느 방(프라이빗 IP)으로 갈지는 공유기(NAT)가 알아서 연결한다.

퍼블릭 IP (ALB / NAT 게이트웨이) ← 대문
├── 10.0.2.20  (프론트 EC2)
├── 10.0.2.21  (백엔드 EC2)
└── 10.0.2.40  (RDS)

구분	퍼블릭 IP	프라이빗 IP
범위	인터넷 전체에서 유일	내부 네트워크에서만 유효
접근	외부에서 접근 가능	외부에서 접근 불가
중복	불가	서로 다른 네트워크에서 중복 가능
유출 시 위험	공격 대상 가능	거의 무관

서로 다른 네트워크에서 프라이빗 IP가 겹쳐도 문제없다. 각자 독립된 내부 네트워크이기 때문이다.

쿠팡 VPC 내부:  10.0.0.1, 10.0.0.2 ...
네이버 VPC 내부: 10.0.0.1, 10.0.0.2 ...  ← 겹쳐도 문제없음

프라이빗 IP 대역 (RFC 1918)

전 세계 공통 표준으로 지정된 사설 IP 범위는 다음 세 가지이다:

10.0.0.0/8       → 앞 8bit 고정,  나머지 24bit 사용 → 약 1,677만 개 (대규모)
172.16.0.0/12    → 앞 12bit 고정, 나머지 20bit 사용 → 약 104만 개  (중규모)
192.168.0.0/16   → 앞 16bit 고정, 나머지 16bit 사용 → 약 65,000개 (소규모)

/숫자(prefix)는 IP 주소 32bit 중 앞에서 몇 bit가 네트워크(고정) 부분인지를 나타낸다. 숫자가 작을수록 기기에 할당 가능한 주소가 많아 넓은 네트워크, 클수록 좁은 네트워크이다.

10       .  0  .  0  .  0     (/8)
────────   ──────────────────
앞 8bit    나머지 24bit → 기기용 (주소 많음)

192 . 168 .  0  .  0          (/16)
────────────   ──────────────
앞 16bit       나머지 16bit → 기기용 (주소 적음)

일반적으로 AWS VPC에서는 10.x.x.x 대역을, 가정용 공유기에서는 192.168.x.x 대역을 사용한다.

유동 IP vs 고정 IP

IP 주소는 범위(공인/사설) 외에 변동성 기준으로도 분류된다.

유동 IP (Dynamic IP): 서버를 재부팅하면 IP가 변경된다. EC2의 퍼블릭 IP 기본값이 이에 해당한다.
고정 IP (Static IP): 재부팅해도 IP가 유지된다. AWS에서는 Elastic IP(EIP)라는 서비스로 제공한다.

이 두 기준은 독립적이므로 다음과 같은 조합이 가능하다:

	유동	고정
공인(퍼블릭)	EC2 기본 퍼블릭 IP (재부팅 시 변경)	Elastic IP (항상 동일)
사설(프라이빗)	거의 없음	EC2 프라이빗 IP (기본적으로 고정)

고정 IP가 필요한 대표적인 경우는 앞서 설명한 IP 화이트리스트 상황이다. PG사에 3.35.100.50을 등록했는데 NAT 게이트웨이의 IP가 바뀌면 결제가 중단된다. 이를 방지하기 위해 NAT 게이트웨이에 Elastic IP를 부여하여 아웃바운드 IP를 고정시킨다.

Elastic IP 없이:
  오늘 → 3.35.100.50 으로 PG사에 등록
  내일 → IP가 52.78.30.22 로 변경 → PG사 차단 → 결제 장애

Elastic IP 사용:
  NAT 게이트웨이에 3.35.100.50 고정 → 재부팅/변경 없이 항상 동일

참고로, ALB를 사용하는 경우 ALB 자체가 고정 DNS를 제공하므로 EC2에 직접 Elastic IP를 붙일 필요가 거의 없다. 고정 IP가 필요한 주요 대상은 NAT 게이트웨이이다.

리전(Region)과 가용 영역(AZ) — AWS의 물리적 인프라 구조

AWS는 전 세계에 데이터센터를 운영하고 있으며, 이를 리전(Region)과 가용 영역(Availability Zone, AZ)이라는 계층으로 구분한다.

리전: 서울, 도쿄, 버지니아 같은 지리적 지역 단위. 현재 약 30개 이상의 리전이 존재한다.
가용 영역(AZ): 한 리전 안에 있는 물리적으로 분리된 데이터센터. 각 AZ는 독립된 전원, 냉각, 네트워크를 갖추고 있다.

리전: ap-northeast-2 (서울)
├── AZ-a: ap-northeast-2a (서울 데이터센터 A)
├── AZ-b: ap-northeast-2b (서울 데이터센터 B)
└── AZ-c: ap-northeast-2c (서울 데이터센터 C)

AZ를 분산하는 이유

하나의 AZ에만 서버를 배치하면, 해당 데이터센터에 화재, 정전, 네트워크 장애가 발생했을 때 서비스 전체가 중단된다. 이를 방지하기 위해 동일한 리소스를 여러 AZ에 분산 배치한다.

AZ-a만 사용:
  AZ-a 장애 → 서비스 전체 중단

AZ-a + AZ-b 분산:
  AZ-a 장애 → AZ-b가 살아있으므로 서비스 유지

RDS의 Multi-AZ 옵션이 대표적인 예이다. DB를 AZ-a와 AZ-b에 동시에 배치하고, AZ-a에 장애가 발생하면 자동으로 AZ-b로 전환(failover)한다.

VPC, 서브넷과 AZ의 관계

VPC와 AZ는 상위/하위 관계가 아니라 서로 다른 축이다. VPC는 논리적 네트워크 구분이고, AZ는 물리적 위치 구분이다. VPC는 리전 단위로 생성하며, 그 안의 서브넷을 특정 AZ에 배치한다.

서울 리전 (ap-northeast-2)
└── VPC: 쿠팡 쇼핑몰 (리전 단위)
    ├── 퍼블릭 서브넷 A  → AZ-a에 배치
    ├── 퍼블릭 서브넷 B  → AZ-b에 배치
    ├── 프라이빗 서브넷 A → AZ-a에 배치
    └── 프라이빗 서브넷 B → AZ-b에 배치

같은 역할의 서브넷을 여러 AZ에 두는 것이 고가용성(High Availability) 설계의 기본이다.

전체 계층 구조

리전 (서울)                  ← 지리적 지역
├── AZ-a, AZ-b, AZ-c       ← 물리적 데이터센터
│   └── VPC                 ← 논리적 네트워크 (리전 단위로 생성)
│       └── 서브넷           ← 특정 AZ에 배치
│           └── EC2, RDS    ← 실제 리소스
└── CloudFront              ← 엣지 로케이션 (리전/AZ와 별개, 전 세계 450+)

VPC (Virtual Private Cloud) — 격리된 가상 네트워크

AWS 클라우드 내에서 논리적으로 격리된 네트워크 공간이다. VPC를 생성하면 해당 공간 안에서 IP 주소 범위, 서브넷, 라우팅 테이블, 게이트웨이 등 네트워크 구조를 직접 설계할 수 있다.

VPC의 핵심 목적은 단순히 다른 사용자와의 분리(이는 AWS가 기본으로 제공)가 아니라, 내 자원들 사이의 네트워크 구조를 설계하는 것이다.

VPC를 나누는 이유

쿠팡에는 쇼핑몰, 쿠팡이츠, 쿠팡플레이 등 여러 서비스가 존재한다. 이를 하나의 네트워크에 두면, 하나의 서비스가 침해당했을 때 나머지 서비스까지 위험해진다.

VPC 1: 쿠팡 쇼핑몰
VPC 2: 쿠팡이츠
VPC 3: 쿠팡플레이

VPC를 분리하면 쿠팡이츠가 침해되더라도 쇼핑몰의 결제 DB는 안전하다. VPC끼리는 완전히 격리되어 있기 때문이다.

VPC 분리 기준:

기준	예시
서비스별	쇼핑몰 / 배달 / 스트리밍
환경별	개발(dev) / 스테이징(staging) / 프로덕션(prod)
팀별	개발팀 / 데이터팀 / AI팀

서브넷 (Subnet) — VPC 내부의 네트워크 구역

서브넷은 VPC의 IP 주소 범위를 더 작은 단위로 분할한 것이다. 서브넷 안에 EC2, RDS 같은 실제 리소스를 배치한다.

VPC: 10.0.0.0/16 (10.0.0.0 ~ 10.0.255.255)
├── 퍼블릭 서브넷: 10.0.1.0/24 (10.0.1.0 ~ 10.0.1.255)
└── 프라이빗 서브넷: 10.0.2.0/24 (10.0.2.0 ~ 10.0.2.255)

서브넷 안에 리소스를 배치하면, 해당 서브넷의 IP 범위에서 프라이빗 IP가 자동 부여된다.

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

구분	퍼블릭 서브넷	프라이빗 서브넷
외부 접근	가능 (인터넷 게이트웨이 연결)	불가
배치 리소스	ALB, NAT 게이트웨이	EC2(프론트/백엔드), RDS
역할	외부와의 접점	내부 로직 및 데이터 처리

쿠팡 쇼핑몰 VPC의 서브넷 구성 예시:

VPC: 쿠팡 쇼핑몰
├── 퍼블릭 서브넷 (외부 접근 가능)
│   ├── ALB (로드밸런서)
│   └── NAT 게이트웨이
└── 프라이빗 서브넷 (외부 접근 불가)
    ├── 프론트 EC2 (Next.js)
    ├── 백엔드 EC2 (NestJS)
    └── RDS (MySQL)

유저는 ALB까지만 접근 가능하고, DB에는 절대 직접 접근할 수 없다. VPC가 서비스 간 격리라면, 서브넷은 한 서비스 내에서 역할별 격리이다.

인터넷 게이트웨이 (IGW) — VPC의 정문

VPC와 외부 인터넷을 연결하는 양방향 통로이다. 인터넷 게이트웨이가 없으면 VPC 내부의 어떤 리소스도 외부와 통신할 수 없다. 퍼블릭 서브넷이 외부에서 접근 가능한 이유는 라우팅 테이블에서 인터넷 게이트웨이로의 경로가 설정되어 있기 때문이다.

NAT 게이트웨이 — 아웃바운드 전용 통로

프라이빗 서브넷의 리소스가 외부로 나가는 것만 허용하는 단방향 통로이다. 퍼블릭 서브넷에 위치하며, 프라이빗 서브넷의 아웃바운드 트래픽을 인터넷 게이트웨이로 중계한다.

사용 예시: 프라이빗 서브넷의 백엔드 서버가 외부 API(카카오 로그인, npm 패키지 다운로드 등)를 호출해야 할 때.

프라이빗 서브넷 (백엔드) → NAT (퍼블릭 서브넷) → 인터넷 게이트웨이 → 외부

외부에서 프라이빗 서브넷으로의 인바운드 접근은 불가능하므로 보안이 유지된다.

라우팅 테이블 — 트래픽의 경로 규칙

네트워크 요청이 발생하면 라우팅 테이블을 참조하여 트래픽의 목적지를 결정한다. 각 서브넷마다 라우팅 테이블이 연결되어 있다.

퍼블릭 서브넷 라우팅 테이블:
  10.0.0.0/16   → local (VPC 내부 통신)
  0.0.0.0/0     → 인터넷 게이트웨이

프라이빗 서브넷 라우팅 테이블:
  10.0.0.0/16   → local (VPC 내부 통신)
  0.0.0.0/0     → NAT 게이트웨이

라우팅 동작 예시:

백엔드 EC2(10.0.2.20)가 RDS(10.0.2.40)에 쿼리 요청 → 목적지 10.0.2.40은 10.0.0.0/16 범위에 해당 → 로컬에서 처리 (VPC 내부 통신)
백엔드 EC2(10.0.2.20)가 카카오 로그인 API 호출 → 목적지가 10.0.0.0/16 범위에 해당하지 않음 → 0.0.0.0/0 규칙 적용 → NAT 게이트웨이를 통해 외부로 나감

0.0.0.0/0은 "그 외 모든 주소"를 의미하는 기본 경로(default route)이다.

EC2 (Elastic Compute Cloud) — 가상 서버

AWS에서 제공하는 가상 컴퓨터이다. 빈 컴퓨터이므로 어떤 소프트웨어를 설치하느냐에 따라 역할이 달라진다.

설치 항목	역할
Next.js	프론트엔드 웹서버
NestJS	백엔드 API 서버
MySQL	DB 서버
Jenkins	CI/CD 서버

"Elastic"이라는 이름답게 필요에 따라 사양을 올리거나 내릴 수 있고, 사용하지 않을 때는 중지하여 비용을 절감할 수 있다.

트래픽이 증가할 경우, AMI(Amazon Machine Image)를 활용하여 동일한 구성의 EC2를 빠르게 복제할 수 있다. AMI는 EC2의 스냅샷(복사본)으로, Auto Scaling과 함께 사용하여 자동 확장 환경을 구성한다.

ELB / ALB — 로드밸런서

ELB(Elastic Load Balancer)는 AWS의 로드밸런서 서비스이다. 여러 대의 서버에 트래픽을 분배하고, 장애가 발생한 서버를 자동으로 우회한다.

ELB의 종류

종류	용도
ALB (Application Load Balancer)	HTTP/HTTPS 기반 웹 서비스. URL 경로 기반 라우팅 지원
NLB (Network Load Balancer)	TCP/UDP 기반. 초고속·대용량 트래픽 처리 (게임, IoT 등)
CLB (Classic Load Balancer)	레거시. 현재는 거의 사용하지 않음

ALB의 경로 기반 라우팅

ALB는 URL 경로를 기준으로 서로 다른 서버(타겟그룹)에 트래픽을 분배한다.

유저 → ALB (퍼블릭 서브넷)
        ├── /             → 타겟그룹 A (프론트 EC2)
        ├── /api/payment  → 타겟그룹 B (결제 EC2)
        └── /api/order    → 타겟그룹 C (주문 EC2)

타겟그룹(Target Group)은 ALB가 트래픽을 전달할 서버들의 묶음이다. 각 타겟그룹 내에 서버가 여러 대 있으면 ALB가 골고루 분배한다.

ALB가 필요한 이유

트래픽 분배: 같은 역할의 서버가 여러 대일 때 골고루 나눠준다.
장애 자동 우회: 헬스 체크를 통해 죽은 서버를 감지하고, 살아있는 서버로만 트래픽을 전달한다.
보안 강화: ALB만 퍼블릭 서브넷에 두고 실제 서버는 프라이빗에 배치하면, 외부 노출 지점이 최소화된다.

Auto Scaling — 자동 서버 확장/축소

트래픽에 따라 EC2 인스턴스 수를 자동으로 조절하는 서비스이다. ALB와 세트로 동작한다.

평소 (유저 1만 명)     → EC2 2대 유지 → ALB가 2대에 분배
트래픽 급증 (100만 명)  → EC2 10대로 자동 확장 → ALB가 10대에 분배
트래픽 감소 (1만 명)    → EC2 2대로 자동 축소 → 비용 절감

Auto Scaling은 AMI(EC2 스냅샷)를 템플릿으로 사용하여 동일한 서버를 자동 생성한다.

1. EC2 하나에 NestJS 설치 및 설정 완료
2. AMI 생성 (스냅샷)
3. Auto Scaling이 트래픽 증가 감지 → AMI 기반으로 EC2 자동 생성
4. 트래픽 감소 시 자동 종료

이것이 클라우드의 핵심 장점이다. 온프레미스에서는 물리 서버를 직접 구매하고 설치해야 하지만, 클라우드에서는 AMI로 수 초 만에 동일한 서버를 복제할 수 있다.

S3 (Simple Storage Service) — 객체 스토리지

파일을 저장하고 조회하는 스토리지 서비스이다. EC2와 달리 프로그램을 실행하는 컴퓨팅 기능은 없다. 이미지, 영상, CSS, JS 번들 등 정적 파일 저장에 사용한다.

RDS (Relational Database Service) — 관리형 데이터베이스

AWS가 관리하는 관계형 데이터베이스 서비스이다. EC2에 직접 MySQL을 설치해도 되지만, RDS를 사용하면 백업, 업데이트, 장애 복구, 스케일링을 AWS가 자동으로 처리한다.

구분	EC2에 직접 설치	RDS
설치/설정	직접 수행	콘솔에서 클릭
백업	직접 설정	자동 백업
업데이트	직접 수행	자동 패치
장애 복구	직접 구축	자동 복구 (Multi-AZ)

프리티어: db.t3.micro 사양, 스토리지 20GB까지 12개월 무료.

CloudFront — CDN (콘텐츠 전송 네트워크)

전 세계 450개 이상의 엣지 로케이션(Edge Location)에 정적 파일을 캐시하여 유저에게 빠르게 전달하는 서비스이다. AWS 리전(약 30개)과는 별개의 인프라이다.

동작 원리

1. 미국 유저가 coupang.com/image.jpg 요청
2. 가까운 엣지 로케이션 (뉴욕)에 도달
3-a. 캐시 있음 → 즉시 응답 (빠름)
3-b. 캐시 없음 → 한국 원본 서버에서 가져옴 → 뉴욕에 캐시 저장 → 응답
3. 이후 같은 리소스 요청은 뉴욕 캐시에서 바로 응답

캐시 대상

캐시 O (정적 파일)	캐시 X (동적 데이터)
이미지, 영상	장바구니 목록
CSS, JS 번들	로그인 유저 정보
폰트 파일	실시간 재고 수량

동적 데이터를 캐시하면 유저 A의 장바구니가 유저 B에게 보일 수 있으므로, API 응답 같은 동적 데이터는 원본 서버까지 도달시킨다.

참고로 Vercel은 CloudFront와 동일한 CDN 기능을 내장하고 있어 별도 설정 없이 정적 파일 캐싱이 자동 적용된다.

Route 53 — DNS 서비스

도메인(coupang.com)을 서버의 IP 주소로 변환해주는 DNS(Domain Name System) 서비스이다.

설정 과정:

도메인 등록 업체(가비아 등)에서 도메인 구매
Route 53에서 호스팅 영역 생성 → 네임서버(NS) 주소 발급
도메인 등록 업체에 Route 53 네임서버 주소 등록
Route 53에서 도메인과 EC2/ALB의 IP 주소를 연결하는 레코드 설정

이 설정이 완료되면 유저가 coupang.com을 입력했을 때 Route 53이 해당 서버의 IP로 변환하여 접속을 연결해준다.

보안 그룹 (Security Group) — 인스턴스 레벨 방화벽

EC2, RDS 등 개별 리소스에 적용되는 가상 방화벽이다. 인바운드(외부 → 내부)와 아웃바운드(내부 → 외부) 트래픽 규칙을 설정할 수 있다.

웹서버 보안 그룹:
  인바운드: 80번(HTTP), 443번(HTTPS) 포트만 허용

DB 보안 그룹:
  인바운드: 3306번(MySQL) 포트, 백엔드 보안 그룹에서 오는 요청만 허용

네트워크 ACL (Access Control List) — 서브넷 레벨 방화벽

보안 그룹이 개별 리소스(EC2) 단위라면, ACL은 서브넷 전체에 적용되는 방화벽이다.

구분	보안 그룹	네트워크 ACL
적용 단위	EC2 개별 인스턴스	서브넷 전체
상태	Stateful (응답 자동 허용)	Stateless (인바운드/아웃바운드 각각 설정)
기본 설정	모든 인바운드 차단	모든 트래픽 허용

실무에서는 보안 그룹만으로 충분한 경우가 많으며, ACL은 추가적인 보안 계층이 필요한 경우에 사용한다.

IAM (Identity and Access Management) — 권한 관리

AWS 내에서 누가 어떤 리소스에 접근할 수 있는지 제어하는 서비스이다.

쿠팡 AWS 계정
├── 프론트팀 (그룹) → EC2, S3만 접근 가능
├── 백엔드팀 (그룹) → EC2, RDS만 접근 가능
├── 인프라팀 (그룹) → 모든 서비스 접근 가능
└── 인턴 (사용자)   → S3 읽기만 가능 (삭제 불가)

IAM 주요 개념

개념	설명
사용자 (User)	개별 인원. 프론트 개발자 김철수 등
그룹 (Group)	사용자 묶음. 프론트팀, 백엔드팀 단위로 권한 부여
역할 (Role)	서비스에 부여하는 권한. "이 EC2는 S3 접근 가능" 등
정책 (Policy)	구체적인 권한 규칙을 JSON으로 정의한 문서

IAM이 없으면 모든 팀원이 전체 리소스에 접근 가능하여, 인턴이 실수로 프로덕션 DB를 삭제하는 사고가 발생할 수 있다.

서비스 규모별 아키텍처 변화

1단계 — 개인 프로젝트 (모놀리식):
  EC2 1대에 프론트 + 백엔드 + DB 전부

2단계 — 트래픽 증가 (수평 확장):
  같은 EC2 여러 대 + ALB로 분배 + Auto Scaling

3단계 — 대규모 서비스 (마이크로서비스):
  기능별로 서버 분리 (결제, 주문, 알림 서버 각각 독립)
  서비스별 독립적인 스케일링 가능

전체 아키텍처 흐름

유저가 coupang.com 입력
    ↓
Route 53 (DNS: 도메인 → IP 변환)
    ↓
인터넷 게이트웨이 (VPC 정문)
    ↓
퍼블릭 서브넷
    ├── ALB (URL 경로별 트래픽 분배)
    └── NAT 게이트웨이 (프라이빗 → 외부 아웃바운드 전용)
    ↓
프라이빗 서브넷
    ├── 프론트 EC2 (Next.js) ← / 요청
    ├── 백엔드 EC2 (NestJS) ← /api 요청
    └── RDS (MySQL)

정적 파일 (이미지, JS, CSS)
    → S3에 저장
    → CloudFront 엣지 로케이션에서 글로벌 캐시 전달

IaC (Infrastructure as Code) — 인프라를 코드로 관리

지금까지 설명한 VPC, 서브넷, EC2, ALB, 보안 그룹 등을 AWS 콘솔에서 마우스로 클릭하여 생성할 수도 있지만, IaC는 이 인프라 구성을 코드 파일로 작성하고 실행하여 자동으로 생성·관리하는 방식이다.

예를 들어 Terraform으로 VPC와 서브넷을 생성하는 코드:

resource "aws_vpc" "coupang_vpc" {
  cidr_block = "10.0.0.0/16"
  tags = { Name = "coupang-vpc" }
}

resource "aws_subnet" "private" {
  vpc_id     = aws_vpc.coupang_vpc.id
  cidr_block = "10.0.2.0/24"
  tags = { Name = "private-subnet" }
}

이 코드를 실행하면 VPC와 서브넷이 자동으로 생성된다.

콘솔 클릭 방식의 한계

재현 불가: 동일한 인프라를 다시 만들려면 모든 설정을 기억해서 하나하나 다시 클릭해야 한다.
변경 추적 불가: 누군가 보안 그룹 설정을 변경해도 기록이 남지 않는다.
환경 불일치: dev, staging, prod 환경이 미묘하게 달라져 "개발 환경에서는 되는데 프로덕션에서는 안 된다"는 문제가 발생한다.

IaC의 장점

코드 실행 한 번으로 동일한 인프라를 반복 생성할 수 있다 (dev/staging/prod 환경 통일).
Git으로 변경 이력을 추적할 수 있다 ("누가 언제 보안 그룹을 변경했는지" 확인 가능).
코드 리뷰를 통해 인프라 변경도 사전 검증이 가능하다.

대표 도구

도구	특징
Terraform	가장 널리 사용. AWS/GCP/Azure 등 멀티 클라우드 지원
AWS CloudFormation	AWS 전용. AWS 콘솔과의 통합이 강점
Pulumi	JavaScript, TypeScript, Python 등 일반 프로그래밍 언어로 작성 가능

참고

강대명, 『스타트업 서비스 설계는 처음인데요』
가장 쉽게 VPC 개념잡기 — Harry The Great (Medium)
Amazon VPC란 무엇인가?

hahhhm

이전 포스트

개발자를 위한 Googling

다음 포스트