[CLOUD-004][기초] VPC와 서브넷을 나누고 통신 규칙 설계하기 > IT 기술 공유

• 목록

[이번 수업]
클라우드 서버를 바로 만들기 전에 네트워크 경계부터 설계해야 합니다. 이번에는 AWS 용어를 기준으로 VPC, 서브넷, 라우팅, 보안그룹의 역할을 연결합니다. 비용이 생기는 클라우드 자원은 만들지 않고 Python으로 CIDR 주소 범위만 로컬 검증합니다.

[선수지식]
CLOUD-001~003의 리전·가용영역·공유 책임과 NET-001의 IP·CIDR 기초를 알고 있으면 됩니다. CIDR은 `10.20.0.0/16`처럼 주소 범위와 네트워크 비트 수를 함께 쓰는 표기입니다.

[학습목표]
1. VPC와 서브넷의 포함 관계를 설명한다.
2. 라우팅과 보안그룹의 역할을 구분한다.
3. 서브넷이 겹치지 않는지 코드로 확인한다.

[핵심개념]
VPC(Virtual Private Cloud)는 계정이 정의하는 논리적으로 격리된 가상 네트워크입니다. 먼저 큰 CIDR 범위를 정하고 그 안을 서브넷으로 나눕니다. AWS에서 한 서브넷은 하나의 가용영역 안에 존재합니다. 웹 진입, 애플리케이션, 데이터베이스처럼 역할별로 나누면 경로와 접근 규칙을 명확히 관리할 수 있습니다.

서브넷의 public·private 성격은 이름이 아니라 라우트 테이블로 정해집니다. 라우트 테이블은 목적지 CIDR과 다음 대상(인터넷 게이트웨이, NAT 게이트웨이 등)을 연결합니다. 인터넷 게이트웨이로 직접 가는 경로가 있으면 public subnet, 없으면 private subnet입니다. 사설 서브넷의 외부 나가기용 NAT 경로는 외부에서 직접 들어오는 경로가 아닙니다.

보안그룹은 연결된 인스턴스·네트워크 인터페이스의 허용 트래픽을 제어하는 상태 저장 가상 방화벽입니다. 허용된 요청의 응답 트래픽은 반대 방향 규칙과 별개로 허용됩니다. 라우팅이 길을 정하고 보안그룹이 그 길의 통신을 허용하는 셈입니다. 둘 중 하나만 맞아도 통신되지는 않습니다.

예를 들어 공개 로드밸런서용 alb-sg는 필요한 443만 받고, app-sg는 alb-sg에서 오는 8080만, db-sg는 app-sg에서 오는 5432만 허용합니다. 관리자 포트 22를 전 세계에 열지 말고 관리 서비스나 제한된 VPN 경로를 사용합니다.

[따라하기]
아래를 cidr_check.py로 저장합니다. 세 `/24` 서브넷이 `/16` VPC 안에 있고 서로 겹치지 않는지 확인합니다. 실제 AWS API는 호출하지 않습니다.

```python
from ipaddress import ip_network
from itertools import combinations

vpc = ip_network("10.20.0.0/16")
subnets = {
    "public-a": ip_network("10.20.0.0/24"),
    "app-a": ip_network("10.20.1.0/24"),
    "db-a": ip_network("10.20.2.0/24"),
}

for name, subnet in subnets.items():
    print(name, subnet, "inside:", subnet.subnet_of(vpc))

for (name_a, net_a), (name_b, net_b) in combinations(subnets.items(), 2):
    if net_a.overlaps(net_b):
        raise ValueError(f"overlap: {name_a}, {name_b}")

print("overlap: none")
```

macOS/Linux는 `python3 cidr_check.py`, Windows는 `py cidr_check.py`를 실행합니다. 세 줄 모두 `inside: True`, 마지막은 `overlap: none`이 나와야 합니다. Python 명령 이름 외에 운영체제 차이는 없습니다.

[흔한 실수]
서브넷 CIDR을 VPC 밖에 잡거나 서로 겹치게 만들면 연결 설계가 깨집니다. 이름에 private를 붙였다고 사설이 되는 것도 아닙니다. 라우트, 공인 주소, 게이트웨이 조건을 함께 확인하세요. 보안그룹과 서브넷 수준의 네트워크 ACL을 같은 것으로 생각하지 마세요.

[보안 주의]
학습 중 실제 클라우드 자원과 NAT 게이트웨이를 만들지 마세요. 비용과 외부 노출이 생길 수 있습니다. 보안그룹의 `0.0.0.0/0`은 모든 IPv4 주소를 뜻하므로 관리 포트에 쓰지 말고 출발지와 포트를 최소화합니다. 데이터베이스는 사설 서브넷에 두고 앱 계층에서 필요한 포트만 허용하세요. 규칙 변경은 코드 리뷰와 로그로 추적합니다.

[직접 해볼 과제]
1. `10.20.3.0/24` 관리 서브넷을 추가해 검사를 통과시키세요.
2. db-a를 `10.20.1.128/25`로 바꾸어 겹침 오류를 관찰한 뒤 복구하세요.
3. alb-sg→app-sg→db-sg 흐름을 출발지, 목적지 포트 표로 적으세요.

[확인문제]
1. AWS에서 서브넷이 public인지 결정하는 핵심 설정은 무엇인가요?
2. 라우트 테이블과 보안그룹의 역할은 어떻게 다른가요?
3. 상태 저장 보안그룹에서 허용된 요청의 응답은 어떻게 처리되나요?

[다음 학습]
다음 순환은 DEVOPS-004 CI에서 빌드·테스트 자동화입니다. 클라우드 트랙은 CLOUD-005 로드밸런서와 오토스케일링으로 이어집니다.

[공식 참고 자료]
https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html
https://docs.python.org/3/library/ipaddress.html