MagentaGaming Cloud Gaming Platform

Überblick

MagentaGaming ist der Cloud-Gaming-Dienst der Deutschen Telekom, der AAA-Spieletitel über Browser und Thin Clients an Endnutzer ausliefert — ohne lokale Hardware. Als Teil von T-Systems war ich als Cloud Architect für den Plattformaufbau verantwortlich und zuständig für die AWS-Infrastruktur, die Session-Management, Streaming-Delivery und Player-State-Persistenz betreibt.

Das Projekt lief von Mitte 2020 bis Anfang 2021. Das 25-köpfige Team lieferte einen produktionsreifen MVP in 5 Monaten und startete öffentlich auf der Gamescom — einer der weltweit größten Gaming-Messen — im August 2021.

Herausforderung

Die bestimmende Rahmenbedingung dieses Projekts war das feste Gamescom-Launch-Datum. Die Deadline war unveränderlich: Die Deutsche Telekom hatte sich zu einem öffentlichen Launch auf der Messe verpflichtet, mit bereits geplanter Presseberichterstattung und Partnerankündigungen. Ein Verpassen war keine Option.

Dies schuf eine harte Engineering-Rahmenbedingung: Jede Architekturentscheidung musste Korrektheit gegen Liefergeschwindigkeit abwägen. Die Plattform musste unvorhersehbaren Burst-Traffic eines Live-Launch-Events bewältigen und gleichzeitig stabil genug für eine öffentliche Demo-Umgebung sein. Die Latenzanforderungen für Cloud-Gaming sind unnachgiebig — jeder Infrastruktur-Engpass übersetzt sich direkt in eine verschlechterte Spielerfahrung, die für Presse und Partner auf dem Messegelände sichtbar ist.

Rolle

Als Cloud Architect war ich für das End-to-End-AWS-Infrastrukturdesign und die technische Aufsicht über das 25-köpfige Team verantwortlich. Meine Aufgaben umfassten:

• Design der Game-Session-Orchestrierungsschicht mit Amazon GameLift für Fleet-Management und Session-Placement
• Architektur der EC2-Gaming-Instance-Flotte mit GPU-optimierten Instance-Typen und Auto-Scaling-Policies für Burst-Kapazität
• Design der CloudFront-Distribution für latenzarme Game-Stream-Delivery über europäische Regionen
• Implementierung der Player-State- und Session-Datenschicht mit DynamoDB und ElastiCache
• Definition der Lambda-basierten Control-Plane für das Session-Lifecycle-Management
• Koordination der Infrastrukturlieferung über Frontend-, Backend- und Platform-Engineering-Workstreams

Vorgehen

Angesichts der festen Deadline adoptierte das Team ein zeitgesteuertes Liefermodell mit wöchentlichen Infrastruktur-Meilensteinen.

Wochen 1–4 — Core-Infrastruktur: Aufbau der VPC-Topologie, EC2-Gaming-Instance-Baseline und GameLift-Fleet-Konfiguration. Terraform-Module wurden für alle Kernressourcen von Tag eins an entwickelt, um reproduzierbare Umgebungen über Dev, Staging und Produktion sicherzustellen.

Wochen 5–8 — Session-Management und Skalierung: Implementierung der GameLift-Matchmaking- und Session-Placement-Logik, Integration der Lambda-Control-Plane für Session-Lifecycle-Events und Konfiguration der Auto-Scaling-Policies für die EC2-Flotte. Lasttests begannen in Woche 7, um Burst-Kapazitätsannahmen zu validieren.

Wochen 9–14 — Delivery-Schicht und Härtung: Deployment der CloudFront-Distribution mit optimierten Cache-Behaviors für Game-Stream-Traffic, Integration von ElastiCache für Session-State und End-to-End-Latenz-Benchmarks. Die letzten zwei Wochen waren der Produktionshärtung, Runbook-Erstellung und Gamescom-Rehearsal-Szenarien gewidmet.

Gamescom-Launch: Die Plattform bewältigte das Live-Launch-Event ohne Zwischenfälle. Nach dem Launch wechselte das Team in ein Steady-State-Betriebsmodell.

Entscheidungen

Amazon GameLift statt Custom-Session-Orchestrierung: Das frühe Design hatte eine eigene Session-Broker-Lösung auf EC2 mit DynamoDB-basierter Queue in Betracht gezogen. Wir entschieden uns für GameLift, da es battle-tested Fleet-Management, integriertes Matchmaking und Session-Placement-Logik bot, die zuverlässig zu replizieren Wochen gedauert hätte. Angesichts der Deadline war die Reduzierung der Custom-Code-Oberfläche eine bewusste Risikominimierungsstrategie.

CloudFront für Stream-Delivery: Statt Game-Stream-Traffic direkt von EC2-Instances zu routen, platzierten wir CloudFront vor der Delivery-Schicht. Dies reduzierte die Origin-Last bei Burst-Events und sorgte für eine konsistente Edge-Präsenz über europäische PoPs — entscheidend für das Latenzprofil, das Cloud-Gaming erfordert.

DynamoDB + ElastiCache für Player-State: Player-Session-State erforderte sowohl Dauerhaftigkeit (DynamoDB) als auch Sub-Millisekunden-Leselatenz für aktive Sessions (ElastiCache). Der zweistufige Ansatz ermöglichte es der Plattform, aktive Session-Daten aus dem Cache zu bedienen, während State-Änderungen asynchron in DynamoDB persistiert wurden.

Terraform von Anfang an: Die gesamte Infrastruktur wurde von Sprint eins an in Terraform definiert. Diese Entscheidung zahlte sich in den letzten Wochen aus, als Produktionsumgebungsparität mit Staging für zuverlässige Launch-Rehearsals entscheidend war.

Ergebnisse

Die Plattform startete termingerecht auf der Gamescom und erfüllte alle zugesagten Meilensteine:

• 5-monatige MVP-Lieferung vom Projektstart bis zum öffentlichen Gamescom-Launch
• 25-köpfiges cross-funktionales Team über T-Systems- und Deutsche-Telekom-Stakeholder koordiniert
• Gamescom-Launch ohne Zwischenfälle abgeschlossen — Plattform bewältigte Live-Event-Traffic und Pressedemonstrationen
• EC2-Gaming-Flotte mit Auto Scaling bewältigte Burst-Kapazität während des Launch-Events
• Sub-100ms Session-Placement-Latenz durch GameLift-Fleet-Konfiguration erreicht
• CloudFront-Distribution über europäische Edge-Locations für konsistente Stream-Delivery deployed
• DynamoDB + ElastiCache Player-State-Schicht hielt gleichzeitige aktive Sessions während des gesamten Launch-Fensters aufrecht

Die feste Deadline erzwang eine Disziplin in Bezug auf Scope und architektonische Einfachheit, die eine wartbarere Plattform produzierte, als ein längeres, offeneres Engagement es möglicherweise getan hätte. Der Gamescom-Launch diente als Forcing Function für Produktionsreife.