Knowledge Center Monthly Newsletter - March 2025

Stay up to date with the latest from the Knowledge Center. See all new and updated Knowledge Center articles published in the last month and re:Post’s top contributors.

Wie behebe ich Verbindungsprobleme mit meinen Amazon VPC-Gateway-Endpunkten?

Lesedauer: 5 Minute

Ich möchte Verbindungsprobleme mit meinen Amazon Virtual Private Cloud (Amazon VPC)-Gateway-Endpunkten beheben.

Lösung

Konnektivitätsprobleme mit Gateway-VPC-Endpunkten können auf den Netzwerkzugriff oder auf Sicherheitsregeln zurückzuführen sein, die die Verbindung zulassen.

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Den Reachability Analyzer verwenden

Verwende den Reachability Analyzer, um Konnektivitätsprobleme zwischen der Quelle und dem Gateway-Endpunkt zu beheben. Weitere Informationen findest du unter Wie verwende ich Amazon VPC Reachability Analyzer zur Behebung von Konnektivitätsproblemen mit einer Amazon VPC-Ressource?

Überprüfung der Regionskonfigurationen

Gateway-Endpunkte sind nur in der Region verfügbar, in der du sie erstellst. Stelle sicher, dass du deinen Gateway-Endpunkt in derselben Region wie Amazon Simple Storage Service (Amazon S3)-Buckets oder Amazon DynamoDB-Tabellen erstellst. Um die Region deines Buckets zu ermitteln, führe den AWS CLI-Befehl get-bucket-location aus.

Wenn du ein SDK verwendest, um vom Gateway-Endpunkt aus auf einen Service zuzugreifen, konfiguriere die Region außerdem auf denselben Standort wie die Service-Ressourcen. Du kannst das Config object für Boto3 und aws configure für die AWS CLI verwenden.

Hinweis: Anforderungen, die du an eine falsche Region sendest, können zu Zeitüberschreitungen führen oder den Zugriff auf den Service über das Internet ermöglichen. Dies hängt von der Routing-Tabelle ab, die du im Quellsubnetz konfiguriert hast.

Überprüfung der DNS-Auflösung

Aktualisiere die DNS-Attribute in deiner VPC, um die DNS-Auflösung zu aktivieren. Wenn du deinen eigenen DNS-Server verwendest, stelle sicher, dass DNS-Anfragen an AWS-Services auf die von AWS verwalteten IP-Adressen aufgelöst werden.

Überprüfung der Einstellungen der Subnetz-Routing-Tabelle

Überprüfe die Einstellungen der Routing-Tabelle, um sicherzustellen, dass es eine Route zu Amazon S3 und DynamoDB gibt, die den Gateway-VPC-Endpunkt verwendet.

Überprüfung der Sicherheitsgruppen

Überprüfe die Sicherheitsgruppen, die der Quelle zugeordnet sind, die die Verbindungen zu Amazon S3 und DynamoDB initiiert. Vergewissere dich, dass die verfügbaren Regeln für ausgehenden Datenverkehr zu Amazon S3 oder DynamoDB zulassen. Wenn die Sicherheitsgruppe restriktivere Regeln als die Standardregeln für ausgehenden Datenverkehr hat, bestätige eine der folgenden Optionen:

Es gibt eine Regel für ausgehenden Datenverkehr, die Datenverkehr an die ID der Präfixliste zulässt, die dem Gateway-VPC-Endpunkt zugeordnet ist.
Im Ziel befindet sich ein Service-spezifischer CIDR-Block (IP-Adressbereich). Wenn es keinen Service-spezifischen CIDR-Block gibt, kannst du keinen hinzufügen. Es hat sich bewährt, die vom Service bereitgestellte Präfixliste-ID zu verwenden, da AWS die IP-Adressbereiche der Präfixliste verwaltet.

Um die öffentlichen IP-Adress-CIDRs für Amazon S3 und DynamoDB in einer bestimmten Region anzuzeigen, führe den AWS CLI-Befehl describe-prefix-lists aus:

aws ec2 describe-prefix-lists --region example-Region

Hinweis: Ersetze example-Region durch deine Region.

Überprüfung der Netzwerk-ACL-Regeln

Netzwerk-Zugriffssteuerungslisten (Netzwerk-ACLs) für Subnetze müssen eingehende und ausgehende TCP-Verbindungen zu Amazon S3- oder DynamoDB-Service-CIDRs innerhalb der Region zulassen.

Füge Netzwerk-ACL-Regeln hinzu, die Folgendes bewirken:

Sie erlauben eingehenden Rückverkehr vom Service, auf den du zugreifen möchtest, über die kurzlebigen TCP-Ports 1024-65535.
Sie erlauben den Datenverkehr zum CIDR-Block (IP-Adressbereich) des Services unter HTTPS.

Hinweis: Standardmäßig lassen Netzwerk-ACLs den gesamten eingehenden und ausgehenden IPv4- und IPv6-Datenverkehr zu. Wenn deine Netzwerk-ACL-Regeln den Datenverkehr einschränken, gib den CIDR-Block für den Service an, für den du den Gateway-Endpunkt erstellt hast. Es hat sich bewährt, Benachrichtigungen einzurichten, wenn sich Service-IP-Adressen ändern, und Skripts zu verwenden, um die Netzwerk-ACL-Regeln automatisch zu aktualisieren. Weitere Informationen findest du unter Wie erhalte ich Benachrichtigungen, wenn Amazon S3 seine IP-Adresse ändert?

Überprüfung der VPC-Endpunktrichtlinie

Überprüfe die VPC-Endpunktrichtlinie, um festzustellen, ob es sich um eine benutzerdefinierte Richtlinie oder um die Standardrichtlinie handelt. Eine benutzerdefinierte Endpunktrichtlinie muss den Zugriff ermöglichen, um Aktionen gegen den Service ausführen zu können. Eine Standard-Endpunktrichtlinie ermöglicht den vollständigen Zugriff auf den Service. Weitere Informationen findest du unter Steuern des Zugriffs auf VPC-Endpunkte mithilfe von Endpunktrichtlinien.

Überprüfung der Amazon S3-Bucket-Richtlinie

Überprüfe die Amazon S3-Bucket-Richtlinie, um sicherzustellen, dass die Richtlinie den Zugriff vom Gateway-VPC-Endpunkt und der VPC aus ermöglicht. Weitere Informationen findest du unter Steuerung des Zugriffs von VPC-Endpunkten aus mithilfe von Bucket-Richtlinien.

Hinweis: Deine Bucket-Richtlinie kann den Zugriff nur von einer bestimmten öffentlichen oder elastischen IP-Adresse aus einschränken, die einer Instance in einer VPC zugeordnet ist. Die Richtlinie kann den Zugriff auf der Grundlage von privaten IP-Adressen einschränken, die Instances zugeordnet sind. Weitere Informationen findest du unter Beispiele für Amazon S3-Bucket-Richtlinien.

Wenn du einen Proxyserver verwendest, stelle sicher, dass deine VPC-Verbindungen über den Server zulässig sind. Wenn du keinen Proxyserver für Amazon S3 verwendest, führe den folgenden Befehl aus, um den Proxyserver zu umgehen, wenn du auf deinen Bucket zugreifst:

export no_proxy = s3.example-Region.amazonaws.com