NAT Gateway 사용 사례 - Amazon Virtual Private Cloud
프라이빗 서브넷에서 인터넷 액세스허용 목록에 있는 IP 주소를 사용하여 네트워크에 액세스중첩되는 네트워크 간에 통신 사용

NAT Gateway 사용 사례

다음은 퍼블릭 및 프라이빗 NAT 게이트웨이의 사용 사례입니다.

프라이빗 서브넷에서 인터넷 액세스

퍼블릭 NAT 게이트웨이를 사용하여 프라이빗 서브넷의 인스턴스가 아웃바운드 트래픽을 인터넷으로 전송할 수 있도록 하는 동시에 인터넷이 인스턴스에 대한 연결을 설정하는 것을 방지할 수 있습니다.

개요

다음 다이어그램에서 이 사용 사례를 보여줍니다. 각 가용 영역에 2개의 서브넷이 있는 2개의 가용 영역이 있습니다. 각 서브넷에 대한 라우팅 테이블에 따라 트래픽이 라우팅되는 방법이 결정됩니다. 가용 영역 A에서 퍼블릭 서브넷의 인스턴스는 인터넷 게이트웨이에 대한 경로를 통해 인터넷에 연결할 수 있지만 프라이빗 서브넷의 인스턴스는 인터넷에 대한 경로가 없습니다. 가용 영역 B에서 퍼블릭 서브넷은 NAT 게이트웨이를 포함하고 프라이빗 서브넷의 인스턴스는 퍼블릭 서브넷의 NAT 게이트웨이 경로를 통해 인터넷에 연결할 수 있습니다. 프라이빗 및 퍼블릭 NAT 게이트웨이는 모두 인스턴스의 소스 프라이빗 IPv4 주소를 프라이빗 NAT 게이트웨이의 프라이빗 IPv4 주소에 매핑하지만, 퍼블릭 NAT 게이트웨이의 경우 인터넷 게이트웨이는 퍼블릭 NAT 게이트웨이의 프라이빗 IPv4 주소를 NAT 게이트웨이와 연결된 엘라스틱 IP 주소에 매핑합니다. 인스턴스에 응답 트래픽을 전송할 때 인스턴스는 퍼블릭 또는 프라이빗 NAT 게이트웨어 여부에 상관없이 NAT 게이트웨이는 주소를 원래 소스 IP 주소로 다시 변환합니다.

퍼블릭 및 프라이빗 서브넷이 있는 VPC, NAT 게이트웨이 및 인터넷 게이트웨이.

가용 영역 A의 프라이빗 서브넷에 있는 인스턴스도 인터넷에 연결해야 하는 경우 이 서브넷에서 가용 영역 B의 NAT 게이트웨이로 가는 경로를 생성할 수 있습니다. 또는 인터넷 액세스가 필요한 리소스가 포함된 각 가용 영역에 NAT 게이트웨이를 생성하여 복원력을 향상시킬 수 있습니다. 예시 다이어그램은 예시: 프라이빗 서브넷과 NAT에 서버가 있는 VPC 섹션을 참조하세요.

라우팅

다음은 가용 영역 A의 퍼블릭 서브넷과 연결된 라우팅 테이블입니다. 첫 번째 항목은 로컬 경로입니다. 서브넷의 인스턴스가 프라이빗 IP 주소를 사용하여 VPC의 다른 인스턴스와 통신할 수 있도록 합니다. 두 번째 항목은 다른 모든 서브넷 트래픽을 인터넷 게이트웨이로 전송하여 서브넷의 인스턴스가 인터넷에 액세스할 수 있도록 합니다.

대상 주소 대상
VPC CIDR 로컬
0.0.0.0/0 internet-gateway-id

다음은 가용 영역 A의 프라이빗 서브넷과 연결된 라우팅 테이블입니다. 첫 번째 항목은 로컬 경로이며 이 경로는 서브넷의 인스턴스가 프라이빗 IP 주소를 사용하여 VPC의 다른 인스턴스와 통신할 수 있도록 합니다. 이 서브넷의 인스턴스에는 인터넷에 대한 액세스 권한이 없습니다.

대상 주소 대상
VPC CIDR 로컬

다음은 가용 영역 B의 퍼블릭 서브넷과 연결된 라우팅 테이블입니다. 첫 번째 항목은 로컬 경로이며, 이 경로는 서브넷의 인스턴스가 프라이빗 IP 주소를 사용하여 VPC의 다른 인스턴스와 통신할 수 있도록 합니다. 두 번째 항목은 다른 모든 서브넷 트래픽을 인터넷 게이트웨이로 전송하여 서브넷의 NAT 게이트웨이가 인터넷에 액세스할 수 있도록 합니다.

대상 주소 대상
VPC CIDR 로컬
0.0.0.0/0 internet-gateway-id

다음은 가용 영역 B의 프라이빗 서브넷과 연결된 라우팅 테이블입니다. 첫 번째 항목은 로컬 경로입니다. 서브넷의 인스턴스가 프라이빗 IP 주소를 사용하여 VPC의 다른 인스턴스와 통신할 수 있도록 합니다. 두 번째 항목에서는 기타 서브넷 트래픽을 모두 NAT 게이트웨이로 전송합니다.

대상 주소 대상
VPC CIDR 로컬
0.0.0.0/0 nat-gateway-id

자세한 내용은 서브넷의 라우팅 테이블 변경 단원을 참조하십시오.

퍼블릭 NAT 게이트웨이 테스트

NAT 게이트웨이를 만들고 라우팅 테이블을 업데이트한 후에는 프라이빗 서브넷의 인스턴스에서 인터넷의 원격 주소를 ping하여 인터넷에 연결할 수 있는지 테스트할 수 있습니다. 이렇게 하는 방법의 예는 인터넷 연결 테스트 섹션을 참조하세요.

인터넷에 연결할 수 있는 경우 인터넷 트래픽이 NAT 게이트웨이를 통해 라우팅되는지도 확인할 수 있습니다.

  • 프라이빗 서브넷의 인스턴스에서 전송되는 트래픽의 경로를 추적합니다. 이렇게 하려면 프라이빗 서브넷의 Linux 인스턴스에서 traceroute 명령을 실행합니다. 출력에서 홉 중 하나(일반적으로 첫 번째 홉)에 NAT 게이트웨이의 프라이빗 IP 주소가 보여야 합니다.

  • 프라이빗 서브넷의 인스턴스에서 소스 IP 주소에 연결할 때 이를 표시하는 타사 웹 사이트 또는 도구를 사용합니다. 소스 IP 주소는 NAT 게이트웨이의 탄력적 IP 주소여야 합니다.

이러한 테스트가 실패하는 경우 NAT 게이트웨이 문제 해결 섹션을 참조하세요.

인터넷 연결 테스트

다음 예시는 프라이빗 서브넷의 인스턴스가 인터넷에 연결할 수 있는지 테스트하는 방법을 보여 줍니다.

  1. 퍼블릭 서브넷에서 인스턴스를 시작합니다(이 인스턴스를 Bastion Host로 사용). 시작 마법사에서 Amazon Linux AMI를 선택하고 인스턴스에 퍼블릭 IP 주소를 할당해야 합니다. 보안 그룹 규칙이 로컬 네트워크의 IP 주소 범위에서 전송되는 인바운드 SSH 트래픽을 허용하고, 프라이빗 서브넷의 IP 주소 범위로 전송되는 아웃바운드 SSH 트래픽을 허용하는지 확인합니다. 이 테스트에서는 인바운드 및 아웃바운드 SSH 트래픽 모두에 0.0.0.0/0을 사용할 수 있습니다.

  2. 프라이빗 서브넷에서 인스턴스를 시작합니다. 시작 마법사에서 Amazon Linux AMI를 선택해야 합니다. 인스턴스에 퍼블릭 IP 주소를 할당하지 마세요. 보안 그룹 규칙이 퍼블릭 서브넷에서 시작한 인스턴스의 프라이빗 IP 주소에서 전송되는 인바운드 SSH 트래픽 및 모든 아웃바운드 ICMP 트래픽을 허용하는지 확인합니다. 퍼블릭 서브넷에서 인스턴스를 시작하는 데 사용한 것과 동일한 키 페어를 선택해야 합니다.

  3. 로컬 컴퓨터에서 SSH 에이전트 전달을 구성하고, 퍼블릭 서브넷의 Bastion Host에 연결합니다. 자세한 내용은 Linux 또는 macOS에 대한 SSH 에이전트 전달을 구성하려면 또는 Windows에 대한 SSH 에이전트 전달 구성 단원을 참조하세요.

  4. Bastion Host에서 프라이빗 서브넷의 인스턴스에 연결한 다음, 프라이빗 서브넷의 인스턴스에서 인터넷 연결을 테스트합니다. 자세한 내용은 인터넷 연결을 테스트하려면 단원을 참조하세요.

Linux 또는 macOS에 대한 SSH 에이전트 전달을 구성하려면

  1. 로컬 시스템에서 인증 에이전트에 프라이빗 키를 추가합니다.

    Linux의 경우 다음 명령을 사용합니다.

    ssh-add -c mykeypair.pem

    macOS의 경우 다음 명령을 사용합니다.

    ssh-add -K mykeypair.pem

  2. 다음 예시와 같이 -A 옵션으로 퍼블릭 서브넷의 인스턴스에 연결하여 SSH 에이전트 전달을 활성화하고 해당 인스턴스의 퍼블릭 주소를 사용합니다.

    ssh -A ec2-user@54.0.0.123
Windows에 대한 SSH 에이전트 전달 구성

Windows에서 사용 가능한 OpenSSH 클라이언트를 사용하거나 선호하는 SSH 클라이언트(예: PuTTY)를 설치할 수 있습니다.

OpenSSH

Getting started with OpenSSH for Windows의 설명에 따라 Windows용 OpenSSH를 설치합니다. 그런 다음 인증 에이전트에 키를 추가합니다. 자세한 내용은 Key-based authentication in OpenSSH for Windows를 참조하세요.

PuTTY

  1. Pageant가 아직 설치되어 있지 않으면 PuTTY 다운로드 페이지에서 Pageant를 다운로드하여 설치합니다.

  2. 프라이빗 키를 .ppk 형식으로 변환합니다. 자세한 내용은 Amazon EC2 사용 설명서의 PuTTYgen을 사용하여 프라이빗 키 변환을 참조하세요.

  3. Pageant를 시작하고 작업 표시줄의 Pageant 아이콘을 마우스 오른쪽 버튼으로 클릭한 다음 키 추가(Add Key)를 선택합니다. 생성한 .ppk 파일을 선택하고 필요에 따라 암호를 입력한 다음 열기(Open)를 선택합니다.

  4. PuTTY 세션을 시작하고 퍼블릭 IP 주소를 사용하여 퍼블릭 서브넷의 인스턴스에 연결합니다. 자세한 내용은 Linux 인스턴스 연결을 참조하세요. [Auth] 범주에서 [Allow agent forwarding] 옵션을 선택하고 [Private key file for authentication] 상자를 공백 상태로 둡니다.
인터넷 연결을 테스트하려면

  1. 다음 예시와 같이 퍼블릭 서브넷의 인스턴스에서 프라이빗 IP 주소를 사용하여 프라이빗 서브넷의 인스턴스에 연결합니다.

    ssh ec2-user@10.0.1.123

  2. 프라이빗 인스턴스에서 ICMP가 활성화된 웹 사이트에 대해 ping 명령을 실행하여 인터넷에 연결할 수 있는지 테스트합니다.

    ping ietf.org
    PING ietf.org (4.31.198.44) 56(84) bytes of data.
64 bytes from mail.ietf.org (4.31.198.44): icmp_seq=1 ttl=47 time=86.0 ms
64 bytes from mail.ietf.org (4.31.198.44): icmp_seq=2 ttl=47 time=75.6 ms
...

    키보드에서 [Ctrl+C]를 눌러 ping 명령을 취소합니다. ping 명령이 실패할 경우 인스턴스에서 인터넷에 액세스할 수 없음을 참조하세요.

  3. (선택 사항) 더 이상 필요하지 않으면 인스턴스를 종료합니다. 자세한 내용은 Amazon EC2 사용 설명서의 인스턴스 종료를 참조하세요.

허용 목록에 있는 IP 주소를 사용하여 네트워크에 액세스

프라이빗 NAT 게이트웨이를 통해 허용 목록에 있는 주소 풀을 사용하여 VPC에서 온프레미스 네트워크로의 통신을 사용할 수 있습니다. 각 인스턴스에 허용 목록에 있는 IP 주소 범위의 별도 IP 주소를 할당하는 대신 허용 목록에 있는 IP 주소 범위의 IP 주소를 사용하여 프라이빗 NAT 게이트웨이를 통해 온프레미스 네트워크로 향하는 서브넷의 트래픽을 라우팅할 수 있습니다.

개요

다음 다이어그램은 인스턴스가 AWS VPN을 통해 온프레미스 리소스에 액세스할 수 있는 방법을 보여줍니다. 인스턴스의 트래픽은 VPN 연결을 통해 가상 프라이빗 게이트웨이로 라우팅되고 고객 게이트웨이로 라우팅된 후 온프레미스 네트워크의 대상으로 라우팅됩니다. 그러나 대상에서 100.64.1.0/28과 같은 특정 IP 주소 범위의 트래픽만 허용된다고 가정해 보겠습니다. 이 경우에는 이러한 인스턴스의 트래픽이 온프레미스 네트워크에 도달하지 못하게 됩니다.

AWS VPN 연결을 사용하여 온프레미스 네트워크에 액세스

다음 다이어그램은 이 시나리오를 위한 구성의 주요 구성 요소를 보여줍니다. VPC에는 원본 IP 주소 범위와 함께 허용된 IP 주소 범위가 있습니다. VPC에는 프라이빗 NAT 게이트웨이가 있는 허용된 IP 주소 범위의 서브넷이 있습니다. 온프레미스 네트워크로 향하는 인스턴스의 트래픽은 VPN 연결로 라우팅되기 전에 NAT 게이트웨이로 전송됩니다. 온프레미스 네트워크는 허용된 IP 주소 범위에서 제공되는 NAT 게이트웨이의 소스 IP 주소가 있는 인스턴스에서 트래픽을 수신합니다.

프라이빗 NAT 게이트웨이를 통해 라우팅되는 VPC 서브넷 트래픽

리소스

다음과 같이 리소스를 생성하거나 업데이트합니다.

  • 허용된 IP 주소 범위를 VPC와 연결합니다.

  • 허용된 IP 주소 범위의 VPC에서 서브넷을 생성합니다.

  • 새 서브넷에서 프라이빗 NAT 게이트웨이를 생성합니다.

  • 서브넷의 라우팅 테이블을 인스턴스로 업데이트하여 온프레미스 네트워크로 향하는 트래픽을 NAT 게이트웨이로 전송합니다. 온프레미스 네트워크로 향하는 트래픽을 가상 프라이빗 게이트웨이로 전송하는 프라이빗 NAT 게이트웨이가 있는 서브넷의 라우팅 테이블에 경로를 추가합니다.

라우팅

다음은 첫 번째 서브넷과 연결된 라우팅 테이블입니다. 각 VPC CIDR에 대한 로컬 경로가 있습니다. 로컬 경로를 사용하면 서브넷의 리소스가 프라이빗 IP 주소를 사용하여 VPC의 다른 리소스와 통신할 수 있습니다. 세 번째 항목은 온프레미스 네트워크로 향하는 트래픽을 프라이빗 NAT 게이트웨이로 전송합니다.

대상 주소 대상
10.0.0.0/16 로컬
100.64.1.0/24 로컬
192.168.0.0/16 nat-gateway-id

다음은 두 번째 서브넷과 연결된 라우팅 테이블입니다. 각 VPC CIDR에 대한 로컬 경로가 있습니다. 로컬 경로를 사용하면 서브넷의 리소스가 프라이빗 IP 주소를 사용하여 VPC의 다른 리소스와 통신할 수 있습니다. 세 번째 항목은 온프레미스 네트워크로 향하는 트래픽을 가상 프라이빗 게이트웨이로 전송합니다.

대상 주소 대상
10.0.0.0/16 로컬
100.64.1.0/24 로컬
192.168.0.0/16 vgw-id

중첩되는 네트워크 간에 통신 사용

프라이빗 NAT 게이트웨이를 사용하여 네트워크 간에 CIDR 범위가 중첩되더라도 통신할 수 있습니다. 예를 들어, VPC A의 인스턴스가 VPC B의 인스턴스에서 제공되는 서비스에 액세스해야 한다고 가정해 보십시오.

CIDR 범위가 중첩되는 두 개의 VPC입니다.

개요

다음 다이어그램은 이 시나리오를 위한 구성의 주요 구성 요소를 보여줍니다. 먼저 IP 관리 팀이 중첩될 수 있는 주소 범위(라우팅 불가능한 주소 범위) 및 중첩될 수 없는 주소 범위(라우팅 가능한 주소 범위)를 결정합니다. IP 관리 팀은 라우팅 가능한 주소 범위 풀에서 요청이 있을 경우 프로젝트에 주소 범위를 할당합니다.

각 VPC에는 라우팅이 불가능한 원래 IP 주소 범위와 IP 관리 팀에 의해 할당된 라우팅 가능한 IP 주소 범위가 있습니다. VPC A에는 프라이빗 NAT 게이트웨이가 포함된 라우팅 가능한 범위의 서브넷이 있습니다. 프라이빗 NAT 게이트웨이는 해당 서브넷에서 해당 IP 주소를 가져옵니다. VPC B에는 Application Load Balancer가 포함된 라우팅 가능한 범위의 서브넷이 있습니다. Application Load Balancer는 해당 서브넷에서 해당 IP 주소를 가져옵니다.

VPC B의 라우팅 불가능한 서브넷에 있는 인스턴스로 향하는 VPC A의 라우팅 불가능한 서브넷에 있는 인스턴스의 트래픽은 프라이빗 NAT 게이트웨이를 통해 전송된 다음 전송 게이트웨이로 라우팅됩니다. 전송 게이트웨이는 트래픽을 Application Load Balancer로 전송합니다. Application Load Balancer는 VPC B의 라우팅 불가능한 서브넷에 있는 대상 인스턴스 중 하나로 해당 트래픽을 라우팅합니다. 전송 게이트웨이에서 Application Load Balancer로의 이 트래픽에는 프라이빗 NAT 게이트웨이의 소스 IP 주소가 있습니다. 따라서 로드 밸런서의 응답 트래픽은 프라이빗 NAT 게이트웨이의 주소를 대상으로 사용합니다. 응답 트래픽은 전송 게이트웨이로 보내진 후 프라이빗 NAT 게이트웨이로 라우팅됩니다. NAT 게이트웨이는 대상을 VPC A의 라우팅 불가능한 서브넷에 있는 인스턴스로 변환합니다.

중첩되는 CIDR이 있는 VPC 간 통신을 위한 프라이빗 NAT 게이트웨이 및 전송 게이트웨이가 포함된 VPC

리소스

다음과 같이 리소스를 생성하거나 업데이트합니다.

  • 할당된 라우팅 가능한 IP 주소 범위를 각각의 해당 VPC에 연결합니다.

  • 라우팅 가능한 IP 주소 범위의 VPC A에서 서브넷을 생성하고 이 새 서브넷에서 프라이빗 NAT 게이트웨이를 생성합니다.

  • 라우팅 가능한 IP 주소 범위의 VPC B에서 서브넷을 생성하고 이 새 서브넷에서 Application Load Balancer를 생성합니다. 로드 밸런서의 대상 그룹에 라우팅 불가능한 서브넷의 인스턴스를 등록합니다.

  • VPC를 연결할 전송 게이트웨이를 생성합니다. 경로 전파를 사용 중지했는지 확인합니다. 각 VPC를 전송 게이트웨이에 연결하는 경우에는 VPC의 라우팅 가능한 주소 범위를 사용하세요.

  • VPC A의 라우팅 불가능한 서브넷의 라우팅 테이블을 업데이트하여 VPC B의 라우팅 가능한 주소 범위로 향하는 모든 트래픽을 프라이빗 NAT 게이트웨이로 전송합니다. VPC A의 라우팅 가능한 서브넷의 라우팅 테이블을 업데이트하여 VPC B의 라우팅 가능한 주소 범위로 향하는 모든 트래픽을 전송 게이트웨이로 전송합니다.

  • VPC B의 라우팅 가능한 서브넷의 라우팅 테이블을 업데이트하여 VPC A의 라우팅 가능한 주소 범위로 향하는 모든 트래픽을 전송 게이트웨이로 전송합니다.

라우팅

다음은 VPC A의 라우팅 불가능한 서브넷에 대한 라우팅 테이블입니다.

대상 주소 대상
10.0.0.0/16 로컬
100.64.1.0/24 로컬
100.64.2.0/24 nat-gateway-id

다음은 VPC A의 라우팅 가능한 서브넷에 대한 라우팅 테이블입니다.

대상 주소 대상
10.0.0.0/16 로컬
100.64.1.0/24 로컬
100.64.2.0/24 transit-gateway-id

다음은 VPC B의 라우팅 불가능한 서브넷에 대한 라우팅 테이블입니다.

대상 주소 대상
10.0.0.0/16 로컬
100.64.2.0/24 로컬

다음은 VPC B의 라우팅 가능한 서브넷에 대한 라우팅 테이블입니다.

대상 주소 대상
10.0.0.0/16 로컬
100.64.2.0/24 로컬
100.64.1.0/24 transit-gateway-id

다음은 전송 게이트웨이 라우팅 테이블입니다.

CIDR 연결 경로 유형
100.64.1.0/24 VPC A 연결 정적
100.64.2.0/24 VPC B 연결 정적