EC2-Arbeitsspeicher in CloudWatch überwachen: Warum der CloudWatch Agent zwingend notwendig ist

Du öffnest die CloudWatch-Konsole, suchst nach RAM-Auslastung deiner EC2-Instanz — und findest nichts. Kein Memory-Metrik, kein Swap, kein Filesystem. Das ist kein Bug und kein fehlendes Feature: Es ist eine bewusste Architekturentscheidung von AWS, die viele Engineers beim ersten Mal überrascht und die du verstehen musst, bevor du EC2-Arbeitsspeicher überwachen kannst.

TL;DR: EC2-Speicherüberwachung auf einen Blick

AspektDetail
Standardmäßige CloudWatch-MetrikenNur Hypervisor-seitige Metriken: CPU, Netzwerk, Disk-I/O (EBS-Ebene)
Warum kein RAM per Default?AWS hat keinen Zugriff auf das Gastbetriebssystem — der Hypervisor sieht nur zugewiesenen, nicht genutzten Speicher
LösungCloudWatch Agent auf der Instanz installieren und konfigurieren
Metrik-NamespaceCWAgent (benutzerdefinierter Namespace)
Benötigte IAM-BerechtigungManaged Policy CloudWatchAgentServerPolicy an die Instance Role anhängen
KostenCustom Metrics werden pro Metrik und pro Datenpunkt abgerechnet — aktuelle Preise in der AWS-Dokumentation prüfen

Warum CloudWatch EC2-Arbeitsspeicher nicht nativ anzeigt

AWS betreibt EC2 auf einem Hypervisor (Nitro oder Xen, je nach Instanztyp). Der Hypervisor sieht, wie viel RAM einer Instanz zugewiesen wurde — aber er sieht nicht, wie viel davon das Gastbetriebssystem tatsächlich nutzt. Das ist der entscheidende Unterschied: Zugewiesener Speicher ist eine Hypervisor-Ressource. Genutzter Speicher ist eine Betriebssystem-Ressource.

Stell dir vor, du vermietest ein Lagerhaus. Du weißt, wie groß es ist — aber du weißt nicht, wie voll es innen ist, ohne selbst hineinzugehen. AWS ist der Vermieter. Der CloudWatch Agent ist der Mitarbeiter, der drinnen steht und zählt.

CloudWatch-Standardmetriken wie CPUUtilization kommen direkt vom Hypervisor und sind ohne zusätzliche Konfiguration verfügbar. Metriken wie mem_used_percent oder disk_used_percent existieren nur innerhalb des Gastbetriebssystems — und AWS hat aus Sicherheits- und Isolationsgründen keinen direkten Zugriff darauf. Genau hier kommt der CloudWatch Agent ins Spiel: Er läuft als Prozess innerhalb der Instanz, liest OS-Metriken und schickt sie aktiv an CloudWatch.

graph TD HV["AWS Nitro Hypervisor"] STD["Standard CloudWatch Metriken CPUUtilization, NetworkIn/Out DiskReadOps (EBS)"] GUEST["Gastbetriebssystem (EC2)"] AGENT["CloudWatch Agent (Daemon auf der Instanz)"] OS_METRICS["OS-Metriken mem_used_percent disk_used_percent swap_used_percent"] CW["Amazon CloudWatch Namespace: CWAgent"] IAM["IAM Instance Role CloudWatchAgentServerPolicy"] HV -->|"automatisch, kein Agent nötig"| STD STD --> CW GUEST --> OS_METRICS OS_METRICS -->|"gelesen von"| AGENT IAM -->|"autorisiert PutMetricData"| AGENT AGENT -->|"publiziert Metriken"| CW style STD fill:#2d6a4f,color:#fff style OS_METRICS fill:#e76f51,color:#fff style AGENT fill:#457b9d,color:#fff style CW fill:#1d3557,color:#fff
  1. Hypervisor-Ebene: AWS Nitro/Xen sieht CPU-Zyklen, Netzwerkpakete und EBS-I/O — diese Daten fließen automatisch in CloudWatch.
  2. Gastbetriebssystem-Ebene: RAM-Nutzung, Swap, Dateisystem-Füllstand — diese Daten existieren nur innerhalb der Instanz.
  3. CloudWatch Agent: Läuft als Daemon auf der Instanz, liest OS-Metriken über Standard-Kernel-Schnittstellen und publiziert sie in den CWAgent-Namespace.
  4. IAM Instance Role: Der Agent benötigt Schreibrechte auf CloudWatch, um Metriken hochzuladen — ohne korrekte Role schlägt der Upload still fehl.

EC2-Arbeitsspeicher überwachen: CloudWatch Agent installieren und konfigurieren

Schritt 1: IAM Instance Role vorbereiten

Bevor der Agent auch nur einen Datenpunkt senden kann, muss die EC2-Instance Role die nötigen Berechtigungen haben. Die verwaltete Policy CloudWatchAgentServerPolicy enthält alle erforderlichen Rechte für den normalen Agentenbetrieb. Ohne diese Policy schreibt der Agent Fehler ins lokale Log, aber CloudWatch zeigt schlicht keine Metriken — kein Alarm, keine Fehlermeldung in der Konsole.

# Managed Policy an eine bestehende Instance Role anhängen
aws iam attach-role-policy \
  --role-name MeineEC2InstanceRole \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

Prüfe anschließend, ob die Policy korrekt angehängt wurde:

aws iam list-attached-role-policies \
  --role-name MeineEC2InstanceRole \
  --query 'AttachedPolicies[?PolicyName==`CloudWatchAgentServerPolicy`]'

Schritt 2: CloudWatch Agent installieren

AWS stellt den Agent über SSM Parameter Store und direkte Paketquellen bereit. Der einfachste Weg auf Amazon Linux 2 / Amazon Linux 2023 ist der Paketmanager:

# Amazon Linux 2 / Amazon Linux 2023
sudo yum install -y amazon-cloudwatch-agent

# Ubuntu / Debian
sudo apt-get install -y amazon-cloudwatch-agent

Alternativ kann der Agent über AWS Systems Manager Distributor auf eine Flotte von Instanzen ausgerollt werden — sinnvoll ab mehr als einer Handvoll Instanzen.

Schritt 3: Agent konfigurieren

Der Agent liest seine Konfiguration aus einer JSON-Datei. Der Wizard ist der schnellste Einstieg, aber für reproduzierbare Deployments sollte die Konfiguration versioniert und über SSM Parameter Store verteilt werden.

# Interaktiven Konfigurationsassistenten starten
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

Für eine direkte, nicht-interaktive Konfiguration: Erstelle die Datei /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json mit folgendem Inhalt:

🔽 Beispiel-Konfiguration anzeigen (Speicher + Disk) 
{
  "metrics": {
    "namespace": "CWAgent",
    "metrics_collected": {
      "mem": {
        "measurement": [
          "mem_used_percent"
        ],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": [
          "disk_used_percent"
        ],
        "resources": [
          "/"
        ],
        "metrics_collection_interval": 60
      }
    },
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}"
    }
  }
}

Die Dimension InstanceId wird automatisch zur Laufzeit aufgelöst — kein Hardcoding nötig. Der Namespace CWAgent ist der Standard; er kann überschrieben werden, aber dann müssen alle Alarme und Dashboards entsprechend angepasst werden.

Schritt 4: Agent starten und Status prüfen

Der Agent wird über ein eigenes Steuerskript verwaltet, nicht direkt über systemd — obwohl er intern systemd nutzt. Das Steuerskript ist der dokumentierte Weg:

# Agent mit der erstellten Konfiguration starten
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -s \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json

# Betriebsstatus prüfen
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a status

Die Ausgabe des Status-Befehls zeigt "status": "running" wenn alles korrekt läuft. Wenn der Status stopped zeigt, ist die erste Anlaufstelle das Agent-Log:

sudo tail -f /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log

Schritt 5: Metriken in CloudWatch verifizieren

Nach dem Start dauert es typischerweise eine bis zwei Minuten, bis die ersten Datenpunkte in CloudWatch erscheinen. Prüfe direkt über die CLI, ob Metriken ankommen — das ist schneller als das Warten auf die Konsole:

aws cloudwatch list-metrics \
  --namespace CWAgent \
  --metric-name mem_used_percent \
  --region us-east-1

Wenn die Ausgabe leer ist, liegt das Problem entweder an der IAM-Policy (Schritt 1), an der Agent-Konfiguration oder daran, dass der Agent nicht läuft. Leere Ausgabe bedeutet: CloudWatch hat noch keine Daten empfangen — nicht, dass die Metrik nicht existiert.

graph TD START(["Agent gestartet"]) CHECK_LOG["Agent-Log prüfen /logs/amazon-cloudwatch-agent.log"] ACCESS_DENIED{"AccessDenied im Log?"} FIX_IAM["IAM Policy anhängen: CloudWatchAgentServerPolicy"] CHECK_CONFIG{"Konfigurationsfehler im Log?"} FIX_CONFIG["JSON-Konfiguration korrigieren und Agent neu starten"] CHECK_CW["CloudWatch prüfen: aws cloudwatch list-metrics --namespace CWAgent"] METRICS_OK{"Metriken sichtbar?"} DONE(["Überwachung aktiv"]) CHECK_NET["Netzwerk prüfen: VPC Endpoint oder Internet Gateway für CloudWatch"] START --> CHECK_LOG CHECK_LOG --> ACCESS_DENIED ACCESS_DENIED -->|"Ja"| FIX_IAM FIX_IAM --> START ACCESS_DENIED -->|"Nein"| CHECK_CONFIG CHECK_CONFIG -->|"Ja"| FIX_CONFIG FIX_CONFIG --> START CHECK_CONFIG -->|"Nein"| CHECK_CW CHECK_CW --> METRICS_OK METRICS_OK -->|"Ja"| DONE METRICS_OK -->|"Nein"| CHECK_NET style DONE fill:#2d6a4f,color:#fff style FIX_IAM fill:#e76f51,color:#fff style FIX_CONFIG fill:#e76f51,color:#fff

Typischer Fehler in der Praxis: Stille IAM-Fehler beim EC2-Arbeitsspeicher überwachen

Das klassische Muster sieht so aus: Agent installiert, Konfiguration erstellt, Agent läuft — aber in CloudWatch erscheinen keine Metriken. Die Konsole zeigt keinen Fehler. Kein Alarm schlägt an. Nichts.

Die erste Vermutung ist meist ein Konfigurationsfehler in der JSON-Datei. Also wird die Konfiguration geprüft, der Agent neugestartet — immer noch nichts. Dann wird die Netzwerkkonnektivität verdächtigt: Kann die Instanz den CloudWatch-Endpunkt erreichen?

Die eigentliche Ursache: Die EC2-Instance Role hat keine CloudWatchAgentServerPolicy angehängt. Der Agent versucht, Metriken per cloudwatch:PutMetricData hochzuladen, erhält einen AccessDenied-Fehler — und schreibt diesen Fehler ins lokale Agent-Log, nicht in CloudWatch. In der CloudWatch-Konsole sieht man schlicht gar nichts.

Der Agent-Log zeigt in diesem Fall Einträge wie:

E! [outputs.cloudwatch] E! WriteToCloudWatch, error: AccessDeniedException: 
   User: arn:aws:sts::123456789012:assumed-role/MeineEC2InstanceRole/i-0abc123def456789 
   is not authorized to perform: cloudwatch:PutMetricData

Sobald die Policy angehängt und der Agent neugestartet ist, erscheinen die Metriken innerhalb von Minuten. Das Lesen des Agent-Logs ist bei fehlenden Metriken immer der erste Diagnoseschritt — nicht die CloudWatch-Konsole.

CloudWatch-Alarm für hohe Speicherauslastung erstellen

Metriken ohne Alarme sind nur halbe Arbeit. Ein Alarm auf mem_used_percent ist schnell erstellt — wichtig ist, die korrekte Dimension InstanceId anzugeben, sonst greift der Alarm auf alle Instanzen im Namespace:

aws cloudwatch put-metric-alarm \
  --alarm-name 'EC2-HighMemoryUsage-i-0abc123def456789' \
  --metric-name mem_used_percent \
  --namespace CWAgent \
  --statistic Average \
  --period 300 \
  --threshold 85 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --dimensions Name=InstanceId,Value=i-0abc123def456789 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:MeinAlarmTopic \
  --region us-east-1

Konfiguration zentral über SSM Parameter Store verwalten

Für mehr als eine Instanz ist das manuelle Kopieren der Konfigurationsdatei nicht skalierbar. Der CloudWatch Agent unterstützt das Laden der Konfiguration direkt aus dem SSM Parameter Store — der empfohlene Weg für Fleet-Deployments.

# Konfiguration in SSM Parameter Store speichern
aws ssm put-parameter \
  --name '/cloudwatch-agent/config' \
  --type String \
  --value file:///opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \
  --region us-east-1

# Agent auf Instanz mit SSM-Konfiguration starten
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -s \
  -c ssm:/cloudwatch-agent/config

Damit kann dieselbe Konfiguration über SSM Run Command oder State Manager auf alle Instanzen ausgerollt werden, ohne SSH-Zugriff auf jede einzelne Maschine.

Nächste Schritte und weiterführende Ressourcen

Der CloudWatch Agent ist der einzige dokumentierte Weg, OS-seitige Metriken wie EC2-Arbeitsspeicher in CloudWatch zu publizieren. Wer darüber hinaus Log-Dateien zentralisieren will, kann denselben Agent nutzen — die logs-Sektion der Konfiguration ermöglicht das Streamen beliebiger Logdateien in CloudWatch Logs ohne zusätzliche Software.

Glossar: Schlüsselbegriffe zur EC2-Speicherüberwachung

BegriffBedeutung
CloudWatch AgentSoftware-Daemon, der auf EC2-Instanzen läuft und OS-seitige Metriken sowie Logs an CloudWatch sendet
Custom Metrics / Benutzerdefinierte MetrikenMetriken, die nicht vom AWS-Hypervisor stammen, sondern von Anwendungen oder dem CloudWatch Agent publiziert werden; werden separat abgerechnet
CWAgent NamespaceStandard-Namespace, unter dem der CloudWatch Agent Metriken in CloudWatch ablegt
Instance RoleIAM-Rolle, die einer EC2-Instanz zugewiesen ist und deren Berechtigungen für AWS-API-Aufrufe definiert
SSM Parameter StoreAWS-Dienst zur zentralen Verwaltung von Konfigurationsdaten; wird für Fleet-weite Agent-Konfigurationen empfohlen

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

EC2 ohne Internetzugang im eigenen VPC – Internet Gateway und Route Table korrekt einrichten

Du hast ein eigenes VPC erstellt, eine EC2-Instanz in einem öffentlichen Subnetz gestartet – und ping google.com läuft ins Leere. Kein Timeout-Fehler, keine Fehlermeldung, einfach nichts. Dieses Problem tritt fast immer auf, wenn ein Custom VPC ohne Internet Gateway oder mit einer unvollständigen Route-Table-Konfiguration aufgesetzt wird, weil AWS bei eigenen VPCs bewusst keine Standard-Internetverbindung mitliefert. TL;DR – EC2 Internetzugang im Custom VPC Schritt Aktion Warum notwendig 1 Internet Gateway erstellen und an VPC anhängen Ohne IGW gibt es keinen Pfad ins öffentliche Internet 2 Route Table aktualisieren (0.0.0.0/0 → IGW) Der Traffic muss explizit über das IGW geroutet werden 3 Subnetz mit Route Table verknüpfen Eine Route Table ohne Subnetz-Assoziation hat keine Wirkung 4 Öffentliche IP oder Elastic IP prüfen Ohne öffentliche IP kann das IGW keinen eingehenden Rückpfad aufbauen 5 Securi...
Mehr anzeigen

EC2 SSH Verbindungs-Timeout: Security Group Inbound-Regeln richtig konfigurieren

Du startest eine neue EC2-Instanz, versuchst dich per SSH zu verbinden — und bekommst sofort ein 'Connection timed out'. Kein 'Connection refused', kein Passwort-Prompt, einfach Stille. Das ist fast immer ein Netzwerkproblem auf Infrastrukturebene, und die häufigste Ursache ist eine fehlende oder falsch konfigurierte Inbound-Regel in der Security Group der EC2 SSH-Verbindung. TL;DR — EC2 SSH Verbindungs-Timeout auf einen Blick Schicht Was prüfen Häufigste Ursache Security Group Inbound-Regel für TCP Port 22 Regel fehlt oder falsche Quell-IP Network ACL Inbound + Outbound für Port 22 und Ephemeral Ports Outbound-Regel für Ephemeral Ports fehlt Route Table Route zum Internet Gateway (0.0.0.0/0) Kein Internet Gateway zugewiesen Instanz Public IP vorhanden, Instanz-Status 'running' Keine öffentliche IP zugewiesen Wie EC2-Netzwerkzugriff funktioniert — Pflichtlektüre vor Schritt 1...
Mehr anzeigen