vpc,igw,nat-gw, ec2, sg,eip 직접 구성 - 1

AWS 네트워크 아키텍처 — 구축 순서 · 당위성 · OSI 7계층 매핑

My-VPC 실습 구성을 "전문가가 처음부터 설계·생성한다면 어떤 순서로, 왜 그렇게 하는가"의 관점으로 정리.
각 단계마다 ① 무엇을 ② 왜(당위성·비유) ③ 어떻게 연결 ④ OSI 계층 으로 설명.

---

0. 큰 그림 — 도시/건물에 빗댄 전체 구조

네트워크 구성은 "빈 땅에 보안이 갖춰진 사옥 단지를 짓는 일" 과 같습니다.

AWS 리소스	현실 비유
Region / AZ	도시 / 서로 떨어진 건물 부지(재해 분산)
VPC	울타리 친 내 사유지(부지 전체)
Subnet	부지를 나눈 구역(공개 구역 / 비공개 구역)
Internet Gateway	단지의 정문(외부 도로와 연결)
Route Table	이정표/내비게이션(어디로 가라)
VPC Router	이정표를 보고 운전하는 운전기사
Network ACL	구역 정문 경비(구역 출입을 양방향 명부로 확인)
Security Group	각 건물 현관 도어맨(방문자를 기억함)
EC2	건물 안의 직원/서버
NAT Gateway	내부인이 외부로 나갈 때 쓰는 대표 창구(우체국 사서함)
Elastic IP	바뀌지 않는 고정 간판 주소

이 순서로 짓는 이유: 바깥 골격(부지→구역→문)을 먼저 만들고, 그 안에 보안 장치(경비·도어맨)를 두고, 마지막에 사람(서버)을 들이고, 필요하면 외출 통로(NAT)를 뚫는다. 의존성이 낮은 것부터 높은 것 순입니다.

---

1단계 — VPC 생성 (My-VPC, 10.9.0.0/16)

무엇: AWS 안에 격리된 가상 네트워크. CIDR 10.9.0.0/16(약 6.5만 IP)을 부여.

왜(당위성): 모든 리소스는 어딘가에 "소속"돼야 합니다. 서버를 만들기 전에 그것이 살 땅(주소 공간) 부터 정의해야 하죠. 울타리를 쳐서 외부 인터넷·다른 사용자와 논리적으로 분리하는 게 첫걸음입니다. CIDR을 /16처럼 크게 잡는 건, 나중에 구역(서브넷)을 여러 개 나눠도 주소가 모자라지 않게 하기 위함입니다.

연결: 아직 없음(최상위 컨테이너).

OSI: L3(네트워크 계층) — IP 주소 공간 정의.

---

2단계 — Subnet 생성 (Public 10.9.1.0/24, Private 10.9.2.0/24)

무엇: VPC의 큰 주소 범위를 잘게 나눈 구역. 각 서브넷은 하나의 AZ에 소속.

왜(당위성): 모든 서버를 한 구역에 두면 보안·관리가 어렵습니다. 외부에 노출돼야 하는 것(웹 서버) 과 숨겨야 하는 것(DB·내부 서버) 을 물리적으로 분리해야 합니다. 그래서 공개 구역(Public)과 비공개 구역(Private)으로 나눕니다. 또 두 서브넷을 서로 다른 AZ(2c, 2d) 에 두는 건, 한 건물(AZ)에 불이 나도 다른 건물은 살아남게 하는 고가용성 설계입니다.

연결: VPC에 소속. (퍼블릭/프라이빗 성격은 아직 미정 — 4단계 라우팅에서 결정됨)

OSI: L3 — 주소 범위 분할.

---

3단계 — Internet Gateway 생성·연결 (My-IGW)

무엇: VPC와 인터넷을 잇는 양방향 관문. VPC당 1개 부착.

왜(당위성): 부지(VPC)는 기본적으로 외부와 단절돼 있습니다. 외부 도로(인터넷)와 연결하려면 정문(IGW) 이 있어야 합니다. 정문이 없으면 어떤 라우팅을 설정해도 인터넷으로 나갈 길 자체가 없습니다. 그래서 외부 통신을 하려면 IGW를 먼저 VPC에 부착합니다.

연결: VPC에 attach. (단, 정문만 달았다고 길이 생기는 건 아님 → 4단계에서 이정표 필요)

OSI: L3 + NAT 수행 시 L4 관여.

---

4단계 — Route Table 생성·연결 (Public-RT, Private-RT)

무엇: "목적지 IP를 어디로 보낼지" 정한 이정표. 서브넷에 연결(association)됨.

• Public-RT: 10.9.0.0/16 → local + 0.0.0.0/0 → IGW
• Private-RT: 10.9.0.0/16 → local (이 시점엔 아직 인터넷 경로 없음)

왜(당위성): 정문(IGW)을 달았어도 "인터넷으로 가려면 정문으로 가라"는 이정표 가 없으면 패킷이 길을 못 찾습니다. 바로 이 0.0.0.0/0 → IGW 이정표가 "이 구역은 공개 구역(Public)" 임을 결정합니다. 반대로 이 이정표가 없는 Private-RT에 연결된 구역은 자동으로 비공개가 됩니다. 즉 퍼블릭/프라이빗은 서브넷 자체 속성이 아니라 "라우팅 테이블에 인터넷 경로가 있느냐"로 갈립니다.

연결: Public-RT ↔ Public-subnet, Private-RT ↔ Private-Subnet. RT는 VPC 리소스이고 서브넷에 연결되며, 운전기사(라우터)가 이를 참조합니다(RT는 라우터 소유가 아님).

OSI: L3 — 라우팅(경로 결정).

---

5단계 — Network ACL (My-VPC-ACL)

무엇: 서브넷 경계에서 동작하는 방화벽. 서브넷에 연결. Stateless.

왜(당위성): 구역(서브넷) 단위로 출입을 통제하는 1차 경비초소 입니다. 건물(인스턴스)에 도달하기 전 구역 입구에서 먼저 거릅니다. NACL은 상태를 기억하지 못하므로(Stateless), 들어온 손님의 응답이 나갈 때도 "나가는 명부(아웃바운드 규칙)"를 따로 확인합니다. 광범위한 차단(예: 특정 IP 대역 전체 거부)에 적합합니다.

연결: 서브넷에 연결. (생성·연결 안 하면 기본 NACL이 자동 적용 — 전체 허용)

OSI: L3(IP) + L4(포트/프로토콜).

---

6단계 — Security Group (Public-Web-SSH-SG, Private-SSH-SG)

무엇: 인스턴스(ENI) 단위 방화벽. Stateful. 허용 규칙만.

왜(당위성): 각 건물 현관의 도어맨 입니다. 구역 경비(NACL)를 통과한 손님을 건물 입구에서 한 번 더 확인합니다.

• Public-Web-SSH-SG: 웹(80)·관리(22)를 외부에 허용 → 웹 서버는 누구나 접속해야 하니까.
• Private-SSH-SG: SSH(22)를 IP가 아니라 "Public SG에 속한 인스턴스" 로부터만 허용 → 외부에서 비공개 서버로 직접 못 들어오고, 반드시 공개 서버(Bastion)를 거치게 강제.

도어맨은 손님을 기억하므로(Stateful), 인바운드만 열면 응답은 자동으로 내보냅니다. EC2를 만들 때 함께 지정하므로 인스턴스보다 먼저 준비합니다.

연결: 인스턴스(ENI)에 적용. Private-SG는 소스로 Public-SG를 참조.

OSI: L3 + L4.

---

7단계 — EC2 인스턴스 생성 (PublicEC2, Private-EC2)

무엇: 실제 연산을 수행하는 가상 서버.

• PublicEC2: Public-subnet에 배치, 공인 IP 자동 할당(3.35.195.121) → 웹 서비스 + Bastion 역할.
• Private-EC2: Private-Subnet에 배치, 공인 IP 없음(10.9.2.240) → 외부 직접 노출 금지.

왜(당위성): 부지·구역·문·경비·도어맨이 모두 준비된 뒤에야 사람(서버)을 들입니다. 공개 서버는 외부 주소(공인 IP)가 있어야 손님이 찾아올 수 있고, 비공개 서버는 외부 주소를 주지 않아 애초에 외부에서 찾을 수 없게 합니다.

연결: 서브넷에 배치 + SG 적용.

OSI: L1~L7 전 계층(호스트는 통신의 종단).

---

8단계 — NAT Gateway + Elastic IP (My-NAT-GW, My-EIP)

무엇: 프라이빗 서브넷의 아웃바운드 전용 출구. 퍼블릭 서브넷에 배치하고 EIP를 부착.

왜(당위성): ★사용자가 든 예시 그대로★ — Private-EC2가 외부 인터넷과 통신(예: 패키지 업데이트)하기 위해 필요 합니다. 비공개 서버는 공인 IP가 없어 직접 인터넷에 못 나갑니다. 그렇다고 공인 IP를 주면 외부에 노출돼 버리죠. 그래서 "내부인은 대표 창구(NAT GW)를 통해서만 외출하고, 외부인은 그 창구로 들어올 수 없다" 는 단방향 출구를 둡니다. NAT GW가 출발지 IP를 대표 주소(EIP)로 바꿔 내보내므로, 외부에선 누가 나왔는지 개별 서버를 알 수 없습니다.

• 퍼블릭 서브넷에 두는 이유: NAT GW 자신이 인터넷으로 나가려면 0.0.0.0/0 → IGW 경로가 있는 구역(=퍼블릭)에 있어야 하기 때문. 프라이빗에 두면 동작하지 않음.
• EIP가 필요한 이유: 대표 주소가 자꾸 바뀌면 곤란하므로 고정 공인 IP 를 부여.

연결: Public-subnet에 생성 + EIP 할당.

OSI: L3 + L4(IP·포트 변환).

---

9단계 — Private-RT에 NAT 경로 추가 (0.0.0.0/0 → NAT-GW)

무엇: Private-RT에 0.0.0.0/0 → My-NAT-GW 라우팅을 추가.

왜(당위성): NAT GW(창구)를 만들기만 해선 안 됩니다. "외부로 갈 땐 NAT 창구로 가라"는 이정표 를 비공개 구역의 라우팅 테이블에 넣어줘야 비로소 길이 연결됩니다. 이 경로가 없으면 Private-EC2는 여전히 밖으로 못 나갑니다. (8·9단계가 짝)

연결: Private-RT → NAT-GW.

OSI: L3.

---

10단계 — 검증 (통신 흐름 확인)

구축이 끝나면 의도대로 동작하는지 확인합니다.

• PublicEC2: 외부에서 웹(80) 접속 가능 / SSH(22) 가능.
• Private-EC2: 외부 직접 접속 불가, Bastion(PublicEC2) 경유 SSH만 가능, ping·yum update 같은 아웃바운드는 NAT GW로 가능.

---

OSI 7계층 종합 매핑

구축 단계 / 리소스	OSI 계층	무엇을 보고 동작하나
VPC, Subnet	L3 네트워크	IP 주소 공간
Route Table, VPC Router	L3 네트워크	목적지 IP → 경로
Internet Gateway	L3(+L4)	공인↔사설 IP 변환(NAT)
NAT Gateway	L3+L4	출발지 IP·포트 변환(SNAT/PAT)
Network ACL	L3+L4	IP + 프로토콜 + 포트(Stateless)
Security Group	L3+L4	IP + 포트 + SG참조(Stateful)
EC2 / ENI	L1~L7	호스트(전 계층)
HTTP·SSH·ping	L7 / (ping은 L3 ICMP)	서비스·도달성

핵심 한 줄: 아래 계층(L3 라우팅: 어디로 갈지)을 먼저 깔고 → 그 위에 L3/L4 방화벽(NACL·SG: 통과 여부)을 얹고 → 최종적으로 L7 서비스(웹·SSH)가 그 길 위에서 동작합니다. 계층을 쌓는 순서가 곧 구축 순서와 닮아 있습니다.

---

한눈에 보는 구축 순서 요약

1. VPC               (땅 = 주소 공간)              L3
2. Subnet ×2         (구역: 공개/비공개)            L3
3. Internet Gateway  (정문: 외부 연결)              L3
4. Route Table ×2    (이정표 → 퍼블릭/프라이빗 결정)  L3
5. Network ACL       (구역 경비, Stateless)         L3+L4
6. Security Group ×2 (현관 도어맨, Stateful)         L3+L4
7. EC2 ×2            (서버 입주)                    L1~L7
8. NAT GW + EIP      (내부인 전용 외출 창구)         L3+L4
9. Private-RT 경로    (NAT로 가는 이정표 추가)        L3
10. 검증             (흐름 확인: ping/curl/SSH)      L7