VPC·서브넷·보안그룹
70분 안팎
학습 목표
주소·경로·접근 경계를 구분합니다.
개념
주소가 있다고 경로가 생기지는 않습니다
안내판의 공개 진입점, 앱, 저장소를 모두 같은 네트워크에 넣으면 설명은 짧아지지만 접근 책임이 흐려집니다. 이번 목표는 주소 묶음을 나누고 누가 어느 경로로 어느 서비스에 도달할 수 있는지 설명하는 것입니다. AWS 자원을 만들지 않고 설계를 제출합니다. Docker bridge를 만든 사실을 AWS VPC 실습 완료라고 부르지 않습니다. 전용 Docker 네트워크는 로컬 연결 실습이고 VPC의 라우팅·인터넷 게이트웨이·보안그룹을 대신 구현하는 장치는 아닙니다.
VPC와 서브넷의 책임
VPC는 선택한 주소 범위 안에서 클라우드 네트워크를 구성하는 경계입니다. 서브넷은 VPC 주소 공간의 일부를 사용하며 AWS에서는 하나의 가용 영역에 속합니다. 이번 교육 설계는 10.40.0.0/16 안에 10.40.1.0/24, 10.40.2.0/24, 10.40.3.0/24를 둡니다. 세 범위가 서로 겹치지 않는지 먼저 계산합니다. 이름이 public이라서 공개되는 것이 아니라 연결한 라우팅 표와 주소 설정이 실제 도달 가능성을 결정합니다. 주소 선택 뒤 역할과 가용 영역을 그림에 적습니다.
공개 진입점을 별도로 둡니다
인터넷 사용자는 TLS 443으로 진입점에 요청하고 진입점이 앱의 TCP 8080으로 전달합니다. 앱이 저장소의 TCP 5432를 사용한다는 가상 확장을 추가합니다. 지금 Java 안내판은 파일을 사용하므로 PostgreSQL 설치를 과제에 숨기지 않습니다. 5432는 설계상의 저장소 경계를 설명하는 예시입니다. 진입점의 TLS 인증서와 실제 로드밸런서 생성도 이번 로컬 수료 조건은 아닙니다. 무엇을 구현했고 무엇을 설계했는지 제출물에서 구분합니다.
라우팅 표는 다음 전달 대상을 고릅니다
공개 서브넷은 VPC 내부 local 경로와 0.0.0.0/0에서 인터넷 게이트웨이로 가는 경로를 갖습니다. 인터넷 게이트웨이로의 경로만 있어도 모든 인스턴스에 자동 공인 주소가 붙지는 않습니다. 인터넷과 직접 통신할 자원의 주소 조건도 확인합니다. 앱과 저장소 서브넷은 이번 그림에서 VPC 내부 local 경로만 두어 외부 직접 연결을 배제합니다. 외부 패키지 저장소에 나가야 한다면 NAT 등 송신 경로를 별도 설계해야 하며 보안그룹 허용만으로 그 경로가 생기지 않습니다.
보안그룹은 자원 연결에 붙는 접근 정책입니다
보안그룹은 허용 규칙으로 인바운드와 아웃바운드 트래픽을 제어합니다. 일치하는 허용 규칙이 없는 새 연결은 허용하지 않습니다. 여러 보안그룹을 붙이면 그 허용 규칙을 함께 고려합니다. 명시적 deny 규칙을 뒤에 추가해 먼저 열린 범위를 덮는 모델이 아닙니다. 앱에 TCP 8080을 진입점 보안그룹에서만 허용하면 임의 외부 주소에서 앱으로 직접 오는 새 연결과 진입점을 거친 연결을 구분할 수 있습니다. 라우팅은 별도로 충족되어야 합니다.
응답과 새 연결을 구분합니다
AWS 보안그룹은 stateful입니다. 허용한 연결의 응답 트래픽은 연결 추적의 영향을 받으므로 반대 방향의 동일한 포트를 기계적으로 새 규칙에 추가하는 방식으로 설명하지 않습니다. 새로운 앱→저장소 연결은 앱 송신과 저장소 수신 정책을 확인합니다. 저장소가 시작한 앱 방향의 새로운 연결은 기존 조회 요청의 응답과 다른 사례입니다. 네트워크 ACL은 서브넷 단위이며 stateless라는 차이가 있지만 이 과제에서는 기본 ACL을 가정하고 상세 규칙을 추가하지 않습니다.
그룹 참조를 주소 대역과 혼동하지 않습니다
앱의 수신 출발지를 진입점 SG로 지정하는 설계는 진입점 SG가 붙은 네트워크 인터페이스를 식별하는 방식입니다. 진입점이 허용한 사용자 주소를 앱에 그대로 복사하는 것과 다릅니다. 보안그룹 참조는 전이적으로 다른 그룹의 규칙을 가져오는 동작도 아닙니다. 앱이 저장소에 접근한다고 해서 진입점도 저장소 접근 권한을 얻지는 않습니다. 사용자 IP를 기준으로 추가 HTTP 정책이 필요하면 프록시 전달 헤더의 신뢰 경계도 별도 설계합니다.
허용 표로 그림을 검토합니다
열은 출발지 역할, 목적지 역할, 프로토콜, 목적지 포트, 경로, 정책, 결론으로 만듭니다. 인터넷→진입점 443, 진입점→앱 8080, 앱→저장소 5432는 허용 후보입니다. 인터넷→저장소 5432와 진입점→저장소 5432는 거부합니다. 진입점→앱 5432도 포트가 달라 거부합니다. 각 행의 결론에는 라우팅과 SG 두 조건을 따로 적습니다. 허용 표가 그림과 충돌하면 둘 중 하나를 고쳐야 하며 그림이 예쁘다는 이유로 충돌을 남기지 않습니다.
서브넷 경계를 계산으로 확인합니다
따라하기의 ipaddress 예제는 서브넷이 VPC 안에 포함되고 서로 겹치지 않는지 확인합니다. 이것은 실제 클라우드 예약 주소나 주소 할당 성공을 검증하지 않습니다. 10.41.1.0/24로 바꾸면 VPC 바깥이라는 사실을 계산할 수 있습니다. overlap 결과가 True이면 어느 범위를 나눌지 다시 결정합니다. 더 작은 범위부터 무작정 배치하면 확장 여지가 부족할 수 있으므로 예상 역할과 확장 구간을 주석으로 남깁니다.
접속 실패의 세 질문
주소가 의도한 자원인지, 전달 경로가 존재하는지, 새 연결이 허용되는지 순서대로 확인합니다. 타임아웃만 보고 SG를 전부 열면 잘못된 DNS나 경로 누락은 고쳐지지 않습니다. Connection refused는 목적지에 도달했지만 listen 상태나 거부 정책 등을 살펴볼 신호입니다. 시간 초과가 SG 때문이라고 단정하지 않습니다. 실제 검증에서는 DNS·TCP·HTTP 관측을 연결해야 하지만 설계 실습에서는 각 실패 사례를 어느 경계에서 거부하려는지 먼저 적습니다.
제출물과 검토 기준
VPC 큰 상자 안에 세 서브넷을 배치하고 진입점·앱·저장소를 역할별로 넣습니다. 화살표에 TCP와 목적지 포트를 표시하고 각 서브넷의 라우팅 표를 연결합니다. SG는 자원 옆에 붙이며 출발지 그룹을 적습니다. 저장소 직접 공개를 거부하는 두 사례와 잘못된 포트 사례를 허용 표에 포함합니다. 면접에서는 VPC가 주소·네트워크 경계, 서브넷이 주소 구획, SG가 허용 정책이라는 분리와 실제 접속 조건을 함께 설명합니다. 세 용어를 서로의 동의어처럼 말하지 않습니다.
AWS 동작은 보안그룹 공식 문서로 확인합니다.
따라하기
범위 포함 확인
세 서브넷이 VPC 안에 있고 서로 겹치지 않는지 계산합니다.
import ipaddress
v=ipaddress.ip_network('10.40.0.0/16')
s=[ipaddress.ip_network('10.40.%d.0/24'%i) for i in [1,2,3]]
print('inside', all(n.subnet_of(v) for n in s))
print('overlap', any(a.overlaps(b) for i,a in enumerate(s) for b in s[i+1:]))실행 결과
inside True overlap False
그림 배치
VPC와 공개·앱·저장소 서브넷을 그리고 각 자원을 넣습니다. 화살표에 443, 8080, 5432를 표시합니다. AWS 콘솔에서 실행한 결과가 아니라 설계 제출물입니다.
경로와 규칙 대조
공개 서브넷에 IGW 경로를 연결합니다. 앱과 저장소에는 local 경로만 표시합니다. 수신·송신 그룹과 포트를 허용 표에 적고 직접 저장소 접근 거부를 설명합니다.
동료 리뷰
인터넷→앱 8080, 진입점→저장소 5432, 앱→저장소 5432 행을 추가합니다. 경로·정책·결론이 그림과 같은지 체크합니다.
확인 문제
실습
VPC 10.40.0.0/16 안에 공개·앱·저장소 서브넷을 겹치지 않게 배치한 그림과 라우팅 표를 제출합니다. SG 수신·송신의 출발지/목적지 그룹·포트를 적습니다. 인터넷→진입점 443, 진입점→앱 8080, 앱→저장소 5432 허용과 인터넷→저장소, 진입점→저장소, 잘못된 포트 거부를 6행 이상 표로 설명합니다. 실제 로컬 구현과 AWS 설계를 구분하며 AWS 자원 생성은 요구하지 않습니다.
더 읽기
면접 질문
- VPC·서브넷·보안그룹의 역할을 설명합니다.