AWS VPC 구성 에는 4 가지 시나리오 가 있습니다. 그러나이 두 가지를 살펴 보자.
- 시나리오 1 : 1 퍼블릭 서브넷.
- 시나리오 2 : 퍼블릭 서브넷 1 개 및 프라이빗 서브넷 1 개
퍼블릭 서브넷에서 시작된 인스턴스에는 EIP가 없으므로 (할당되지 않은 경우) 이미 인터넷에서 주소를 지정할 수 없습니다. 그때:
- 프라이빗 서브넷이 필요한 이유는 무엇입니까?
- 프라이빗 서브넷과 퍼블릭 서브넷의 차이점은 무엇입니까?
답변
업데이트 : 2015 년 12 월 말 AWS 는 VPC 용 Managed NAT Gateway 라는 새로운 기능을 발표 했습니다 . 이 선택적 서비스는 프라이빗 서브넷의 VPC 인스턴스가 인터넷에 액세스 할 수있는 대체 메커니즘을 제공합니다. 이전에는 일반적인 솔루션이 VPC 내의 퍼블릭 서브넷에있는 EC2 인스턴스였으며 “NAT 인스턴스”로 작동하여 네트워크 주소 변환을 제공했습니다 ( 다른 프라이빗 서브넷의 인스턴스에 대해서는 기술적으로 포트 주소 변환)을 통해 해당 머신이 아웃 바운드 인터넷 액세스에 NAT 인스턴스의 퍼블릭 IP 주소를 사용할 수 있습니다.
새로운 관리 형 NAT 서비스는 기본적으로 다음 정보의 적용 가능성을 변경하지는 않지만 이어지는 내용에서는이 옵션을 다루지 않습니다. 설명에 따라 NAT 인스턴스를 계속 사용하거나 대신 관리 형 NAT 게이트웨이 서비스를 프로비저닝 할 수 있습니다. 이 답변의 확장 버전은 NAT 게이트웨이에 대한 자세한 정보와 NAT 인스턴스와 비교하는 방법이 VPC의 프라이빗 / 퍼블릭 서브넷 패러다임과 관련되어 있기 때문에 향후 제공 될 예정입니다.
점을 유의 인터넷 게이트웨이 및 NAT 게이트웨이는 두 개의 서로 다른 기능이 있습니다. 인터넷 액세스가 가능한 모든 VPC 구성에는 인터넷 게이트웨이 가상 개체가 있습니다.
Amazon VPC에서 “프라이빗”서브넷과 “퍼블릭”서브넷의 차이점을 이해하려면 IP 라우팅 및 NAT (Network Address Translation)의 일반적인 작동 방식과 VPC에서 구체적으로 구현되는 방식을 이해해야합니다.
VPC의 퍼블릭 서브넷과 프라이빗 서브넷의 핵심 차별화는 해당 서브넷의 기본 경로가 VPC 라우팅 테이블에 정의되어 있습니다.
이 구성은 특정 서브넷의 인스턴스에서 퍼블릭 IP 주소를 사용하거나 사용하지 않는 유효성을 나타냅니다.
각 서브넷에는 정확히 하나의 기본 경로가 있으며 다음 두 가지 중 하나 일 수 있습니다.
- “퍼블릭”서브넷 인 경우 VPC의 “Internet Gateway”개체 또는
- NAT 디바이스- “개인”서브넷의 경우 “NAT 인스턴스”역할을 수행하는 NAT 게이트웨이 또는 EC2 인스턴스
인터넷 게이트웨이는 퍼블릭 IP 주소가없는 인스턴스에 대해서는 네트워크 주소 변환을 수행하지 않으므로 퍼블릭 IP 주소가없는 인스턴스 는 인터넷에 외부 로 연결할 수 없습니다 ( 소프트웨어 업데이트 다운로드 또는 S3 1 및 SQS와 같은 다른 AWS 리소스에 액세스 등) -VPC 서브넷의 기본 경로가 인터넷 게이트웨이 개체 인 경우 당신이 “공개”서브넷에있는 인스턴스 그래서 만약, 당신이 필요로 서버가 일반적으로해야 할 것들의 상당수을하기 위해 공용 IP 주소를.
개인 IP 주소 만있는 인스턴스의 경우 인터넷에 대한 대체 아웃 바운드 액세스 방법이 있습니다. 네트워크 주소 변환 ²과 NAT 인스턴스가 들어옵니다.
프라이빗 서브넷의 기본 경로 는 VPC “Internet Gateway”개체 가 아니기 때문에 프라이빗 서브넷의 머신은 인터넷에 액세스 할 수 있습니다 . 이는 NAT 인스턴스로 구성된 EC2 인스턴스입니다.
NAT 인스턴스는 퍼블릭 IP 및 특정 구성을 가진 퍼블릭 서브넷의 인스턴스입니다. 이를 위해 사전 구축 된 AMI가 있거나 직접 구축 할 수 있습니다.
프라이빗 주소가 지정된 머신이 트래픽을 외부로 전송하면 VPC에 의해 트래픽이 NAT 인스턴스로 전송됩니다. NAT 인스턴스는 패킷의 소스 IP 주소 (프라이빗 머신의 프라이빗 IP 주소)를 자체 퍼블릭 IP 주소로 바꾸고 트래픽을 전송합니다. 인터넷으로 전송하고 응답 패킷을 수락 한 다음 원래 시스템의 개인 주소로 다시 전달합니다. 또한 소스 포트를 다시 쓸 수도 있으며 어떤 경우에도 매핑을 기억하여 응답 패킷을 수신 할 내부 시스템을 알 수 있습니다. NAT 인스턴스는 “예기치 않은”인바운드 트래픽이 프라이빗 인스턴스에 도달하도록 특별히 구성되지 않은 한 프라이빗 인스턴스에 도달하는 것을 허용하지 않습니다.
따라서 프라이빗 서브넷에서 외부 인터넷 리소스에 액세스 할 때 트래픽은 NAT 인스턴스를 통과하고 NAT 인스턴스의 퍼블릭 IP 주소에서 시작된 대상으로 보입니다. 따라서 응답 트래픽은 NAT 인스턴스로 돌아옵니다. NAT 인스턴스에 할당 된 보안 그룹이나 개인 인스턴스에 할당 된 보안 그룹은 보안 그룹이 상태 저장 상태이므로이 응답 트래픽을 “허용”하도록 구성 할 필요가 없습니다. 응답 트래픽이 내부에서 시작된 세션과 상관되어 있으므로 자동으로 허용됩니다. 물론 보안 그룹이 허용하도록 구성되어 있지 않으면 예기치 않은 트래픽은 거부됩니다.
기본 게이트웨이가 동일한 서브넷에있는 기존 IP 라우팅과 달리 VPC에서 작동하는 방식이 다릅니다. 특정 프라이빗 서브넷의 NAT 인스턴스는 항상 다른 서브넷에 있고 다른 서브넷은 항상 퍼블릭 서브넷입니다. NAT 인스턴스는 퍼블릭 외부 IP를 가져야하며 기본 게이트웨이는 VPC “Internet Gateway”개체 여야합니다.
마찬가지로 … 프라이빗 서브넷에는 퍼블릭 IP가있는 인스턴스를 배포 할 수 없습니다. 프라이빗 서브넷의 기본 경로는 정의에 따라 NAT 인스턴스 (트래픽에서 NAT를 수행하는)이고 인터넷 게이트웨이 개체 (하지 않는)이므로 작동하지 않습니다. 인터넷의 인바운드 트래픽은 인스턴스의 퍼블릭 IP에 도달하지만 응답은 NAT 인스턴스를 통해 외부로 라우팅하려고 시도합니다. NAT 인스턴스는 트래픽을 삭제합니다 (알지 못하는 연결에 대한 응답으로 구성되므로) 유효하지 않은 것으로 간주되거나 자체 공개 IP 주소를 사용하기 위해 회신 트래픽을 다시 작성합니다. 외부 발신자는 통신을 시작하려는 IP 주소 이외의 IP 주소에서 온 회신을 수락하지 않으므로 작동하지 않습니다. .
본질적으로 “개인”및 “공개”지정은 실제로 인터넷의 접근성 또는 접근성에 관한 것이 아닙니다. 이들은 해당 서브넷의 인스턴스에 할당 될 주소의 종류에 관한 것으로, 이는 인터넷 상호 작용을 위해 해당 IP 주소를 변환하거나 변환하지 않아야하기 때문에 관련이 있습니다.
VPC에는 모든 VPC 서브넷에서 다른 모든 VPC 서브넷으로의 암시 적 경로가 있으므로 기본 경로는 내부 VPC 트래픽에서 역할을하지 않습니다. 프라이빗 IP 주소가있는 인스턴스는 퍼블릭 IP 주소 (있는 경우)가 아닌 프라이빗 IP 주소를 “보낸”VPC의 다른 프라이빗 IP 주소에 연결됩니다. 대상 주소가 다른 프라이빗 주소 인 한 VPC 내에서
프라이빗 IP 주소를 가진 인스턴스가 어떤 상황에서도 아웃 바운드 인터넷 트래픽을 발생시키지 않아도되는 경우 기술적으로 “퍼블릭”서브넷에 배포 할 수 있으며 여전히 인터넷에서 액세스 할 수 없지만 이러한 구성에서는 S3 1 또는 SQS 와 같은 다른 AWS 인프라 서비스와의 연결을 포함하여 인터넷으로 나가는 트래픽을 발생시키는 것은 불가능합니다 .
1. S3와 관련하여 특히 인터넷 액세스가 항상 필요하다는 것은 VPC의 기능이 지속적으로 발전하고 발전함에 따라 시간이 지남에 따라 범위가 확대되고 다른 AWS 서비스로 확산 될 수있는 지나치게 단순화 된 것입니다. VPC 엔드 포인트 라는 비교적 새로운 개념이 있습니다.“인터넷”을 건드리지 않고 NAT 인스턴스 또는 NAT 게이트웨이를 사용하지 않고 프라이빗 IP 주소 만있는 인스턴스를 포함하여 인스턴스가 VPC 내의 선택된 서브넷에서 S3에 직접 액세스 할 수 있지만 추가 구성이 필요합니다. VPC와 동일한 AWS 리전 내 버킷에만 액세스 할 수 있습니다. 기본적으로이 문서 작성 시점에서 VPC 엔드 포인트 생성 기능을 노출 한 유일한 서비스 인 S3는 인터넷을 통해 VPC 내부에서만 액세스 할 수 있습니다. VPC 엔드 포인트를 생성하면 접두사 목록 (pl-xxxxxxxx)를 사용하여 VPC 라우팅 테이블에서 가상 “VPC 엔드 포인트”객체를 통해 해당 특정 AWS 서비스에 바인딩 된 트래픽을 서비스로 직접 보낼 수 있습니다. 또한 접두사 목록을 대상 IP 주소 또는 블록 대신 아웃 바운드 보안 그룹에서 사용할 수 있고 S3 VPC 엔드 포인트에 추가 정책 설명이 적용될 수 있기 때문에 특정 인스턴스의 S3에 대한 아웃 바운드 액세스 제한 문제를 해결합니다. 원하는대로 내부에서 버킷 액세스를 제한합니다.
2. 문서에서 언급했듯이 여기에서 실제로 논의되는 것은 포트 및 네트워크 주소 변환입니다. 기술적으로 약간 부정확하지만 결합 된 작업을 “NAT”라고하는 것이 일반적입니다. 이것은 우리가 실제로 “TLS”를 의미 할 때 많은 사람들이 “SSL”이라고 말하는 경향과 다소 유사합니다. 우리는 우리가 무엇을 말하는지 알고 있지만, 그것을 묘사하기 위해 가장 정확한 단어를 사용하지는 않습니다. “참고 NAT 장치의 실제 역할은 주소 변환 및 포트 주소 변환 (PAT) 모두이지만이 설명서에서 NAT라는 용어를 사용하여 일반적인 IT 실무를 따릅니다.”
답변
도끼 “개인”서브넷과 NAT 인스턴스 / 게이트웨이와 같은 다른 방법을 제안합니다. 필요하지 않습니다. 인터넷에서 기기에 액세스하지 못하게하려면 해당 액세스를 허용하는 보안 그룹에 기기를 두지 마십시오.
NAT 인스턴스 / 게이트웨이를 버림으로써 인스턴스 / 게이트웨이의 운영 비용을 제거하고 속도 제한 (250mbit 또는 10gbit)을 제거합니다.
인터넷에 직접 액세스 할 필요가없는 컴퓨터가 있다면 (그리고 어떻게 패치하고 있는지 물어볼 것입니다 *), 반드시 공용 IP 주소를 할당하지 마십시오.
* 여기에 대한 답변이 일종의 대리자 인 경우, 오버 헤드가 발생하지만 각각 자체적으로 발생합니다.
답변
위의 Michael 답변에 의견을 추가하는 것으로 평판이 없으므로 답변으로 내 의견을 추가하십시오.
AWS 관리 게이트웨이는 자체 인스턴스를 실행할 때와 비교해 볼 때 현재보다 3 배 더 비쌉니다. 물론 이것은 대부분의 중소 규모의 사용 사례 시나리오에서 일반적으로 적용되는 하나의 NAT 인스턴스 만 필요하다고 가정합니다 (즉, 장애 조치 등을 위해 구성된 여러 NAT 인스턴스가없는 등). NAT 게이트웨이를 통해 매월 100GB의 데이터 전송을 가정하면,
관리 형 NAT 인스턴스 월별 비용 = 월 $ 33.48 (월 $ 0.045 / 시간 * 한 달에 744 시간) + $ 4.50 (처리 된 GB 데이터 당 $ 0.045 * 100GB) + $ 10 ($. 10 / GB를 통해 전송 된 모든 데이터에 대한 표준 AWS 데이터 전송 요금) NAT 게이트웨이) = $ 47.98
NAT 인스턴스로 구성된 t2.nano 인스턴스 = $ 4.84 / 월 (한 달에 $ 0.0065 * 744 시간) + $ 10 (NAT 인스턴스를 통해 전송 된 모든 데이터에 대해 GB 당 $ 10.10 / GB) = 14.84 달러
AWS 관리 형 NAT 게이트웨이에는 고 가용성을위한 중복성이 기본 제공되므로 중복 NAT 인스턴스를 사용하는 경우에는 물론 변경됩니다. 추가 $ 33 / 월에 신경 쓰지 않는다면 관리되는 NAT 인스턴스는 다른 인스턴스를 유지 관리하지 않아도되는 두통을 줄여 줄 가치가 있습니다. VPC 내 인스턴스에 액세스하기 위해 VPN (예 : OpenVPN) 인스턴스를 실행하는 경우 NAT 게이트웨이 역할을하도록 해당 인스턴스를 구성하면 NAT에 대해서만 추가 인스턴스를 유지할 필요가 없습니다 ( 일부 사람들은 VPN과 NAT를 결합한다는 생각에 눈살을 찌푸 릴 수도 있습니다).
답변
Michael-sqlbot 의 대답 은 개인 IP 주소가 필요하다는 암시 적 가정을 만듭니다. 그런 가정에 의문을 갖는 것이 가치가 있다고 생각합니다. 우선 개인 IP 주소를 사용해야합니까? 적어도 한 명의 의견자가 같은 질문을했습니다.
NAT 인스턴스가있는 개인용 서브넷 (vs.)과 엄격한 보안 정책을 가진 공용 서브넷에있는 서버의 장점은 무엇입니까? – abhillman 2016 년 6 월 24 일 23:45에
VPC를 사용하고 모든 EC2 인스턴스에 퍼블릭 IP 주소를 할당하는 시나리오를 상상해보십시오. 보안 그룹을 사용하여 EC2 classic에서 작동하는 것과 동일한 방식으로 액세스를 제한하기 때문에 반드시 인터넷을 통해 도달 할 수 있다는 것을 걱정하지 마십시오. 공용 IP 주소를 사용하면 ELB와 같은 것을 사용하지 않고도 특정 서비스를 제한된 대상에게 쉽게 노출 할 수 있다는 이점이 있습니다. 따라서 NAT 인스턴스 또는 NAT 게이트웨이를 설정할 필요가 없습니다. 또한 서브넷 수의 절반이 필요하므로 VPC에 더 작은 CIDR 할당을 사용하도록 선택하거나 동일한 크기의 VPC로 더 큰 서브넷을 만들 수 있습니다. 서브넷 수가 적 으면 AZ 간 트래픽 비용도 줄어 듭니다.
우리는 왜 이것을하지 않습니까? AWS에서 모범 사례가 프라이빗 IP를 사용하는 것이라고 말하는 이유는 무엇입니까?
인터넷 전체에 퍼블릭 IPv4 주소의 공급이 제한되어 있기 때문에 Amazon Web Services는 퍼블릭 IPv4 주소의 공급이 제한되어 있습니다. 드문 공용 IPv4 주소를 과도하게 소비하지 않고 사실상 무제한 인 개인 IP 주소를 사용하는 것이 가장 좋습니다. AWS가 탄력적 IP의 가격을 책정하는 방법에서 이에 대한 몇 가지 증거를 볼 수 있습니다. 인스턴스에 연결된 EIP는 무료이지만 사용하지 않은 EIP는 비용이 듭니다.
그러나 논쟁을 위해 인터넷의 공개 IPv4 주소 부족에 신경 쓰지 않는다고 가정 해 봅시다. 결국, 나의 신청은 특별하다. 다음은 어떻게됩니까?
퍼블릭 IP 주소를 VPC의 EC2 인스턴스에 연결하는 방법은 두 가지뿐입니다.
1. 준 공공 IP 주소
새 EC2 인스턴스를 시작할 때 퍼블릭 IP 주소를 요청할 수 있습니다. 이 옵션은 콘솔에서 확인란으로, aws-cli 사용시 –associate-public-ip-address 플래그로, CloudFormation 사용시 임베디드 네트워크 인터페이스 객체 에서 AssociatePublicIpAddress 플래그로 나타납니다. 어쨌든 퍼블릭 IP 주소는 eth0(DeviceIndex = 0)에 할당됩니다 . 새 인스턴스를 시작할 때만이 방법을 사용할 수 있습니다. 그러나 여기에는 몇 가지 단점이 있습니다.
단점은 내장 된 네트워크 인터페이스 객체를 사용하는 인스턴스의 보안 그룹을 변경하면 적어도 CloudFormation을 사용하는 경우 인스턴스를 즉시 교체해야한다는 것입니다.
또 다른 단점은 이러한 방식으로 할당 된 퍼블릭 IP 주소가 인스턴스가 중지 될 때 유실된다는 것입니다.
2. 탄력적 IP
일반적으로 Elastic IP는 더 안전하기 때문에 선호되는 방법입니다. 동일한 IP 주소를 계속 사용하는 것이 보장되며 실수로 EC2 인스턴스를 삭제할 위험이 없으며 언제든지 탄력적 IP를 자유롭게 연결 / 분리 할 수 있으며 EC2 인스턴스에 적용된 보안 그룹을 자유롭게 변경할 수 있습니다.
…하지만 AWS는 리 전당 5 개의 EIP로 제한합니다. 더 요청할 수 있으며 요청 이 승인 될 수 있습니다. 그러나 AWS는 위에서 언급 한 추론에 따라 해당 요청을 거부 할 수 있습니다. 따라서 리 전당 5 EC2 인스턴스 이상으로 인프라를 확장하려는 경우 EIP에 의존하고 싶지 않을 것입니다.
결론적으로 퍼블릭 IP 주소를 사용하면 몇 가지 장점이 있지만 퍼블릭 IP 주소를 독점적으로 사용하려고하면 관리 또는 확장 문제가 발생합니다. 이것이 모범 사례가 왜 그런지 설명하고 설명하는 데 도움이되기를 바랍니다.
답변
