AWS Lambda Verbindung zu internen ELB mit privaten Hostzone DNS

Question

Ich möchte eine EC2-Instanz auf einem privaten VPC einrichten. Er kann sich von der privaten VPC aus mit dem Internet verbinden, kann jedoch nicht von außen darauf zugreifen. Und es gibt eine Lambda-Funktion, die den EC2 veranlasst, einige Interaktionen mit externen Ressourcen (S3, Dynamo, Internet) zu initiieren.

Ich habe eine VPC wie folgend aufgebaut:

1. einer EC2 Instanz läuft Andockfensters in einem privaten VPC Subnetzes
2. Ein ALB (Anwendungslast-Balancer) konfiguriert, wie interne und in privaten Subnetzen (das gleiche wie das EC2-Subnetz)
3. ein NAT-Gateway, die
4. eine Lambda-Funktion arbeitet, die mit dem Internet und ALB ein Rekord, dass die Route „HTTPs GET und POST tun
5. Route53 Privat Hostzone hat abc d.internal/api "an den ALB.

Hier ist das Problem. Die Lambda-Funktion kann mit HTTPs eine Verbindung zum Internet herstellen, aber wenn es nicht gelingt, HTTPs GET zum ALB mit dem privaten Hostzone-Datensatz ("abcd.internal").

Mein Verständnis ist meine ALB, EC2, Lambda, NAT-Gateway und Route53 sind in der gleichen VPC konfiguriert, sollten sie in der Lage sein miteinander mit dem privaten DNS-Namen zu sprechen. Ich weiß nicht, warum es scheitert.

Hinweis: Bevor Sie einen internen ALB einrichten, habe ich versucht, einen Internet-gerichteten ALB in einem öffentlichen Subnetz einzurichten und dann einen öffentlichen Hostzone-Datensatz "abcd.public" für diesen ALB zu konfigurieren. Es kann mit der EC2-Instanz kommunizieren und die EC2-Instanz kann über das NAT-Gateway mit dem Internet interagieren. Also funktioniert der "EC2 to Internet" -Teil.

Update: ich endlich einige Fehlermeldungen in Lambda log graben wie folgt:

Fehler: Hostname/IP nicht mit Zertifikat des altnames: „Host:. Abcd.internal ist nicht in der altnames des cert: DNS : .public "] Grund: 'Host: abcd.internal. ist nicht in den Altnamen des Zertifikats: DNS:. public ', host:' abcd.internal. ',

Das ist interessant. Ich habe eine öffentliche Hostzone mit der privaten Hostzone koexistieren, aber die öffentliche Hostzone ist für andere Zwecke. Ich weiß nicht, warum die Lambda-Funktion das öffentliche DNS anstatt das private DNS verwendet, da es in einem privaten Subnetz konfiguriert wurde.

Answer 1

Wenn Sie ein Lastenausgleichsmodul in einem privaten Subnetz platzieren, ist es nicht mehr nur über die VPC vom Internet aus zugänglich. Wenn das deine Absicht ist, OK. Wenn Sie möchten, dass Ihre Lambda-Funktion auf Ihren internen Load Balancer zugreifen kann, müssen Sie die Lambda-Funktion in dieselbe VPC setzen.

[Edit nach comment]

Wenn Sie sowohl den Load-Balancer und Lambda in einem VPC privaten Subnetz haben, und Sie wollen privaten DNS-Namen verwenden, müssen Sie DHCP-Optionen konfigurieren Stellen Ihren eigenen DNS-Server zu verwenden, in Route53, damit die Lambda-Funktion die privaten DNS-Namen auflösen kann.

DHCP Options Sets

Answer 2

Vielen Dank für alle, die Kommentare und gab Anregungen posten.

Um dieses Problem zu lösen, habe ich fast alle möglichen Lösungen online gefunden. Ich stelle alles an die richtige Stelle. Lambda-Funktion, ELB und EC2 befinden sich im selben privaten VPC-Subnetz. Route53, NAT und IGW sind richtig eingerichtet. Ich habe versucht, mit den DHCP-Optionen zu spielen, hat nicht funktioniert. Vielleicht verstehe ich dieses DHCP nicht vollständig und kann kein Beispiel finden.

Es stellt sich heraus, dass das HTTPS-Protokoll nicht funktioniert. Bevor ich zur privaten VPC übergehe, habe ich dieselbe Einrichtung in einer öffentlichen VPC eingerichtet, und Ressourcen verwenden HTTPS zur Kommunikation. Zum Beispiel wird die Lambda-Funktion GET/POST an die EC2-Instanz oder ELB. Nachdem ich Inhalte in eine private VPC verschoben habe, können HTTPS-Befehle die internen DNS-Namen nicht verwenden.

Wenn ich jedoch HTTP-Protokoll verwende, können sich Ressourcen schließlich durch interne DNS-Namen finden.

Ich weiß immer noch nicht, warum HTTPS nicht in der privaten VPC verwendet werden kann, aber ich kann mit dieser Lösung leben.