← Cloud Compute
Multi-account IBKR · ECS + serverless

IBKR Trading Infrastructure on AWS

A live multi-account futures execution platform: TradingView strategy alerts become real broker orders across many isolated Interactive Brokers accounts, with end-to-end reconciliation proving every signal became the right fill. Each account runs as its own ECS service, discovered over DNS, with credentials injected from Secrets Manager and zero long-lived IAM keys anywhere. ~19k lines of Python, IaC and tooling across 7 ordered SAM/CloudFormation stacks.

Python 3.12 IBKR Gateway + IBC AWS SAM / CloudFormation ECS on EC2 Cloud Map (DNS SRV) Lambda SQS FIFO DynamoDB Secrets Manager Docker
⚡
Built with agentic AI. Development on this project runs through multi-agent Claude Code workflows — developer → independent-reviewer cycles with evidence gates, batched into unattended runs that execute overnight and resume from committed ledgers. How the agent system works →

The signal path

TradingView webhook → API Gateway → ingest Lambda persists the signal and fans out only to accounts flagged provisioned and trading → SQS FIFO with per-account message groups, so each account's entries and exits stay strictly ordered → a forward Lambda resolves which ECS task hosts the account and hands it the signal → the executor qualifies the contract, applies latency and risk gates, and places bracket orders. Fills, P&L and per-hop latency land back in DynamoDB.

Account = one ECS service

  • Each account is an ECS task: an IB Gateway container plus an executor container, credentials injected at start from Secrets Manager — never on disk.
  • A reconciler Lambda is the control plane: onboarding an account = creating a secret; it creates, updates and retires one ECS service per account.
  • Failure domains stay small — a broken gateway affects exactly one account. Operator access via SSM Session Manager: no SSH, no open ports.

Discovery & security

  • "Which task hosts this account" is answered by plain DNS SRV lookups against Cloud Map — replacing paid API calls removed a VPC endpoint and ~150–190 ms of per-signal latency.
  • Every signal carries per-hop timestamp breadcrumbs (webhook → SQS → forward → executor → fill) with zero added calls on the trading path.
  • Zero long-lived IAM keys: SSO locally, IAM roles everywhere else; the sole public surface is the tokenized webhook.

Proving it executed correctly

3-way trade reconciliation

  • A Chrome extension captures TradingView's List-of-Trades; a reconciliation Lambda joins TradingView trade ↔ ingested signal ↔ broker fill, daily.
  • Matching uses a futures continuous-contract normalizer and an asymmetric time window (a fill can only land at-or-after its signal) — both fixes for silent mis-matches found in practice.
  • Every row is classified: signal_missing → fill_missing → price_mismatch → pnl_gap → high_latency → matched.

Execution gates & ops

  • The executor rejects stale signals and refuses entries without explicit take-profit and stop-loss; brackets are placed only after unambiguous contract qualification.
  • Structured ALARM log markers become CloudWatch metrics and alerts automatically — a new alarm condition is a log line, not an infrastructure change.
  • standby / wake scripts park the entire platform without deleting infrastructure; a real bill variance was traced to an oversized status object and fixed at the source.

Deployment

Seven ordered SAM/CloudFormation stacks — network, data, cluster, signals, ops, dashboard, reconciliation — deployed in order by one script. Onboarding a new account afterwards is a single secret in Secrets Manager; the reconciler does the rest.