View a markdown version of this page

Problembehandlung bei privaten Verbindungen - AWS DevOps Agentin
Eine DNS-Hostadresse wird nicht aufgelöst, oder der Datenverkehr erreicht den falschen OrtDie Verbindung steckt in Create failedDie Verbindung ist aktiv, aber die Funktionsregistrierung schlägt fehl und es wird ein Erreichbarkeitsfehler gemeldetDas TLS-Zertifikat des Anbieters ist nicht vertrauenswürdigDer OAuth-Token-Austausch kann nicht erreicht werdenEine private Verbindung kann nicht gelöscht werden, solange sie verwendet wirdResource Gateway oder ENIs bleiben erhalten, nachdem Sie eine Verbindung gelöscht habenHilfe anfordernVerwandte Themen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Problembehandlung bei privaten Verbindungen

Auf dieser Seite werden häufig auftretende Probleme beschrieben, die beim Erstellen oder Verwenden eines Verbindung zu privat gehosteten Tools herstellen for AWS DevOps Agents auftreten können, und wie diese behoben werden können. In jedem Abschnitt werden ein Symptom, die wahrscheinlichsten Ursachen und die Schritte zu seiner Behebung beschrieben.

Einen Überblick über die Funktionsweise privater Verbindungen finden Sie unterVerbindung zu privat gehosteten Tools herstellen.

Eine DNS-Hostadresse wird nicht aufgelöst, oder der Datenverkehr erreicht den falschen Ort

Symptom

Sie haben eine private Verbindung mit einem DNS-Namen für die Hostadresse erstellt, aber die Verbindung kann Ihren Dienst nicht erreichen. Dies ist am häufigsten der Fall, wenn es sich bei Ihrem Zieldienst um eine selbst gehostete GitLab Instance, einen internen Application Load Balancer (ALB) oder einen MCP-Server handelt, dessen Hostname nur in Ihrer VPC existiert.

Ein Fehler bei der DNS-Auflösung führt nicht zu einer Meldung, in der DNS erwähnt wird. Stattdessen wird es als generischer Erreichbarkeits- oder Anbieterfehler angezeigt, wenn Sie den Capability Provider registrieren oder verwenden. Beispielsweise wird möglicherweise ein Authentifizierungsfehler angezeigt Could not complete request to provider.Unable to connect to the MCP server at <endpoint>. The connection was interrupted., oder sogar ein Authentifizierungsfehler wie z. B. Authentication with provider failed. Da die Meldung nicht auf DNS verweist, überprüfen Sie die Ursache mithilfe der folgenden Überprüfung.

Ursache

Standardmäßig löst eine private Verbindung die Hostadresse mithilfe von öffentlichem DNS (dnsResolution: PUBLIC) auf. Wenn Ihr Hostname nur einen Eintrag in einer privat gehosteten Zone, eine Amazon Route 53 Resolver-Regel oder einen lokalen DNS-Server hat, schlägt die öffentliche Auflösung fehl und die Verbindung erreicht Ihren Service nie.

Wie kann man bestätigen, dass DNS die Ursache ist

  • Prüfen Sie, ob Ihre Hostadresse nur in Ihrer VPC aufgelöst wird. Führen Sie von einer Amazon EC2-Instance oder AWS CloudShell -Sitzung in derselben VPC aus. nslookup <your-host-address> Wenn es dort aufgelöst wird, aber nicht aus öffentlichem DNS, und Ihre private Verbindung verwendetdnsResolution: PUBLIC, ist die DNS-Auflösung die Ursache.

  • Testen Sie mit der IP-Adresse statt mit dem Namen. Erstellen Sie vorübergehend eine private Verbindung, die die private IP-Adresse des Ziels (oder eine Load Balancer-IP) für die Hostadresse anstelle des DNS-Namens verwendet. Wenn die Verbindung dann Ihren Dienst erreicht, war der frühere Fehler die DNS-Auflösung, nicht der Netzwerkpfad oder der Dienst selbst.

Resolution (Auflösung)

  • Wenn Ihr Hostname nur innerhalb Ihrer VPC aufgelöst wird, setzen Sie den DNS-Auflösungsmodus auf In VPC (IN_VPC), wenn Sie die Verbindung herstellen. In diesem Modus wird die Hostadresse in Ihrem VPC-Kontext aufgelöst, sodass reine private Hostnamen korrekt aufgelöst werden. Siehe Eine private Verbindung erstellen.

  • Der DNS-Auflösungsmodus wird bei der Erstellung ausgewählt und gilt für die von Ihnen angegebene Hostadresse. Sie können nicht ändern, wie das vom Service verwaltete Resource Gateway DNS nach der Erstellung auflöst. Wählen Sie daher im Voraus den richtigen Modus aus. Wenn Sie den falschen Modus ausgewählt haben, löschen Sie die Verbindung und stellen Sie sie im richtigen Modus neu her.

  • Wenn Sie eine IP-Adresse (statt eines DNS-Namens) für die Hostadresse angeben, hat der DNS-Auflösungsmodus keine Auswirkung, und der Datenverkehr wird direkt an diese IP weitergeleitet.

  • Wenn Sie diese IN_VPC für Ihr Setup nicht verwenden können, können Sie die Hostadresse stattdessen auf die private IP-Adresse des Ziels oder auf den DNS-Namen eines Load Balancers verweisen, der öffentlich auflösbar ist, aber an eine private IP weiterleitet.

Die Verbindung steckt in Create failed

Symptom

Nachdem Sie eine private Verbindung erstellt haben, zeigt die Konsole den Status Verbindung fehlgeschlagen an (und describe-private-connection gibt den Status zurückCREATE_FAILED).

Ursache

Das Erstellen ist in den meisten Fällen auf ein Konfigurationsproblem in der Anfrage oder in Ihrer VPC zurückzuführen und nicht auf einen Servicefehler. Wenn eine Verbindung den Status „Fehlgeschlagen“ hat, beschreibt der AWS DevOps Agent den Grund in dem failureMessage Feld. Lesen Sie daher das Feld, bevor Sie die Checkliste durcharbeiten.

Resolution (Auflösung)

Überprüfen Sie Folgendes in der angegebenen Reihenfolge:

  1. Lesen Sie failureMessage die Verbindungsdetails ein. Dieses Feld beschreibt, warum eine Verbindung den Status „Fehlgeschlagen“ hat. Es ist vorhanden, wenn der Status CREATE_FAILED oder lautetDELETE_FAILED:

aws devops-agent describe-private-connection \ --name my-mcp-tool-connection

failureMessageerscheint auch in der Ausgabe vonlist-private-connections. Wenn das Feld die Ursache nennt, handeln Sie entsprechend. Fehlt das Feld, wurde kein Grund zurückgegeben. Fahren Sie mit den verbleibenden Prüfungen fort.

  1. Portbereiche verwenden ein gültiges Format. Geben Sie jeden Portbereich entweder als einzelnen Port (z. B.443) oder als echten Bereich mit unterschiedlichen Start- und Endports (z. B.8080-8090) an. Ein „Bereich“, dessen Anfang und Ende identisch sind (z. B.443-443), wird abgelehnt. Sie können bis zu 11 Portbereiche angeben.

  2. Ihre Subnetze haben verfügbare IP-Adressen. Das Resource Gateway stellt Elastic Network Interfaces (ENIs) in den von Ihnen angegebenen Subnetzen bereit. Wenn diese Subnetze erschöpft sind, schlägt die Erstellung fehl. Wählen Sie Subnetze mit freiem Adressraum.

  3. Ihre Subnetze befinden sich in unterstützten Availability Zones. Amazon VPC Lattice unterstützt nicht jede Availability Zone. Führen Sie Folgendes aus und vergleichen Sie es mit den nicht unterstützten Zonen, die unter Private Verbindung erstellen aufgeführt sind:

aws ec2 describe-subnets \ --subnet-ids <your-subnet-ids> \ --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'

  1. Sie haben die Amazon VPC Lattice-Servicekontingente nicht erreicht. Prüfen Sie Ihr Konto anhand der Amazon VPC Lattice-Kontingente, insbesondere der Resource Gateway-Limits.

  2. Keine IAM-Richtlinie oder SCP blockiert die serviceverknüpfte Rolle. Das dienstverwaltete Ressourcen-Gateway wird über eine dienstverknüpfte Rolle erstellt. Wenn Ihre Organisation über Service Control Policies (SCPs) verfügt, die Amazon VPC Lattice- oder Amazon EC2-API-Aktionen einschränken, stellen Sie sicher, dass die serviceverknüpfte Rolle diese Ressourcen erstellen kann.

Wenn die Verbindung nach der Überprüfung all dieser Elemente weiterhin fehlschlägt, wenden Sie sich an den Support. AWS

Die Verbindung ist aktiv, aber die Funktionsregistrierung schlägt fehl und es wird ein Erreichbarkeitsfehler gemeldet

Symptom

Die private Verbindung erreicht den Status Aktiv, aber wenn Sie einen Capability Provider (z. B. einen MCP-Server) registrieren, der sie verwendet, schlägt die Registrierung fehl. Bei einem MCP-Server beschreibt die Fehlermeldung, dass die Erreichbarkeitsprüfung fehlgeschlagen ist. Möglicherweise wird eine der folgenden Optionen angezeigt:

  • The MCP server at '<endpoint>' timed out while initializing the session.(Eine ähnliche Variante bezieht sich auf das Auflisten von Ressourcen)

  • Unable to connect to the MCP server at <endpoint>. The connection was interrupted. Verify the server is running and accessible, then try again.

  • Unable to access tools from the MCP server at '<endpoint>' ...

  • Could not complete request to provider.(kann auch als erscheinenAPI error: 504)

Ursache

Eine private Verbindung, die Active erreicht, bestätigt, dass der Netzwerkpfad zu Ihrer VPC eingerichtet ist. Es bestätigt nicht, dass Ihr Zieldienst an der erwarteten Adresse und dem erwarteten Port antwortet. Wenn Sie einen Capability Provider registrieren, überprüft der AWS DevOps Agent, ob der Endpunkt erreichbar ist und reagiert. An dieser Stelle taucht ein falsch konfiguriertes Ziel auf. In der Meldung erfahren Sie, welcher Layer ausgefallen ist:

  • Eine Timeout-Meldung bedeutet, dass die Verbindung nie einen Abhördienst erreicht hat. In den meisten Fällen enthalten die Portbereiche der Verbindung nicht den Port des Endpunkts, die Hostadresse oder die DNS-Auflösung ist falsch oder eine Sicherheitsgruppe blockiert den Datenverkehr.

  • Die Meldung „Verbindung wurde unterbrochen“ bedeutet, dass die Verbindung zurückgesetzt oder unterbrochen wurde, in der Regel aufgrund eines TLS-Handshake-Fehlers oder beim Schließen der Verbindung durch den Dienst.

  • Eine Meldung, dass auf die Tools nicht zugegriffen werden kann, bedeutet, dass der Endpunkt geantwortet, die Anfrage jedoch abgelehnt hat. Dies ist in der Regel eher ein Autorisierungs- oder Anbieterfehler als ein Netzwerkproblem.

  • Die Meldung „Anfrage an den Anbieter konnte nicht abgeschlossen werden“ ist ein allgemeiner Fehler beim Abschließen der Anfrage an Ihren Endpunkt über die private Verbindung. Lesen Sie die folgenden Schritte zur Problembehebung.

Eine erfolgreiche Anfrage von einer Amazon EC2-Instance oder AWS CloudShell -Sitzung in Ihrer VPC bestätigt, dass der Service von dieser Testumgebung aus erreichbar ist. Es bestätigt nicht, dass das Resource Gateway dieselbe Endpunkt-URL, denselben Port, dasselbe DNS-Ziel oder dieselbe TLS-Konfiguration verwendet.

Bestätigen

  1. Wiederholen Sie den Test mit der genauen Endpunkt-URL, die Sie registriert haben, einschließlich des Pfads und aller nicht standardmäßigen Ports.

  2. Vergewissern Sie sich, dass der Port der Endpunkt-URL in den Portbereichen der privaten Verbindung enthalten ist.

  3. Vergewissern Sie sich, dass die Hostadresse der privaten Verbindung in den Load Balancer oder Dienst aufgelöst wird, der TLS an diesem Port beendet, und nicht in eine Task- oder Instanz-IP an einem anderen Anwendungsport.

  4. Vergewissern Sie sich, dass das Ziel HTTPS mit TLS 1.2 oder höher bereitstellt und die erwartete Zertifikatskette präsentiert.

  5. Vergewissern Sie sich, dass die Resource Gateway-Sicherheitsgruppe ausgehenden Verkehr auf dem Zielport zulässt und dass die Zielsicherheitsgruppe den entsprechenden eingehenden Verkehr zulässt.

Resolution (Auflösung)

  • Vergewissern Sie sich, dass die Portbereiche der Verbindung den Port des Endpunkts enthalten. Eine private Verbindung leitet nur den Datenverkehr in den Portbereichen weiter, die Sie bei der Erstellung konfiguriert haben. Wenn Sie keine Portbereiche angegeben haben, erlaubt die Verbindung nur Ports443. Die Verbindung unterbricht den Datenverkehr zu einem anderen Port ohne einen beschreibenden Fehler. Der unterbrochene Datenverkehr wird als Timeout, Unable to access tools Fehler oder Fehler angezeigtCould not complete request to provider.. Dies betrifft häufig Endpunkte an nicht standardmäßigen Anschlüssen (z. B.). https://tools.example.com:8089/mcp Ein erfolgreicher Test curl von einer EC2-Instance in derselben VPC schließt dies nicht aus — bei diesem Test wird die private Verbindung vollständig umgangen. Sie können Portbereiche nach der Erstellung nicht mehr ändern. Löschen Sie die private Verbindung, erstellen Sie sie erneut mit Portbereichen, die jeden Port in Ihrer Endpunkt-URL enthalten, und registrieren Sie den Capability Provider erneut.

  • Stellen Sie sicher, dass das Resource Gateway Ihr Ziel überhaupt erreichen kann. Dies ist das erste, was ausgeschlossen werden muss, wenn das Ziel in einem anderen AWS Konto oder vor Ort ausgeführt wird. Im dienstverwalteten Modus wird das Ressourcen-Gateway in der von Ihnen angegebenen VPC und den Subnetzen im selben Konto wie die private Verbindung erstellt, sodass die VPC eine Route zu Ihrem Ziel benötigt. Eine Verbindung, die Aktiv erreicht, bedeutet nur, dass die Netzwerkschnittstellen des Gateways erstellt wurden und fehlerfrei sind. Das bedeutet nicht, dass sie Ihren Service erreichen können. Prüfen Sie den Verbindungsmodus und die VPC des Gateways und bestätigen Sie dann die Route:

aws devops-agent list-private-connections aws vpc-lattice list-resource-gateways

Wenn die VPC des Gateways keine Route zum Ziel hat, fügen Sie entweder eine über VPC-Peering, AWS Transit Gateway oder eine VPN-Verbindung (Virtual Private Network) hinzu oder verschieben Sie das Gateway im selbstverwalteten Modus auf das Konto des Ziels. Siehe Eine private Verbindung erstellen.

  • Richten Sie DNS auf den Load Balancer, nicht auf eine Task- oder Instanz-IP. Eine häufige Ursache ist ein DNS-Datensatz oder eine Hostadresse, die in eine Container-Aufgabe oder Instance-IP an einem Anwendungsport aufgelöst wird (z. B.8100), anstatt in den Load Balancer, der TLS auf dem von Ihnen konfigurierten Port beendet (z. B.). 443 Vergewissern Sie sich, dass die Hostadresse in den Endpunkt aufgelöst wird, der tatsächlich HTTPS auf dem Zielport bereitstellt.

  • Vergewissern Sie sich, dass der Dienst HTTPS auf dem konfigurierten Port bereitstellt. Das Ziel muss HTTPS mit einer TLS-Version von mindestens 1.2 auf einem Port bereitstellen, der in den Portbereichen der Verbindung enthalten ist.

  • Überprüfen Sie die Sicherheitsgruppenregeln in beide Richtungen. Stellen Sie sicher, dass die an die Ressourcen-Gateway-ENIs angehängte Sicherheitsgruppe ausgehenden Verkehr auf dem Zielport zulässt und dass die Sicherheitsgruppe Ihres Dienstes eingehenden Verkehr auf diesem Port zulässt. Der Datenverkehr kommt von den IP-Adressen der Amazon VPC Lattice-Datenebene innerhalb Ihres VPC-CIDR-Bereichs an. Sie können die Referenzierung von Sicherheitsgruppen verwenden (die ENI-Sicherheitsgruppe als Quelle zulassen) oder eingehenden Datenverkehr vom VPC-CIDR zulassen. Siehe Firewallregeln für private Verbindungen konfigurieren.

  • Überprüfen Sie die vollständige Zertifikatskette für eine private CA. Wenn eine private Zertifizierungsstelle das TLS-Zertifikat Ihres Dienstes ausgestellt hat, geben Sie die vollständige PEM-encoded Zertifikatskette an, wenn Sie die Verbindung herstellen. Platzieren Sie zuerst das Leaf-Zertifikat, dann die Zwischenprodukte und dann das Stammzertifikat. Wenn die Kette unvollständig ist, schlägt der TLS-Handshake fehl, obwohl der Netzwerkpfad aktiv ist. Die dadurch erzeugten Fehlermeldungen finden Sie unter Das TLS-Zertifikat des Anbieters ist nicht vertrauenswürdig.

  • Vergewissern Sie sich, dass das Ziel ausgeführt wird. Vergewissern Sie sich, dass Ihr Dienst aktiv ist und Verbindungen auf dem erwarteten Port akzeptiert, bevor Sie die Registrierung abschließen.

Das TLS-Zertifikat des Anbieters ist nicht vertrauenswürdig

Symptom

Die Registrierung oder Verwendung eines Capability Providers schlägt mit einem Zertifikatsfehler fehl. Die Formulierung hängt vom Funktionstyp ab, aber alle beschreiben dieselbe Problemklasse:

  • Could not establish a trusted TLS connection to the provider host: its certificate could not be validated against a publicly trusted certificate authority.

  • The server is using a self-signed TLS certificate. Use a certificate from a publicly trusted certificate authority.

  • The server's TLS certificate could not be verified. Ensure the full certificate chain is served and issued by a publicly trusted certificate authority.

  • The server's TLS certificate has expired. Renew the certificate.

  • The server's TLS certificate does not match the endpoint hostname. Ensure the certificate covers the endpoint's domain.

Ursache

AWS DevOps Der Agent konnte die von Ihrem Dienst angebotene Zertifikatskette nicht validieren. Die häufigsten Ursachen sind ein von einer privaten oder internen Zertifizierungsstelle (CA) ausgestelltes Zertifikat, eine Kette, der die Zwischenzertifikate fehlen, ein abgelaufenes Zertifikat in der Kette oder ein Zertifikat, das den Hostnamen in Ihrer Endpunkt-URL nicht abdeckt.

Anmerkung

In diesen Nachrichten wird ein Zertifikat von einer öffentlich vertrauenswürdigen Zertifizierungsstelle angefordert, eine private CA wird jedoch unterstützt. Stellen Sie die Kette über die private Verbindung bereit, wie in den Lösungsschritten beschrieben.

Bestätigen

Untersuchen Sie von einer Amazon EC2-Instance oder AWS CloudShell -Sitzung aus, die Ihr Ziel erreichen kann, die Kette, die Ihr Service auf dem von Ihnen konfigurierten Port darstellt, und überprüfen Sie, welche CA den Anfang der Kette signiert hat:

openssl s_client -connect <your-host-address>:<port> -showcerts

Wenn eine interne CA das Zertifikat signiert hat, geben Sie die Kette auf der Verbindung an. Wenn es von einer öffentlichen CA signiert wurde, ist die Kette, die Ihr Service sendet, wahrscheinlich unvollständig.

Resolution (Auflösung)

  • Geben Sie für ein Zertifikat von einer privaten CA die gesamte Kette auf der privaten Verbindung an. Stellen Sie den öffentlichen Schlüssel des Zertifikats in der Konsole oder im certificate Feld in create-private-connection auf die gesamte PEM-encoded Kette ein: zuerst das Leaf-Zertifikat, dann alle Zwischenzertifikate der Zertifizierungsstelle, dann das Stammzertifikat. Siehe Eine private Verbindung erstellen.

  • Für ein Zertifikat von einer öffentlichen CA senden Sie die komplette Kette. Konfigurieren Sie Ihren Service so, dass er das Leaf-Zertifikat plus alle Zwischenzertifikate sendet, nicht das Leaf allein.

  • Ersetzen Sie alle abgelaufenen Zertifikate in der Kette.

  • Bestätigen Sie, dass das Zertifikat den Hostnamen in Ihrer Endpunkt-URL abdeckt.

Der OAuth-Token-Austausch kann nicht erreicht werden

Symptom

Sie haben einen OAuth-based MCP-Server (Client Credentials oder 3LO) oder einen Remote-Agent registriert, der OAuth-Client-Anmeldeinformationen über eine private Verbindung verwendet, aber der Token-Austausch schlägt fehl, obwohl der MCP-Server oder der Remote-Agent-Endpunkt erreichbar ist.

Ursache

Bei Anbietern OAuth-based von Funktionen ruft der AWS DevOps Agent zwei Endpunkte auf: die Ziel-URL (der MCP-Server oder der Remote-Agent-Endpunkt) und die Exchange-URL (der OAuth-Token-Exchange-Endpunkt). Wenn Sie eine einzelne private Verbindung auswählen, gilt sie für beide Endpunkte. Wenn die beiden Endpunkte nur über unterschiedliche Netzwerkpfade erreichbar sind, kann eine einzelne private Verbindung nicht zu beiden weitergeleitet werden.

Resolution (Auflösung)

  • Wenn beide Endpunkte über denselben Pfad erreichbar sind, stellen Sie sicher, dass die Hostadresse der privaten Verbindung sowohl zum MCP-Server- oder Remote-Agent-Endpunkt als auch zum Token-Exchange-Endpunkt weitergeleitet werden kann.

  • Wenn für die Endpunkte unterschiedliche Netzwerkpfade erforderlich sind, verwenden Sie die Felder pro Endpunkt anstelle eines einzelnen. privateConnectionName Wird targetUrlPrivateConnectionName für den MCP-Server- oder Remote-Agent-Endpunkt und exchangeUrlPrivateConnectionName für den Token-Exchange-Endpunkt festgelegt. Wenn Sie nur einen festlegen, wird der andere Endpunkt über das öffentliche Internet erreicht, und es wird nicht auf die andere private Verbindung zurückgegriffen. Sie können die Namen pro Endpunkt nicht privateConnectionName in derselben Anfrage kombinieren. Weitere Informationen finden Sie unter Routing des Endpunkts und des OAuth-Tokenaustauschs über verschiedene private Verbindungen.

Eine private Verbindung kann nicht gelöscht werden, solange sie verwendet wird

Symptom

Das Löschen einer privaten Verbindung schlägt fehl mit Private connection '<name>' is in use by one or more services. Deregister the services first.

Ursache

Eine private Verbindung kann nicht gelöscht werden, solange ein registrierter Capability Provider noch darauf verweist. AWS DevOps Der Agent lehnt den Löschvorgang ab, bevor er Ressourcen entfernt, sodass Ihre Verbindung im aktuellen Zustand bleibt.

Resolution (Auflösung)

  1. Identifizieren Sie die Funktionsanbieter, die die Verbindung verwenden, und heben Sie sie entweder ab oder aktualisieren Sie sie, sodass sie sie nicht mehr verwenden.

  2. Löschen Sie die private Verbindung.

Das Entfernen eines Funktionsanbieters aus einem Agentenbereich ist nicht dasselbe wie dessen Abmeldung. Eine Registrierung ist auf Kontoebene vorhanden. Entfernen Sie sie daher aus allen Agent Spaces und löschen Sie dann die Registrierung, bevor Sie die Verbindung löschen.

Resource Gateway oder ENIs bleiben erhalten, nachdem Sie eine Verbindung gelöscht haben

Symptom

Sie haben erwartet, dass das verwaltete Resource Gateway und seine ENIs entfernt werden, aber sie werden immer noch in Ihrer VPC angezeigt. Dadurch können ENI-Gebühren anfallen und Operationen blockiert werden, die von einer sauberen VPC abhängen, wie z. terraform destroy

Ursache

Das verwaltete Resource Gateway und die ENIs werden nur entfernt, wenn Sie die private Verbindung über den Agenten löschen. AWS DevOps Die häufigsten Gründe dafür sind, dass sie nie aufgerufen DeletePrivateConnection wurden oder dass das AWSAIDevOpsManaged Tag aus den verwalteten Ressourcen entfernt wurde, sodass das Löschen nicht fortgesetzt werden kann.

Wichtig

AWS DevOps Der Agent taggt die Ressourcen, die er verwaltet (das Ressourcen-Gateway und seine ENIs), mitAWSAIDevOpsManaged. Die serviceverknüpfte Rolle kann nur auf Ressourcen angewendet werden, die dieses Tag tragen. Entfernen oder ändern Sie das AWSAIDevOpsManaged Tag daher nicht. Wenn das Tag fehlt, DeletePrivateConnection können die Ressourcen nicht bereinigt werden und das Löschen schlägt fehl.

Resolution (Auflösung)

  • Löschen Sie die Verbindung über den AWS DevOps Agenten. Verwenden Sie die Konsole (Capability Providers > Private Verbindungen > Aktionen > Entfernen) oder die CLI:

aws devops-agent delete-private-connection \ --name my-mcp-tool-connection

Der Status ändert sich in, DELETE_IN_PROGRESS während der AWS DevOps Agent das verwaltete Ressourcen-Gateway und die ENIs aus Ihrer VPC entfernt.

  • Wenn das Löschen fehlschlägt, vergewissern Sie sich, dass das AWSAIDevOpsManaged Tag noch vorhanden ist. Wenn das Tag vom Ressourcen-Gateway oder seinen ENIs entfernt wurde, wenden Sie es erneut auf diese Ressourcen an und führen Sie den Löschvorgang erneut durch.

  • Versuchen Sie nicht, das verwaltete Resource Gateway direkt zu löschen. Das Resource Gateway ist in Ihrem Konto schreibgeschützt und wird vollständig vom AWS DevOps Agenten verwaltet. Sie können es nicht selbst über Amazon VPC Lattice löschen. Das Löschen der privaten Verbindung löst ihre Entfernung aus.

  • Wenn Sie die private Verbindung gelöscht haben, das Tag vorhanden ist und das Ressourcen-Gateway oder die ENIs auch nach Abschluss des Löschvorgangs noch vorhanden sind. Wenden Sie sich an den AWS Support, um die Ressourcen abzugleichen.

Hilfe anfordern

Wenn Sie den entsprechenden Abschnitt für Ihr Problem durchgearbeitet haben und das Problem weiterhin besteht, wenden Sie sich an den AWS Support. Geben Sie den Namen Ihrer privaten Verbindung, den aktuellen Status, die AWS Region sowie die Zielhostadresse und den Port an, damit der Support den Netzwerkpfad untersuchen kann.