Vor drei Wochen haben wir uns für die AWS Lambda Trading-Migration entschieden. Nicht weil ich überzeugt war, dass es funktioniert – sondern weil lokale Entwicklung uns in eine Sackgasse geführt hat. Jetzt, in CW37, zeige ich dir unsere ersten Schritte in der Cloud-Welt. Ehrlich, transparent, ohne Schönfärberei.

Das erwartet dich:

• Was in den ersten 3 Wochen nach der Migrations-Entscheidung wirklich passiert ist
• AWS Lambda Trading Setup: Theorie trifft auf unsere Praxis
• Cost-Reality-Check: Warum ⭐-Vergleiche sinnvoller sind als absolute Zahlen
• Markenanmeldung und strategische Fundamente (vorsichtig kommuniziert)
• Ehrliche Learnings aus 3 Wochen Cloud-Realität

Was seit der AWS-Migrations-Entscheidung passiert ist

In CW36 haben wir entschieden: AWS Lambda Trading statt lokaler Entwicklung. Die Orchestrierungs-Komplexität wurde zu groß, wir brauchten einen Ausweg. Hier ist, was in den ersten 3 Wochen passiert ist – ehrlich und ohne Schönfärberei.

Timeline der ersten 3 Wochen:

Woche 1 (CW37-T1 bis T7): AWS-Account-Setup. Klingt simpel, war aber intensiv. IAM-Rollen, Policies, Budget-Alerts konfiguriert. Learnings aus CW35 (55%-Regel) halfen dabei: Realistische Zeitplanung statt Wunschdenken.

Woche 2 (CW37-T8 bis T14): Erste Lambda-Functions deployed. Python-Code funktionierte lokal, aber AWS-Environment ist anders. Debugging in CloudWatch Logs fühlt sich fremd an nach lokaler Entwicklung.

Woche 3 (CW37-T15 bis T21): EventBridge-Integration. Cron-basierte Trigger starten Lambda-Functions zur richtigen Marktzeit. Erste Erfolge, aber viele Fragen offen.

AWS Lambda Setup – Theorie trifft Praxis

Lambda-Function für Trading-Signale

Serverless klingt kompliziert, ist aber konzeptionell simpel: Code läuft nur wenn nötig, du zahlst nur für Ausführungszeit. Für AWS Lambda Trading ideal, weil Märkte nicht 24/7 analysiert werden müssen.

import json
import boto3

def lambda_handler(event, context):
    # Simplified AWS Lambda Trading Handler
    symbol = event.get('symbol', 'AAPL')
    
    # Trading logic (simplified for demo)
    signal = analyze_market_data(symbol)
    
    # Store result in S3
    s3 = boto3.client('s3')
    s3.put_object(
        Bucket='trading-signals',
        Key=f'signals/{symbol}.json',
        Body=json.dumps(signal)
    )
    
    return {
        'statusCode': 200,
        'body': json.dumps(f'Signal für {symbol} gespeichert')
    }

def analyze_market_data(symbol):
    # Here: Real trading logic
    # Currently: Placeholder for tests
    return {'symbol': symbol, 'signal': 'neutral'}

Was funktioniert: Lambda startet schnell, analysiert Daten, speichert Ergebnis. Serverless bedeutet: Bezahlen nur für die Sekunden, die der Code läuft.

Was noch nicht funktioniert: Echte Trading-Logik fehlt. KI-Integration (Bedrock) kommt Q4. Broker-Anbindung ist in Planung. Wir sind in der Foundation-Phase, nicht im Trading-Modus.

EventBridge als Trading-Orchestrator

EventBridge ersetzt unsere lokale Orchestrierungs-Hölle aus CW36. Cron-Expressions definieren, wann Lambda-Functions starten. Simpel, aber mächtig.

EventBridge kümmert sich um Timing, Retries und Error-Handling. Wir definieren nur „wann“ und „was“ – nicht „wie“. Das ist der Kern von Serverless.

Cost-Reality-Check: ⭐-System statt Prognosen

Absolute Kostenzahlen wären Kaffeesatzleserei nach 3 Wochen. Stattdessen: Kosten-Effizienz-Vergleich mit traditionellen Trading-Plattformen. Lass es mich in 5 Schritten erklären…

Was bedeutet das? Nicht „wir sparen X Euro“, sondern „wir zahlen nur für das, was wir nutzen“. Bei 100 Lambda-Executions/Tag kostet uns das Cent-Beträge. Professionelle Plattformen berechnen Grundgebühren, egal ob du tradest oder nicht.

Markenanmeldung und strategische Fundamente

Parallel zur technischen Migration denke ich über strategische Fundamente nach. AWS Lambda Trading ist nicht nur eine technische Entscheidung, sondern ein systematischer Ansatz zum algorithmischen Trading.

Warum Markenanmeldung jetzt relevant ist: Wenn ein System funktioniert, wird es kopiert. Das ist normal und sogar gut für die Community. Aber: Klare Identität hilft, unseren Ansatz zu schützen und gleichzeitig Open-Source-Philosophie zu leben.

Was ich plane (vorsichtig):

• Markenaufbau: „AWS Lambda Trading“ als identifizierbare Methodik
• Open-Source-Basis: Code bleibt frei verfügbar, Marke schützt Identität
• Community-Fokus: Wissen teilen, aber mit klarer Herkunft
• Langfristige Vision: System skalierbar machen für größere Projekte

Details folgen, wenn die technische Basis stabiler ist. Aktuell: Fokus auf funktionierendes System, strategische Überlegungen im Hintergrund.

Ehrliche Learnings aus 3 Wochen Cloud-Realität

Was gut läuft

1. Serverless vereinfacht Orchestrierung: EventBridge + Lambda ersetzen unsere lokale Cron-Job-Hölle. Weniger Komplexität = weniger Fehlerquellen. Das System funktioniert folgendermaßen: EventBridge triggert, Lambda führt aus, S3 speichert.

2. AWS Free Tier ist großzügig: 1 Million Lambda-Requests/Monat gratis. Für Paper-Trading-Phase mehr als genug. Das sind etwa 33.000 Requests pro Tag. Wir nutzen aktuell ca. 300/Tag.

3. CloudWatch Logs sind mächtig: Debugging in der Cloud funktioniert anders, aber CloudWatch Insights sind besser als lokale Log-Files. Filterbare Logs, Metriken, Alarme – alles integriert.

Was noch hakt

1. Lernkurve steiler als erwartet: IAM-Policies, VPCs, Security-Groups – AWS hat eigene Konzepte. Die offizielle AWS Lambda Dokumentation hilft, aber es dauert. CW30 (65%-Regel) bestätigt sich wieder.

2. Debugging ist anders: Lokaler Code läuft lokal, Cloud-Code läuft… in der Cloud. Offensichtlich, aber gewöhnungsbedürftig. CloudWatch Logs sind keine lokalen print()-Statements.

3. Bedrock-Integration dauert länger: KI-Modelle in Lambda zu integrieren ist nicht trivial. Q4-Ziel bleibt, aber realistisch betrachtet. AWS Bedrock ist mächtig, aber komplex.

Nächste Schritte (realistisch)

Fazit: AWS Lambda Trading – Erste Fundamente stehen

Nach 3 Wochen AWS Lambda Trading-Migration: Die Basis steht. Nicht perfekt, nicht fertig, aber stabiler als unsere lokale Entwicklung in CW36.

Realistische Einschätzung: Wir sind bei ca. 40% eines funktionsfähigen Serverless-Trading-Systems. AWS-Account läuft, Lambda-Functions funktionieren, EventBridge orchestriert. Aber: KI-Integration fehlt, Broker-Anbindung fehlt, echte Trading-Logik fehlt.

Optimistische Note: Die Fundamente sind solide. Serverless-Architektur ist der richtige Ansatz. CW35-Learnings halfen, realistische Erwartungen zu setzen statt Euphorie.

Was als Nächstes kommt: DynamoDB-Integration, Step Functions-Tests, Bedrock-Vorbereitung. Langsam, systematisch, ohne Hektik. Die Migration war richtig, auch wenn sie länger dauert als erhofft.

Wenn du den Weg verfolgst: Newsletter abonnieren für wöchentliche Updates aus dem Trading-Experiment.

Über die Autorin: Miri Lange entwickelt seit 37 Wochen ein KI-gestütztes Trading-System. AWS Lambda Trading ist der nächste Schritt nach lokaler Entwicklung. Ehrlich, transparent, ohne Schönfärberei.