AWS 중급 #1 EC2와 VPC 기초

2026년 4월 18일 토요일

10 분 소요

기초 7편으로 계정 / 리전 / IAM / 비용 / CLI / 보안 / CloudWatch라는 준비 단계가 끝났다면, 이제 실제로 무언가를 띄우는 단계로 들어갑니다. 중급 7편은 AWS 위에서 가장 자주 만나는 컴포넌트들, EC2, VPC, S3, RDS, Route 53, ALB, CloudFront를 운영 시각으로 한 줄에 꿰는 것이 목표입니다.

그 첫 단계는 EC2와 VPC입니다. 클라우드의 가장 오래된, 가장 기본이 되는 도구입니다. EC2는 “가상 컴퓨터 한 대”, VPC는 “그 컴퓨터들이 사는 네트워크"입니다. 둘은 항상 같이 다닙니다.

큰 그림 #

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. 운영 중인 인스턴스를 스냅샷 떠서 만들기 (#2)

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 안의 칸 #

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를 호출하려면 인터넷 access가 필요합니다. 하지만 인터넷에서 그 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 비용 없음)

Security Group vs NACL: 방화벽 #

VPC의 방화벽은 두 층으로 동작합니다. 자세한 내용은 #2 EC2 운영에서 다루니 여기선 그림만:

패킷이 EC2에 닿기까지

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

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

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

EC2 한 대 띄우기: `aws 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 참조.

자주 만나는 함정 #

1) “왜 EC2가 인터넷이 안 됩니까?” #

체크리스트:

퍼블릭 IP가 붙어 있나? (서브넷의 “auto-assign public IP” 또는 EIP)
서브넷이 Public 인가? (라우팅 테이블에 0.0.0.0/0 → igw-...가 있나)
SG가 outbound 허용 인가? (기본은 모두 허용, 직접 닫았을 수 있음)
NACL이 outbound 허용 인가? (기본은 모두 허용)
OS 안의 방화벽 (ufw, iptables)이 막고 있지 않나?

대개 1) 또는 2). Private 서브넷이라면 NAT GW 경로 확인.

2) VPC CIDR을 너무 작게 잡았다 #

10.0.0.0/24 (256 IP)로 시작해서 나중에 서브넷이 부족. VPC CIDR은 만든 뒤 변경이 어렵습니다 (보조 CIDR 추가는 가능). 처음부터 /16으로 넉넉히.

3) NAT Gateway 비용이 청구서에 크게 #

매월 NAT GW만 수십 달러? 트래픽 양 점검. S3 / ECR 호출이 많다면 VPC Endpoint로 NAT 우회 검토.

4) “키 페어를 잃어버렸을 때” #

EC2에 SSH로 접속할 키 페어를 잃어버리면 사실상 인스턴스 종료 후 재생성. 이 위험 때문에 점점 SSM Session Manager (#2)로 옮겨가는 추세. 키 자체가 필요 없습니다.

5) 잘못된 AZ에 RDS가 단독 #

EC2는 AZ a에, RDS는 AZ b에만 두면, 작동은 하지만 AZ 간 데이터 전송 비용이 발생합니다. 같은 AZ에 두거나, RDS를 Multi-AZ로 (양쪽 다 standby).

6) EBS가 인스턴스보다 오래 산다 #

인스턴스 종료 시 EBS가 자동 삭제되는지 (DeleteOnTermination) 확인합니다. 옛 옵션이 false면 종료된 인스턴스의 EBS만 남아 한 달 청구되는 사고가 흔합니다.

정리 #

이번 글에서 잡은 것:

EC2 = 가상 컴퓨터 한 대. 타입 (t3.micro 등)으로 스펙 결정, AMI로 OS, EBS로 디스크
AMI는 리전 단위. 자주 쓰는 건 Amazon Linux 2023 / Ubuntu LTS
EBS의 기본은 gp3. 인스턴스 스토어는 휘발성 (캐시 용도만)
VPC = AWS 안 사설 네트워크. CIDR /16으로 시작, 사설 IP 영역만
서브넷은 AZ 1개에 속함. Public / Private은 본인 속성이 아니라 라우팅 테이블이 결정
라우팅 테이블의 0.0.0.0/0가 IGW로 가면 Public, NAT로 가면 Private
IGW = VPC ↔ 인터넷. NAT Gateway = Private의 outbound만 허용
NAT GW는 비쌉니다. VPC Endpoint로 우회
방화벽은 SG (인스턴스, stateful) + NACL (서브넷, stateless), 거의 SG만 만짐
함정. 인터넷 안됨 5단계, VPC CIDR 작게, NAT 비용, 키 분실, AZ 간 트래픽, EBS 잔여

다음: EC2 운영 #

EC2 한 대를 띄우는 그림은 잡혔습니다. 이제 그 EC2를 안전하게 다루는 단계로 넘어갑니다.

#2 EC2 운영: security group, key pair, SSM에서는 SG 규칙 설계, key pair의 한계와 SSM Session Manager로의 마이그레이션, AMI 만들기까지 운영 도구의 일상 패턴을 정리하겠습니다.