VPC의 기본 서브넷에있는 Elastic Beanstalk 자동 확장 그룹에 여러 EC2 인스턴스가 있습니다. 이러한 EC2 인스턴스의 앱은 액세스를 허용하기 위해 IP 주소 화이트리스트를 사용하는 타사 서비스에 연결해야합니다. 따라서이 서비스 제공 업체에 제공 할 수있는 하나 이상의 고정 IP 주소가 있어야 화이트리스트에 추가 할 수 있습니다. 정적 IP를 얻는 유일한 방법은 탄력적 IP 주소를 얻는 것입니다. 그리고 한 번에 하나의 EC2 인스턴스에만 Elastic IP를 연결할 수 있습니다. 전체 서브넷 또는 인터넷 게이트웨이와 연결할 수 없습니다 (정확합니까?). 각 EC2 인스턴스마다 탄력적 IP가 필요하므로 각 인스턴스를 별도로 화이트리스트에 추가 할 수 있습니까? 자동 확장이 다른 인스턴스를 추가하면 어떻게 작동합니까? 탄력적 IP가있는 EC2 인스턴스가 하나 있어야합니까? 해당 인스턴스를 통해 모든 나가는 트래픽을 라우팅합니까? 그렇다면 해당 인스턴스는이 목적으로 만 사용되어야합니까, 아니면 내 앱을 실행하는 인스턴스 중 하나 일 수 있습니까?
답변
NAT가 필요합니다. 이 구성은 일반적으로 VPC에서 프라이빗 서브넷을 지원하는 데 사용되며 여기에 자세한 지침이 있습니다 . VPC가 NAT 인스턴스를 사용하도록 구성되면 모든 아웃 바운드 트래픽은 NAT 인스턴스의 EIP에 기인합니다.
그렇다면 해당 인스턴스는이 목적으로 만 사용되어야합니까, 아니면 내 앱을 실행하는 인스턴스 중 하나 일 수 있습니까?
기술적으로는 가능하지만 좋은 생각은 아닙니다.
- 역할을 분리하는 것이 좋은 보안입니다.
- 애플리케이션 서버가 유사하거나 동일한로드 프로파일을 갖기를 원합니다. NAT로 인해 하나의 인스턴스에 10 %의 추가로드가있는 경우 해당 인스턴스의 한계에 도달하면 조기에 확장해야합니다. 더 많은 인스턴스가 클러스터에 추가 될수록 NAT가 더 바 빠질수록 상황이 악화됩니다.
- 애플리케이션 서버가 동일하고 임시적이기를 원하므로 문제가 있거나 확장이 필요할 때마다 서버를 분리하거나 교체 할 수 있습니다. 나머지와 다른 하나의 응용 프로그램 서버를 갖는 것은 큰 두통입니다.
당신은 할 수 인스턴스가 용기 화하는 경우 멀리 얻을 수 있지만, 그것은 아마도 여전히 좋은 생각이 아니다.
또한 NAT 인스턴스는 단일 장애 지점이 될 수 있으므로 중복성에 대해 생각할 수 있습니다.
답변
나는 이것이 오래된 스레드라는 것을 알고 있습니다. 유사한 사례가있는 사람에게는 AWS nat-gateway 가 더 나은 솔루션이 될 것입니다.
답변
위의 답변에 대해 언급 할만 큼 평판이 좋지는 않지만 NAT 게이트웨이를 사용하여이를 달성하기 위해 알아야 할 정보를 추가하고 싶었습니다. NAT 게이트웨이를 만들 때 서브넷과 탄력적 IP 주소를 선택합니다.
처음에는 탄력적로드 밸런서 및 EC2 인스턴스와 동일한 서브넷에 NAT 게이트웨이를 추가했습니다. 그런 다음 NAT 게이트웨이를 라우팅 테이블에 추가해야합니다. 연결하려는 외부 데이터베이스 서버의 IP 대상으로 NAT 게이트웨이를 추가했습니다. 이로 인해 탄력있는 beantalk에서 호스팅되는 응용 프로그램이 시간 초과되었습니다. NAT를 통해 외부 데이터베이스에 연결하려고했기 때문입니다. NAT에 도달 한 후 NAT는 인터넷을 통해 서버에 연결을 시도한 후 라우팅 테이블에서 자신이 있던 서브넷의 라우팅 테이블을 검색하여 루프를 생성했습니다.
해결책은 NAT 게이트웨이를 작성하기 전에 NAT 전용 서브넷과 라우트 테이블을 갖도록 NAT 전용 새 서브넷을 작성하는 것입니다. NAT의 라우팅 테이블에서 모든 트래픽을 인터넷 게이트웨이로 지정하십시오. 기본 라우팅 테이블에서 외부 IP가 NAT를 가리 키도록합니다. 그런 다음 EC2 인스턴스가 외부 IP에 연결하려고하면 기본 라우팅 테이블 (또는 인스턴스가 속한 서브넷에 대해 정의한 라우팅 테이블)에서 해당 인스턴스를 찾아 NAT를 찾습니다. 그런 다음 NAT는 자체 라우팅 테이블에서 해당 IP를 찾아 인터넷을 찾습니다.