kumo - Leichter AWS-Service-Emulator, geschrieben in Go

• Für lokale Entwicklung und CI/CD-Tests lässt sich schnell eine kompatible Umgebung aufbauen, auch ohne echtes AWS
• Mit einer einzelnen Binärdatei lässt sich eine schlanke Testumgebung einrichten; Ausführung auf Docker-Basis ist ebenfalls möglich
• Läuft ohne Authentifizierung, wodurch sich der Aufwand für die Bereitstellung von AWS-Zugangsdaten in automatisierten Pipelines verringert
• Unterstützt 76 AWS-Services in großer Breite und deckt dabei wichtige Bereiche wie S3, SQS, DynamoDB, Lambda, IAM, CloudWatch, ECS und RDS ab
• Ein lokaler AWS-kompatibler Endpoint, der standardmäßig auf localhost:4566 läuft
• Wenn KUMO_DATA_DIR gesetzt ist, ist eine optionale Datenpersistenz über JSON-Dateien pro Service möglich; wenn nicht gesetzt, läuft es sauber im In-Memory-Modus
• Alle Anfragen werden zusammen mit strukturierten Log-Feldern protokolliert
  • INFO: HTTP-Methode, Pfad, Statuscode, Latenz, Request-ID, Informationen zum API-Target usw.
  • DEBUG: Protokolliert sogar den vollständigen Request-Body und ist damit nützlich für Debugging, bei dem das Request-Payload selbst untersucht werden muss
• Zusätzliche Endpoints für Tests werden unter /kumo/ bereitgestellt
  • Sie sind zwar kein Teil der offiziellen AWS-API, aber nützlich, um das Verhalten von Anwendungen während Tests zu verifizieren

  • SES v2: gesendete E-Mails abrufen

    • Über GET /kumo/ses/v2/sent-emails lässt sich die Liste der über die SES v2 SendEmail API versendeten E-Mails abrufen
    • Antwort: enthält u. a. MessageId, Absenderadresse, Empfänger, Betreff, Inhalt und Versandzeitpunkt

  • Pinpoint SMS Voice v2: gesendete Nachrichten abrufen

    • Über GET /kumo/pinpointsmsvoicev2/sent-messages lässt sich die Liste der über die SendTextMessage API versendeten SMS abrufen
    • Antwort: enthält u. a. MessageId, Empfängernummer, Absenderkennung, Nachrichteninhalt und Versandzeitpunkt
  • Besonders nützlich, um beim Testen von E-Mail- und SMS-Versandfunktionen Ergebnisse zu verifizieren, ohne von externen Services abhängig zu sein
• MIT License

Unterstützte Services

• Insgesamt werden 76 AWS-Services unterstützt

• Storage

  • S3, S3 Control, S3 Tables, DynamoDB, ElastiCache, MemoryDB, Glacier und EBS werden unterstützt

• Compute

  • Lambda, Batch, EC2 und Elastic Beanstalk werden unterstützt

• Container

  • ECS, ECR und EKS werden unterstützt

• Datenbanken

  • RDS, Neptune und Redshift werden unterstützt

• Messaging und Integration

  • SQS, SNS, EventBridge, Kinesis, Firehose, MQ, Pipes und MSK werden unterstützt

• Sicherheit und Identität

  • IAM, KMS, Secrets Manager, ACM, Cognito, Security Lake, STS und Macie werden unterstützt

• Monitoring und Logging

  • CloudWatch, CloudWatch Logs, X-Ray und CloudTrail werden unterstützt

• Networking und Content Delivery

  • CloudFront, Global Accelerator, API Gateway, Route 53, Route 53 Resolver, ELBv2, App Mesh und Location werden unterstützt

• Anwendungsintegration

  • Step Functions, AppSync, SES v2, Pinpoint SMS Voice v2, Scheduler und Amplify werden unterstützt

• Verwaltung und Konfiguration

  • SSM, Config, CloudFormation, Organizations, Service Quotas, CodeConnections und Backup werden unterstützt

• Analyse und ML

  • Athena, Glue, Comprehend, Rekognition, SageMaker, Forecast, Data Exchange und Entity Resolution werden unterstützt

• Entwickler-Tools

  • CodeGuru Profiler und CodeGuru Reviewer werden unterstützt

• Weitere Services

  • Cost Explorer, DLM, Directory Service, EMR Serverless, FinSpace, GameLift und Resilience Hub werden unterstützt

Anwendungsbeispiele

• S3

  • Im S3-Client wird BaseEndpoint auf http://localhost:4566 gesetzt und UsePathStyle aktiviert, um sich mit dem lokalen Emulator zu verbinden
  • Der Ablauf von der Bucket-Erstellung bis zum Upload von Objekten ermöglicht es, Object-Storage-Tests ohne echtes AWS nachzubilden

• SQS

  • Der SQS-Client verwendet denselben lokalen Endpoint; der Ablauf umfasst das Erstellen einer Queue sowie das Senden und Empfangen von Nachrichten
  • Gut geeignet, um asynchrone Messaging-Logik in lokalen Integrationstests zu prüfen

• DynamoDB

  • Durch das Erstellen von Tabellen, das Definieren von Key-Schemas und das Speichern von Items lässt sich ein NoSQL-Workflow nachbilden
  • So lässt sich die Datenzugriffslogik einer Anwendung auch ohne echte Cloud-Ressourcen leicht prüfen

• Secrets Manager

  • Enthält Beispiele zum Erstellen und Abrufen von Geheimnissen, sodass sich auch die Anbindung an einen Secret Store testen lässt
  • Nützlich für die Verifikation von Anwendungen, die lokal mit sensiblen Informationen im JSON-Format arbeiten