← Alle Insights
9 Min. Lesezeit · Infrastruktur · Dezember 2029

Cloud für Trading-Bots: AWS/GCP statt VPS — wann lohnt's?

AWS und Google Cloud klingen für viele Trader nach Profi-Setup. Für 90 % der Strategien sind sie aber teurer und komplexer, ohne dass sie etwas liefern, das ein guter Hetzner-Server nicht auch könnte. Wann sich Cloud trotzdem rechnet — und wie ich es in der Praxis aufteile.

Ich nutze sowohl dedizierte VPS (Hetzner, Linode) als auch AWS und GCP. Die Entscheidung ist nie pauschal — sie hängt an Workload, Skalierungs-Bedarf und an Kosten. Hier die Heuristik, mit der ich in der Praxis arbeite.

AWS EC2 / GCP Compute vs. dedizierte VPS.

Auf dem Papier sehen die Angebote ähnlich aus: virtuelle Maschine, X vCPU, Y GB RAM, Z GB Disk. In der Realität gibt es zwei harte Unterschiede:

Für einen reinen MT5- oder Python-Bot, der auf einer Maschine läuft, brauchen Sie keine Plattform. Sie zahlen den AWS-Aufpreis ohne Gegenwert.

Wann Cloud trotzdem die richtige Wahl ist.

Latenz zur Börse

AWS hat Regionen direkt neben den großen Börsen-Rechenzentren:

Hetzner Falkenstein liegt geografisch ungünstiger — Frankfurt ist ca. 350 km entfernt, das macht 5–8 ms zusätzlich. Für M1-Scalping oder News-Trading auf US-Aktien lohnt sich AWS us-east-1 trotz höherem Preis.

Backtest-Cluster

Für große Parameter-Sweeps oder Walk-Forward-Optimierungen brauche ich kurzfristig 50–500 CPU-Kerne, danach nichts mehr. Hetzner hat hier kein gutes Modell — bei Hetzner Cloud sind Server Stunden-billable, aber das Provisioning von 50 Maschinen per API ist nicht so glatt wie bei AWS. Auf AWS spinne ich mit Terraform 100 Spot-Instances hoch, lasse den Backtest laufen, Cluster geht runter, Rechnung kommt für ein paar Stunden statt für einen Monat.

Spot-Instances sind hier der Killer: bis zu 90 % Rabatt gegenüber On-Demand. Backtests sind unkritisch — wenn AWS eine Spot-Instance vorzeitig terminiert, startet sie woanders neu.

Managed Services

Für ein größeres Setup mit mehreren Strategien, eigener Frontend-Plattform und Analytics-Pipeline lohnen sich:

Hidden-Costs: das, was AWS-Anfänger killt.

Der EC2-Preis ist nur die Spitze. Die Rechnung am Monatsende wird durch Nebenkosten überraschend hoch:

Mein Tipp: AWS Cost Explorer am Tag 1 aktivieren, Budget-Alert auf 1,5x erwarteter Kosten setzen. Ein vergessenes NAT-Gateway in einer Sandbox-VPC hat mich einmal 120 € gekostet, bis ich es bemerkt habe.

Region-Selection für Multi-Asset-Strategien.

Wenn Sie US-Aktien und EU-Futures gleichzeitig handeln, gibt es keine perfekte Region. Drei Optionen:

  1. Strategie pro Asset-Klasse pro Region: US-Strategie in us-east-1, EU-Strategie in eu-central-1. Beste Latenz pro Markt, höchste Kosten und Komplexität.
  2. Ein Standort, Kompromiss-Latenz: alles in eu-central-1, US-Trades laufen mit 90 ms zusätzlicher Latenz. Für Daily-Strategien irrelevant, für M1 problematisch.
  3. VPC-Peering zwischen Regionen: zentraler Order-Manager in einer Region, Marktdaten-Receiver in jeweiliger Markt-Region. Sauberste Architektur, höchster Aufwand.

In der Praxis fahre ich Option 2, solange die Strategien Daily oder H1 sind. Erst ab M5-Frequenz wechsle ich auf Option 1.

Konkretes Setup mit Terraform.

Ein minimales AWS-Setup für einen Trading-Bot, das ich oft als Baseline nutze: 

resource "aws_instance" "trading_bot" {
  ami                    = data.aws_ami.ubuntu_22.id
  instance_type          = "c6i.large"
  subnet_id              = aws_subnet.public.id
  vpc_security_group_ids = [aws_security_group.bot.id]
  key_name               = aws_key_pair.deployer.key_name

  root_block_device {
    volume_size = 30
    volume_type = "gp3"
    encrypted   = true
  }

  tags = { Name = "trading-bot-prod", Env = "prod" }
}

resource "aws_db_instance" "trade_log" {
  identifier        = "trade-log"
  engine            = "postgres"
  engine_version    = "16.3"
  instance_class    = "db.t4g.micro"
  allocated_storage = 20
  username          = "trader"
  password          = var.db_password
  skip_final_snapshot = false
  backup_retention_period = 7
}

Plus: Security-Group, die nur SSH von meiner IP und Outbound zu Broker-Hosts erlaubt. CloudWatch-Alarm auf CPU > 80 % und Status-Check-Fehler. EBS-Snapshot-Plan über Data Lifecycle Manager.

Spot-Instances für Backtests.

Für CPU-intensive Backtests nutze ich Spot Fleet mit Mixed Instance Types: 

resource "aws_spot_fleet_request" "backtest" {
  iam_fleet_role  = aws_iam_role.fleet.arn
  spot_price      = "0.10"
  target_capacity = 100  # CPU-Stunden in Sum
  allocation_strategy = "capacityOptimized"

  launch_specification {
    ami           = data.aws_ami.ubuntu_22.id
    instance_type = "c6i.xlarge"
    subnet_id     = aws_subnet.private.id
    iam_instance_profile = aws_iam_instance_profile.worker.name
    user_data = filebase64("worker_init.sh")
  }
  # ... mehrere weitere Instance Types als Fallback
}

Worker pullen Jobs aus SQS, schreiben Ergebnisse nach S3. Ein 200-Parameter-Sweep, der lokal 8 Stunden braucht, dauert hier 15 Minuten und kostet 4–6 €.

Meine Praxis.

Mein Aufteilung sieht aktuell so aus:

Wer mit AWS oder GCP startet, weil es „professioneller" klingt, verbrennt unnötig Geld. Wer Hetzner-only fährt und nie skaliert, lässt Bequemlichkeit und Geschwindigkeit liegen. Die richtige Antwort ist meistens hybrid — und beginnt mit der Frage: was rechtfertigt den Faktor-5-Aufpreis?

Sie planen ein Trading-Setup und sind unsicher, ob Cloud oder VPS? Erstgespräch buchen — wir gehen Workload und Kosten konkret durch.