Behebung von RFC-Fehlern in AMS - AMS-Benutzerhandbuch für Fortgeschrittene
RFC-Fehler im Bereich „Verwaltung“RFC-Fehler bei der „Bereitstellung“RFC-Validierung versus AusführungsfehlerRFC-FehlermeldungenWie erhalte ich Hilfe bei einem RFC

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.

Behebung von RFC-Fehlern in AMS

Viele RFC-Fehler bei der AMS-Bereitstellung können anhand der Dokumentation untersucht werden. CloudFormation Weitere Informationen finden Sie unter AWS-Fehlerbehebung CloudFormation: Fehlerbehebung

In den folgenden Abschnitten finden Sie weitere Vorschläge zur Fehlerbehebung.

RFC-Fehler im Bereich „Verwaltung“ in AMS

Mit den AMS-Kategorieänderungstypen (CTs) können Sie Zugriff auf Ressourcen beantragen und vorhandene Ressourcen verwalten. In diesem Abschnitt werden einige häufig auftretende Probleme beschrieben.

RFC-Zugriffsfehler

  • Stellen Sie sicher, dass der Benutzername und der FQDN, die Sie im RFC angegeben haben, korrekt sind und in der Domäne vorhanden sind. Hilfe bei der Suche nach Ihrem FQDN finden Sie unter Finden Ihres FQDN.

  • Stellen Sie sicher, dass es sich bei der Stack-ID, die Sie für den Zugriff angegeben haben, um einen verwandten Stack handelt EC2. Stacks wie ELB und Amazon Simple Storage Service (S3) sind keine RFCs Zugriffskandidaten. Verwenden Sie stattdessen Ihre Nur-Lese-Zugriffsrolle, um auf diese Stack-Ressourcen zuzugreifen. Hilfe bei der Suche nach einer Stack-ID finden Sie unter Stack suchen IDs

  • Stellen Sie sicher, dass die von Ihnen angegebene Stack-ID korrekt ist und zum entsprechenden Konto gehört.

Hilfe bei anderen RFC-Zugriffsausfällen finden Sie unter Zugriffsverwaltung.

YouTube Video: Wie stelle ich einen Request for Change (RFC) richtig ein, um Ablehnungen und Ausfälle zu vermeiden?

RFC (manuell) CT-Planungsfehler

Die meisten Änderungstypen sind ExecutionMode =Automatisiert, aber einige sind ExecutionMode =Manuell, was sich darauf auswirkt, wie Sie sie planen sollten, um RFC-Fehler zu vermeiden.

Geplant RFCs mit ExecutionMode =Manual, muss so eingestellt sein, dass es mindestens 24 Stunden in der future ausgeführt wird, wenn Sie die AMS-Konsole verwenden, um den RFC zu erstellen. Dieser Vorbehalt gilt nicht für die AMS API/CLI, aber es ist dennoch wichtig, Manual RFCs mindestens 8 Stunden im Voraus zu planen.

AMS ist bestrebt, auf ein manuelles CT innerhalb von vier Stunden zu antworten und wird so schnell wie möglich antworten, aber es könnte viel länger dauern, bis der RFC tatsächlich ausgeführt wird.

Verwendung RFCs mit manuellem Update CTs

AMS Operations lehnt Management | Andere | Andere RFCs für Aktualisierungen von Stacks ab, wenn es für den Stacktyp, den Sie aktualisieren möchten, einen Aktualisierungstyp gibt.

RFC-Fehler beim Löschen des Stacks

RFC-Fehler beim Löschen von Stacks: Wenn Sie das CT Management | Standard Stacks | Stack | Delete verwenden, werden Ihnen in der CloudFormation Konsole die detaillierten Ereignisse für den Stack mit dem AMS-Stack-Namen angezeigt. Sie können Ihren Stack identifizieren, indem Sie ihn mit dem Namen vergleichen, den er in der AMS-Konsole hat. Die CloudFormation Konsole bietet weitere Informationen zu den Fehlerursachen.

Bevor Sie einen Stapel löschen, sollten Sie sich überlegen, wie der Stack erstellt wurde. Wenn Sie den Stack mit einem AMS-CT erstellt und die Stack-Ressourcen nicht hinzugefügt oder bearbeitet haben, können Sie davon ausgehen, dass Sie ihn problemlos löschen können. Es ist jedoch eine gute Idee, alle manuell hinzugefügten Ressourcen aus einem Stack zu entfernen, bevor Sie einen Löschstapel-RFC für diesen Stack einreichen. Wenn Sie beispielsweise einen Stack mit dem Full-Stack-CT (HA Two Tier) erstellen, enthält er eine Sicherheitsgruppe -. SG1 Wenn Sie dann AMS verwenden, um eine weitere Sicherheitsgruppe zu erstellen - und auf die neue SG2 Sicherheitsgruppe verweisen SG2, die als Teil des vollständigen Stacks SG1 erstellt wurde, und dann den Löschstapel-CT verwenden, um den Stack zu löschen, SG1 wird der nicht gelöscht, da er von referenziert wird SG2.

Wichtig

Das Löschen von Stacks kann unerwünschte und unerwartete Folgen haben. Aus diesem Grund zieht es AMS vor, Stacks oder Stack-Ressourcen nicht im Namen von Kunden zu löschen. Beachten Sie, dass AMS in Ihrem Namen nur Ressourcen löscht (durch einen eingereichten Änderungstyp Verwaltung | Andere | Andere | Aktualisierung), die nicht mit dem entsprechenden, automatisierten Änderungstyp gelöscht werden können. Weitere Überlegungen:

  • Wenn die Ressourcen für den Löschschutz aktiviert sind, kann AMS helfen, diesen zu entsperren, indem Sie den Änderungstyp Verwaltung | Andere | Andere | Aktualisierung einreichen. Nachdem der Löschschutz aufgehoben wurde, können Sie diese Ressource mit dem automatisierten CT löschen.

  • Wenn ein Stack mehrere Ressourcen enthält und Sie nur eine Teilmenge der Stack-Ressourcen löschen möchten, verwenden Sie den Änderungstyp CloudFormation Update (siehe CloudFormation Ingest Stack: Aktualisierung). Sie können auch den Änderungstyp Verwaltung | Andere | Andere | Aktualisierung angeben. Die AMS-Techniker können Ihnen bei Bedarf bei der Erstellung des Changesets helfen.

  • Falls aufgrund von Abweichungen Probleme bei der Verwendung des CloudFormation Update CT auftreten, kann AMS helfen, indem Sie ein Management | Other | Other | Other | Update zur Behebung des Fehlers einreichen (sofern vom CloudFormation AWS-Service unterstützt) und ein Update bereitstellen ChangeSet , das Sie dann mit den automatisierten CT, Management/Custom Stack/Stack From CloudFormation Template/Approve Changeset und Update validieren und ausführen können.

AMS hält sich an die oben genannten Einschränkungen, um sicherzustellen, dass es nicht zu unerwarteten oder unerwarteten Löschungen von Ressourcen kommt.

Weitere Informationen finden Sie unter Fehlerbehebung bei AWS CloudFormation: Stack löschen schlägt fehl.

DNS-Fehler beim RFC-Update

Es kann RFCs vorkommen, dass mehrere Aktualisierungen einer DNS-Hosting-Zone fehlschlagen, manchmal auch ohne Grund. Das RFCs gleichzeitige Erstellen mehrerer Zonen zur Aktualisierung von DNS-Hosting-Zonen (privat oder öffentlich) kann dazu führen RFCs , dass einige fehlschlagen, weil sie versuchen, denselben Stack gleichzeitig zu aktualisieren. AMS Change Management lehnt ab oder schlägt fehl RFCs , wenn ein Stack nicht aktualisiert werden kann, weil der Stack bereits von einem anderen RFC aktualisiert wird. AMS empfiehlt, dass Sie jeweils einen RFC erstellen und warten, bis der RFC erfolgreich ist, bevor Sie einen neuen für denselben Stack starten.

Fehler bei RFC-IAM-Entitäten

AMS stellt eine Reihe von Standard-IAM-Rollen und -Profilen für AMS-Konten bereit, die auf Ihre Bedürfnisse zugeschnitten sind. Möglicherweise müssen Sie jedoch gelegentlich zusätzliche IAM-Ressourcen anfordern.

Das Verfahren zur Einreichung von RFCs Anfragen für benutzerdefinierte IAM-Ressourcen folgt dem Standardablauf für manuelle Anwendungen. Der Genehmigungsprozess umfasst jedoch auch eine Sicherheitsüberprüfung RFCs, um sicherzustellen, dass angemessene Sicherheitskontrollen vorhanden sind. Daher dauert der Vorgang in der Regel länger als bei anderen manuellen RFCs Vorgängen. Um die Zykluszeit bei diesen zu reduzieren RFCs, befolgen Sie bitte die folgenden Richtlinien.

Informationen darüber, was wir unter einer IAM-Überprüfung verstehen und wie sie unseren technischen Standards und unserem Prozess zur Risikoakzeptanz entspricht, finden Sie unterRFC-Sicherheitsüberprüfungen verstehen.

Häufig gestellte Anfragen zu IAM-Ressourcen:

  • Wenn Sie nach einer Richtlinie für eine wichtige Cloud-kompatible Anwendung fragen, wie z. B. CloudEndure, schauen Sie sich die vorab genehmigte CloudEndure IAM-Richtlinie von AMS an: Entpacken Sie die WIGs Cloud Endure Landing Zone-Beispieldatei und öffnen Sie die customer_cloud_endure_policy.json

    Anmerkung

    Wenn Sie eine restriktivere Richtlinie wünschen, besprechen Sie Ihre Bedürfnisse mit Ihrem Unternehmen und lassen Sie sich, falls erforderlich, von einem AMS Security Review CloudArchitect/CSDM und Signoff überzeugen, bevor Sie einen RFC zur Umsetzung der Richtlinie einreichen.

  • Wenn Sie eine von AMS standardmäßig in Ihrem Konto bereitgestellte Ressource ändern möchten, empfehlen wir Ihnen, anstelle von Änderungen an der vorhandenen eine modifizierte Kopie dieser Ressource anzufordern.

  • Wenn Sie Berechtigungen für einen menschlichen Benutzer anfordern (anstatt die Berechtigungen dem Benutzer zuzuweisen), ordnen Sie die Berechtigungen einer Rolle zu und gewähren Sie dem Benutzer dann die Erlaubnis, diese Rolle anzunehmen. Einzelheiten dazu finden Sie unter Temporärer Zugriff auf die AMS Advanced-Konsole.

  • Wenn Sie außergewöhnliche Berechtigungen für eine temporäre Migration oder einen temporären Workflow benötigen, geben Sie in Ihrer Anfrage ein Enddatum für diese Berechtigungen an.

  • Wenn Sie den Gegenstand Ihrer Anfrage bereits mit Ihrem Sicherheitsteam besprochen haben, legen Sie Ihrem CSDM so detailliert wie möglich einen Nachweis über deren Genehmigung vor.

Wenn AMS einen IAM-RFC ablehnt, geben wir einen klaren Grund für die Ablehnung an. Beispielsweise könnten wir eine Anfrage zur Erstellung einer IAM-Richtlinie ablehnen und erklären, was an der Richtlinie unangemessen ist. In diesem Fall können Sie die identifizierten Änderungen vornehmen und die Anfrage erneut einreichen. Wenn weitere Informationen zum Status einer Anfrage erforderlich sind, reichen Sie eine Serviceanfrage ein oder wenden Sie sich an Ihren CSDM.

In der folgenden Liste werden die typischen Risiken beschrieben, die AMS bei der Überprüfung Ihres IAM zu minimieren versucht. RFCs Wenn Ihr IAM-RFC eines dieser Risiken birgt, kann dies zur Ablehnung des RFC führen. In Fällen, in denen Sie eine Ausnahme benötigen, bittet AMS Ihr Sicherheitsteam um die Genehmigung. Um eine solche Ausnahme zu beantragen, stimmen Sie sich mit Ihrem CSDM ab.

Anmerkung

AMS kann aus beliebigem Grund jegliche Änderung der IAM-Ressourcen innerhalb eines Kontos ablehnen. Wenn Sie Bedenken bezüglich einer RFC-Ablehnung haben, wenden Sie sich über eine Serviceanfrage an AMS Operations oder wenden Sie sich an Ihren CSDM.

  • Eskalation von Rechten, z. B. Berechtigungen, die es Ihnen ermöglichen, Ihre eigenen Berechtigungen oder die Berechtigungen anderer Ressourcen innerhalb des Kontos zu ändern. Beispiele:

    • Die Verwendung iam:PassRole mit einer anderen, privilegierteren Rolle.

    • Zugriff auf attach/detach IAM-Richtlinien durch eine Rolle oder einen Benutzer.

    • Die Änderung der IAM-Richtlinien im Konto.

    • Die Fähigkeit, API-Aufrufe im Kontext der Verwaltungsinfrastruktur zu tätigen.

  • Berechtigungen zum Ändern von Ressourcen oder Anwendungen, die für die Bereitstellung von AMS-Diensten für Sie erforderlich sind. Beispiele:

    • Änderung der AMS-Infrastruktur wie der Bastions-, Management-Host- oder EPS-Infrastruktur.

    • Löschen von Protokollverwaltungsfunktionen, AWS Lambda Lambda-Funktionen oder Protokollstreams.

    • Das Löschen oder Ändern der CloudTrail Standard-Überwachungsanwendung.

    • Die Änderung des Active Directory (AD) der Verzeichnisdienste.

    • Deaktivierung CloudWatch (CW) von Alarmen.

    • Die Änderung der Principals, Richtlinien und Namespaces, die im Konto als Teil der landing zone bereitgestellt werden.

  • Bereitstellung von Infrastruktur außerhalb von bewährten Verfahren, wie z. B. Genehmigungen, die den Aufbau einer Infrastruktur in einem Zustand ermöglichen, der Ihre Informationssicherheit gefährdet. Beispiele:

    • Die Erstellung von öffentlichen oder unverschlüsselten S3-Buckets oder die öffentliche gemeinsame Nutzung von EBS-Volumes.

    • Die Bereitstellung öffentlicher IP-Adressen.

    • Die Änderung von Sicherheitsgruppen, um einen breiten Zugriff zu ermöglichen.

  • Zu weit gefasste Berechtigungen können Auswirkungen auf Anwendungen haben, z. B. Berechtigungen, die zu Datenverlust, Integritätsverlust, unangemessener Konfiguration oder Betriebsunterbrechungen für Ihre Infrastruktur und die Anwendungen innerhalb des Kontos führen können. Beispiele:

    • Deaktivierung oder Umleitung von Netzwerkverkehr über ähnliche oder. APIs ModifyNetworkInterfaceAttribute UpdateRouteTable

    • Deaktivierung der verwalteten Infrastruktur durch Trennen von Volumes von verwalteten Hosts.

  • Berechtigungen für Dienste, die nicht Teil der AMS-Servicebeschreibung sind und von AMS nicht unterstützt werden.

    Dienste, die nicht in der AMS-Servicebeschreibung aufgeführt sind, können nicht in AMS-Konten verwendet werden. Wenn Sie Support für eine Funktion oder einen Dienst anfordern möchten, wenden Sie sich bitte an Ihren CSDM.

  • Genehmigungen, die Ihr erklärtes Ziel nicht erfüllen, da sie entweder zu großzügig oder zu konservativ sind oder auf die falschen Ressourcen angewendet werden. Beispiele:

    • Eine Anfrage nach s3:PutObject Berechtigungen für einen S3-Bucket mit obligatorischer KMS-Verschlüsselung ohne KMS:Encrypt Berechtigungen für den entsprechenden Schlüssel.

    • Berechtigungen, die sich auf Ressourcen beziehen, die im Konto nicht vorhanden sind.

    • IAM RFCs , bei dem die Beschreibung des RFC nicht mit der Anfrage zu übereinstimmen scheint.

RFC-Fehler bei der „Bereitstellung“

Mit den Änderungstypen für die Kategorie „Einsatz“ (CTs) von AMS können Sie beantragen, dass Ihrem Konto verschiedene AMS-unterstützte Ressourcen hinzugefügt werden.

Die meisten AMS CTs , die eine Ressource erstellen, basieren auf CloudFormation Vorlagen. Als Kunde haben Sie Lesezugriff auf alle AWS-Services CloudFormation, einschließlich, Sie können anhand der CloudFormation Stack-Beschreibung mithilfe der Konsole schnell den Stack identifizieren, der Ihren Stack darstellt. CloudFormation Der ausgefallene Stack wird sich wahrscheinlich im Status DELETE_COMPLETE befinden. Sobald Sie den CloudFormation Stack identifiziert haben, zeigen Ihnen die Ereignisse, welche spezifische Ressource nicht erstellt werden konnte und warum.

Verwenden Sie die CloudFormation Dokumentation zur Fehlerbehebung

Die meisten AMS-Bereitstellungen RFCs verwenden eine CloudFormation Vorlage, und diese Dokumentation kann bei der Fehlerbehebung hilfreich sein. Die Dokumentation zu dieser CloudFormation Vorlage finden Sie in der Dokumentation:

Fehler beim Erstellen von AMIs RFC

Ein Amazon Machine Image (AMI) ist eine Vorlage, die eine Softwarekonfiguration enthält (z. B. ein Betriebssystem, einen Anwendungsserver und Anwendungen). Von einem AMI aus starten Sie eine Instance, bei der es sich um eine Kopie des AMI handelt, die als virtueller Server in der Cloud ausgeführt wird. AMIs sind sehr nützlich und werden benötigt, um EC2 Instanzen oder Auto Scaling Scaling-Gruppen zu erstellen. Sie müssen jedoch einige Anforderungen beachten:

  • Die Instanz, für die Sie angeben, Ec2InstanceId muss sich in einem gestoppten Zustand befinden, damit der RFC erfolgreich ist. Verwenden Sie für diesen Parameter keine Auto Scaling Scaling-Gruppeninstanzen (ASG), da die ASG eine gestoppte Instance beendet.

  • Um ein AMS Amazon Machine Image (AMI) zu erstellen, müssen Sie mit einer AMS-Instance beginnen. Bevor Sie die Instance zum Erstellen des AMI verwenden können, müssen Sie sie vorbereiten, indem Sie sicherstellen, dass sie gestoppt und von ihrer Domäne getrennt ist. Einzelheiten finden Sie unter Erstellen eines standardmäßigen Amazon-Computerabbilds mithilfe von Sysprep

  • Der Name, den Sie für das neue AMI angeben, muss innerhalb des Kontos eindeutig sein, sonst schlägt der RFC fehl. Wie das geht, ist unter AMI | Create beschrieben. Weitere Informationen finden Sie unter AWS AMI Design.

Anmerkung

Weitere Informationen zur Vorbereitung der AMI-Erstellung finden Sie unter AMI | Create.

RFCs Erstellen EC2s oder Fehler ASGs

Bei EC2 oder ASG-Ausfällen mit Timeouts empfiehlt AMS, zu überprüfen, ob das verwendete AMI angepasst ist. Falls ja, lesen Sie bitte die Schritte zur AMI-Erstellung in diesem Handbuch (siehe AMI | Create), um sicherzustellen, dass das AMI korrekt erstellt wurde. Ein häufiger Fehler beim Erstellen eines benutzerdefinierten AMI besteht darin, die Schritte im Handbuch zum Umbenennen oder Aufrufen von Sysprep nicht zu befolgen.

RFCs Erstellen von RDS-Fehlern

Fehler im Amazon Relational Database Service (RDS) können aus vielen verschiedenen Gründen auftreten, da Sie bei der Erstellung des RDS viele verschiedene Engines verwenden können und jede Engine ihre eigenen Anforderungen und Einschränkungen hat. Bevor Sie versuchen, einen AMS-RDS-Stack zu erstellen, überprüfen Sie die AWS-RDS-Parameterwerte sorgfältig, siehe Erstellen DBInstance.

Weitere Informationen zu Amazon RDS im Allgemeinen, einschließlich Größenempfehlungen, finden Sie in der Dokumentation zu Amazon Relational Database Service.

RFCs Amazon S3-Fehler erstellen

Ein häufiger Fehler beim Erstellen eines S3-Speicher-Buckets besteht darin, dass kein eindeutiger Name für den Bucket verwendet wird. Wenn Sie einen S3-Bucket Create CT mit demselben Namen wie einen zuvor eingereichten eingereicht haben, würde dies fehlschlagen, da bereits ein S3-Bucket mit diesem Bucket vorhanden wäre BucketName. Dies wird in der CloudFormation Konsole detailliert beschrieben, wo Sie sehen werden, dass das Stack-Ereignis anzeigt, dass der Bucket-Name bereits verwendet wird.

RFC-Validierung versus Ausführungsfehler

RFC-Fehler und zugehörige Meldungen unterscheiden sich in den Ausgabemeldungen auf der RFC-Detailseite der AMS-Konsole für einen ausgewählten RFC:

  • Die Gründe für Validierungsfehler sind nur im Statusfeld verfügbar

  • Die Gründe für Ausführungsfehler sind sowohl in den Feldern Ausführungsausgabe als auch in den Statusfeldern verfügbar.

Request for change details showing rejected status due to no domain trust found.

RFC-Fehlermeldungen

Wenn Sie bei den aufgelisteten Änderungstypen (CTs) auf den folgenden Fehler stoßen, können Sie diese Lösungen verwenden, um die Ursache der Probleme zu finden und sie zu beheben.

{"errorMessage":"An error has occurred during RFC execution. We are investigating the issue.","errorType":"InternalError"}

Wenn Sie weitere Unterstützung benötigen, nachdem Sie sich auf die folgenden Optionen zur Fehlerbehebung bezogen haben, wenden Sie sich per RFC-Korrespondenz an AMS oder stellen Sie eine Serviceanfrage. Weitere Informationen finden Sie unter RFC-Korrespondenz und Anhang (Konsole) und Erstellen einer Serviceanfrage in AMS.

Fehler bei der Workload Ingestion (WIGS)

Anmerkung

Validierungstools für Windows und Linux können heruntergeladen und direkt auf Ihren lokalen Servern sowie auf EC2 Instanzen in AWS ausgeführt werden. Diese finden Sie im AMS Advanced Application Developer's Guide Migrating workloads: Linux pre-ingestion validation und Migrating workloads: Windows pre-ingestion validation.

  • EC2 Stellen Sie sicher, dass die Instanz im AMS-Zielkonto vorhanden ist. Wenn Sie beispielsweise Ihr AMI von einem Nicht-AMS-Konto für ein AMS-Konto freigegeben haben, müssen Sie in Ihrem AMS-Konto eine EC2 Instance mit dem gemeinsam genutzten AMI erstellen, bevor Sie einen Workload Ingest RFC einreichen können.

  • Prüfen Sie, ob für die mit der Instance verbundenen Sicherheitsgruppen ausgehender Datenverkehr zulässig ist. Der SSM-Agent muss in der Lage sein, eine Verbindung zu seinem öffentlichen Endpunkt herzustellen.

  • Überprüfen Sie, ob die Instanz über die richtigen Berechtigungen verfügt, um eine Verbindung mit dem SSM-Agenten herzustellen. Diese Berechtigungen sind im Lieferumfang customer-mc-ec2-instance-profile enthalten. Sie können dies in der EC2 Konsole überprüfen:

    EC2 instance details showing IAM role set to customer-mc-ec2-instance-profile.

EC2 Fehler beim Stopp des Instance-Stacks

  • Prüfen Sie, ob sich die Instance bereits in einem gestoppten oder beendeten Zustand befindet.

  • Wenn die EC2 Instance online ist und Ihnen der InternalError Fehler angezeigt wird, senden Sie eine Serviceanfrage an AMS zur Untersuchung.

  • Beachten Sie, dass Sie den Änderungstyp Management | Advanced stack components | EC2 instance stack | Stop ct-3mvvt2zkyveqj nicht verwenden können, um eine Auto Scaling Scaling-Gruppeninstanz (ASG) zu stoppen. Wenn Sie eine ASG-Instance beenden müssen, reichen Sie eine Serviceanfrage ein.

EC2 Fehler beim Erstellen des Instanzstapels

Die InternalError Nachricht stammt von CloudFormation; ein Grund für den Status CREATION_FAILED. Einzelheiten zum Stack-Fehler finden Sie in CloudWatch Stack-Ereignissen, indem Sie die folgenden Schritte ausführen:

  • In der AWS-Managementkonsole können Sie eine Liste von Stack-Ereignissen anzeigen, während Ihr Stack erstellt, aktualisiert oder gelöscht wird. Finden Sie das Fehlerereignis in dieser Liste und sehen dann den Statusgrund für dieses Ereignis an.

    Der Statusgrund kann eine Fehlermeldung von AWS CloudFormation oder von einem bestimmten Service enthalten, die Ihnen helfen kann, das Problem zu verstehen.

  • Weitere Informationen zum Anzeigen von Stack-Ereignissen finden Sie unter CloudFormation AWS-Stack-Daten und -Ressourcen in der AWS-Managementkonsole anzeigen.

EC2 Fehler bei der Wiederherstellung des Instance-Volumes

AMS erstellt einen internen RFC zur Fehlerbehebung, wenn die Wiederherstellung des EC2 Instance-Volumes fehlschlägt. Dies geschieht, weil die Wiederherstellung des EC2 Instance-Volumes ein wichtiger Bestandteil der Notfallwiederherstellung (DR) ist und AMS diesen internen RFC zur Fehlerbehebung automatisch für Sie erstellt.

Wenn der interne RFC zur Fehlerbehebung erstellt wurde, wird ein Banner mit Links zum RFC angezeigt. Dieser interne RFC zur Fehlerbehebung bietet Ihnen mehr Einblick in RFC-Fehler. Anstatt Wiederholungsversuche zu senden, die zu denselben Fehlern RFCs führen, oder Sie müssen sich wegen dieses Fehlers manuell an AMS wenden, können Sie Ihre Änderungen verfolgen und wissen, dass AMS an dem Fehler arbeitet. Dadurch wird auch die time-to-recovery (TTR) -Metrik für ihre Änderung reduziert, da AMS-Operatoren proaktiv an dem RFC-Fehler arbeiten, anstatt auf Ihre Anfrage zu warten.

Wie erhalte ich Hilfe bei einem RFC

Sie können sich an AMS wenden, um die Ursache Ihres Fehlers zu ermitteln. Die AMS-Geschäftszeiten sind 24 Stunden am Tag, 7 Tage die Woche, 365 Tage im Jahr.

AMS bietet Ihnen verschiedene Möglichkeiten, um Hilfe zu bitten oder Serviceanfragen zu stellen.

  • Verwenden Sie die AMS-Konsole und senden Sie eine Serviceanfrage, um Informationen oder Beratung oder um Zugriff auf einen von AMS verwalteten IT-Service zu erhalten oder um einen zusätzlichen Service von AMS anzufordern. Einzelheiten finden Sie unter Serviceanfrage erstellen. Allgemeine Informationen zu AMS-Serviceanfragen finden Sie unter Verwaltung von Serviceanfragen.

  • Um ein Leistungsproblem mit dem AWS- oder AMS-Service zu melden, das sich auf Ihre verwaltete Umgebung auswirkt, verwenden Sie die AMS-Konsole und reichen Sie einen Vorfallbericht ein. Einzelheiten finden Sie unter Einen Vorfall melden. Allgemeine Informationen zum AMS Incident Management finden Sie unter Reaktion auf Vorfälle.

  • Wenn Sie spezielle Fragen dazu haben, wie Sie oder Ihre Ressourcen oder Anwendungen mit AMS zusammenarbeiten, oder um einen Vorfall zu eskalieren, senden Sie eine E-Mail an eine oder mehrere der folgenden Adressen:

    1. Wenn Sie mit der Serviceanfrage oder der Antwort auf den Vorfallbericht nicht zufrieden sind, senden Sie zunächst eine E-Mail an Ihren CSDM: ams-csdm@amazon.com

    2. Als Nächstes können Sie, falls eine Eskalation erforderlich ist, eine E-Mail an den AMS Operations Manager senden (aber Ihr CSDM wird das wahrscheinlich tun): ams-opsmanager@amazon.com

    3. Eine weitere Eskalation erfolgt an den AMS-Direktor: ams-director@amazon.com

    4. Schließlich sind Sie immer in der Lage, den AMS VP zu erreichen: ams-vp@amazon.com