8 장

EC2와 VPC 기초

클라우드의 가장 오래된 컴퓨팅과 네트워크, EC2와 VPC. 인스턴스 타입과 AMI와 EBS, 그리고 VPC / 서브넷 / 라우팅 테이블 / IGW / NAT가 어떻게 한 그림으로 엮이는지 — 운영 인프라의 첫 골격을 잡습니다.

1부에서 계정과 IAM, 비용, CLI, 보안, CloudWatch까지 준비 단계를 마쳤다면, 본 챕터부터는 실제로 무언가를 띄우는 단계로 들어갑니다. 2부는 AWS 위에서 가장 자주 만나는 컴포넌트들 — EC2, VPC, S3, RDS, Route 53, ALB, CloudFront — 을 운영 시각으로 한 줄에 꿰는 것이 목표입니다.

그 첫 단계가 EC2와 VPC입니다. 클라우드의 가장 오래된, 가장 기본이 되는 도구입니다. EC2는 가상 컴퓨터 한 대이고, VPC는 그 컴퓨터들이 사는 네트워크입니다. 둘은 항상 같이 다닙니다. 본 챕터에서 잡는 골격은 9장 EC2 운영의 보안 규칙과 접속, 그리고 11장 RDS의 서브넷 배치로 그대로 이어집니다.

본 챕터에서는 EC2 인스턴스 한 대를 띄울 때 뒤에서 함께 만들어지는 모든 역할 — 인스턴스 타입, AMI, EBS, VPC, 서브넷, 라우팅 테이블, IGW, NAT Gateway — 를 차례로 정리합니다.

큰 그림 #

EC2 한 대를 콘솔에서 띄우면 사실 뒤에서 다음이 모두 만들어집니다.

EC2 인스턴스 한 대의 풀 스택

              ┌──────────────────────────────────┐
              │              VPC                 │
              │  10.0.0.0/16                     │
              │                                  │
              │   ┌──────────────────────────┐   │
              │   │   Subnet (Public)        │   │
              │   │   10.0.1.0/24            │   │
              │   │                          │   │
              │   │     ┌────────────┐       │   │
              │   │     │ EC2 인스턴스 │       │   │
              │   │     │ AMI = OS    │       │   │
              │   │     │ EBS = 디스크  │       │   │
              │   │     │ ENI = 네트워크│       │   │
              │   │     └────────────┘       │   │
              │   └──────────┬───────────────┘   │
              │              │                   │
              │              ▼                   │
              │      Route Table                 │
              │              │                   │
              │              ▼                   │
              │      Internet Gateway (IGW)      │
              └──────────────┼───────────────────┘
                             ▼
                          인터넷

이 그림에 등장하는 역할을 차례로 정리하겠습니다.

EC2 — 가상 컴퓨터 한 대 #

**EC2 (Elastic Compute Cloud)**는 AWS의 가상 머신 서비스입니다. 콘솔에서 **인스턴스 (Instance)**라고 부르는 한 대를 띄우면, 그것이 가상 리눅스 또는 윈도우 컴퓨터 한 대입니다.

인스턴스 타입 #

EC2 인스턴스 타입은 이름이 곧 스펙입니다.

인스턴스 타입의 모양

t3.micro
│  │  └── 사이즈 (nano / micro / small / medium / large / xlarge / 2xlarge / ...)
│  └───── 세대 (1, 2, 3, 4, 5, 6, 7 ...)
└──────── 패밀리

자주 쓰는 패밀리는 다음과 같습니다.

패밀리	별명	역할
`t`	Burstable	평소엔 적게 쓰다가 갑자기 튀는 워크로드. 개발 / 사이드 프로젝트의 기본
`m`	General purpose	CPU / 메모리 균형. 일반 웹 서버
`c`	Compute optimized	CPU 비중 높은 작업 (인코딩, 빌드 서버)
`r`	Memory optimized	메모리 큰 작업 (Redis, 큰 캐시)
`i`, `d`	Storage optimized	로컬 NVMe / HDD가 큰 작업 (DB, 데이터 파이프라인)
`g`, `p`	GPU	머신러닝 / 그래픽

처음에는 거의 다 t3.micro / t3.small / t3.medium으로 시작합니다. t 패밀리는 CPU 크레딧 모델이라 평균 사용률이 낮을 때 비용 효율이 좋습니다. 운영에 들어가면 m으로 옮기는 것이 일반적입니다.

t3 vs t3a vs t4g. t3는 인텔, t3a는 AMD (약 10% 저렴), t4g는 ARM (Graviton, 약 20% 저렴하면서 빠름)입니다. 새 워크로드는 호환성 확인 후 t4g부터 검토합니다.

AMI — OS 이미지 #

**AMI (Amazon Machine Image)**는 인스턴스를 띄울 때 쓰는 OS 이미지입니다. “Ubuntu 22.04” 또는 “Amazon Linux 2023” 같은 OS에 미리 설치된 도구를 더한 스냅샷입니다.

자주 쓰는 AMI 종류는 다음과 같습니다.

Amazon Linux 2023 — AWS가 만들고 유지하는 RHEL 계열. EC2 위에서 가장 매끄럽습니다.
Ubuntu LTS — 가장 익숙한 선택. 22.04 / 24.04입니다.
Debian — Ubuntu보다 가볍습니다.
Windows Server — 라이선스 비용이 포함됩니다.
사용자가 만든 AMI — 운영 중인 인스턴스를 스냅샷 떠서 만듭니다(9장 EC2 운영).

AMI는 리전 단위입니다. 서울 리전의 AMI를 도쿄 리전에서 그대로 쓸 수 없습니다. AMI 복사 명령으로 옮길 수 있습니다.

EBS — 디스크 #

**EBS (Elastic Block Store)**는 EC2에 붙는 블록 스토리지, 즉 가상 SSD입니다. 인스턴스를 종료해도 EBS는 살아남는 별도 리소스입니다. EBS가 없으면 EC2는 빈 깡통입니다.

볼륨 타입은 다음과 같습니다.

타입	약자	역할
General Purpose SSD	`gp3`	기본값. 가성비 좋음
General Purpose SSD (구)	`gp2`	옛 기본값. 새 작업은 gp3
Provisioned IOPS SSD	`io2` / `io2 Block Express`	높은 IOPS가 필요한 DB
Throughput Optimized HDD	`st1`	큰 파일 순차 읽기 (빅데이터)
Cold HDD	`sc1`	자주 안 쓰는 백업

대부분 gp3로 시작합니다. gp2보다 20% 저렴하면서 IOPS와 Throughput을 따로 조절할 수 있습니다.

**인스턴스 스토어 (Instance Store)**라는 또 다른 종류도 있습니다. 인스턴스에 물리적으로 붙은 NVMe로 빠르지만, 인스턴스 종료 시 사라집니다. 캐시나 임시 용도에만 씁니다.

VPC — 가상 네트워크 #

**VPC (Virtual Private Cloud)**는 AWS 안에 만드는 나만의 네트워크입니다. EC2 / RDS / Lambda 같은 리소스가 살아가는 사설 IP 공간입니다.

CIDR 블록 #

VPC를 만들 때 가장 먼저 정하는 것이 CIDR 블록, 즉 IP 주소 범위입니다.

자주 쓰는 VPC CIDR

10.0.0.0/16    # 10.0.0.0 ~ 10.0.255.255 (65,536 개)
172.16.0.0/16  # 172.16.0.0 ~ 172.16.255.255
192.168.0.0/16 # 사설 IP 영역

/16 이면 65,536개의 IP가 있고, /24 면 256 개입니다. 처음에는 /16으로 잡아 두고 그 안을 서브넷으로 잘라 쓰는 것이 일반적입니다.

사설 IP 영역만 씁니다. RFC 1918의 사설 영역 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) 안에서 골라야 합니다. 공인 IP를 VPC CIDR로 쓰면 그 IP의 인터넷 접근이 막힐 수 있습니다.

기본 VPC #

새 계정에는 **기본 VPC (Default VPC)**가 리전마다 미리 만들어져 있습니다. CIDR 172.31.0.0/16, 모든 AZ에 퍼블릭 서브넷이 하나씩, IGW도 자동 연결되어 있습니다.

학습이나 프로토타입은 기본 VPC로 충분합니다. 운영은 새로 만든 커스텀 VPC로 가는 것이 통용됩니다. 기본 VPC는 모든 것이 인터넷에 노출되어 있어 보안적으로 약합니다. VPC 설계를 더 깊이 다루는 것은 28장 VPC 심화입니다.

서브넷 — VPC 안의 칸 #

VPC 안을 더 쪼갠 단위가 **서브넷 (Subnet)**입니다. 서브넷은 하나의 AZ에 속합니다. 그래서 Multi-AZ 운영을 위해서는 서브넷도 여러 AZ에 만들어야 합니다.

VPC 안 서브넷 분할 예

VPC 10.0.0.0/16
│
├── Public Subnet A   10.0.1.0/24  (AZ a) ── ALB, NAT, Bastion
├── Public Subnet B   10.0.2.0/24  (AZ b)
│
├── Private Subnet A  10.0.10.0/24 (AZ a) ── EC2 (앱)
├── Private Subnet B  10.0.11.0/24 (AZ b)
│
└── Database Subnet A 10.0.20.0/24 (AZ a) ── RDS
    Database Subnet B 10.0.21.0/24 (AZ b)

서브넷의 종류는 본인이 정하는 것이 아니라 라우팅 테이블이 정합니다. “퍼블릭"이라는 속성이 따로 있는 것이 아니라, IGW로 가는 라우트가 있는 서브넷이 곧 퍼블릭입니다.

Public vs Private 서브넷 #

	Public 서브넷	Private 서브넷
인터넷 in/out	직접 가능	NAT 경유로 out만
퍼블릭 IP 자동 할당	옵션 켜면 그렇게	보통 끔
두는 리소스	ALB, NAT GW, Bastion	EC2 (앱), Lambda
라우팅	IGW로 `0.0.0.0/0`	NAT GW로 `0.0.0.0/0`

운영 패턴은 앱 서버는 Private에, 외부 노출은 ALB가 Public에서 받는 형태입니다. 앱 서버에 직접 인터넷 IP가 붙지 않아 공격 면적이 줄어듭니다.

라우팅 테이블 — 어디로 보낼까 #

**라우팅 테이블 (Route Table)**은 서브넷의 트래픽이 어디로 갈지를 정의합니다. 서브넷 하나에 라우팅 테이블 하나가 붙습니다.

Public 서브넷의 라우팅 테이블

| Destination    | Target          |
| -------------- | --------------- |
| 10.0.0.0/16    | local           |  ← VPC 안은 항상 local
| 0.0.0.0/0      | igw-xxxxxxxx    |  ← 그 외는 IGW (인터넷)

Private 서브넷의 라우팅 테이블

| Destination    | Target          |
| -------------- | --------------- |
| 10.0.0.0/16    | local           |
| 0.0.0.0/0      | nat-xxxxxxxx    |  ← 그 외는 NAT GW

local 라우트는 자동으로 추가되며 지울 수 없습니다. 같은 VPC 안의 모든 서브넷은 항상 서로 통신할 수 있습니다(단 SG / NACL이 막을 수 있습니다).

IGW — Internet Gateway #

IGW는 VPC와 인터넷을 잇는 단방향 게이트웨이입니다. VPC 당 하나씩 붙입니다(붙이지 않으면 완전한 사설 VPC).

IGW 자체는 트래픽을 라우팅하지 않습니다. 라우팅 테이블에 IGW를 target으로 추가해야 트래픽이 흘러갑니다. 그래서 같은 IGW를 쓰는 VPC 안에서도 일부 서브넷만 퍼블릭으로 만들 수 있습니다.

IGW는 무료이고, 가용성도 자동으로 관리됩니다.

NAT Gateway — 사설에서 인터넷으로 #

Private 서브넷의 EC2가 OS 패치를 받거나 외부 API를 호출하려면 인터넷 접근이 필요합니다. 하지만 인터넷에서 그 EC2로 들어오면 안 됩니다. **NAT (Network Address Translation)**가 그 역할을 합니다.

NAT Gateway의 트래픽 흐름

[Private EC2] ──out──▶ [NAT GW (Public Subnet)] ──out──▶ [IGW] ──▶ 인터넷
                                                ◀ in 안 됨

NAT GW는 Public 서브넷에 둡니다(자기는 인터넷에 보일 수 있어야 IGW와 통신합니다). Private 서브넷의 라우팅 테이블이 NAT GW를 target으로 가리키면, Private의 트래픽이 NAT를 거쳐 인터넷으로 나갑니다.

NAT GW vs NAT Instance #

옛날에는 NAT를 EC2 한 대로 직접 띄웠습니다(NAT Instance). 지금은 매니지드인 NAT Gateway를 거의 항상 사용합니다.

	NAT Gateway	NAT Instance (구)
관리	AWS가 관리	직접
가용성	AZ 단위 자동 (Multi-AZ는 AZ 마다 둘 것)	단일 EC2
대역폭	최대 100 Gbps	EC2 사이즈에 의존
비용	시간당 + GB 당	EC2 비용만

NAT GW 비용 함정 #

NAT Gateway는 시간당과 데이터 처리 GB 당 둘 다 과금됩니다. 트래픽이 많으면 의외로 큰 비용이 됩니다. 절약하는 방법은 다음과 같습니다.

AZ 마다 NAT GW를 두지 않고 한 개만 두면 비용은 줄지만 가용성은 낮아집니다(단일 AZ 장애 시 다른 AZ의 Private도 인터넷이 끊깁니다).
S3 / DynamoDB 트래픽은 Gateway VPC Endpoint로 NAT를 우회합니다(무료).
ECR / Secrets Manager 같은 서비스도 Interface VPC Endpoint로 NAT를 우회할 수 있습니다(시간당 비용은 있지만 트래픽 GB 비용은 없습니다).

VPC Endpoint의 종류와 설계는 28장 VPC 심화에서 본격적으로 다룹니다.

Security Group vs NACL — 방화벽 #

VPC의 방화벽은 두 층으로 동작합니다. 자세한 설계는 9장 EC2 운영에서 다루니 여기서는 그림만 봅니다.

패킷이 EC2에 닿기까지

인터넷 ──▶ NACL (서브넷 단위) ──▶ Security Group (인스턴스 단위) ──▶ EC2

	Security Group	NACL
적용 단위	인스턴스 (ENI)	서브넷
Stateful	응답 자동 허용	아님
규칙	Allow만 (Deny 없음)	Allow + Deny
사용 빈도	매일	거의 안 만짐

운영에서는 거의 SG만 만지고, NACL은 기본값을 그대로 둡니다.

EC2 한 대 띄우기 — CLI #

콘솔 클릭 대신 CLI로 한 줄에 띄울 수 있습니다.

EC2 띄우기

aws ec2 run-instances \
  --image-id ami-0f3a440bbcff3d043 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-0abc1234def567890 \
  --subnet-id subnet-0abc1234def567890 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=my-server}]'

콘솔에서 한 모든 선택이 플래그 하나하나에 대응됩니다. CLI를 한 번 보면 콘솔이 무엇을 선택하라고 묻고 있었는지가 명확해집니다. CLI / SDK 셋업은 4장 AWS CLI와 SDK를 참조합니다.

자주 만나는 함정 #

“왜 EC2가 인터넷이 안 됩니까?” — 다음을 순서대로 확인합니다. (1) 퍼블릭 IP가 붙어 있는가(서브넷의 auto-assign public IP 또는 EIP), (2) 서브넷이 Public 인가(라우팅 테이블에 0.0.0.0/0 → igw-...가 있는가), (3) SG가 outbound를 허용하는가, (4) NACL이 outbound를 허용하는가, (5) OS 안의 방화벽(ufw, iptables)이 막고 있지 않은가. 대개 (1) 또는 (2)이며, Private 서브넷이라면 NAT GW 경로를 확인합니다.
VPC CIDR을 너무 작게 잡음 — 10.0.0.0/24 (256 IP)로 시작하면 나중에 서브넷이 부족해집니다. VPC CIDR은 만든 뒤 변경이 어렵습니다(보조 CIDR 추가는 가능). 처음부터 /16으로 넉넉히 잡습니다.
NAT Gateway 비용이 청구서에 크게 잡힘 — 매월 NAT GW만 수십 달러라면 트래픽 양을 점검합니다. S3 / ECR 호출이 많다면 VPC Endpoint로 NAT를 우회합니다.
키 페어 분실 — SSH 접속 키 페어를 잃어버리면 사실상 인스턴스를 종료한 뒤 재생성해야 합니다. 이 위험 때문에 점점 SSM Session Manager(9장 EC2 운영)로 옮겨가는 추세입니다.
잘못된 AZ에 RDS 단독 배치 — EC2는 AZ a에, RDS는 AZ b에만 두면 작동은 하지만 AZ 간 데이터 전송 비용이 발생합니다. 같은 AZ에 두거나 RDS를 Multi-AZ로 둡니다.
EBS가 인스턴스보다 오래 삶 — 인스턴스 종료 시 EBS가 자동 삭제되는지(DeleteOnTermination) 확인합니다. 옛 옵션이 false 면 종료된 인스턴스의 EBS만 남아 한 달 청구되는 사고가 흔합니다.

연습문제 #

§“VPC 안 서브넷 분할 예"의 그림을 보고, 본인이 만들 서비스의 VPC CIDR (/16)을 하나 정한 뒤 Public · Private · Database 서브넷을 각 AZ에 두 개씩, 총 여섯 개로 잘라 IP 범위를 적어 보세요. 25장 Terraform 입문에서 이 분할이 aws_subnet 리소스가 됩니다.
“왜 EC2가 인터넷이 안 됩니까?“의 다섯 단계 체크리스트를 보지 않고 적어 보세요. 그중 어느 단계가 라우팅 테이블의 문제이고 어느 단계가 SG / NACL의 문제인지 §“라우팅 테이블"과 §“Security Group vs NACL"을 근거로 분류해 보세요.
NAT Gateway 비용을 줄이는 세 가지 방법을 적고, 각각이 가용성 · 무료 여부 측면에서 어떤 트레이드오프가 있는지 한 줄씩 메모해 두세요. 이 메모는 27장 비용 최적화에서 다시 활용됩니다.

한 줄 요약: EC2는 가상 컴퓨터 한 대로 인스턴스 타입이 스펙을, AMI가 OS를, EBS가 디스크를 정한다. VPC는 사설 IP 네트워크이고 그 안의 서브넷은 라우팅 테이블이 IGW를 가리키면 Public, NAT를 가리키면 Private이 된다. IGW는 무료이지만 NAT Gateway는 시간당과 GB 당 둘 다 과금되니 VPC Endpoint로 우회한다.

다음 챕터 #

본 챕터에서 EC2 한 대를 띄우는 그림은 잡혔습니다. 다음 9장 EC2 운영에서는 그 EC2를 안전하게 다루는 일상 도구로 넘어갑니다. Security Group 규칙 설계, key pair의 한계와 SSM Session Manager로의 마이그레이션, AMI로 골격을 굳히는 법까지 정리합니다.