실습 1-4 — 라우팅 테이블을 서브넷에 연결하기 (Association)
실습 1-1에서
My-VPC-RT를 만들기만 했습니다. 그땐local경로뿐이라 아무 서브넷에도 영향을 주지 못했죠. 이번 편은 그 라우팅 테이블을 서브넷에 "연결" 해 비로소 효력을 주는 단 하나의 행위에 집중합니다.
📌 이번 편 한눈에
| 질문 | 답 |
|---|---|
| 연결(Association)이 뭐? | RT를 특정 서브넷에 적용시키는 행위 |
| 안 하면? | 서브넷은 기본(Main) RT를 그대로 사용 |
| 규칙은? | 서브넷 1개 = RT 1개만 (연결 시 기존 연결 자동 해제) |
| 왜 명시적으로? | 묵시적(기본 RT)에 묻어가면 의도와 다르게 동작 |
1. 연결(Association)이란 — "어느 서브넷에 적용할지" 지정
라우팅 테이블은 만들어 두는 것만으로는 아무 일도 하지 않습니다. "이 규칙표를 어느 서브넷에 적용할래?"를 지정하는 행위가 바로 연결(Association) 입니다.
비유하면, RT는 "이정표 묶음" 이고 연결은 그걸 특정 구역(서브넷) 입구에 세우는 일입니다. 세우기 전엔 길안내가 시작되지 않습니다.
2. 연결의 3가지 규칙 (이것만 기억)
① 서브넷 1개 = RT 1개
한 서브넷은 동시에 하나의 라우팅 테이블에만 연결됩니다. (반대로 RT 1개는 여러 서브넷에 연결 가능)
② 연결하면 기존 연결은 자동 해제 (갈아타기)
서브넷을 My-VPC-RT에 연결하는 순간, 그 서브넷이 쓰던 기존 RT(보통 기본 RT) 연결은 자동으로 끊깁니다. 별도로 해제할 필요가 없습니다.
③ 연결 안 하면 기본(Main) RT 사용
명시적으로 연결하지 않은 서브넷은 VPC의 기본 RT에 묵시적으로 묶여 있습니다. "아무것도 안 했는데 왜 인터넷이 되지/안 되지?"의 원인이 대개 이것입니다.
3. 왜 "명시적 연결"이 중요한가
묵시적으로 기본 RT에 묻어가면, 기본 RT의 경로 변화에 의도치 않게 휩쓸립니다. 예를 들어 누군가 기본 RT에 IGW 경로를 넣으면, 연결을 안 해둔 "프라이빗이어야 할" 서브넷까지 갑자기 퍼블릭이 되어 노출 사고가 납니다.
💡 실무 원칙: 기본 RT는 손대지 않고(프라이빗하게 유지), 모든 서브넷을 의도한 커스텀 RT에 명시적으로 연결한다. 그래야 "이 서브넷이 어떤 길을 쓰는지"가 항상 명확합니다.
실습 — 서브넷 연결 편집
라우팅 테이블(My-VPC-RT) 상세 → 서브넷 연결 탭 → 서브넷 연결 편집에서 대상 서브넷을 체크하고 저장합니다.

연결을 저장하면, 라우팅 테이블의 "서브넷 연결" 목록에 해당 서브넷이 나타납니다. (서브넷 쪽에서 보면, 연결된 RT가 방금 그 RT로 바뀌어 있습니다)

연결 후 — 이렇게 바뀌었는지 확인
- RT 화면: "서브넷 연결" 목록에 대상 서브넷이 보인다
- 서브넷 화면: "라우팅 테이블" 항목이 기본 RT →
My-VPC-RT로 변경됐다 - 명시적 연결로 표시된다(묵시적이 아님)
흔한 실수 3가지 (연결 단계 한정)
- 연결을 안 함 — RT를 만들고 경로까지 넣었는데 서브넷 연결을 빠뜨림 → 서브넷은 여전히 기본 RT 사용 → "설정은 맞는데 왜 안 되지?"
- 엉뚱한 서브넷에 연결 — 퍼블릭 RT를 프라이빗 서브넷에, 혹은 그 반대로 연결 → 공/사 구조가 뒤바뀜
- 연결은 했지만 경로가 없음 — 서브넷을 연결해도 이 RT에
0.0.0.0/0 → IGW경로가 없으면 인터넷 불가
⚠️ 연결 + 경로, 둘 다 있어야 완성 — 이번 편은 "연결"까지입니다. 진짜 퍼블릭은 다음 편에서 IGW 경로를 추가해야 완성됩니다.
마치며
이번 편의 한 줄:
"라우팅 테이블은 '연결'되는 순간부터 일을 시작한다."
'클라우드 컴퓨팅 > AWS' 카테고리의 다른 글
| 실습 1-6 _ EC2 (0) | 2026.06.06 |
|---|---|
| 실습 1-5 _ IGW & RT Table (0) | 2026.06.06 |
| 실습 1-3 _ Subnet (0) | 2026.06.06 |
| 실습 1-2 _ Network ACL (0) | 2026.06.06 |
| 실습 1-1 _ 라우팅 테이블 - 1 (0) | 2026.06.06 |