← Alle Insights
10 Min. Lesezeit · Cloud · Mai 2026

AWS-Architektur für systematisches Trading.

Cloud-Trading hat einen schlechten Ruf — zu Recht, wenn man die typischen Anfängerfehler sieht: Single-EC2-Instanz, ungesicherte API-Keys, keine Backups, keine Alerts. Richtig gebaut ist AWS aber eine der robustesten Plattformen, die Sie für systematisches Trading bekommen können. Hier zeige ich Ihnen die Architektur, die ich für Mandanten und eigene Strategien einsetze — inklusive der unbequemen Details, die kein Marketingblog erwähnt.

Warum AWS und nicht ein günstiger VPS?

Ein einzelner Hetzner-VPS kostet 5 Euro im Monat, AWS für dieselbe Workload eher 60 bis 120 Euro. Der Unterschied ist nicht Compute, sondern was Sie an Infrastruktur dazubekommen: Multi-AZ-Failover, IAM mit Audit-Trail, KMS für Secrets, CloudWatch für Metriken, EventBridge für saubere Event-Pipelines, Glacier für Compliance-Archive. Für eine Hobby-Strategie ist das Overkill. Für Mandanten-Kapital oder echtes Eigenkapital im sechsstelligen Bereich nicht.

Die zweite, wichtigere Antwort: bei AWS sind Ausfälle bekannt, dokumentiert und kompensierbar. Bei einem kleinen VPS-Anbieter erfahren Sie aus dem Forum, dass das Rechenzentrum brennt, während Ihre Strategie offene Positionen hat. Das ist mir früher passiert. Seitdem ist die Architekturentscheidung in der Cloud klar.

Die Grundarchitektur.

Eine produktive Trading-Plattform auf AWS besteht aus fünf Schichten: Daten-Ingestion, Signal-Engine, Order-Router, State-Storage und Observability. Jede Schicht ist unabhängig deployable, jede hat klare Eingaben und Ausgaben, jede ist in einer eigenen VPC-Subnet-Gruppe isoliert.

Multi-AZ und Failover.

Eine Single-AZ-Architektur ist im Live-Betrieb keine Option. AWS dokumentiert AZ-Ausfälle mehrmals pro Jahr — meist kurz, manchmal länger. Wenn Ihre Strategie offene Positionen hat und der Order-Router gerade in der ausgefallenen AZ läuft, müssen Sie manuell eingreifen. Das hat um drei Uhr morgens niemand vor.

Die Standardlösung: zwei AZs in einer Region, Active-Standby für stateful Komponenten, Active-Active für stateless. DynamoDB ist von Haus aus Multi-AZ, RDS Aurora ebenfalls wenn man die Multi-AZ-Option setzt. Der Order-Router selbst läuft als Auto-Scaling-Group mit Min=1, Max=1 und Health-Check über die SQS-Konsumrate. Fällt die Instanz aus, startet innerhalb von zwei Minuten eine neue in der zweiten AZ. Während dieser zwei Minuten stauen sich Orders in der FIFO-Queue, gehen aber nicht verloren.

Beispiel: EventBridge-Schedule für Signal-Generierung.

Hier ein typischer Ausschnitt aus einem CloudFormation-Template für eine Tages-Strategie, die täglich um 22:05 UTC (kurz nach US-Close) Signale rechnet: 

# cloudformation/signal-engine.yaml
Resources:
  SignalSchedule:
    Type: AWS::Events::Rule
    Properties:
      Name: daily-signal-generation
      ScheduleExpression: "cron(5 22 ? * MON-FRI *)"
      State: ENABLED
      Targets:
        - Arn: !GetAtt SignalEngineCluster.Arn
          Id: signal-engine-target
          RoleArn: !GetAtt EventBridgeInvokeRole.Arn
          EcsParameters:
            TaskDefinitionArn: !Ref SignalEngineTaskDef
            LaunchType: FARGATE
            NetworkConfiguration:
              AwsVpcConfiguration:
                Subnets:
                  - !Ref PrivateSubnetA
                  - !Ref PrivateSubnetB
                SecurityGroups:
                  - !Ref SignalEngineSG
                AssignPublicIp: DISABLED

  SignalEngineTaskDef:
    Type: AWS::ECS::TaskDefinition
    Properties:
      Family: signal-engine
      Cpu: "2048"
      Memory: "8192"
      NetworkMode: awsvpc
      RequiresCompatibilities: [FARGATE]
      ExecutionRoleArn: !GetAtt TaskExecutionRole.Arn
      TaskRoleArn: !GetAtt SignalEngineTaskRole.Arn
      ContainerDefinitions:
        - Name: engine
          Image: !Sub "${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/signal-engine:prod"
          Essential: true
          Environment:
            - Name: DDB_TABLE
              Value: !Ref PositionsTable
            - Name: SIGNAL_QUEUE_URL
              Value: !Ref SignalQueue
          LogConfiguration:
            LogDriver: awslogs
            Options:
              awslogs-group: /ecs/signal-engine
              awslogs-region: !Ref AWS::Region
              awslogs-stream-prefix: engine

Drei Dinge sind hier wichtig: erstens das AssignPublicIp: DISABLED — die Signal-Engine hat keine direkte Internet-Verbindung, nur über NAT-Gateway. Zweitens getrennte Rollen für Task-Execution (Container starten, Logs schreiben) und Task-Role (DynamoDB lesen, SQS schreiben). Drittens explizite CPU/Memory-Werte — Fargate-Tasks ohne Limits sind ein Kostenrisiko.

Secrets, IAM und API-Keys.

Der häufigste Anfängerfehler in Cloud-Trading-Setups: API-Keys in Environment-Variablen im Klartext. Das sehe ich bei fast jedem ersten Audit. Die richtige Lösung ist AWS Secrets Manager mit KMS-Verschlüsselung und automatischer Rotation, wo der Broker es unterstützt. 

# Python-Code, der den API-Key zur Laufzeit holt
import boto3
import json
from functools import lru_cache

@lru_cache(maxsize=1)
def get_broker_credentials() -> dict:
    client = boto3.client("secretsmanager", region_name="eu-central-1")
    response = client.get_secret_value(SecretId="prod/ibkr/api")
    return json.loads(response["SecretString"])

def place_order(symbol: str, quantity: int) -> str:
    creds = get_broker_credentials()
    # ... Order-Logik mit creds["api_key"] und creds["secret"]

Die IAM-Policy für die Task-Role erlaubt nur den secretsmanager:GetSecretValue für genau diese eine Secret-ARN. Kein Wildcard, keine Pauschalrechte. Wenn jemand den Container kompromittiert, bekommt er Zugriff auf einen Schlüssel — nicht auf das ganze Account.

Kostenkontrolle.

AWS-Rechnungen sind das, woran die meisten Hobby-Setups scheitern. Die Hauptverursacher sind selten Compute, sondern: NAT-Gateway-Egress, CloudWatch-Logs ohne Retention, Lambda-Invocations in Endlosschleifen, und vergessene RDS-Instanzen.

Disaster Recovery.

Was passiert, wenn die ganze Region eu-central-1 ausfällt? Selten, aber möglich. Mein Setup für Mandanten mit hohen Beträgen: tägliche DynamoDB-Backups per AWS Backup nach eu-west-1, S3-Cross-Region-Replication für historische Daten, Terraform-State in einem dritten Account. Der Failover ist nicht automatisch — in einem regionalen Ausfall lohnt sich die manuelle Entscheidung, ob man weiter handeln will oder lieber abwartet.

Wichtiger als ein perfekter Disaster-Recovery-Plan ist eine ehrliche Bewertung: was würde es Sie tatsächlich kosten, wenn die Strategie 24 Stunden offline ist? Bei vielen Setups ist die Antwort „weniger als der monatliche Aufpreis für Multi-Region". Bauen Sie nicht für den Worst Case, den Sie nie sehen — bauen Sie für den realistischen Fall.

Wann AWS die falsche Wahl ist.

AWS ist nicht für jeden. Wenn Sie Latenz im einstelligen Millisekundenbereich brauchen (HFT, Market Making), gehen Sie zu Colocation. Wenn Ihr Strategie-Budget unter 10.000 Euro liegt und Sie eine einzige Strategie betreiben, reicht ein gut konfigurierter VPS mit Backup-Plan. Wenn Sie kein DevOps-Wissen haben und niemanden, der es Ihnen beibringt, wird die Lernkurve Sie überfordern — dann ist eine fertige Plattform wie QuantConnect oder Alpaca die bessere Wahl.

AWS ist die richtige Antwort, wenn Sie mehrere Strategien gleichzeitig betreiben, wenn Audit und Compliance eine Rolle spielen, wenn Sie mit Mandanten-Geld arbeiten, oder wenn Sie eine Infrastruktur bauen wollen, die in fünf Jahren noch sinnvoll ist — statt jedes Jahr neu zu basteln.

Sie planen einen Trading-Stack auf AWS oder migrieren bestehende Strategien in die Cloud? Erstgespräch buchen — wir schauen Architektur, Sicherheit und Kosten gemeinsam an.