1. NAT 종류·위치 확인 (Gateway vs Instance)

  • NAT Gateway라면
    • 퍼블릭 서브넷에 있어야 하고, 그 서브넷 라우팅 테이블의 0.0.0.0/0는 Internet Gateway(IGW) 를 가리켜야 합니다.
    • NAT Gateway에 Elastic IP가 반드시 연결되어 있어야 합니다.
  • NAT Instance라면
    • 퍼블릭 서브넷에 있고, EIP 또는 Public IP를 가져야 하며, Source/Dest Check 비활성화, 보안 그룹·라우트 구성이 필요합니다.

2. 서브넷 / 라우팅 연관 상태

  • “라우팅 테이블은 오케이”라고 하셨으니 추가로:
    • private 서브넷이 정말 그 라우팅 테이블에 연관(Subnet associations) 되어 있는지 확인.
    • NAT Gateway와 EC2가 같은 AZ에 있는지 확인 (다른 AZ NAT을 타고 가도 되긴 하지만, 잘못된 설정이 없는지 체크).

3. 보안 그룹(Security Group) 설정

  • EC2 인스턴스 SG:
    • 아웃바운드에 0.0.0.0/0, TCP 80/443 등 필요한 포트가 허용되어 있는지.
  • NAT Instance를 쓰는 경우:
    • NAT 인스턴스 SG 인바운드가 private subnet CIDR 또는 EC2 SG에서 오는 트래픽을 허용하는지 확인.
  • NAT Gateway는 SG를 직접 붙일 수 없으니, NAT가 위치한 퍼블릭 서브넷에 붙은 NACL만 영향 줍니다.

4. 네트워크 ACL(NACL) 확인

  • private 서브넷과 NAT가 있는 퍼블릭 서브넷 둘 다:
    • 인바운드/아웃바운드에 Ephemeral Port(1024–65535) 와 80/443이 허용돼 있는지.
    • 0.0.0.0/0을 막는 규칙이 없는지 확인 (특히 커스텀 NACL 사용하는 경우 자주 막힘).

5. NAT / IGW 상태와 로그 확인

  • NAT Gateway 상태가 Available인지, 실패 상태가 아닌지 콘솔에서 확인.
  • VPC Flow Logs를 private 서브넷에 켜서, 외부 IP로 나가는 트래픽이 NAT까지 도달하는지, REJECT 되는지 확인.
  • NAT Instance일 경우, 직접 SSH 접속해서 curl https://www.google.com 등으로 NAT 자체의 인터넷 접속 여부를 먼저 확인합니다.

 

 

이 모~~~든걸 확인하고 또 확인했는데도 아웃바운딩이 되지 않았다.

 

그러다가 찾게 된 원인!!!!!

 

 

가용성 모드 리전별 / 영역별 (Regional / Zonal) 선택이 관건이었다.

 

 

 

 

설명으로는 가용성 NAT은 더 범용? 범위로 쓸 수 있어 고효율적이라고 되어있었는데...

 

실제로는 영역별 NAT을 선택해야 해당 서브넷에 연결이 되어 아웃바운딩이 될 수 있었음 아나

+ Recent posts