Design a VPC on Paper

한국어 원문으로 표시합니다.

목표

클라우드 네트워크는 만들기 전에 정하는 것이 거의 전부입니다. 대역을 잘못 고르면 나중에 못 고칩니다 — 이미 도는 서비스의 IP 를 바꿔야 하기 때문입니다.

이 실습은 클라우드 계정 없이, 실제로 하는 계산을 그대로 합니다.

조건

온프레미스가 이미 10.0.0.0/12 를 쓴다
AZ 3개, 각 AZ 마다 public /24 · app /22 · db /24
나중에 AZ 를 하나 더 붙일 수 있어야 한다

계산은 손으로 하지 않는다

python3 - <<'PY'
import ipaddress as i
vpc = i.ip_network('10.42.0.0/16')
print(list(vpc.subnets(new_prefix=22))[:4])
print(vpc.overlaps(i.ip_network('10.0.0.0/12')))
PY

ipaddress 모듈이면 충분합니다. 사람 눈으로는 10.42.4.0/22 와 10.42.6.0/24 가 겹치는지 알 수 없습니다.

파일

파일	내용
`01-range.txt`	고른 VPC 대역 한 줄
`plan.csv`	`이름,CIDR` 9줄
`check.py`	겹침 검사 — 겹치면 종료 코드 1
`04-growth.txt`	4번째 AZ 로 쓸 빈 블록
`route.csv`	`계층,기본경로대상` 3줄
`06-nacl.txt`	NACL 규칙
`07-egress.txt`	비용 계산
`08-notes.md`	정리

참고

3단계의 check.py 는 채점기가 일부러 겹치게 만든 계획에 돌려 봅니다. 잡아내지 못하면 통과하지 못합니다 — 검사가 실제로 검사하는지 확인하는 것도 실습의 일부입니다.

겹치지 않는 대역을 고른다

온프레미스가 이미 10.0.0.0/12 를 쓰고 있습니다. 여기와 겹치지 않는 /16 VPC 대역을 골라 01-range.txt 에 한 줄로 적으세요(예: 10.42.0.0/16).

/12 는 10.0.0.0 부터 10.15.255.255 까지입니다. 세 번째 옥텟이 아니라 두 번째 옥텟을 보세요. 확인은 파이썬으로: python3 -c "import ipaddress as i; print(i.ip_network('10.42.0.0/16').overlaps(i.ip_network('10.0.0.0/12')))".

대역이 겹치면 나중에 VPN·피어링을 붙일 때 되돌릴 수 없습니다. 이미 도는 서비스의 IP 를 바꿔야 하기 때문입니다.

3개 AZ 에 3계층을 깐다

AZ 3개 각각에 public /24, app /22, db /24 를 배치해 plan.csv 에 이름,CIDR 형식으로 9줄 쓰세요.

이름은 public-a, app-a, db-a, public-b… 처럼 붙이세요. 서로 겹치면 안 되고 전부 VPC 안에 있어야 합니다. /22 는 /24 네 개 크기입니다 — 앱 계층이 가장 커야 하는 이유는 파드·태스크가 IP 를 하나씩 먹기 때문입니다.

계산은 손으로 하지 마세요. python3 -c "import ipaddress as i; print(list(i.ip_network('10.42.0.0/16').subnets(new_prefix=22))[:4])".

겹침 검사를 직접 짠다

check.py 를 만드세요. plan.csv 를 읽어 겹치는 쌍이 있으면 그 쌍을 출력하고 종료 코드 1, 없으면 0 으로 끝나야 합니다.

ipaddress.ip_network(x).overlaps(y) 면 충분합니다. 사람 눈으로는 10.42.4.0/22 와 10.42.6.0/24 가 겹치는지 알 수 없습니다 — 그래서 이 검사를 CI 에 겁니다.

채점기는 당신의 check.py 를 일부러 겹치게 만든 계획에 돌려 봅니다. 잡아내지 못하면 통과하지 못합니다.

네 번째 AZ 자리를 남긴다

지금 계획에서 AZ 하나를 더 붙일 수 있는지 확인하고, 쓸 수 있는 빈 블록을 04-growth.txt 에 적으세요.

필요한 것은 public /24 + app /22 + db /24 한 벌입니다. VPC 에서 이미 쓴 것을 빼고 남은 블록을 구하세요.

처음부터 /16 을 꽉 채워 쓰는 설계가 가장 흔한 실수입니다. AZ 는 늘어나고 대역은 못 늘립니다.

어디로 나가는지 정한다

route.csv 에 계층별로 계층,기본경로대상 을 세 줄 쓰세요 — public / app / db.

public 은 인터넷 게이트웨이(igw), app 은 NAT(nat), db 는 바깥으로 나가지 않습니다(none). 이 세 줄이 곧 보안 경계입니다.

'private 서브넷' 이라는 말은 기본 경로가 IGW 가 아니라는 뜻일 뿐입니다. NAT 를 달면 나가긴 나갑니다 — 못 나가게 하려면 기본 경로를 아예 두지 않아야 합니다.

NACL 은 왜 규칙이 두 배인가

app 서브넷에서 바깥 HTTPS(443)로 나가야 합니다. NACL 로만 이걸 허용하려면 필요한 규칙을 06-nacl.txt 에 방향과 포트까지 적으세요.

보안 그룹은 상태를 기억해서 나간 요청의 응답이 자동으로 돌아옵니다. NACL 은 기억하지 않습니다 — 나가는 443 을 열고, 돌아오는 응답을 위해 **인바운드 임시 포트 범위(1024–65535)**도 열어야 합니다.

이걸 몰라서 'SG 는 열었는데 왜 안 되지' 로 반나절을 씁니다.

나가는 데이터에 돈이 붙는다

app 서브넷이 매달 오브젝트 스토리지로 500GB 를 보냅니다. NAT 를 지날 때와 게이트웨이 엔드포인트를 쓸 때의 월 비용 차이를 계산해 07-egress.txt 에 숫자와 함께 적으세요.

NAT 게이트웨이는 시간당 요금과 처리량당 요금이 따로 붙습니다(대략 GB 당 $0.045). 게이트웨이 엔드포인트는 처리량 요금이 없습니다. 500GB × $0.045 = ? 그리고 NAT 상주 비용(730시간 × $0.045)도 함께 적으세요.

요율은 사업자·리전마다 다릅니다. 중요한 것은 자릿수입니다 — 트래픽이 같은데 경로만 바꿔서 비용이 사라지는 구조가 있다는 것.

세 가지를 정리한다

08-notes.md 에 세 줄 이상. 대역을 잘못 고르면 왜 되돌릴 수 없는지, private 서브넷의 진짜 뜻, SG 와 NACL 의 차이.

본문에 겹, 기본 경로, 상태 가 들어가야 합니다.