사전 NAT 게이트웨이
구현체

NAT 게이트웨이

gabury1고친 사람 github-actions[bot]

NAT 게이트웨이는 인터넷 주소가 없는 서버가 인터넷으로 나갈 수 있게 길을 내 줍니다. 아마존 클라우드가 대신 운영하는 주소 변환 장치입니다. 안에서 바깥으로 거는 연결은 통과시키고 바깥에서 먼저 거는 연결은 받지 않습니다.

쉽고 빠른 이해

NAT 게이트웨이는 바깥에 직접 나갈 수 없는 서버들의 대리 창구입니다. 데이터베이스 곁에 숨겨 둔 서버가 보안 패치를 내려받을 때, 요청을 대신 들고 나갔다가 응답을 받아 돌려줍니다.

중요한 서버는 인터넷에서 아예 찾아올 수 없는 구역에 둡니다. 그런데 그 서버도 패치를 받고 외부 서비스를 불러야 합니다. 들어오는 쪽은 막아 둔 채 나가는 쪽만 열어 주는 장치가 필요합니다.

어떻게 도나:

  1. 서버가 바깥으로 보낼 패킷을 NAT 게이트웨이에 넘깁니다
  2. NAT 게이트웨이가 보낸 쪽 주소를 자기 주소로 바꿔 적습니다
  3. 인터넷으로 나가는 문에서 그 주소가 바깥에서 통하는 주소 하나로 한 번 더 바뀝니다
  4. 응답이 오면 거꾸로 되짚어 원래 서버에 건네줍니다

대가가 있습니다. 켜 둔 시간만큼, 지나간 데이터 양만큼 요금이 붙습니다. 트래픽이 많은 서비스에서는 이 요금이 빠르게 불어납니다. 그래서 바깥에 나갈 일이 없는 서버나 같은 클라우드 안의 저장소로만 가는 서버에는 두지 않습니다.

상세

이 절은 NAT 게이트웨이를 다섯 갈래로 봅니다. 왜 따로 나가는 경로가 필요한지, 인터넷 게이트웨이와 무엇이 다른지, 공인 주소를 주는 쪽과 견주면 무엇을 얻는지, 요금이 왜 자주 놀라움이 되는지, 언제는 없어도 되는지입니다. 결제 서버 한 대가 외부 결제 대행사를 부르는 장면을 줄곧 예로 씁니다.

인터넷에서 기기를 찾아가는 IP 주소(Internet Protocol address, 인터넷 프로토콜 주소)에는 두 종류가 있습니다. 공인 주소는 인터넷 어디서나 찾아갈 수 있는 주소입니다. 사설 주소는 회사나 집 같은 한 네트워크 안에서만 통하는 주소입니다. 인터넷의 라우터들은 사설 주소 앞으로 가는 패킷을 넘겨 주지 않습니다.

NAT(Network Address Translation, 네트워크 주소 변환)는 패킷이 네트워크 경계를 지날 때 그 안에 적힌 주소를 바꿔 적는 일입니다. 사설 주소만 가진 기기도 NAT 를 거치면 공인 주소를 빌려 인터넷에 나갈 수 있습니다.

집 공유기가 하는 일이 이것입니다. 집 안 기기들은 사설 주소만 받고 나갈 때 공유기의 공인 주소 하나를 다 같이 빌려 씁니다. 바깥에서 먼저 걸어오는 연결은 막힙니다. 공유기는 포트포워딩으로 이 막힘을 열 수 있지만 NAT 게이트웨이에는 그렇게 여는 설정이 없습니다.

NAT 게이트웨이는 이 일을 AWS(Amazon Web Services, 아마존 웹 서비스)가 운영하는 장치에 맡기는 서비스입니다. 장비를 설치하지 않고 만들기만 하면 됩니다.

이 장치가 놓이는 곳은 VPC(Virtual Private Cloud, 가상 사설 클라우드)입니다. VPC 는 AWS 안에 내 몫으로 떼어 받은 가상 네트워크입니다. 서버는 이 안에서 사설 주소를 받습니다. 바깥과 오가는 경로는 내가 정해 줍니다.

공개 서브넷과 사설 서브넷

VPC 는 다시 서브넷으로 나뉩니다. 서브넷은 주소 범위를 잘게 떼어 낸 구역입니다. 서브넷마다 라우팅 테이블이 붙어, 이 구역에서 나가는 패킷을 어디로 보낼지 정합니다.

VPC 를 인터넷과 잇는 문은 인터넷 게이트웨이입니다. 라우팅 테이블에 「바깥 주소는 전부 인터넷 게이트웨이로」라는 줄이 있는 서브넷을 공개 서브넷이라고 부릅니다. 그 줄이 없는 서브넷이 사설 서브넷입니다.

공개 서브넷의 서버가 인터넷과 이야기하려면 그 서버 몫의 공인 주소가 하나 있어야 합니다. 서버 자신은 여전히 사설 주소만 압니다. 패킷이 인터넷 게이트웨이를 지날 때 인터넷 게이트웨이가 사설 주소를 그 서버 몫의 공인 주소로 바꿔 적습니다. 웹 서버나 로드 밸런서처럼 바깥 손님을 받아야 하는 것이 공개 서브넷에 섭니다.

데이터베이스와 결제 서버처럼 바깥 손님을 받을 일이 없는 것은 사설 서브넷에 둡니다. 이 구역에는 인터넷에서 들어올 경로가 없습니다. 주소를 알아도 거기까지 가는 경로가 없습니다.

사설 서브넷 서버가 나가는 경로가 따로 필요한 이유

사설 서브넷의 서버도 바깥에 나갈 일은 많습니다. 운영체제 보안 패치와 라이브러리 패키지를 내려받습니다. 외부 API(Application Programming Interface, 응용 프로그램 인터페이스)도 부릅니다. 결제 서버라면 결제 대행사의 서버를 불러야 일이 됩니다.

그런데 이 서버에는 공인 주소가 없습니다. 출발지가 사설 주소인 패킷은 인터넷으로 나가도 응답이 돌아올 길이 없습니다. 앞서 본 대로 인터넷의 라우터들이 사설 주소로는 패킷을 넘겨 주지 않기 때문입니다.

그래서 사설 서브넷 쪽에 「나가는 패킷은 NAT 게이트웨이로」라는 줄을 둡니다. NAT 게이트웨이는 출발지 주소를 자기 주소로 바꿔 인터넷 게이트웨이에 넘깁니다. 인터넷 게이트웨이가 그 주소를 NAT 게이트웨이 몫의 공인 주소로 한 번 더 바꿔 내보냅니다. 응답은 같은 경로를 거꾸로 밟아 서버에 돌아옵니다. 들어오는 경로는 여전히 없습니다.

인터넷 게이트웨이와 무엇이 다른가

둘 다 VPC 에서 인터넷으로 가는 길목입니다. 갈리는 것은 누구를 위한 통로이고 어느 방향을 여느냐입니다.

인터넷 게이트웨이 NAT 게이트웨이
쓰는 서버 공인 주소를 가진 서버 공인 주소가 없는 서버
놓이는 곳 VPC 에 붙는다 공개 서브넷 안에 만든다
방향 양방향. 바깥에서 먼저 걸어올 수 있다 나가기만. 바깥에서 먼저 거는 연결은 못 들어온다
주소 서버마다 그 서버 몫의 공인 주소 하나로 바꿔 적는다 서버 여럿이 공인 주소 하나를 함께 쓴다

둘은 겨루는 사이가 아니라 이어지는 사이입니다. NAT 게이트웨이도 결국 인터넷 게이트웨이를 지나 인터넷에 닿습니다. 그래서 NAT 게이트웨이는 사설 서브넷이 아니라 공개 서브넷에 만듭니다.

flowchart TD
    I["인터넷"]
    subgraph V["VPC"]
        G["인터넷 게이트웨이"]
        subgraph PUB["공개 서브넷"]
            N["NAT 게이트웨이 · 탄력적 IP"]
        end
        subgraph PRI["사설 서브넷"]
            A["결제 서버 · 사설 주소만"]
        end
    end
    A -->|"사설 서브넷 라우팅 · 바깥 주소는 전부 NAT 게이트웨이로"| N
    N -->|"공개 서브넷 라우팅 · 바깥 주소는 전부 인터넷 게이트웨이로"| G
    G --> I

결제 서버는 사설 서브넷에 있습니다. NAT 게이트웨이는 공개 서브넷에 있습니다. 화살표마다 붙은 글은 그 서브넷 라우팅 테이블의 줄입니다. 결제 서버가 보낸 요청은 두 줄을 차례로 따라 NAT 게이트웨이를 거쳐 인터넷 게이트웨이로 나갑니다. 그림의 탄력적 IP 는 바로 아래 소절에서 풉니다.

패킷이 나갔다 돌아오는 순서

NAT 게이트웨이를 만들 때 탄력적 IP를 하나 붙입니다. 탄력적 IP 는 AWS 계정이 붙잡아 두는 고정 공인 주소입니다. 서버를 지웠다 다시 만들어도 이 주소는 바뀌지 않습니다.

주소는 두 번 바뀝니다. 먼저 NAT 게이트웨이가 결제 서버의 사설 주소를 자기 사설 주소로 바꿉니다. 그다음 인터넷 게이트웨이가 그 주소를 NAT 게이트웨이에 붙은 탄력적 IP 로 바꿉니다. 결제 서버 사설 주소를 10.0.2.15, NAT 게이트웨이 사설 주소를 10.0.1.20, 탄력적 IP 를 203.0.113.7 로 두고 봅니다.

sequenceDiagram
    participant S as 결제 서버
    participant N as NAT 게이트웨이
    participant G as 인터넷 게이트웨이
    participant X as 결제 대행사
    S->>N: 출발지 10.0.2.15
    N->>G: 출발지 10.0.1.20 으로 바꿔 넘긴다
    G->>X: 출발지 203.0.113.7 로 바꿔 내보낸다
    X-->>G: 203.0.113.7 앞으로 응답
    G-->>N: 10.0.1.20 앞으로 되돌린다
    N-->>S: 10.0.2.15 앞으로 되돌린다
    Note over X,N: 결제 대행사가 먼저 거는 연결은 받지 않는다

결제 대행사의 눈에는 요청이 203.0.113.7 에서 온 것으로 보입니다. 사설 서브넷 서버가 몇 대든 바깥에는 이 주소 하나만 보입니다.

여러 서버가 주소 하나를 같이 쓰므로 NAT 게이트웨이는 포트 번호도 바꿔 적어 연결을 구별합니다. 어느 서버의 어느 연결이 어느 포트로 나갔는지 표에 적어 둡니다. 응답이 오면 그 표를 보고 되돌립니다. 표에 없는 패킷, 바깥에서 먼저 걸어온 연결은 돌려줄 곳이 없어 들어오지 못합니다.

공인 주소를 주고 보안 그룹으로 막으면 안 되나

결제 서버에 공인 주소를 주고 공개 서브넷에 두어도 나갈 수는 있습니다. 들어오는 것은 보안 그룹으로 막으면 됩니다. 보안 그룹은 서버마다 붙이는 방화벽 규칙 묶음입니다. 어느 주소에서 어느 포트로 들어오는 연결을 받을지 적습니다.

그래도 사설 서브넷과 NAT 게이트웨이를 쓰는 데는 이유가 셋 있습니다.

첫째는 방어가 두 겹이 된다는 것입니다. 공인 주소를 가진 서버는 보안 그룹 규칙 한 줄만 잘못 열어도 인터넷에 드러납니다. 사설 서브넷의 서버는 규칙이 잘못 열려도 들어올 경로가 아예 없습니다. 이렇게 한 겹이 뚫려도 다른 겹이 막게 짜는 것을 심층 방어라고 부릅니다.

둘째는 나가는 주소가 하나로 고정된다는 것입니다. 결제 대행사는 흔히 「미리 알려 준 주소에서 오는 요청만 받는다」는 허용 목록을 둡니다. 서버마다 공인 주소가 따로 있으면 서버를 늘릴 때마다 대행사에 새 주소를 알려야 합니다. NAT 게이트웨이 뒤에 두면 서버를 몇 대로 늘리든 알릴 주소는 탄력적 IP 하나입니다.

셋째는 공인 IPv4(Internet Protocol version 4, 인터넷 프로토콜 버전 4) 주소의 수입니다. IPv4 주소는 모자란 자원입니다. 서버 쉰 대가 저마다 공인 주소를 쥐면 주소가 쉰 개 듭니다. 사설 서브넷에 두면 NAT 게이트웨이의 주소 하나로 나갑니다.

보안 그룹을 달 수 없다

NAT 게이트웨이 자신에는 보안 그룹을 붙일 수 없습니다. 드나드는 것을 거르려면 두 군데를 씁니다. 하나는 뒤에 있는 서버들의 보안 그룹이고, 다른 하나는 NAT 게이트웨이가 놓인 서브넷의 네트워크 ACL(Access Control List, 접근 제어 목록)입니다.

네트워크 ACL 은 서브넷 단위로 드나드는 패킷을 거르는 규칙입니다. NAT 게이트웨이는 바깥으로 연결을 열 때 1024 부터 65535 까지의 포트를 씁니다. 네트워크 ACL 로 NAT 게이트웨이 쪽 트래픽을 막을 때는 이 범위를 열어 두어야 응답이 돌아옵니다.

가용 영역마다 하나씩 둔다

AWS 의 한 지역은 가용 영역 여럿으로 나뉩니다. 가용 영역은 전기와 네트워크를 따로 쓰는 데이터센터 묶음이라, 한 곳이 멈춰도 다른 곳은 돕니다.

NAT 게이트웨이는 기본으로 가용 영역 하나를 골라 그 안에 만듭니다. 그 영역 안에서는 AWS 가 이중화를 해 둡니다. 다만 영역 자체가 멈추면 그 NAT 게이트웨이도 멈춥니다.

서버는 여러 가용 영역에 퍼져 있는데 NAT 게이트웨이가 하나뿐이라고 해 봅니다. 그 영역이 멈추면 다른 영역의 서버들까지 인터넷을 잃습니다. 아래 그림에서 영역 경계를 건너가는 점선이 그 경로입니다.

flowchart TD
    subgraph A1["가용 영역 A"]
        N1["공개 서브넷 · NAT 게이트웨이"]
        S1["사설 서브넷 · 서버들"]
    end
    subgraph B1["가용 영역 B"]
        T1["사설 서브넷 · 서버들"]
    end
    S1 --> N1
    T1 -.->|"영역 경계를 건너간다"| N1

이를 피하려면 서버가 있는 가용 영역마다 NAT 게이트웨이를 하나씩 둡니다. 각 서브넷은 같은 영역의 것을 쓰게 라우팅을 짭니다. 그러면 모든 화살표가 제 영역 안에서 끝납니다.

flowchart TD
    subgraph A2["가용 영역 A"]
        N2["공개 서브넷 · NAT 게이트웨이 A"]
        S2["사설 서브넷 · 서버들"]
    end
    subgraph B2["가용 영역 B"]
        N3["공개 서브넷 · NAT 게이트웨이 B"]
        T2["사설 서브넷 · 서버들"]
    end
    G2["인터넷 게이트웨이"]
    S2 --> N2
    T2 --> N3
    N2 --> G2
    N3 --> G2

영역마다 만드는 수고를 덜어 주는 지역 단위 NAT 게이트웨이(regional NAT gateway)도 있습니다. 서버가 새 가용 영역에 생기면 그 영역으로 저절로 넓혀집니다. 서버가 없어진 영역에서는 물러납니다. 이 방식은 놓일 공개 서브넷을 따로 만들지 않아도 됩니다.

요금이 자주 놀라움이 되는 이유

NAT 게이트웨이 요금은 두 갈래로 붙습니다. 떠 있는 시간마다 붙는 요금과, 지나간 데이터 기가바이트마다 붙는 처리 요금입니다. 인터넷으로 나가는 데이터 전송 요금은 이와 따로 붙습니다.

요금 붙는 조건
시간 요금 만들어 둔 동안 내내. 트래픽이 하나도 없어도 붙습니다
처리 요금 NAT 게이트웨이를 지나간 데이터의 양만큼
데이터 전송 요금 처리 요금과 별도. 가용 영역을 넘나들어도 붙습니다

놀라움은 대개 처리 요금에서 옵니다. NAT 게이트웨이는 어디로 가는 패킷인지 가리지 않고 지나간 양을 셉니다. 사설 서브넷 서버가 같은 AWS 안의 Amazon S3(Simple Storage Service, 심플 스토리지 서비스)에 백업을 올려도, 그 경로가 NAT 게이트웨이를 지나면 처리 요금이 붙습니다.

이런 트래픽은 조용히 쌓입니다. 서버가 뜰 때마다 내려받는 컨테이너 이미지, 바깥 수집기로 보내는 로그, S3 에 올리는 백업 파일이 그렇습니다. 하나하나는 서비스 기능이 아니라서 설계할 때 셈에 안 들어갑니다.

시간 요금은 가용 영역 수만큼 곱해집니다. 앞 소절대로 영역마다 하나씩 두면 쓰지 않는 밤에도 그 수만큼 요금이 나갑니다. 반대로 하나만 두면 앞 소절 첫 그림의 점선처럼 다른 영역 서버들이 그쪽으로 건너옵니다. 이번에는 영역을 넘나드는 전송 요금이 붙습니다.

같은 목적지로 여는 연결에는 상한이 있다

NAT 게이트웨이는 주소 하나를 여러 서버가 나눠 쓰는 장치라, 포트 번호가 바닥나면 새 연결을 못 엽니다. 공인 주소 하나로 같은 목적지에 동시에 열 수 있는 연결은 5만 5천 개까지입니다. 이 셈에서 같은 목적지란 목적지 주소, 목적지 포트, 프로토콜 셋이 모두 같은 것입니다.

결제 대행사의 같은 주소와 같은 포트로 연결을 쉴 새 없이 새로 여는 서비스가 이 상한에 먼저 닿습니다. 이렇게 쓸 포트가 모자라 연결이 실패하는 것을 포트 고갈이라고 부릅니다. NAT 게이트웨이에 주소를 더 붙이면 주소 수만큼 상한이 늘어납니다. 연결을 재사용하는 커넥션 풀을 두면 새로 여는 연결 자체가 줄어듭니다.

사설 NAT 게이트웨이

지금까지의 NAT 게이트웨이는 인터넷으로 나가는 공개 방식입니다. 만들 때 고르는 다른 하나가 사설 방식입니다.

사설 NAT 게이트웨이에는 탄력적 IP 를 붙일 수 없습니다. 인터넷이 아니라 다른 VPC 나 회사 내부망으로 나갈 때 씁니다. 두 네트워크의 주소 범위가 겹칠 때 한쪽 주소를 바꿔 적어 부딪히지 않게 하는 용도입니다. 사설 NAT 게이트웨이의 트래픽을 인터넷 게이트웨이로 보내면 인터넷 게이트웨이가 버립니다. 사설 방식은 가용 영역 하나에 만드는 기본 방식으로만 씁니다. 지역 단위 NAT 게이트웨이로는 만들 수 없습니다.

NAT 게이트웨이가 필요 없는 때

서버가 바깥에 나갈 일이 전혀 없으면 필요 없습니다. VPC 안의 다른 서버하고만 이야기하는 내부 서비스가 그렇습니다.

가는 곳이 AWS 서비스뿐이면 VPC 엔드포인트로 대신합니다. VPC 엔드포인트는 VPC 안에서 AWS 서비스로 곧장 가는 전용 통로입니다. S3 로 가는 트래픽을 엔드포인트로 돌리면 NAT 게이트웨이를 지나지 않으므로 그 몫의 처리 요금이 빠집니다.

IPv6(Internet Protocol version 6, 인터넷 프로토콜 버전 6)로만 나가면 송신 전용 인터넷 게이트웨이를 씁니다. IPv6 에서는 주소가 넉넉해 주소를 바꿔 적을 까닭이 없습니다. 이 게이트웨이는 주소를 바꾸지 않고 나가는 연결만 통과시킵니다.

flowchart TD
    Q1{"서버가 VPC 바깥으로 나가야 하나"}
    Q1 -->|아니다| X1["NAT 게이트웨이 없이 둔다"]
    Q1 -->|그렇다| Q2{"가는 곳이 AWS 서비스뿐인가"}
    Q2 -->|그렇다| X2["VPC 엔드포인트"]
    Q2 -->|아니다| Q3{"IPv6 로만 나가나"}
    Q3 -->|그렇다| X3["송신 전용 인터넷 게이트웨이"]
    Q3 -->|아니다| X4["NAT 게이트웨이"]

남는 대안이 하나 더 있습니다. NAT 인스턴스는 Amazon EC2(Elastic Compute Cloud, 일래스틱 컴퓨트 클라우드) 인스턴스 한 대에 주소 변환을 맡기는 방식입니다. EC2 인스턴스는 AWS 에서 빌려 쓰는 가상 서버입니다. 처리 요금 없이 인스턴스 값만 냅니다.

NAT 게이트웨이 NAT 인스턴스
굴리는 쪽 AWS 내가 직접
요금 시간 요금 + 처리 요금 인스턴스 값
죽었을 때 가용 영역 안에서 AWS 가 이중화 내가 살리고 갈아 끼운다
대역폭 트래픽에 따라 저절로 늘어난다 고른 인스턴스 크기에 묶인다
보안 그룹 못 단다 단다

NAT 인스턴스는 돈을 아끼는 대신 패치와 장애 대응을 떠안습니다. 트래픽은 많아도 잠깐 끊기는 것은 견디는 개발 환경이라면 NAT 인스턴스 쪽이 맞기도 합니다.

맞물림

NAT 게이트웨이는 혼자서는 패킷 하나도 내보내지 못합니다. 누군가 패킷을 보내 주어야 합니다. 내보낸 뒤 이어 줄 문도 있어야 합니다. 아래 네 소절이 그 상대들입니다. 패킷을 보내 주는 라우팅 테이블, 뒤를 잇는 인터넷 게이트웨이와 탄력적 IP, 일을 덜어 가는 VPC 엔드포인트, 이 경로에 기대는 AWS Lambda 입니다.

라우팅 테이블이 패킷을 보낸다

NAT 게이트웨이는 만들어 두기만 해서는 아무 패킷도 받지 않습니다. 사설 서브넷의 라우팅 테이블에 「바깥 주소 전부(0.0.0.0/0)는 이 NAT 게이트웨이로」라는 줄을 넣어야 서버들의 패킷이 넘어옵니다.

가용 영역마다 NAT 게이트웨이를 두면 라우팅 테이블도 영역마다 따로 둡니다. 각 영역의 사설 서브넷이 제 영역의 NAT 게이트웨이를 가리켜야 하기 때문입니다. 이 줄을 하나 잘못 가리키면 장애 때 인터넷이 끊기거나, 평소에 영역을 넘나드는 전송 요금이 붙습니다.

인터넷 게이트웨이와 탄력적 IP 가 뒤를 잇는다

공개 NAT 게이트웨이는 받은 패킷을 다시 VPC 의 인터넷 게이트웨이로 넘깁니다. 그래서 NAT 게이트웨이가 놓인 공개 서브넷의 라우팅 테이블에는 인터넷 게이트웨이로 가는 줄이 있어야 합니다. 인터넷 게이트웨이가 없는 VPC 에서는 공개 NAT 게이트웨이를 만들어도 인터넷에 닿지 않습니다.

마지막 주소 변환은 인터넷 게이트웨이가 합니다. NAT 게이트웨이의 사설 주소를 그것에 붙은 탄력적 IP 로 바꿉니다. 탄력적 IP 는 NAT 게이트웨이를 만들 때 붙여야 합니다. 이 주소가 결제 대행사의 허용 목록에 적히는 값입니다. NAT 게이트웨이를 지웠다 다시 만들어도 같은 탄력적 IP 를 다시 붙이면 허용 목록을 고치지 않아도 됩니다.

VPC 엔드포인트가 AWS 서비스 몫을 덜어 간다

S3 로 가는 트래픽에 엔드포인트를 두면 라우팅 테이블이 그 트래픽만 엔드포인트로 보냅니다. 나머지 인터넷행 트래픽은 여전히 NAT 게이트웨이로 갑니다. 한 서버의 나가는 경로가 목적지에 따라 둘로 갈리는 셈입니다.

이렇게 가르면 NAT 게이트웨이의 처리 요금에서 AWS 서비스 몫이 빠집니다. 다만 엔드포인트는 서비스마다 하나씩 만들어야 합니다. 엔드포인트 종류에 따라서는 그 자체에도 요금이 붙으므로 트래픽 양과 견줘 고릅니다.

VPC 에 붙인 AWS Lambda 가 이 경로로 나간다

AWS Lambda 함수는 서버를 띄우지 않고 코드를 돌리는 서비스입니다. 데이터베이스에 닿으려고 함수를 VPC 에 붙이면, 함수는 그 VPC 서브넷의 사설 주소를 받습니다. 공인 주소는 받지 않으므로 공개 서브넷에 붙여도 인터넷에 나가지 못합니다.

그래서 VPC 에 붙인 함수가 외부 API 를 부르려면 함수를 사설 서브넷에 붙이고 그 서브넷이 NAT 게이트웨이로 나가게 합니다. 함수 하나 때문에 NAT 게이트웨이의 시간 요금이 새로 생기기도 합니다.

같은 얼개는 다른 클라우드에도 있습니다. GCP(Google Cloud Platform, 구글 클라우드 플랫폼)의 Cloud NAT, Azure 의 Azure NAT Gateway 가 사설 주소만 가진 서버를 바깥으로 내보내는 같은 일을 맡습니다.

관련 항목

NAT 게이트웨이가 속하는 상위 분류

NAT · 게이트웨이 · AWS · VPC · 관리형 서비스 · 클라우드 · 클라우드 네트워킹

NAT 게이트웨이를 둘러싼 VPC 구성 요소

서브넷 · 공개 서브넷 · 사설 서브넷 · 라우팅 테이블 · 인터넷 게이트웨이 · 탄력적 IP · 가용 영역 · 네트워크 ACL · 보안 그룹

NAT 게이트웨이가 바꿔 적는 주소와 번호

IP 주소 · 공인 IP 주소 · 사설 IP 주소 · IPv4 · IPv6 · 포트 · 변환 테이블 · 패킷

NAT 게이트웨이를 대신할 수 있는 다른 수단

NAT 인스턴스 · 지역 단위 NAT 게이트웨이 · VPC 엔드포인트 · 송신 전용 인터넷 게이트웨이 · 포워드 프록시 · Cloud NAT · Azure NAT Gateway

집 네트워크에서 NAT 게이트웨이와 같은 일을 하는 공유기 기능

공유기 · 포트포워딩

NAT 게이트웨이 뒤에서 바깥으로 나가는 AWS 서비스

Amazon EC2 · AWS Lambda · Amazon S3 · Amazon ECS · Amazon EKS · Amazon RDS

NAT 게이트웨이가 떠받치는 보안 원칙

심층 방어 · 최소 권한 원칙 · 허용 목록 · 방화벽 · 공격 표면

NAT 게이트웨이를 굴릴 때 터지는 문제

포트 고갈 · 단일 장애점 · 데이터 전송 요금 · 가용 영역 간 트래픽 · 비용 폭탄

다른 이름: NAT Gateway · AWS NAT Gateway · NAT GW