2016-10-31 3 views
1

Unsere Redshift Cluster in Zone A. befindetConnect Lambda in verschiedenen Availability Zones Rotverschiebung

Wenn unsere Lambda-Funktion Zone A Subnetz verwendet, kann es zu Redshift verbinden.

Wenn unsere Lambda-Funktion ein anderes Subnetz als Zone A verwendet, wird das Zeitlimit überschritten.

Die Arbeit herum, wo wir Verbindungen für Redshift auf Port 5439 von 0.0.0.0/0, sind nicht erwünscht.

  • Wir haben unsere Lambda-Funktionen und Redshift-Cluster in der gleichen VPC.
  • Lambda-Funktionen haben vier dedizierte Subnetzen (eine pro Zone)
  • Redshift verfügt über 4 dedizierten Subnetze pro Zone haben auch
  • Lambda-Funktionen ihre eigene Sicherheitsgruppe (SG)
  • Der Redshift-Cluster als seine eigene SG hat Gut.
  • Redshift SG ermöglicht Port 5439 von Lambda SG und Admin SG
  • Enhanced VPC Routing aktiviert ist
  • Cluster Subnet Groups umfassen alle 4 Redshift Subnetzen (eine pro Zone)
  • keine Probleme, wenn so dass Port 5439 von 0.0.0.0/0 auf Redshift SG
  • Flow-Protokolle für REJECT funktionieren von Zone A zu Zone A, aber nicht von anderen Zonen zu Zone A, wenn wir die Regel 0.0.0.0/0 deaktivieren.
  • Alle Lambda-Subnetze verwenden, um eine NAT, die alle Redshift Subnetze verwenden, um ein IGW in Zone A
  • existiert, die derzeit in
  • Alle Netzwerk-ACLs existiert erlauben alle (Standard)
+2

Könnten Sie bitte die aktuellen Situationen erklären, die wie erwartet funktionieren, und diejenigen, die NICHT wie erwartet funktionieren? Zum Beispiel funktioniert es, wenn Lambda & Redshift beide in der gleichen AZ sind?Kannst du klarstellen, was du mit "aber nicht aus anderen Zonen, wenn wir ... deaktivieren" meinst? Sie sagen "Keine Probleme, wenn Port 5439 von 0.0.0.0/0 zugelassen wird" - bedeutet das, dass * alles * in dieser Situation gut ist, aber Sie möchten Redshift nicht so weit öffnen? Verfügen Sie über Netzwerk-ACLs, die den Datenverkehr in einem der Subnetze blockieren? –

+0

Aktualisierte den Beitrag. Netzwerk-ACLs sind Standard (allow). Redshift offen für 0.0.0.0/0 ist eine Arbeit, die wir nicht verwenden können. Lambda Zone A bis Redshift Zone A funktioniert. Problem ist, dass Funktionen in anderen Zonen als Zone A keine Verbindung zur Redshift Zone A herstellen können. –

+0

Wie verhalten sich die Lambda-Funktionen zu Amazon Redshift? Vermutlich über einen DNS-Namen - aber wird dieser DNS-Name in eine ** interne IP-Adresse ** oder eine ** öffentliche IP-Adresse ** aufgelöst? Sie können dies testen, indem Sie ein 'nslookup' von einer EC2-Instanz in der VPC ausführen, um zu sehen, welche IP-Adresse zurückgegeben wird. Haben Sie versucht, ** VPC Flow Logs ** zu aktivieren, um den Verkehr zwischen Lambda und Redshift zu analysieren? –

Antwort

1

ich in einer ähnlichen festsaß Lage. Das Hinzufügen der Elastic-IP des NAT-Gateways zu der eingehenden Regel der Sicherheitsgruppe von Redshift für Port 5439 hat es für mich behoben.

Schritte:

  • privates Check Lambda-Subnetz eines NAT-Gateway (Subnetz-abc)
  • Zur VPC-Konsole> Subnetze> Subnetz-abc> Route-Tabelle
  • In Route-Tabelle Routen mit , finden Sie das NAT-Gateway (nat-abcdefg)
  • Gehen Sie zu VPC-Konsole> NAT Gateways> nat-abcdefg. Ermitteln Sie die Elastic-IP, die von diesem NAT-Gateway verwendet wird. (Xx.yy.zz.pqr)
  • Fügen Sie eine eingehende Regel für diese elastisch-ip in Rotverschiebung der Sicherheitsgruppe (port = 5439 CIDR xx.yy.zz.pqr/32)

Volla! Lambda verbindet sich mit Rotverschiebung.

Obwohl, bevor dies getan wird, sollte Lambda in der gleichen VPC als Rotverschiebung konfiguriert werden und das entsprechende private Subnetz verwenden (konfiguriert für die Verwendung von NAT-Gateway) wie OP vorgeschlagen.

Verwandte Themen