GuardDuty für EKS 2026: 50 optionale Runtime-Regeln
Amazon GuardDuty bringt über 50 optionale Runtime-Regeln für EKS, EC2 und ECS. Was sie erkennen, was Runtime Monitoring in Frankfurt kostet und wie Sie testen.
TL;DR
GuardDuty für EKS erkennt seit dem 19. Oktober 2026 mit über 50 optionalen Runtime-Regeln Aktivitäten, die nur in Ihrer Umgebung verdächtig sind, etwa Änderungen an sudoers oder abgeschaltetes Audit-Logging. Die Regeln laufen auch in Frankfurt, setzen Runtime Monitoring voraus und lassen sich 14 Tage im Dry Run testen. Einen eigenen Preis nennt AWS nicht.
Was hat AWS geändert?
AWS hat die Custom Detection Rules von GuardDuty um Runtime-Monitoring-Regeln erweitert. Sie werten Prozess-, Datei- und Netzwerkereignisse des GuardDuty-Agents aus und gelten für EC2, EKS sowie ECS auf EC2 und Fargate. Jede Regel aktivieren Sie einzeln pro Konto, im Dry Run oder live.
Eckdaten laut AWS-Ankündigung und Doku, Stand 21.10.2026:
| Merkmal | Wert |
|---|---|
| Anzahl Runtime-Regeln | über 50 |
| Finding-Typen | 13, davon 4 neu |
| Ressourcen | EC2, EKS, ECS (EC2 und Fargate) |
| Regionen | alle kommerziellen AWS-Regionen, GovCloud (US) |
| Dry Run | nur CloudWatch-Metriken, Ablauf nach 14 Tagen |
| Live | Findings in GuardDuty, EventBridge, Security Hub |
Neu sind unter anderem CredentialAccess:Runtime/SensitiveFileRead und Exfiltration:Runtime/SuspiciousCommand. Die Regeln sind MITRE ATT&CK zugeordnet, darunter Persistence, Privilege Escalation und Command and Control.
Was bedeutet das für EKS-Teams in Deutschland?
Für EKS in Frankfurt schließen die Regeln eine Lücke zwischen generischer Erkennung und eigenem Falco-Regelwerk. Sie markieren Aktionen, die in einem Produktivcluster nie vorkommen sollten, ohne dass Sie Regeln selbst schreiben. Für Nachweise zur Angriffserkennung unter NIS2 liefern sie zusätzliche, dokumentierte Detektionen.
Zwei Grenzen nennt die Doku ausdrücklich: Eine Regel greift nur, wenn der Agent ihre Mindestversion erfüllt, und bei zu altem Agent meldet GuardDuty keinen Fehler. Aktuell ist der EKS-Agent v1.17.1 vom 9. September 2026 laut Release-Historie. Für die AWS European Sovereign Cloud nennt die Ankündigung keine Verfügbarkeit, also k. A.
Was kostet Runtime Monitoring in Frankfurt?
Für die optionalen Regeln nennt die Preisseite keinen Aufpreis. Kosten entstehen über Runtime Monitoring, abgerechnet nach überwachten vCPUs im Monatsmittel. Die AWS Price List API nennt für eu-central-1 folgende Netto-Listenpreise:
| vCPU pro Monat (EKS) | Preis je vCPU und Monat |
|---|---|
| erste 500 | 1,92 USD |
| nächste 4.500 | 0,96 USD |
| über 5.000 | 0,32 USD |
Rechenbeispiel: drei Nodes mit je 4 vCPU im Dauerbetrieb ergeben 12 vCPU mal 1,92 USD, also 23,04 USD pro Monat netto. Konten, die eine GuardDuty-Funktion noch nicht genutzt haben, testen sie 30 Tage kostenlos. Die Cluster-Gebühr von EKS steht im EKS-Profil.
Was sollten Sie jetzt tun?
Starten Sie mit einem Dry Run in einem Produktivkonto, nicht in Entwicklung, weil dort das Rauschen anders aussieht. Prüfen Sie vorher Agent-Version und Abdeckung.
aws guardduty list-custom-detection-rules --filters Name=severity,Values=HIGH
aws guardduty create-custom-detection-rule-association \
--rule-id <rule-id> --mode DRY_RUN- Runtime Monitoring für EKS aktivieren und Agent auf v1.17.1 bringen.
- Passende Regeln im Dry Run zuordnen und CloudWatch-Metriken 14 Tage beobachten.
- Regeln ohne Fehlalarme mit
update-custom-detection-rule-associationaufLIVEsetzen. - In Organisationen die Zuordnung zentral über das delegierte Administratorkonto steuern.
Welche Alternativen ohne US-Mutter es gibt, zeigt der Managed-Kubernetes-Vergleich für Deutschland.
FAQ
Sind die neuen GuardDuty-Regeln in Frankfurt verfügbar?
Ja. AWS gibt sie für alle kommerziellen Regionen frei, Frankfurt (eu-central-1) gehört dazu. Einzelne Regeln hängen davon ab, ob der zugrunde liegende Dienst in der Region verfügbar ist.
Was kosten die optionalen Regeln?
AWS nennt keinen eigenen Preis. Sie zahlen Runtime Monitoring, in Frankfurt 1,92 USD je vCPU und Monat für die ersten 500 vCPU, netto, Stand 21.10.2026.
GuardDuty-Regeln vs Falco: was passt?
GuardDuty passt, wenn Sie Regeln nicht selbst pflegen und Findings in Security Hub wollen. Falco passt, wenn Sie eigene Regeln brauchen oder Cluster über mehrere Anbieter hinweg gleich überwachen.
Erzeugt der Dry Run Findings?
Nein. Im Dry Run zählt GuardDuty Treffer nur als CloudWatch-Metriken. Nach 14 Tagen ist die Regel wieder deaktiviert.
Was passiert bei einem veralteten Agent?
Die Regel greift auf dieser Ressource nicht, und GuardDuty meldet keinen Fehler. Halten Sie den Agent aktuell oder lassen Sie ihn von GuardDuty verwalten.
Quellen
- AWS What’s New: Optional threat detection rules for Runtime Monitoring, 19.10.2026
- GuardDuty: Custom Detection Rules
- GuardDuty: How Custom Detection Rules work
- GuardDuty: Managing Custom Detection Rules
- GuardDuty: Agent-Versionen
- AWS Price List API: GuardDuty eu-central-1, abgerufen 21.10.2026
- Amazon GuardDuty Pricing
Quellen
- AWS What's New: Amazon GuardDuty adds optional threat detection rules for Runtime Monitoring (19.10.2026) (abgerufen 21. Oktober 2026)
- AWS GuardDuty User Guide: Custom Detection Rules (abgerufen 21. Oktober 2026)
- AWS GuardDuty User Guide: How Custom Detection Rules work (abgerufen 21. Oktober 2026)
- AWS GuardDuty User Guide: Managing Custom Detection Rules (abgerufen 21. Oktober 2026)
- AWS GuardDuty User Guide: Security agent release versions (abgerufen 21. Oktober 2026)
- AWS Price List API: AmazonGuardDuty eu-central-1 (Stand 08.10.2026) (abgerufen 21. Oktober 2026)
- Amazon GuardDuty Pricing (abgerufen 21. Oktober 2026)