카테고리 없음

[네트워크]_AWS를 통한 네트워크 구조 이해

코딩연습중 2026. 2. 15. 15:38

 

Private/Public IP, Subnet에 대한 이해가 조금 어려워서 AWS를 예시로 이해해봤다.

 

 

예를 들어 내가 A 웹 서비스를 개발해서 EC2 인스턴스에 배포하려고 할 때, 가장 먼저 해야할 것은 VPC를 만들고 내가 사용할 사설 IP 대역(CIDR 블록)을 정하는 것이다.

여기서 중요한 포인트는 “사설 IP를 하나 할당받는다”가 아니라, 사설 IP ‘대역’을 내가 설정한다는 느낌이다.
예를 들어 VPC를 이렇게 만든다고 하자.

  • VPC CIDR: 10.0.0.0/16

이 뜻은 “나는 10.0.0.0부터 10.0.255.255까지의 사설 IP 공간을 내 네트워크로 쓰겠다”는 의미다.
(이 CIDR(/16)은 AWS가 정해주는 게 아니라 내가 선택/설정한다.)

그리고 AWS에서 어떤 서비스를 이용하든, VPC 내부에서는 이 사설 IP 대역을 기반으로 네트워크가 구성된다.

서브넷을 나누는 이유 (Public / Private 분리)

내 DB는 private하게 올려서 외부에서는 접근할 수 없게 하고,
내 서비스는 외부 사용자가 접근할 수 있도록 하고 싶다면, 서브네팅으로 네트워크 대역을 나눠서 “구역”을 분리한다.

예를 들어 /16 전체를 두 개의 서브넷으로 나눠보면:

  • Public Subnet: 10.0.1.0/24
  • Private Subnet: 10.0.2.0/24

여기서 10.0.1.0/24, 10.0.2.0/24 자체가 public/private인 건 아니고,
같은 사설 IP 대역 안에서 역할별로 구역을 나눈 것이라고 보면 된다.

그럼 “대체 public subnet / private subnet은 뭐가 다른데?”가 남는다.

public subnet이 public이 되는 기준: 라우팅(길)

여기서 헷갈렸던 게, IP처럼 public/private가 대역으로 딱 정해져있는 게 아니라는 점인데,
AWS에서 public subnet / private subnet은 주소 모양이 아니라 라우팅 테이블(어디로 나가는 길이 있냐)로 결정된다.

즉,

  • Public Subnet: 0.0.0.0/0 → IGW 라우트가 있음
  • Private Subnet: 0.0.0.0/0 → IGW 라우트가 없음 (보통 NAT로 감)

정리하면,

 

“public subnet”은 인터넷으로 나갈 수 있는 출구(IGW)로 가는 길이 열려있는 서브넷이다.

IGW

여기서 IGW(Internet Gateway)를 “등록”이라는 느낌으로 이해했었는데,
정확히는 VPC와 인터넷을 연결해주는 출입구/통로라고 보면 된다.

  • IGW를 만든다
  • IGW를 VPC에 연결(attach)한다

이건 “내 VPC가 인터넷과 연결될 수 있는 문을 만든다”는 느낌이다.
하지만 IGW만 붙인다고 외부가 자동으로 내 서비스를 찾는 건 아니고,
어떤 서브넷이 IGW로 나갈지(라우팅 테이블)를 따로 지정해줘야 한다.

그래서 Public Subnet 쪽 라우팅 테이블에:

  • 0.0.0.0/0 → IGW

이걸 넣어주면 “이 서브넷은 인터넷으로 나갈 때 IGW로 나가라”가 된다.

여기까지가 public subnet “길 뚫기” 느낌임!

그럼 외부에서 내 EC2로 바로 접속 가능해질까?

아니다. 아직은 길만 뚫린 상태고, 외부에서 실제로 접속 가능하려면 추가 조건이 필요하다.

 

EC2에 Public IP(또는 Elastic IP)가 있어야 한다

  • EC2는 기본적으로 Private IP는 무조건 받음(10.0.x.x)
  • Public IP는 옵션으로 추가로 붙는 개념

Security Group에서 인바운드를 열어야 한다

  • 예: HTTP(80), HTTPS(443), SSH(22) 등
  • 안 열면 길이 있어도 못 들어옴

그래서 public subnet + public ip + security group 인바운드 허용이 되면
외부 사용자가 내 서비스에 접근할 수 있게 된다.

그리고 IP가 고정이어야 하면 EIP(탄력적 IP)를 발급해서 EC2에 연결하면 된다.

만약 DB나 WAS를 private하게 두고 싶다면?

DB나 내부 WAS처럼 외부에서 직접 접근하면 안 되는 애들은 Private Subnet에 둔다.

Private Subnet은 기본적으로

  • 0.0.0.0/0 → IGW 라우트가 없음
  • 그래서 인터넷과 직접 연결이 안 됨
  • 즉 외부에서 먼저 들어오는 요청을 직접 받을 수 없음

여기까지가 private subnet이 private인 이유다.

근데 문제는:
private subnet에 있는 애들도 외부 API 호출(결제 API, 지도 API 등)은 해야함.
즉, “외부에서 들어오는 건 막되, 내부에서 나가는 건 허용”이 필요함.

이럴 때 쓰는 게 NAT이다.

 

NAT란?

사설 IP를 공인 IP로 변환해서 외부 네트워크와 통신할 수 있도록 해주는 기술

 

AWS에서는 보통 NAT Gateway를 사용한다.

여기서 내가 처음에 착각했던 부분이 있는데,
“NAT Gateway에 서비스를 올린다”가 아니라,

✅ NAT Gateway는 서비스를 호스팅하는 곳이 아니라 ‘트래픽 변환기’다.

 

NAT Gateway는 Public Subnet에 둔다.
그리고 NAT Gateway는 공인 IP(EIP)를 하나 가진다.

구조는 이런 느낌:

  • Private Subnet의 EC2(예: 10.0.2.15)가 인터넷으로 나가려 함
  • Private Subnet 라우팅 테이블에 0.0.0.0/0 → NAT Gateway 설정
  • 그러면 인터넷으로 나가는 트래픽은 NAT Gateway로 감
  • NAT Gateway가 출발지 IP를 자기 공인 IP로 바꿔서 IGW를 통해 인터넷으로 보냄
  • 응답은 다시 NAT로 돌아오고, NAT가 원래의 private EC2로 전달

즉,

Private Subnet은 IGW로 직접 나가는 게 아니라 NAT를 거쳐서 나간다.

근데 왜 외부에서는 private subnet으로 접근이 안 될까?

보면 NAT는 그냥 트래픽 변환기일 뿐이지, 외부 접근을 ‘막는 장치’는 아닌데,,

그리고 외부에서 접근이 안 된다면, 만약 db에서 외부 api 호출 후 응답을 받을 때 어떻게 그게 가능할까?

 

 

NAT의 동작 원리

핵심은, NAT는 “내부에서 먼저 시작된 연결”만 기억하고 변환해준다는 것이다.

 

🌐 내부 → 외부 요청

Private EC2 (10.0.2.15)가 외부 API 서버(1.2.3.4)에 요청을 보낸다고 해보자.

  1. EC2 → NAT로 패킷 보냄
    출발지: 10.0.2.15
    목적지: 1.2.3.4
  2. NAT가 출발지 IP를 자기 공인 IP로 바꿈
    출발지: 3.100.200.10
    목적지: 1.2.3.4
  3. 인터넷으로 나감

이때 NAT는 내부에 이런 걸 저장함:

 
3.100.200.10:포트 → 10.0.2.15:포트
 
 

즉, “이 연결은 내부 EC2가 시작한 것”이라고 기억해둠

 

외부에서 요청이 “먼저” 들어오면, NAT는 그걸 내부의 어떤 EC2로 전달해야 할지 모른다.
(NAT는 기본적으로 “내부에서 먼저 나간 요청의 응답”만 다시 돌려보내는 구조라서)

그래서 결과적으로,

  • Private Subnet의 EC2는 외부로 “나갈 수는” 있지만
  • 외부에서 “직접 들어오는” 건 불가능하게 유지된다.

이게 private subnet + NAT의 핵심 목적임!

 

 

그럼 AWS에서 외부에서 Private EC2 접근하려면?

방법은 3가지

  1. Bastion Host
  2. ALB/NLB 같은 Load Balancer
  3. 포트포워딩 (AWS NAT Gateway는 지원 안 함)

AWS NAT Gateway는
포트포워딩 기능이 없다.

그래서 Private Subnet은 기본적으로 외부에서 직접 접근 불가.

 

이는 따로 블로그를 작성해보겠다.

Security Group / NACL은 어디서 역할이 갈리냐?

  • Security Group: 인스턴스 단위, Stateful
    • 내가 가장 자주 만지는 규칙 (인바운드/아웃바운드)
    • 요청을 허용하면 응답은 자동 허용
  • NACL: 서브넷 단위, Stateless
    • 추가적인 방어선
    • 인바운드/아웃바운드 각각 허용해줘야 함

대부분은 SG로 해결하고, 필요하면 NACL로 한 번 더 제어한다고 보면 된다.

정리하자면,

  1. VPC에서 사설 IP “대역”을 정한다 (예: 10.0.0.0/16)
  2. 그 대역을 서브넷으로 나눈다 (public/private 용도 분리)
  3. public subnet은 라우팅 테이블로 IGW로 나가는 길을 만든다
  4. public subnet에 EC2를 두고 public ip + sg 설정하면 외부 접근 가능
  5. private subnet은 IGW 직접 연결 없이 NAT를 통해 외부로만 나가게 만든다
  6. 그래서 DB/WAS 같은 건 private에 두고, 외부 노출은 막으면서도 외부 API 호출은 가능하게 만든다

우선 다음 글에서 AWS로 직접 실습을 해보겠다.