Ein systematischer Leitfaden zur Fehlerbehebung bei AWS-Service-Problemen

Wenn ein AWS-Service-Problem auftritt, ist Raten Zeitverschwendung und verschlimmert den Vorfall oft. Ein systematischer AWS-Troubleshooting-Workflow hilft Ihnen, das Symptom zu definieren, die richtigen Beweise zu prüfen, die Ursache zu isolieren und das Problem zu beheben, ohne drei Dinge gleichzeitig zu ändern.

Verwenden Sie diesen Leitfaden, wenn Sie mit einer nicht erreichbaren EC2-Instanz, einem AccessDenied-Fehler, einem gedrosselten API-Aufruf, einer fehlschlagenden Lambda-Funktion oder einem anderen AWS-Service-Problem konfrontiert sind, bei dem die Ursache nicht offensichtlich ist.

Die systematische Fehlerbehebungsmethodik

Effektive Fehlerbehebung bedeutet nicht Raten, sondern das Befolgen eines logischen, wiederholbaren Prozesses. Die Annahme einer strukturierten Methodik stellt sicher, dass Sie alle notwendigen Informationen sammeln, plausible Hypothesen aufstellen und diese effizient testen. Hier ist eine Aufschlüsselung der Kernschritte:

1. Definieren Sie das Problem klar

Bevor Sie in Logs eintauchen, nehmen Sie sich einen Moment Zeit, um das Problem gründlich zu verstehen. Fragen Sie sich:

Was genau ist das Problem? (z.B. EC2-Instanz nicht erreichbar, S3-Uploads fehlschlagen, Lambda-Funktion timeout).
Wann hat es begonnen? Ist es konstant oder intermittierend? Gibt es bestimmte Zeiten, zu denen es auftritt?
Wo passiert es? Welche Region, Availability Zone, welcher Service oder welche spezifische Ressource?
Wer ist betroffen? Alle Benutzer, eine bestimmte Gruppe oder interne Systeme?
Wie oft tritt es auf? Ist es ein einmaliges Ereignis oder ein wiederkehrendes Muster?
Welche Auswirkungen hat es? Ist die Schwere kritisch, hoch, mittel oder niedrig?

Tipp: Überprüfen Sie kürzliche Bereitstellungen, Terraform- oder CloudFormation-Änderungen, IAM-Bearbeitungen, Routentabellen-Updates und Sicherheitsgruppen-Änderungen, bevor Sie tiefer graben.

2. Sammeln Sie Informationen und beobachten Sie

Hier kommen die leistungsstarken Überwachungs- und Protokollierungstools von AWS ins Spiel. Sammeln Sie so viele relevante Daten wie möglich, ohne Änderungen vorzunehmen.

Überprüfen Sie das AWS Health Dashboard: Suchen Sie nach kontospezifischen Ereignissen, regionalen Service-Ereignissen oder geplanten Wartungsarbeiten.
Überprüfen Sie CloudWatch-Metriken: Untersuchen Sie relevante Metriken für Ihren Service (z.B. CPU-Auslastung, Netzwerk-I/O, Fehlerraten, gedrosselte Anfragen).
Analysieren Sie CloudWatch-Logs: Tauchen Sie in Anwendungslogs, VPC-Flow-Logs, Lambda-Logs usw. ein, um Fehler oder ungewöhnliche Muster zu finden.
Konsultieren Sie CloudTrail-Logs: Identifizieren Sie kürzliche API-Aufrufe, besonders wenn Sie unbefugten Zugriff oder Fehlkonfigurationen vermuten.
Überprüfen Sie die Konfiguration: Verwenden Sie AWS Config, um zu sehen, ob sich Ressourcenkonfigurationen kürzlich geändert haben.
Überprüfen Sie den Ressourcenstatus: Verifizieren Sie den Status von Instanzen, Datenbanken, Load Balancern in ihren jeweiligen Konsolen.

3. Stellen Sie eine Hypothese auf

Basierend auf den gesammelten Informationen schlagen Sie eine oder mehrere wahrscheinliche Ursachen für das Problem vor. Ihre Hypothese sollte spezifisch und testbar sein. Zum Beispiel:

"Die EC2-Instanz ist nicht erreichbar, weil ihre Sicherheitsgruppe keinen eingehenden SSH-Verkehr zulässt."
"S3-Uploads schlagen aufgrund eines Access Denied-Fehlers fehl, was auf eine falsche IAM-Richtlinie hindeutet."
"Die Lambda-Funktion hat einen Timeout, weil sie ein Service-Concurrency-Limit erreicht."

4. Testen Sie die Hypothese und isolieren Sie Variablen

Entwerfen Sie einen einfachen Test, um Ihre Hypothese zu beweisen oder zu widerlegen. Wenn Ihr erster Test das Problem nicht löst, verfeinern Sie Ihre Hypothese und testen Sie erneut. Nehmen Sie beim Testen jeweils nur eine Änderung vor, um die Ursache-Wirkung leicht zu identifizieren.

Beispiel (Konnektivität): Wenn Sie ein Sicherheitsgruppenproblem vermuten, testen Sie von einer bekannten Quell-IP und einem Port. Wenn das beweist, dass die Regel das Problem ist, ersetzen Sie den temporären Test durch die enge Regel, die Sie tatsächlich benötigen.
Beispiel (Berechtigungen): Verwenden Sie den IAM Policy Simulator, um verschiedene IAM-Richtlinien gegen die fehlschlagenden Aktionen zu testen.

5. Beheben und verifizieren

Sobald Sie die Ursache identifiziert haben, implementieren Sie die entsprechende Lösung. Überprüfen Sie nach der Anwendung der Lösung gründlich, ob das Problem behoben ist und keine neuen Probleme aufgetreten sind.

6. Dokumentieren und lernen

Dokumentieren Sie nach der Behebung das Problem, die Diagnoseschritte, die Ursache und die Lösung. Dies schafft eine wertvolle Wissensdatenbank für zukünftige Vorfälle und hilft, die Widerstandsfähigkeit Ihres Systems zu verbessern. Erwägen Sie eine Post-Mortem-Analyse für kritische Probleme, um vorbeugende Maßnahmen zu identifizieren.

Wichtige AWS-Troubleshooting-Tools und -Ressourcen

AWS bietet eine umfangreiche Suite von Tools, die für die Diagnose von Problemen unerlässlich sind.

Amazon CloudWatch

Ihr primäres Tool zur Überwachung von Ressourcen und Anwendungen. CloudWatch bietet:

Metriken: Echtzeit-Datenpunkte für praktisch jeden AWS-Service (CPU-Auslastung, Netzwerk-I/O, S3-Anfragezahlen, DynamoDB-gedrosselte Ereignisse, Lambda-Aufrufe/Fehler). Erstellen Sie benutzerdefinierte Metriken für anwendungsspezifische Daten.
Logs: Zentralisierte Protokollierung für fast jede Quelle (EC2, Lambda, VPC-Flow-Logs, CloudTrail, Anwendungslogs). Verwenden Sie CloudWatch Logs Insights für leistungsstarke Abfragen und Analysen.
Alarme: Legen Sie Schwellenwerte für Metriken fest, um Benachrichtigungen (über SNS) oder automatisierte Aktionen (z.B. Auto-Scaling) auszulösen.
Dashboards: Erstellen Sie benutzerdefinierte Dashboards, um wichtige Metriken und Logs zu visualisieren und eine zentrale Ansicht der Betriebsgesundheit zu erhalten.

AWS CloudTrail

CloudTrail zeichnet API-Aktivitäten in Ihrem AWS-Konto auf und zeigt, wer was wann, von wo und mit welchem Ergebnis getan hat. Es ist unverzichtbar für Sicherheitsuntersuchungen, Compliance-Audits und, entscheidend, für die Fehlerbehebung bei Problemen im Zusammenhang mit Berechtigungen oder unbeabsichtigten Ressourcenänderungen.

Verwendung: Suchen Sie nach Access Denied-Ereignissen, UPDATE-, DELETE- oder CREATE-Operationen, die mit dem Beginn des Problems zusammenfallen.

Beispiel-Athena-Abfrage für CloudTrail-Logs in S3:

SELECT eventtime, eventsource, eventname, useridentity.arn, errorcode, errormessage
FROM cloudtrail_logs
WHERE eventtime > current_timestamp - interval '1' hour
  AND (errorcode LIKE '%AccessDenied%' OR errormessage LIKE '%denied%')
ORDER BY eventtime DESC
LIMIT 100

AWS Management Console

Jede Service-Konsole bietet spezifische Dashboards, Statusseiten und Konfigurationsdetails. Dies ist oft der erste Ort, um die Ressourcengesundheit und -einstellungen zu überprüfen. Zum Beispiel zeigt die EC2-Konsole den Instanzstatus, Sicherheitsgruppen und Netzwerkschnittstellen.

AWS CLI/SDKs

Für programmatische Überprüfungen, Automatisierung und schnelle Ad-hoc-Abfragen sind die AWS Command Line Interface (CLI) und Software Development Kits (SDKs) unverzichtbar. Sie ermöglichen es Ihnen, Informationen abzurufen, Konfigurationen zu ändern und direkt von Ihrem Terminal oder Ihrer Anwendung aus mit Diensten zu interagieren.

Beispiel (Sicherheitsgruppenregeln überprüfen):

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0

AWS Health Dashboard

Bietet personalisierte Informationen über die Gesundheit von AWS-Services und Ihrem Konto. Es ist entscheidend, um zu verstehen, ob ein Problem kontospezifisch oder ein breiteres AWS-Service-Ereignis ist. Es zeigt Betriebsprobleme, geplante Wartungsarbeiten und personalisierte Warnungen an.

AWS Config

Zeichnet Konfigurationsänderungen für Ihre AWS-Ressourcen auf. Wenn sich eine Ressource plötzlich unerwartet verhält, kann Config Ihnen den Konfigurationsverlauf anzeigen und genau bestimmen, wann und wie eine Änderung vorgenommen wurde.

Häufige AWS-Problemkategorien und Lösungen

Die meisten AWS-Probleme fallen in einige wenige wiederkehrende Kategorien. Das Verständnis dieser Muster hilft bei der Bildung genauer Hypothesen.

1. Konnektivitätsprobleme

Wenn Ressourcen nicht kommunizieren können, überprüfen Sie den Netzwerkpfad:

Sicherheitsgruppen & Netzwerk-ACLs (NACLs): Dies sind die häufigsten Übeltäter. Sicherheitsgruppen sind zustandsbehaftet und gelten für Instanzen/ENIs; NACLs sind zustandslos und gelten für Subnetze. Überprüfen Sie, ob die Eingangs-/Ausgangsregeln den erforderlichen Verkehr zulassen.
- Tipp: Denken Sie daran, dass Sicherheitsgruppen Allow-Listen sind. NACLs haben sowohl Allow- als auch Deny-Regeln. Die Reihenfolge ist bei NACLs wichtig.
Routentabellen: Stellen Sie sicher, dass Ihre Subnetze korrekte Routen zum Internet (über Internet Gateway), zu anderen VPCs (Peering) oder zu lokalen Netzwerken (VPN/Direct Connect) haben.
DNS-Auflösung: Wenn Ressourcen Hostnamen nicht auflösen können, überprüfen Sie die VPC-DNS-Einstellungen, Route-53-Konfigurationen oder anwendungsspezifische DNS-Einstellungen.
VPC-Flow-Logs: Für tiefgehende Netzwerk-Fehlerbehebung zeichnen Flow-Logs den gesamten IP-Verkehr zu und von Netzwerkschnittstellen in Ihrer VPC auf. Analysieren Sie sie in CloudWatch Logs Insights, um akzeptierte/abgelehnte Verbindungen zu sehen.
```
fields @timestamp, @message
| filter logStatus = 'OK'
| filter action = 'REJECT'
| filter srcAddr = '192.0.2.1' or dstAddr = '192.0.2.1' -- IP von Interesse
| sort @timestamp desc
```

2. Berechtigungsfehler (Access Denied)

Diese treten häufig auf und werden durch Access Denied-, UnauthorizedOperation- oder Forbidden-Meldungen angezeigt.

IAM-Richtlinien: Überprüfen Sie die angehängten IAM-Richtlinien für den Benutzer, die Rolle oder die Gruppe, die die Aktion ausführt. Stellen Sie sicher, dass sie Allow-Anweisungen für die spezifische Action auf der korrekten Resource enthalten.
- Tipp: IAM-Richtlinien sind standardmäßig deny. Sie benötigen explizites allow.

Ressourcenrichtlinien: Einige Services, darunter S3, SQS, KMS, SNS und Lambda, unterstützen ressourcenbasierte Richtlinien, die den Zugriff direkt auf der Ressource gewähren oder verweigern. Diese müssen mit den IAM-Identitätsrichtlinien übereinstimmen.

Beispiel-S3-Bucket-Richtlinie für ein AWS-Konto, kein öffentlicher Zugriff:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadFromAppRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/app-readonly-role"
      },
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::example-private-bucket/*"
      ]
    }
  ]
}

Service Control Policies (SCPs): Wenn Sie AWS Organizations verwenden, können SCPs die maximalen Berechtigungen in einem Konto festlegen. Ein IAM-Allow kann eine SCP-Einschränkung nicht außer Kraft setzen.
CloudTrail: Suchen Sie in CloudTrail-Logs nach Access Denied-Fehlern, um den genauen API-Aufruf, den Prinzipal und die beteiligte Ressource zu identifizieren.
IAM Policy Simulator: Ein leistungsstarkes Tool in der IAM-Konsole, um die Auswirkungen verschiedener Richtlinien auf bestimmte Aktionen zu testen.

3. Service-Limits und Drosselung

AWS-Services haben weiche und harte Limits. Das Erreichen dieser Limits kann Fehler oder Leistungseinbußen verursachen (ThrottlingException, TooManyRequestsException).

CloudWatch-Metriken: Überwachen Sie servicespezifische Metriken auf Anzeichen von Drosselung, wie DynamoDB ReadThrottleEvents oder Lambda Throttles.
Service Quotas Console: Diese Konsole listet alle Ihre AWS-Service-Kontingente, deren aktuelle Nutzung auf und ermöglicht es Ihnen, Erhöhungen für anpassbare Kontingente zu beantragen.
Exponential Backoff und Wiederholungen: Implementieren Sie diese Muster in Ihren Anwendungen, wenn Sie mit AWS-APIs interagieren, um vorübergehende Drosselung elegant zu handhaben.

4. Ressourcenfehlkonfigurationen

Falsch konfigurierte Ressourcen sind eine häufige Ursache für Probleme.

Speicher: Falsche S3-Bucket-Berechtigungen (öffentlicher Zugriff), unverschlüsselte EBS-Volumes, unzureichende IOPS für EBS.
Compute: Falscher EC2-Instanztyp, falsches AMI, falsch konfigurierte Benutzerdaten, Auto-Scaling-Gruppen-Probleme.
Datenbanken: Probleme mit Verbindungszeichenfolgen, Fehlkonfiguration von Sicherheitsgruppen, Parametergruppeneinstellungen.
Load Balancer: Falsche Listener-Regeln, ungesunde Zielgruppen, Sicherheitsgruppenprobleme.
AWS Config: Verwenden Sie Config, um Änderungen an Ressourcenkonfigurationen im Laufe der Zeit zu verfolgen und so zu identifizieren, wann eine falsche Konfiguration eingeführt wurde.

5. Anwendungsspezifische Probleme

Selbst wenn AWS-Services einwandfrei laufen, kann Anwendungscode Probleme haben.

Anwendungslogs: Stellen Sie sicher, dass Ihre Anwendungslogs in CloudWatch Logs fließen. Analysieren Sie sie auf Fehler, Ausnahmen oder unerwartetes Verhalten.
Anwendungsmetriken: Senden Sie benutzerdefinierte CloudWatch-Metriken von Ihrer Anwendung (z.B. Fehleranzahlen, Anforderungslatenz, Warteschlangentiefe) für tiefere Einblicke.
AWS X-Ray: Für verteilte Anwendungen bietet X-Ray Ende-zu-Ende-Transparenz, verfolgt Anfragen, während sie durch verschiedene Dienste fließen, und identifiziert Leistungsengpässe oder Fehler.

Best Practices zur Reduzierung der MTTR

Gute Vorbereitung reduziert die Detektivarbeit, die Sie während eines Vorfalls leisten müssen.

Proaktive Überwachung und Alarmierung: Implementieren Sie umfassende CloudWatch-Alarme für kritische Metriken (CPU-Auslastung, Fehlerraten, Latenz, Speicherplatz, API-Fehler). Integrieren Sie SNS, um Benachrichtigungen an PagerDuty, Slack oder E-Mail zu senden.
Zentralisierte Protokollierung: Aggregieren Sie Logs von allen Ihren Diensten (EC2, Lambda, Container usw.) in CloudWatch Logs oder einem S3-basierten Data Lake für einfache Suche und Analyse.
Infrastructure as Code (IaC): Verwenden Sie CloudFormation, AWS CDK oder Terraform, um Ihre Infrastruktur zu definieren. Dies gewährleistet Konsistenz, reduziert manuelle Fehler und macht das Rückgängigmachen von Änderungen einfacher.
Runbooks und Playbooks: Dokumentieren Sie häufige Probleme, ihre Symptome, Diagnoseschritte und Lösungsverfahren. Dies befähigt Ihr Team, Probleme schnell und konsistent zu lösen.
Nutzen Sie das AWS Well-Architected Framework: Entwerfen Sie Ihre Systeme mit operativer Exzellenz, Sicherheit, Zuverlässigkeit, Leistungseffizienz und Kostenoptimierung im Hinterkopf. Proaktives Design verhindert viele Probleme.
Regelmäßige Audits und Überprüfungen: Überprüfen Sie regelmäßig Sicherheitsgruppenregeln, IAM-Richtlinien und Ressourcenkonfigurationen, um sicherzustellen, dass sie mit Best Practices und aktuellen Anforderungen übereinstimmen.
Nutzen Sie den AWS-Support: Öffnen Sie bei komplexen Problemen, die Sie nicht lösen können, oder wenn Sie ein AWS-seitiges Service-Problem vermuten, einen Support-Fall, wenn Ihr Support-Plan dies zulässt. Fügen Sie Ressourcen-IDs, Regionen, Zeitstempel mit Zeitzonen, Fehlermeldungen, Anforderungs-IDs und die Schritte hinzu, die Sie bereits unternommen haben.

Fazit

Beginnen Sie jedes AWS-Service-Problem mit dem gleichen Rhythmus: Definieren Sie das Symptom, überprüfen Sie kürzliche Änderungen, sammeln Sie Logs und Metriken, testen Sie eine Hypothese nach der anderen und dokumentieren Sie dann die Lösung. Diese Gewohnheit hält Ihre Fehlerbehebung ruhig, wenn der Vorfall es nicht ist.