자동 확장 그룹에 추가 된 새로운 인스턴스를 탄력적 IP와 연관시킬 수있는 방법이 있습니까? 내 autoscale 그룹의 인스턴스가 원격 서버에서 허용 목록에 있어야하는 유스 케이스가 있으므로 예측 가능한 IP가 필요합니다.탄성 IP가있는 Amazon EC2 자동 확장 인스턴스
프로그래밍 방식으로 API를 사용하여이 작업을 수행하는 방법이 있다는 것을 알고 있지만 다른 방법이 있는지 궁금합니다. CloudFormation이이를 수행 할 수있을 것 같습니다.
수동 또는 스크립팅 API 호출을 사용하여 다른 인스턴스처럼 탄성 IP를 ASG 인스턴스에 연결할 수 있지만 자동화 된 방법은 없습니다. ASG 인스턴스는 임시/일회용으로 설계되었으며, Elastic IP 협회는이 철학에 반대합니다.
문제를 다시 해결하기 :
이렇게하는 데는 3 가지 방법이 있습니다. 구름 형성은 단지 그것을 자동화 할 것이지만, 당신은 먼저 무슨 일이 일어나는지 이해할 필요가 있습니다.
1. 위에서 언급 한 바와 같이 VPC를 사용하면 두 가지 옵션이 있습니다. 1.1 - VPC 내에서 NAT 게이트웨이를 사용하여 게이트웨이에 들어오고 나가는 모든 트래픽을 라우팅합니다. 게이트웨이에는 탄성 IP 및 인터넷 트래픽이 있으며 서버 측에서 NAT 게이트웨이를 허용 목록에 추가합니다. AWS 설명서에서 NAT 게이트웨이를 찾으십시오.
1.2 - 데이터 센터의 백엔드 서버에 가상 사설망/VPN 연결을 만들고이를 통해 트래픽을 라우팅합니다. 1.2.a - DEDICATED 개인 서브넷 내에서 인스턴스를 만듭니다. 1.2.b- 너의 측면에있는 전체 서브넷을 허용 목록에 넣으면 해당 서브넷의 모든 요청이 허용됩니다. 1.2.c 서브넷의 경로가 올바른지 확인하십시오.
3 - 게으른 방법 (즉, 1.2이기 때문에 일부러 2를 건너 뛰는거야) 1 : 탄성 IP를의 자원 풀을 할당 두 가지를 할 AWS Opsworks를 활용합니다. 두 번째 : 요청시 LOAD 인스턴스를 시작하고 AUTO는 풀에서 하나의 신축성있는 IP를 할당합니다. 두 번째 부분에서는 24/7 인스턴스를 최소로,로드 인스턴스를 최대로 유지해야합니다. AWS Opsworks는 이제 Cloud Watch 경보가 인스턴스 시작을 트리거하도록 허용하여 ASG와 매우 유사합니다. Opsworks의 유일한 단점은 인스턴스가 종료되지 않고로드가 중단되고 인스턴스를 미리 "만들어야"할 때 인스턴스가 중지된다는 것입니다. 또한 당신은 당신의 인스턴스를 시작하기 위해 Chef solo에 의존하지만, 당신이 새로 발견 한 인스턴스에 자동으로 EIP를 할당 할 수있는 유일한 방법입니다.
건배!