AWS Lambda가 프라이빗 프록시에 도달하지 못함: VPC 경로 점검
첫 VPC 연결에는 프록시 리스너의 주소와 포트를 사용하고, 보안 그룹 방향과 DNS 뷰를 올바르게 맞춥니다.
Requests가 포워드 프록시로 구성되면 Lambda는 먼저 해당 리스너에 연결합니다. 443의 HTTPS 사이트 때문에 3128에서 수신하는 프록시가 첫 홉 포트 443이 되는 것은 아닙니다.
Lambda code → configured VPC path → proxy listener → destinationEC2에서 호스팅되는 프라이빗 프록시라면 함수를 의도한 VPC 서브넷과 보안 그룹에 연결합니다. Lambda는 이 연결의 네트워크 인터페이스를 관리합니다. 라우팅과 접근 제어가 허용하면 다른 서브넷도 동작할 수 있습니다.
| 제어 | 같은 VPC에서 직접 라우팅되는 구성의 첫 홉 요건 |
|---|---|
| 함수 보안 그룹 | 프록시 리스너로 나가는 TCP |
| 프록시 보안 그룹 | 의도한 함수 소스 또는 보안 그룹에서 해당 포트로 들어오는 TCP |
| 프록시 프로세스 | 도달 가능한 인터페이스에서 클라이언트 접근이 허용된 리스너 |
함수 그룹의 인바운드 규칙만으로는 이 아웃바운드 클라이언트 연결을 허용할 수 없습니다. 경로 점검에 라우팅 테이블과 서브넷 네트워크 ACL을 포함합니다.
Route 53의 프라이빗 프록시 이름이라면 호스팅 영역의 VPC 연결과 DNS 구성을 확인합니다. enableDnsHostnames과 enableDnsSupport도 포함합니다. 노트북에서의 성공적인 조회가 Lambda의 DNS 뷰를 증명하지는 않습니다. 실패한 이름이 프록시인지 웹사이트인지 기록합니다. 웹사이트를 숫자 IP로 바꾸는 것은 프록시 이름의 수정이 아닙니다.
이 홉이 동작하면 프록시 자체의 다음 경로가 필요합니다. Lambda를 퍼블릭 서브넷에 연결해도 퍼블릭 IP가 할당되지 않고 직접 인터넷 접근이 자동으로 제공되지 않습니다. 두 연결 각각의 이그레스를 따로 결정합니다.