Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- Ajax
- TDD
- Transaction
- 전전긍긍
- AOP
- index
- 커뮤니티서버
- 공통규약
- 공통기술
- 사면초가
- OOP
- MVC요청플로우
- springsecurity
- DDD
- 단위테스트
- 로그백
- 냄새라도
- 디스크i/o
- 클린아키텍처
- model
- 이벤트핸들러this
- 설정세팅
- SEQUENCE
- 이벤트핸들러등록
- JDBC
- MVC
- JPA
- 문제선택근거
- string
- SpringLegacy
Archives
- Today
- Total
개발이군고구마
[AWS Networking] VPC &Subnet 본문
728x90
1. 개념 학습
1-1. OSI 7계층과 AWS VPC
AWS 에서 디폴트 vpc를 ec2에 부여함
1-2. Subnet(Public/Private) 참고자료

- Base IP
- public ip
- private ip
can only allow certain values- 10.0.0.0/8 (in big networks)
- 172.16.0.0/12 (AWS default VPC)
- 192.168.0.0/16 (home)
- Subnet
서브넷, 즉 서브네트워크는 네트워크 내부의 네트워크
각 서브넷은 고유한 IP 주소 범위를 가지게 된다.

👽 왜 필요할까?
- 서브넷은 IP 주소를 장치 범위 내에서 사용하도록 좁혀준다.
- IP 주소는 네트워크 및 장치 주소를 나타내는 것으로 제한되므로 IP 주소를 사용하여 IP 패킷이 이동해야 하는 서브넷을 나타낼 수는 없음
- 네트워크 내의 라우터는 서브넷 마스크라는 것을 사용하여 데이터를 하위 네트워크로 정렬
- Subnet Mask
- 네트워크 내에서 내부적으로만 사용
- 해당 서브넷 내에 포함된 IP 주소의 수를 정의하는 숫자
- IP 주소의 어떤 부분이 네트워크를 나타내고 어떤 부분이 장치를 나타내는지를 결정
- IP 안에서 얼마나 많은 비트들이 변경될 것이냐를 나타냄
- 라우터는 서브넷 마스크를 사용하여 데이터 패킷을 올바른 위치로 라우팅
- 장치가 다른 장치와 동일한 네트워크에 있는지 아니면 다른 네트워크에 있는지를 판단할 수 있게 해준다.
- IP 주소와 서브넷 마스크가 결합될 때, 결과는 해당 네트워크 내의 고유한 네트워크와 고유한 장치를 식별
1- 3. Subnet 표기법
- CIDR 표기법
ㄴIP 주소 뒤에 슬래시('/')와 서브넷 마스크의 '1' 비트 수가 포함- 서브넷 마스크가 '255.255.255.0'인 '192.168.1.0' IP 주소는 '192.168.1.0/24'로 표현
- 32를 기준으로 "/x" 처음 x 비트가 네트워크 주소로 사용되고 32-x가 호스트 주소로 남는다는 것
- 서브넷 마스크 표기법
ㄴ서브넷 마스크를 IP 주소와 유사한 네 개의 옥텟으로 표현- 256개의 호스트 주소(사용 가능한 254개)를 허용하는 서브넷 마스크는 '255.255.255.0'으로 표현
1- 4. Internet Gateway
- VPC 안에 있는 리소스 (eg EC2) 가 인터넷에 연결되도록 허용함 (=VPC에 인터넷 엑세스를 제공)
- VPC와는 별개로 생성되어야 하며, VPC 1 : IGW 1 (1:1 연결)
- 그 자체는 인터넷 엑세스를 허용하지 않음 -> 라우팅 테이블 수정해야함
-

VPC에 별도로 IGW -> VPC의 라우팅 테이블이 정의되고 -> 라우터를 통해서 인터넷 연결 - [outbound] EC2 → 서브넷 → 라우팅 테이블 → IGW(VPC에 attach)
- [inboubnd] Internet → IGW(VPC에 attach) → 라우팅 테이블(0.0.0.0/0 → igw-xxxx) → 서브넷 → EC2(public ip)
👽 왜 필요할까?
- 인터넷을 쓰는 리소스와 인터넷과 완전히 분리된 리소스를 명확히 나누기 위해서
=> 사설 IP(10.x, 172.x, 192.x)로 직접 접근 불가 - IGW는:
- VPC라는 사설 네트워크 (=완전히 폐쇄된 사설 네트워크) 와 연결해주는 공식 출입구이자 주소 변환기
- Public IP ↔ Private IP 매핑 역할을 함
- EC2의 실제 IP: 10.0.1.5 / 인터넷에서 쓰는 주소: 54.xxx.xxx.xxx
- 54.xxx.xxx.xxx ⇄ 10.0.1.5
- Routing Table
- 어디로 보낼지 적힌 규칙표
- 서브넷에 라우팅 테이블을 연결
- 0.0.0.0/0 → igw-1234 "인터넷으로 가는 트래픽은 IGW로 보내"
- 예, 모든 IP -> IGW (즉, 모든 요청이 EC2에 접근할 수 있음)
1- 5.NAT Gateway
ㄴNAT Gateway는 “밖으로만 나가는" 일방통행 문
- Publiuc subnet / Private Subnet
- 구분기준
Public Subnet Routing Table에 0.0.0.0/0 → IGW Private Subnet 위 경로 없음 (보통 NAT Gateway로만 연결)
- 구분기준
- Private subnet 안에서 EC2가 인터넷에 접속하도록 함
- 외부에서 접근은 절대 안되고, Outbound only
- [EC2-outbound] 0.0.0.0/0 → nat-xxxx
- [전체흐름] Private EC2 → NAT Gateway → IGW → Internet
- NAT Gateway는 혼자서 인터넷 절대 못나감
- 반드시 Public Subnet에 있어야 하며, 그 서브넷 라우팅 테이블에
- 0.0.0.0/0 → IGW
- 외부에서 접근은 절대 안되고, Outbound only
👽 왜 필요할까?
- “인터넷은 위험하다. 기본은 차단, 필요한 것만 연다.”
- ✅ IGW + Public Subnet : 외부 요청을 직접 받는다
- ALB / NLB
- Bastion Host
- CDN Origin (필요한 경우)
- ✅ NAT Gateway + Private Subnet : 외부에 노출될 필요 없는 서버
- Spring / Node / Python 서버
- Worker / Batch
- DB (외부 접근 차단)
- ✅ IGW + Public Subnet : 외부 요청을 직접 받는다
2. VPC 구조 분석

▶ 요청이 들어오는 흐름 (사용자 -> 서버)
사용자 브라우저
│
▼
DNS 조회 (api.example.com)
│
▼
ALB (로드밸런서)
│
│ 어떤 EC2가 살아있는지 확인
│
▼
Target Group
│
▼
EC2 서버 선택
│
▼
EC2의 ENI private IP
▶ 요청이 나가는 흐름 (서버 -> 인터넷)
EC2 (private subnet)
│
▼
NAT Gateway
│
▼
Internet
▶ 네트워크 내부 구조
AWS Cloud
┌───────────────────────────────────────────┐
VPC
(예: 10.0.0.0/16)
┌──────────────┐ ┌──────────────┐
│ PublicSubnet │ │ PublicSubnet │
│ 10.0.1.0/24 │ │ 10.0.2.0/24 │
│ │ │ │
│ ALB │ │ NAT Gateway │
│ │ │ │
└───────┬──────┘ └───────┬──────┘
│ │
│ │
┌───────▼──────────────────▼───────┐
│ Private Subnet │
│ 10.0.10.0/24 │
│ │
│ EC2 (10.0.10.5) ENI │
│ EC2 (10.0.10.6) ENI │
│ │
└──────────────────────────────────┘
│
▼
Internet Gateway
│
▼
Internet
└───────────────────────────────────────────┘
-------------------------------------------
EC2 Instance
│
│ attach
▼
+-------------------+
| ENI (eth0) |
| |
| private IP |
| 10.0.10.5 |
| |
| security group |
+-------------------+'Cloud Deploy' 카테고리의 다른 글
| [AWS Networking] DNS와 보안 (Route53 & Security) (0) | 2026.01.27 |
|---|---|
| [AWS Networking] 로드밸런싱의 모든 것ELB (0) | 2026.01.24 |
| [멱살잡고 DevOps] 9. Terraform 및 CodeDeploy를 사용하여 dev/prod 서버 분리와 green/blue 배포 (0) | 2025.08.12 |
| [멱살잡고 DevOps] 8. 확장성 고민과 ESC 적용 (0) | 2025.07.29 |
| [멱살잡고 DevOps] 7. DNS 설정 및 테스트 (트러블 슈팅🎯) (0) | 2025.07.26 |
