Fehlerbehebung bei allgemeinen Amplify Problemen - AWS Amplify Hosten

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.

Fehlerbehebung bei allgemeinen Amplify Problemen

Die folgenden Informationen können Ihnen helfen, allgemeine Probleme mit Amplify Hosting zu beheben.

HTTP 429-Statuscode (Zu viele Anfragen)

Amplify steuert die Anzahl der Anfragen pro Sekunde (RPS) an Ihre Website auf der Grundlage der Verarbeitungszeit und der Datenübertragung, die eingehende Anfragen verbrauchen. Wenn Ihre Anwendung einen HTTP-Statuscode 429 zurückgibt, überschreiten eingehende Anfragen die für Ihre Anwendung vorgesehene Bearbeitungszeit und Datenübertragung. Dieses Anwendungslimit wird durch die Servicequote von Amplify verwaltet. REQUEST_TOKENS_PER_SECOND Weitere Informationen zu Kontingenten finden Sie unter Amplify Kontingente für Hosting-Dienste.

Um dieses Problem zu beheben, empfehlen wir, Ihre Anwendung zu optimieren, um die Anforderungsdauer und die Datenübertragung zu reduzieren und so den RPS der App zu erhöhen. Bei denselben 20.000 Tokens kann beispielsweise eine hochoptimierte SSR-Seite, die innerhalb von 100 Millisekunden reagiert, höhere RPS unterstützen als eine Seite mit einer Latenz von mehr als 200 Millisekunden.

In ähnlicher Weise verbraucht eine Anwendung, die eine Antwortgröße von 1 MB zurückgibt, mehr Token als eine Anwendung, die eine Antwortgröße von 250 KB zurückgibt.

Wir empfehlen Ihnen außerdem, den CloudFront Amazon-Cache zu nutzen, indem Sie Cache-Control Header so konfigurieren, dass die Zeit, in der eine bestimmte Antwort im Cache aufbewahrt wird, maximiert wird. Anfragen, die vom CloudFront Cache aus bedient werden, werden nicht auf das Ratenlimit angerechnet. Jede CloudFront Distribution kann bis zu 250.000 Anfragen pro Sekunde verarbeiten, sodass Sie Ihre App mithilfe des Caches sehr stark skalieren können. Weitere Informationen zum CloudFront Cache finden Sie unter Optimizing Caching and Availability im Amazon CloudFront Developer Guide.

In der Amplify-Konsole werden der Build-Status und die Uhrzeit der letzten Aktualisierung für meine App nicht angezeigt

Wenn Sie in der Amplify-Konsole zur Seite Alle Apps navigieren, wird für jede Ihrer Apps in der aktuellen Region eine Kachel angezeigt. Wenn der Build-Status, wie z. B. Bereitgestellt, und die Uhrzeit der letzten Aktualisierung für eine App nicht angezeigt werden, ist der App kein Production Phase-Branch zugeordnet.

Um die Apps in der Konsole aufzulisten, verwendet Amplify die ListApps API. Amplify verwendet das ProductionBranch.status Attribut, um den Build-Status anzuzeigen, und das ProductionBranch.lastDeployTime Attribut, um den Zeitpunkt der letzten Aktualisierung anzuzeigen. Weitere Informationen zu dieser API finden Sie ProductionBranchin der Amplify Hosting API-Dokumentation.

Verwenden Sie die folgenden Anweisungen, um dem Branch Ihrer App eine Production Phase zuzuordnen.

  1. Melden Sie sich bei der Amplify-Konsole an.

  2. Wählen Sie auf der Seite Alle Apps die App aus, die Sie aktualisieren möchten.

  3. Wählen Sie im Navigationsbereich App-Einstellungen und dann Branch-Einstellungen aus.

  4. Wählen Sie im Abschnitt Filialeinstellungen die Option Bearbeiten aus.

  5. Wählen Sie unter Produktionszweig den Namen der Filiale aus, die Sie verwenden möchten.

  6. Wählen Sie Speichern.

  7. Kehren Sie zur Seite „Alle Apps“ zurück. Der Build-Status und die Uhrzeit der letzten Aktualisierung sollten jetzt für Ihre App angezeigt werden.

Für neue Pull-Requests werden keine Webvorschauen erstellt

Mit der Webvorschau-Funktion können Sie eine Vorschau von Änderungen aus Pull-Requests anzeigen, bevor Sie sie zu einem Integrationszweig zusammenführen. Eine Webvorschau stellt jede an dein Repository gerichtete Pull-Anfrage an eine eindeutige Vorschau-URL bereit, die sich von der URL unterscheidet, die deine Hauptseite verwendet.

Wenn Sie Webvorschauen für Ihre App aktiviert haben, diese aber nicht für neue Apps erstellt werden PRs, untersuchen Sie, ob eine der folgenden Ursachen die Ursache für Ihr Problem ist.

  1. Prüfen Sie, ob Ihre App das maximale Branches per app Dienstkontingent erreicht hat. Weitere Informationen zu Kontingenten finden Sie unter Amplify Kontingente für Hosting-Dienste.

    Um innerhalb des Standardkontingents von 50 Branches pro App zu bleiben, sollten Sie das auto Löschen von Filialen in Ihrer App aktivieren. Dadurch wird verhindert, dass du in deinem Konto Branches anhäufst, die in deinem Repository nicht mehr existieren.

  2. Wenn Sie ein öffentliches GitHub Repository verwenden und Ihrer Amplify-App eine IAM-Servicerolle zugewiesen ist, erstellt Amplify aus Sicherheitsgründen keine Vorschauen. Beispielsweise benötigen Apps mit Backends und Apps, die auf der WEB_COMPUTE Hosting-Plattform bereitgestellt werden, eine IAM-Servicerolle. Daher können Sie für diese Arten von Apps keine Webvorschauen aktivieren, wenn ihr Repository öffentlich ist.

    Damit Webvorschauen für Ihre App funktionieren, können Sie entweder die Zuordnung der Dienstrolle aufheben (falls die App kein Backend hat oder keine WEB_COMPUTE App ist), oder Sie können das Repository privat machen. GitHub

Meine manuelle Bereitstellung bleibt in der Amplify-Konsole mit dem Status „Ausstehend“ hängen

Manuelle Bereitstellungen ermöglichen es Ihnen, Ihre Web-App mit Amplify Hosting zu veröffentlichen, ohne einen Git-Anbieter zu verbinden. Verwenden Sie eine der folgenden vier Bereitstellungsoptionen.

  1. Ziehen Sie Ihren Anwendungsordner per Drag & Drop in die Amplify-Konsole.

  2. Ziehen Sie eine ZIP-Datei (die die Build-Artefakte Ihrer Site enthält) per Drag & Drop in die Amplify-Konsole.

  3. Laden Sie eine .zip-Datei (die die Build-Artefakte Ihrer Site enthält) in einen Amazon S3 S3-Bucket hoch und verbinden Sie den Bucket mit einer App in der Amplify-Konsole.

  4. Verwenden Sie eine öffentliche URL, die auf eine ZIP-Datei (die die Build-Artefakte Ihrer Site enthält) in der Amplify-Konsole verweist.

Wir sind uns der Probleme mit der Drag-a-Drop-Funktionalität bewusst, wenn ein Anwendungsordner für eine manuelle Bereitstellung in der Amplify-Konsole verwendet wird. Diese Bereitstellungen können aus folgenden Gründen fehlschlagen.

  • Vorübergehende Netzwerkprobleme treten auf.

  • Während des Uploads gibt es eine lokale Änderung der Dateien.

  • Die Browsersitzung versucht, eine große Menge statischer Assets gleichzeitig hochzuladen.

Wir arbeiten zwar daran, die Zuverlässigkeit unserer Drag-and-Drop-Uploads zu verbessern, empfehlen jedoch, eine ZIP-Datei zu verwenden, anstatt die Anwendungsordner per Drag-and-Drop zu verschieben.

Wir empfehlen dringend, eine .zip-Datei in einen Amazon S3 S3-Bucket hochzuladen, da dadurch Dateiuploads von der Amplify-Konsole vermieden werden und eine höhere Zuverlässigkeit bei manuellen Bereitstellungen gewährleistet wird. Amplify Amazon S3 zur Integration in Amazon S3 vereinfacht diesen Prozess. Weitere Informationen finden Sie unter Bereitstellung einer statischen Website für Amplify aus einem Amazon S3 S3-Bucket.

Ich muss die Version Node.js meiner Anwendung aktualisieren

Die Amplify-Unterstützung für Apps, die die Versionen 16 und 18 von Node.js verwenden, endet am 15. September 2025. Anwendungen, die bereits bereitgestellt wurden, werden weiterhin ausgeführt. Nach diesem Datum können Sie jedoch erst dann Updates für Ihre Anwendung bereitstellen, wenn Sie ein Upgrade auf Node.js Version 20 oder höher durchführen.

Wenn Sie das Amazon Linux 2023 Build-Image verwenden, wird Node.js Version 20 standardmäßig unterstützt. Ab dem 15. September 2025 unterstützt das AL2 023-Image automatisch Node.js 22 und ändert seine Standardversion Node.js von 18 auf 22.

Amazon Linux 2 (AL2) unterstützt Node.js Version 20 oder höher nicht automatisch. Wenn Sie aktuell verwenden AL2, empfehlen wir Ihnen, auf AL2 023 zu wechseln. Sie können das Build-Image in der Amplify-Konsole ändern. Sie können auch ein benutzerdefiniertes Build-Image verwenden, das die von Ihnen angegebene Version von Node.js unterstützt.

Vor dem Upgrade empfehlen wir, dass Sie Ihre Anwendung in einem neuen Branch testen, um sicherzustellen, dass sie ordnungsgemäß funktioniert.

Upgrade-Optionen

Amplify Konsole Konsole

Sie können die Funktion für Live-Paketaktualisierungen in der Amplify-Konsole verwenden, um die zu verwendende Version von Node.js anzugeben. Detaillierte Anweisungen finden Sie unter Verwenden bestimmter Paket- und Abhängigkeitsversionen im Build-Image.

Benutzerdefiniertes Image

Wenn Sie ein benutzerdefiniertes Build-Image verwenden und NVM auf Ihrem Image installiert ist, können Sie es nvm install 20 zu Ihrem Dockerfile hinzufügen. Weitere Informationen zu den Anforderungen und Konfigurationsanweisungen für ein benutzerdefiniertes Build-Image finden Sie unter. Anpassen des Build-Images

Build-Einstellungen

Sie können die zu verwendende Version von Node.js in den amplify.yml Build-Einstellungen Ihrer Anwendung angeben, indem Sie den nvm use Befehl zum Abschnitt PreBuild-Befehle hinzufügen. Anweisungen zum Aktualisieren der Build-Einstellungen einer Anwendung finden Sie unterKonfiguration der Build-Einstellungen für eine Amplify-Anwendung.

Das folgende Beispiel zeigt, wie Sie die Buildeinstellungen anpassen, um die Standardversion von Node.js auf Node.js 18 festzulegen und ein Upgrade auf Node.js Version 20 in einem Testzweig namens durchzuführennode-20.

frontend: phases: preBuild: commands: - nvm use 18 - if [ "${AWS_BRANCH}" = "node-20" ]; then nvm use 20; fi
Warnung

Beachten Sie, dass preBuild Befehle nach Live-Paket-Updates ausgeführt werden. Die durch den nvm use Befehl angegebene Version von Node.js überschreibt die durch Live-Paketaktualisierungen festgelegte Version von Node.js.