MEMON SYSTEMS

Cloud Gaming Infrastructure: Per-Tenant Egress and Idle-Storage Cost at 56-Tenant Density

Profile Hyperscale Cloud Gaming Blueprint (Middle East & Singapore)
Stack Oracle Cloud (OCI) / Linux / Proton / OverlayFS / Tauri / Moonlight+Sunshine
Duration 8 Weeks
Outcome Sub-$0.70/hr Unit Economics at 56-Tenant Bare-Metal Density

Video Walkthrough & Architecture Breakdown

Watch on YouTube ↗

The Challenge

Under standard 1:1 cloud provisioning, data egress alone cost $1.24/hr per tenant on AWS, before compute, before idle storage. Set against the per-tenant price incumbents on dedicated hardware fleets charge end users, the cost floor sat above the revenue ceiling.

Executive Summary

We architected a hyperscale cloud gaming infrastructure capable of competing with NVIDIA GeForce NOW, without requiring upfront capital expenditure, access to proprietary hardware, or a pre-existing user base.

The target deployment regions, the Middle East and Singapore, imposed latency requirements that ruled out decentralized compute markets. Under standard 1:1 provisioning on major hyperscalers, data egress and idle storage put the per-tenant cost floor above the per-tenant revenue ceiling: $1.24/hr in egress per tenant on AWS, before compute.

We resolved this by transitioning the compute topology to Oracle Cloud Infrastructure (OCI), exploiting its asymmetric egress pricing. We selected Linux with Proton as the game execution layer (eliminating Windows licensing overhead) and enforced a Bring Your Own Game (BYOG) licensing model via Steam OAuth verification. We decoupled game state at the kernel storage layer using OverlayFS, implemented an instant hot-swap orchestration framework, and designed a multi-tier compute scaling strategy spanning cost-optimized A10 nodes at startup to high-density BM.GPU.RTXPRO.8 bare-metal clusters at scale. This architecture brings per-tenant cost to $0.56/hr at startup scale and $0.65/hr at 56-tenant density, without upfront CapEx.

1. The Cost Floor

We audited three infrastructure models targeting the Middle East and Singapore. Each revealed a distinct failure mode that, while individually solvable, compounded into a catastrophic margin erosion rooted in the fundamental economics of cloud compute.

1.1 The 1:1 Cloud Provisioning Trap

The naive approach provisions a dedicated cloud GPU instance and a 1TB storage volume per user. The volume contains the game library, and a streaming stack (Sunshine, Proton, Wine) delivers the video feed. While this architecture is functionally correct, the unit economics are dead on arrival.

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph Client ["Client Edge"]
        Player["Client Application<br>(Moonlight Protocol • 1080p 60fps)"]:::prominent
    end

    subgraph Infrastructure ["Hyperscaler Cloud Architecture (1:1 Provisioning)"]
        CloudGPU["Dedicated Cloud GPU Instance<br>(On-Demand/<br>Spot Compute)"]:::steel
        UserDisk[("Dedicated Storage Volume<br>(1TB Block Storage per User)")]:::sage
        StreamStack["Streaming Service Stack<br>(Sunshine / Proton / Wine)"]:::gold
        EgressCost["Data Transfer Routing<br>(High Egress Volume)"]:::crimson
        
        CloudGPU --> UserDisk
        CloudGPU --> StreamStack
        StreamStack --> EgressCost
    end

    Player -- "Standard Latency / High Cost Structure" --> Infrastructure
    class Client,Infrastructure ghost

At standard hyperscaler rates (AWS), a 1080p 60fps stream generates continuous high-bandwidth egress. Per user, the cost structure decomposes to:

  • Compute: ~$1.99/hr on-demand for a g5.4xlarge GPU instance.
  • Storage: $9.60/mo per 100GB EBS volume (at minimum; a full game library volume costs significantly more).
  • Egress: ~$1.24/hr per tenant in data transfer fees for the video stream alone.

The bandwidth costs exceed the compute overhead by over 300%. Giving each user a dedicated node and a dedicated storage volume generates an immediate OpEx liability that outpaces any viable consumer price point.

1.2 The P2P Compute Dead End

To optimize capital efficiency, we audited peer-to-peer compute networks. Platforms like Vast.ai offer bare-metal GPU nodes at a fraction of hyperscaler pricing, with rates as low as $0.058/hr for basic instances and ~$0.30/hr for AAA-capable GPUs.

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph Client ["Client Edge"]
        Player["Client Application<br>(Moonlight Protocol • 1080p 60fps)"]:::prominent
    end

    subgraph Infrastructure ["Decentralized P2P Compute Architecture"]
        CheapHost["Leased Bare-Metal GPU Node<br>(Spot/P2P Market Pricing)"]:::steel
        StreamStack["Streaming Service Stack<br>(Sunshine / Proton / Wine)"]:::gold
        NetIssues["Network Topology Constraints<br>(Variable Stability)"]:::crimson
        GeoIssues["Geographic Availability Limitations<br>(e.g., Middle East, APAC Gaps)"]:::crimson
        
        CheapHost --> StreamStack
        CheapHost --> NetIssues
        CheapHost --> GeoIssues
    end

    Player -- "Variable Latency / Low Cost Structure" --> Infrastructure
    class Client,Infrastructure ghost

However, this approach introduced three critical failure modes:

  1. Geographic Unavailability: The target regions (Middle East, Singapore) are consistently underserved on P2P compute markets. Reliable nodes in these locations are rarely available, and when they are, they are quickly rented by other customers.
  2. Machine Lock-in & Data Persistence: Games are persisted to the local disk of a specific machine. If that machine is rented by another customer between sessions, the next session cannot utilize it. Transferring multi-hundred-gigabyte game installations to a new node introduces significant delays and network costs.
  3. Network Instability: Despite fast internet connections, the variable network topology of P2P hosts introduces significantly noticeable timeouts, latency spikes, and connection drops during gameplay.

Conclusion: Cheap compute generates zero leverage if the network topology isolates the target user base. The cost savings are negated by the inability to guarantee consistent geographic availability and session continuity.

1.3 The Spot Instance Engineering Trap

A competent engineer's next attempt targets the compute cost via ephemeral Spot Instances. On AWS, Spot discounts of 35-45% reduce a g5.4xlarge instance from ~$1.99/hr to ~$1.30/hr, yielding a per-tenant compute cost of ~$0.40/hr when grouping 3 tenants per node. However, Spot instances can be terminated with only a 2-minute warning, requiring a ruthless orchestration layer.

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph Client ["Client Edge"]
        T1(("Tenant 1")):::prominent
        T2(("Tenant 2")):::prominent
        T3(("Tenant 3")):::prominent
    end

    subgraph AWS ["AWS Infrastructure (Instant Hot-Swap Architecture)"]
        S3[("Amazon S3<br>Game Library & Saves")]:::sage
        Orchestrator["Tiny VM Orchestrator<br>(Lifecycle Management)"]:::steel
        EBS[("EBS gp3 NVMe<br>Game, OS, Software")]:::sage
        
        subgraph SpotNode ["g5.4xlarge Spot Instance"]
            Wine["Linux Host / Proton + Sunshine<br>(Streaming Stack)"]:::gold
        end
        
        S3 -->|"1. Transfer Data on Demand"| EBS
        EBS --- SpotNode
        SpotNode -->|"3. 2-Min Warning: Slam state/saves to cloud"| S3
        Orchestrator -->|"2. Provision replacement node on warning"| SpotNode
    end
    
    T1 -->|"Play Session"| Wine
    T2 -->|"Play Session"| Wine
    T3 -->|"Play Session"| Wine
    
    class Client,AWS ghost
    class SpotNode ghost

The Instant Hot-Swap Method

To survive Spot terminations, we designed an instant hot-swap orchestration process that must execute within the 2-minute termination window:

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    Signal["⚠️ 2-Minute Termination Warning Received"]:::crimson

    subgraph DyingNode ["Active Spot Instance (Terminating)"]
        ForceSave["1. Slam Quick Save<br>(AutoHotkey / Script Injection)"]:::gold
        Upload["2. Upload State<br>(Push save files to S3)"]:::sage
    end

    subgraph ControlPlane ["Control Plane"]
        Orchestrator["Tiny VM Orchestrator"]:::steel
        Provision["3. Provision Replacement Instance<br>& Attach existing EBS gp3 Volume"]:::steel
    end

    subgraph CloudStorage ["Persistent Cloud Storage"]
        ObjStore[("Object Storage<br>(S3 / Cloud Saves)")]:::sage
    end

    subgraph NewNode ["Replacement Spot Instance (Active)"]
        Download["4. Restore State<br>(Pull saves from S3)"]:::sage
        Resume["5. Resume Play<br>(Auto-load save via CLI/Macros)"]:::prominent
    end

    %% Flow of events
    Signal --> ForceSave
    Signal --> Orchestrator

    ForceSave --> Upload
    Upload --> ObjStore

    Orchestrator --> Provision
    Provision --> Download
    
    ObjStore --> Download
    Download --> Resume

    class DyingNode,ControlPlane,CloudStorage,NewNode ghost

The process leverages EBS gp3 volumes, which operate over NVMe-over-Fabrics with a dedicated PCIe lane to the node, separate from the node's primary network interface. This means EBS I/O does not compete with the game stream's network bandwidth. The gp3 IOPS can be dynamically increased for faster game loading, and volumes can be detached and reattached to replacement instances.

The hot-swap orchestration works. The cost per tenant it runs on does not clear the revenue per tenant:

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph Compute ["Compute Allocation (Structurally Viable)"]
        Node["g5.4xlarge Instance<br>Base Price: ~$1.99/hr"]:::steel
        Spot["Spot Instance Discount<br>(35% - 45% Reduction)"]:::sage
        EffectiveCost["Effective Node Cost<br>~$1.30/hr"]:::gold
        TenantCompute["Per-Tenant Compute<br>~$0.40/hr (3 Tenants grouped per node)"]:::gold
        
        Node --> Spot --> EffectiveCost --> TenantCompute
    end

    subgraph Traps ["The Deal Breakers (Architectural Fatalities)"]
        Egress["Data Transfer Egress<br>~$1.24/hr per Tenant"]:::crimson
        Storage["EBS Persistent Storage<br>~$9.60/mo per Volume"]:::crimson
    end

    Result["Broken Unit Economics<br>(Bandwidth costs exceed compute overhead by >300%, negating all Spot savings)"]:::prominent

    TenantCompute --> Result
    Egress --> Result
    Storage --> Result

    class Compute,Traps ghost

Even with Spot-optimized compute at $0.40/hr per tenant, the data transfer egress ($1.24/hr per tenant) and persistent EBS storage costs destroy profitability. The total per-tenant cost lands at $1.27/hr, making the model unviable.

Beyond raw costs, the hot-swap strategy introduces additional structural vulnerabilities specific to the target regions:

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph Core ["AWS Hot Swap Strategy"]
        Mechanism["Hot Swap Orchestration<br>(EBS Detach/Attach + State Sync)"]:::prominent
    end

    subgraph ComputeLimits ["Compute & Geographic Vulnerabilities"]
        GeoConstraints["Regional Capacity Constraints<br>(Smaller AWS Datacenter Footprints in ME / SG)"]:::crimson
        SpotTimeout["Orchestration SLA Failure<br>(Inability to locate/provision Spot VM replacement within 2 min limit)"]:::crimson
        
        GeoConstraints --> SpotTimeout
    end

    subgraph StorageLimits ["Storage Constraints & Economic Traps"]
        IdleEBS["Idle Infrastructure Expenditure<br>(Redundant continuous billing for EBS volumes during zero-tenant periods)"]:::crimson
        
        AttachLimits["EBS 1:1 Attachment Constraint<br>(Scaling for more tenants requires new dedicated EBS volumes & on-the-fly game fetches)"]:::crimson
        MultiAttach["Multi-Attach Volume Risks<br>(Introduces latency & data corruption due to multi-node state tracking)"]:::crimson
        DataTransfer["Prohibitive Data Transfer Costs<br>(Massive Ingress/Egress network charges generated by on-the-fly object storage fetches)"]:::crimson
        
        AttachLimits --> MultiAttach
        AttachLimits --> DataTransfer
    end

    Mechanism --> ComputeLimits
    Mechanism --> IdleEBS
    Mechanism --> AttachLimits

    class Core,ComputeLimits,StorageLimits ghost

AWS datacenters in the Middle East and Singapore have smaller Spot pools, increasing the probability that a replacement instance cannot be provisioned within the 2-minute window, resulting in a hard session drop. EBS volumes are billed continuously even during zero-tenant idle periods. And EBS's 1:1 attachment model means scaling multi-tenancy requires either duplicating volumes (multiplying storage costs) or fetching games on-the-fly from S3 (introducing prohibitive data transfer charges).

Conclusion: The engineering is sound. The financial architecture is not. A new architectural equilibrium was required.

2. The Architectural Transition

2.1 Infrastructure Arbitrage: OCI Selection

To compete with giants, we don't optimize code; we exploit infrastructure pricing models. We resolved the egress vulnerability by transitioning the network topology to Oracle Cloud Infrastructure (OCI), which offers a fundamentally different cost structure:

  • Egress: The first 10TB of outbound data transfer per month is free. Beyond that, OCI egress rates are a fraction of AWS pricing.
  • Internal VCN Traffic: Unmetered. No inter-availability-domain transfer fees.
  • Block Storage: Significantly lower per-GB pricing with high-performance tiers.

The economic impact is immediate and decisive:

Cost Element (Per Month) AWS g5.4xlarge (3 Tenants) OCI VM.GPU3.1 (2 Tenants) OCI VM.GPU.A10.1 (4 Tenants)
Compute Cost $949.00 $1,097.40 $1,488.00
Egress Cost $1,725.35 $101.07 $101.07
Storage Cost $120.00 $50.00 $50.00
Total Cost / Instance $2,794.35 $1,248.47 $1,639.07
Max Concurrent Tenants 3 Users 2 Users 4 Users
Total Tenant Hours / Month 2,190 Hours 1,460 Hours 2,920 Hours
True Cost Per Tenant Hour $1.27 / hour $0.86 / hour $0.56 / hour

Note: Computations assume 100% utilization to determine baseline operational costs. Real-world costs are managed via the idle cost management strategy detailed in Section 2.4.

The OCI V100 (VM.GPU3.1) served as our initial cost validation, proving the economics at $0.86/hr per tenant. We then progressed to A10 GPU nodes for production, which support modern rendering features (DLSS, Ray Tracing) and higher tenant density (4-5 tenants per GPU), driving the cost to $0.56/hr.

2.2 Platform & Software Stack

A critical architectural decision was the selection of the game execution layer. The industry standard for cloud gaming is hardware virtualization via VFIO/QEMU, passing a physical GPU directly to a Windows guest VM. We rejected this approach in favor of API translation via Linux + Proton.

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph Client ["Client Edge"]
        Player["Client Application<br>(Moonlight Protocol • 1080p 60fps)"]:::prominent
    end

    subgraph VFIO ["Hardware Virtualization (VFIO QEMU/KVM)"]
        Hypervisor["QEMU / KVM Hypervisor<br>(Host Linux Kernel)"]:::steel
        VFIO_PCI["VFIO PCIe Passthrough<br>(1:1 GPU Allocation)"]:::sage
        GuestOS["Guest Operating System<br>(Strict Hardware Isolation)"]:::gold
        App_VFIO["Target Application / Game"]:::gold
        
        Hypervisor --> VFIO_PCI
        VFIO_PCI --> GuestOS
        GuestOS --> App_VFIO
    end

    subgraph Proton ["API Translation (Proton / Wine)"]
        LinuxHost["Linux Host Operating System<br>(Shared Kernel Resources)"]:::steel
        Isolation["System Isolation Capability<br>(Namespaces, cgroups, Containers)"]:::sage
        Translation["Translation Layer<br>(Proton / Wine / DXVK)"]:::gold
        App_Proton["Target Application / Game"]:::gold
        
        LinuxHost --> Isolation
        Isolation --> Translation
        Translation --> App_Proton
    end

    Player -- "Dedicated Resource Overhead" --> VFIO
    Player -- "Flexible Allocation / Shared Resources" --> Proton

    class Client,VFIO,Proton ghost

Why Proton wins for multi-tenant cloud gaming:

  1. Shared Kernel Resources: VFIO passthrough allocates one physical GPU per VM in a 1:1 binding. Linux + Proton runs games in userspace via DXVK (DirectX-to-Vulkan translation), allowing the host kernel to share GPU compute across multiple tenant processes. This is the foundation of our multi-tenant density model.
  2. Zero Windows Licensing: Eliminating Windows Server licensing removes a significant per-node cost and avoids licensing complexity entirely.
  3. Customizability: Full control over the host operating system enables kernel-level storage optimizations (OverlayFS), resource isolation (cgroups, namespaces), and automated game management that would be impossible inside a locked-down Windows guest.

Streaming Protocol: We use Moonlight (client) + Sunshine (server) for the game stream. Sunshine runs on the Linux host, encoding the game video output via the GPU's hardware NVENC encoder and streaming it to the Moonlight client over the network.

Licensing Model (BYOG): Purchased or pirated game copies cannot be legally distributed to users. We enforce a strict Bring Your Own Game model. Users authenticate via Steam OAuth. Through Steam's API, we verify the user's library and game licenses. If the user does not own the game, they cannot play it. The authentication flow is non-negotiable for legal viability.

Game Delivery: To prevent lengthy downloads, each node mounts a read-only drive containing pre-installed game data. This drive includes both the game files and the necessary Steam appmanifest files, allowing Steam to instantly recognize the game as "installed" without any download or verification step.

2.3 Shared Storage & OverlayFS Architecture

With egress costs neutralized via OCI and the software stack defined, we architected the core storage innovation: a shared, read-only block volume with per-tenant OverlayFS write isolation.

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph Client ["Client Edge (Solved Egress: OCI 10TB/mo Free Tier)"]
        T1(("Tenant 1")):::prominent
        T2(("Tenant 2")):::prominent
        T3(("Tenant 3")):::prominent
        T4(("Tenant 4")):::prominent
    end

    subgraph OCI ["Oracle Cloud Infrastructure (Final Optimized Architecture)"]
        ObjStore[("OCI Object Storage<br>(Idle State Backups)")]:::sage
        SharedVol[("Shared Block Storage (1.5TB)<br>(Read-Only Shareable / Multi-Attach)")]:::prominent
        
        ObjStore -- "1. Warmup: Mount & Sequential Read to SSD" --> SharedVol
        SharedVol -- "4. Idle: Backup to Object Storage" --> ObjStore
        
        subgraph Node1 ["VM.GPU3.1 Preemptible Node 1"]
            Overlay1[("Small Local Block<br>(OverlayFS Upperdir)")]:::gold
            Wine1["Linux / Proton + Sunshine<br>(Streaming Stack)"]:::steel
            Wine1 -- "3. Write saves/state" --> Overlay1
            Wine1 -- "2. Read game files" --> SharedVol
        end
        
        subgraph Node2 ["VM.GPU3.1 Preemptible Node 2"]
            Overlay2[("Small Local Block<br>(OverlayFS Upperdir)")]:::gold
            Wine2["Linux / Proton + Sunshine<br>(Streaming Stack)"]:::steel
            Wine2 -- "3. Write saves/state" --> Overlay2
            Wine2 -- "2. Read game files" --> SharedVol
        end
        
        SharedVol -. "Supports up to 8 Nodes<br>(Resolves AWS 1:1 Storage Constraint)" .-> NodeN["... Nodes 3 to 8"]:::ghost
    end
    
    T1 -- "Play Session" --> Wine1
    T2 -- "Play Session" --> Wine1
    T3 -- "Play Session" --> Wine2
    T4 -- "Play Session" --> Wine2

    class Client,OCI,Node1,Node2 ghost

Implementation

We deployed a single 1.5TB, 120 VPU (Volume Performance Units) high-speed block volume on OCI, containing the full game library, operating system, and streaming software. This volume is attached as read-only and shareable across multiple compute nodes.

The problem with standard multi-attach block storage is that multiple nodes writing stateful files to the same volume creates competing state tracking, introducing systemic data corruption. We resolved this via OverlayFS at the Linux kernel level:

  1. Lowerdir (Read-Only): The shared 1.5TB volume is mounted as the OverlayFS lowerdir. All game data reads come from this shared volume.
  2. Upperdir (Writable): On each compute node, a separate, small (~20GB per tenant), cost-optimized block volume serves as the OverlayFS upperdir. Any file modifications (save games, configuration changes, shader caches) are captured here.
  3. Merged View: Proton and Sunshine see a unified, writable filesystem. They read massive game data from the shared volume and write tenant-specific state to the isolated local volume.

Scaling Constraint: OCI allows up to 8 instances to operate from a single shared block volume. To scale beyond 8 nodes, we create storage replicas. At peak density with BM.GPU.RTXPRO.8 nodes (56 tenants per node), a single shared volume supports up to 448 concurrent tenants (8 nodes × 56 tenants).

The Network Throughput Paradox

At 448 concurrent tenants sharing a single block volume, a theoretical throughput concern emerges. The OCI Ultra High Performance volume outputs a maximum of 2,680 MB/s. Divided across 448 tenants, this yields only ~6 MB/s per tenant, far below the 200-500 MB/s burst reads that AAA games require for asset loading. This calculation suggests catastrophic failure.

In practice, the Linux kernel's Page Cache resolves this entirely:

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph TheMath ["The Theoretical Bottleneck (Raw Math)"]
        Pipe["OCI Ultra High Performance Volume<br>(Max Throughput: 2680 MB/s)"]:::steel
        Tenants["448 Concurrent Tenants"]:::crimson
        Math["2680 MB/s ÷ 448 = ~5.98 MB/s per Tenant"]:::crimson
        Panic["Catastrophic Failure<br>(AAA games require 200-500 MB/s bursts; 6 MB/s causes stutter/crashes)"]:::crimson

        Pipe --> Tenants --> Math --> Panic
    end

    subgraph TheSavior ["The Real-World Solution (Linux Page Cache)"]
        NVMeOF["NVMe-oF Backend (OCI SmartNIC)<br>(Sub-millisecond latency; maps directly to PCIe bus)"]:::sage
        FirstRead["1. The First Read (Network Hit)<br>Tenant 1 loads Game X (Uses Network Pipe)"]:::gold
        RAMCache["Linux Page Cache (Node RAM)<br>(Files cached in memory at 50+ GB/s)"]:::prominent
        SubsequentReads["2. Subsequent Reads (RAM Hit)<br>Tenants 2-56 load Game X (Bypasses Network Pipe entirely)"]:::gold

        NVMeOF --> FirstRead --> RAMCache --> SubsequentReads
    end

    subgraph TheDanger ["The Edge Case (Cache Thrashing)"]
        Fragmentation["High Fragmentation<br>(56 tenants play 56 massive, different games)"]:::steel
        Eviction["RAM Fills / Cache Eviction<br>(System forced to fetch assets over network)"]:::crimson
        Thrashing["Network Thrashing<br>(Defaults back to the 5.98 MB/s catastrophic bottleneck)"]:::crimson

        Fragmentation --> Eviction --> Thrashing
    end

    Panic -. "Mitigated by OS Architecture" .-> NVMeOF
    SubsequentReads -. "Breaks if..." .-> Fragmentation

    class TheMath,TheSavior,TheDanger ghost

OCI block volumes operate over NVMe-over-Fabrics via SmartNIC hardware with sub-millisecond latency. When the first tenant loads a game, the files are read from the network volume and cached in the node's RAM by the Linux Page Cache. When subsequent tenants load the same game, the reads are served entirely from RAM at 50+ GB/s, bypassing the network pipe completely.

The edge case is cache thrashing: if 56 tenants on a single node each play 56 different massive games, the RAM fills and the cache evicts assets, forcing network reads. In practice, cloud gaming services exhibit strong title concentration (popular games dominate), and the orchestrator can group tenants playing the same title onto the same node to maximize cache hit rates.

2.4 Cold-Start Elimination & Idle Cost Management

NVIDIA GeForce NOW has an inherent competitive advantage: their massive user base ensures hardware is rarely idle. A startup service will experience significant idle periods, and paying for active block storage during zero-tenant windows is financially unsustainable.

We engineered a three-phase storage lifecycle that transitions between active, warm, and cold states:

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph IdlePhase ["Phase 1: Zero-Tenant Idle State (Cost Optimization)"]
        ObjStore[("OCI Object Storage<br>(Master Backup Repository • ~$0.05/hr)")]:::sage
        TearDown["Compute & Active Block Volumes Terminated<br>(Eliminates ~$0.48/hr idle burn)"]:::steel
        
        TearDown -. "Retains State" .-> ObjStore
    end

    subgraph WarmupPhase ["Phase 2: Predictive / On-Demand Warm-up"]
        RestoredVol[("Restored Block Volume<br>(Vulnerable to Lazy-Loading Network Latency)")]:::crimson
        SeqRead["Sequential Read Execution<br>(e.g., tar -cf /dev/null /mnt/games/target)"]:::prominent
        ReadyVol[("Fully Cached Physical SSD<br>(Eliminates in-game network fetch latency)")]:::sage

        ObjStore -- "1. Restore Volume on Tenant Demand" --> RestoredVol
        RestoredVol -- "2. Force Max-Speed Cache Fetch" --> SeqRead
        SeqRead -- "3. Commit Target Game to SSD" --> ReadyVol
    end

    subgraph ActivePhase ["Phase 3: Active OverlayFS Architecture (Supports 1 to 8 Nodes)"]
        SharedLower[("High-Performance Shared Volume (1.5TB)<br>(Read-Only Lowerdir)")]:::gold
        LocalUpper[("Cheap Small Local Block Volume<br>(Writable Upperdir)")]:::steel
        OverlayFS["OverlayFS Controller<br>(Merges R/O Library + Writable State)"]:::prominent
        GPUApp["Streaming Stack & Game Runtime<br>(Sees unified writable filesystem)"]:::gold

        ReadyVol -. "4. Mounts As" .-> SharedLower
        SharedLower -- "Reads Massive Game Data" --> OverlayFS
        OverlayFS -- "Isolates Saves & Configs" --> LocalUpper
        OverlayFS --- GPUApp
    end

    class IdlePhase,WarmupPhase,ActivePhase ghost

Phase 1 (Idle State): When the tenant count drops to zero, we tear down all compute instances and the active block volume, leaving only the master backup in OCI Object Storage. This reduces idle costs from ~$0.48/hr to ~$0.05/hr, a 90% reduction in idle burn.

Phase 2 (Warm-up): When a tenant requests a session, we restore the block volume from the Object Storage backup. However, a restored volume does not physically contain the files on SSD; it only holds metadata pointers to the network-backed Object Storage. Reading files triggers lazy-loading over the network, introducing massive latency that manifests as severe in-game lagging.

We resolve this by injecting a sequential read execution command immediately upon mounting:

tar -cf /dev/null /mnt/games/cyberpunk2077

This commands the OS to sequentially read the entire game directory from the network pipe at maximum speed, caching the files onto the local SSD. The output is discarded to /dev/null, the objective being solely to populate the SSD cache. Once cached, the files are ready for read-only operation by tenants without in-game network latency.

Optimization: Rather than warming the entire 1.5TB volume (which contains many games), we provision/warm only the requested game from the backup, minimizing the network pull and accelerating time-to-play. Pre-warming can also be triggered predictively based on the peak hours algorithm (Section 3.2).

Phase 3 (Active): The warmed volume mounts as the read-only shared lowerdir, and the OverlayFS architecture operates as described in Section 2.3.

2.5 Compute Tiering & Dynamic Scaling

Selecting the correct compute tier is critical to avoiding early-stage margin erosion. Deploying a high-density BM.GPU.RTXPRO.8 node (capable of 56 concurrent tenants) during a low-traffic startup period guarantees severe underutilization and broken unit economics.

We implemented a three-tier compute scaling strategy using OCI A10 GPU nodes, dynamically selecting the optimal instance type based on real-time traffic volume:

Instance Type GPU Configuration Concurrent Tenants Use Case
VM.GPU.A10.1 1x A10 (24GB VRAM) 4-5 Tenants Low traffic / Startup
VM.GPU.A10.2 2x A10 (48GB VRAM) 8-10 Tenants Moderate traffic
BM.GPU.A10.4 4x A10 (96GB VRAM) 16-20 Tenants Peak traffic (Bare Metal)

Advance Provisioning Threshold: To prevent out-of-capacity errors and wait times, instances are provisioned in advance based on a strict threshold. If a GPU supports 5 tenants, a new node is automatically spun up the moment the 4th tenant connects. The 5th tenant fills the existing node; the 6th tenant is seamlessly routed to the freshly provisioned node.

Storage Efficiency at Scale: Utilizing larger, multi-GPU nodes during high demand maximizes tenant density per machine. This reduces the total number of nodes a read-only shared block volume must be attached to, ensuring that higher demand results in cheaper storage costs per tenant (more tenants share fewer volume attachments).

As traffic scales beyond A10 capacity, the orchestrator synthesizes a forced state-save and seamlessly migrates active users to high-density BM.GPU.RTXPRO.8 nodes:

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph Trap ["Early-Stage Capacity Vulnerability"]
        BigNode["BM.GPU.RTXPRO.8 Node<br>(High Capacity: 56 Tenants)"]:::steel
        EmptySlots["Low Startup Traffic<br>(Severe Underutilization)"]:::crimson
        BrokenEcon["Broken Unit Economics<br>(Subsidizing empty GPU slots)"]:::crimson
        
        BigNode --> EmptySlots --> BrokenEcon
    end

    subgraph Startup ["Phase 1: Right-Sized Startup Architecture"]
        SmallNode["Cost-Optimized A10 Node (VM.GPU.A10.1)<br>(Capacity: 4 Tenants • AA Titles)"]:::sage
        ViableEcon["Compliant Unit Economics<br>(~$0.56 - $0.60/hr compute per tenant)"]:::gold
        
        SmallNode --> ViableEcon
    end

    subgraph Scaling ["Phase 2: Dynamic Migration via Hot Swap"]
        TrafficSpike["Traffic / Concurrency Increases<br>(A10 Nodes reaching aggregate limits)"]:::steel
        HotSwap["Instant Hot Swap Strategy<br>(Seamlessly capture state & redirect clients)"]:::prominent
        DenseNode["Consolidate to High-Density Node<br>(Migrate to BM.GPU.RTXPRO.8)"]:::sage
        SustainedEcon["Sustained Unit Economics<br>(Maximized density as traffic peaks)"]:::gold
        
        TrafficSpike --> HotSwap --> DenseNode --> SustainedEcon
    end

    BrokenEcon -. "Strategic Pivot" .-> Startup
    ViableEcon --> TrafficSpike

    class Trap,Startup,Scaling ghost

This ensures we never subsidize empty GPU slots. Unit economics remain compliant at every traffic level.

2.6 Hot-Swap Orchestration & Disaster Recovery

Although the final OCI architecture uses on-demand A10 nodes (not Spot instances), the hot-swap methodology from the AWS iteration remains critical for two scenarios: viral traffic spikes requiring rapid node migration, and disaster recovery when a node crashes unexpectedly.

Hardware Alignment: Because we standardize on the A10 architecture across all compute tiers, moving a user from one node to another (or one region to another) is predictable and deterministic. The underlying hardware aligns perfectly, eliminating compatibility risks during migration.

Session State Transfer: When a hot-swap is triggered, we rapidly transfer:

  1. Steam ssfn session files to bypass Steam Guard re-authentication on the new node.
  2. OverlayFS upperdir contents (save games, shader caches, configuration files) to the new node's local block volume.
  3. Client redirect command via the orchestrator, seamlessly pointing the Moonlight client to the new node's IP.

The interruption window is kept minimal and the user experience remains seamless.

3. Capacity & Operational Resilience

Handling capacity limits gracefully is critical to maintaining a positive user experience, especially during unexpected demand spikes or node failures.

3.1 Failover Buffer & Instant Transfer

We maintain a strict 95% capacity headroom buffer across the node fleet. This reserves 5% of compute capacity exclusively for emergency failovers. When a node unexpectedly goes down, affected users are instantly transferred to the available failover headroom nodes without dropping the active session. The hot-swap process (Section 2.6) executes automatically.

3.2 Predictive Scaling

A peak hours algorithm determines expected demand spikes based on historical usage data, regional time zones, and cultural patterns (e.g., gaming peaks after work/school hours, weekends, game launch events). Nodes are proactively provisioned in advance of predicted spikes, ensuring capacity is available before users log in.

This same predictive engine drives the storage warm-up process (Section 2.4): volumes can be pre-warmed from Object Storage before peak hours, eliminating cold-start delays entirely for the first users of the day.

3.3 Geo Bursting

When regional capacity reaches 100% (all local and acceptable nodes are full), users are given a choice:

  1. Wait in the local queue for a spot to open up.
  2. Geo Burst: Connect immediately to a nearby server in a different region for instant play, with a clear warning that they may experience slightly higher latency.

This transforms a hard capacity wall into a soft degradation, preserving user engagement.

3.4 Stream Squeezing (Last Resort)

If the queue becomes unmanageable and all failover and geo-burst options are exhausted, we implement dynamic stream squeezing:

  • We downgrade the stream resolution of existing tenants (e.g., from 1080p to 720p) to free up compute and bandwidth headroom on the node.
  • Targeting: This downgrade is selectively applied to users whose client-side limitations (e.g., slow internet connection, high packet loss) mean they are least likely to notice the reduction in visual quality.
  • The freed resources are used to "squeeze" a new tenant onto the existing node, maintaining service availability at the cost of marginal quality reduction for already-constrained users.

4. Multi-Tenant Isolation & Game Compatibility

Running multiple game instances on a single GPU requires strict resource isolation to prevent noisy-neighbor interference. Without hard limits, a single tenant can destabilize every other session on the node.

4.1 Tenant Capacity Heuristics

Determining the true tenant capacity of a node requires a non-obvious testing methodology. Naive benchmarking yields false results:

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph Naive ["The Naive Testing Trap (Unconstrained)"]
        Unconstrained["Unconstrained Execution<br>(Running game freely on massive multi-tenant node)"]:::steel
        GreedyCache["Greedy Engine Caching<br>(Game dynamically claims all free RAM/VRAM)"]:::crimson
        FalseLimit["False Capacity Ceiling<br>(Telemetry falsely suggests node maxes out at 2-3 tenants)"]:::crimson
        
        Unconstrained --> GreedyCache --> FalseLimit
    end

    subgraph Strategic ["Heuristic Slicing Methodology (Strict Isolation)"]
        Isolate["Strict Resource Isolation<br>(Enforce hard limits on compute, VRAM, and memory)"]:::sage
        Heuristic["Iterative Slice Reduction<br>(Gradually cut the resource slice while monitoring FPS/frame times)"]:::gold
        EngineBehavior["Forced Engine Optimization<br>(Prevents lazy caching; forces game engine to strategically manage limited resources)"]:::prominent
        
        Isolate --> Heuristic --> EngineBehavior
    end

    subgraph Outcome ["Optimized Unit Economics"]
        MaxDensity["Maximized Node Density<br>(Unlocks true capacity, e.g., 56 tenants per node)"]:::sage
    end

    FalseLimit -. "Necessitates alternative approach" .-> Isolate
    EngineBehavior --> MaxDensity

    class Naive,Strategic,Outcome ghost

When a game runs unconstrained on a powerful multi-GPU node, game engines greedily claim all available RAM and VRAM for caching (pre-loading textures, shader compilation, asset streaming). Benchmarking under these conditions falsely suggests the node can only support 2-3 tenants.

The correct approach is heuristic slicing: enforce hard resource limits per tenant first, then iteratively reduce the resource slice while monitoring FPS and frame times. Game engines are designed to adapt to constrained environments. When told they only have 5GB of VRAM, they strategically manage resources rather than lazily caching. This unlocks the true capacity ceiling.

4.2 VRAM Hard Caps & System-Wide FSR

Two critical environment variables enforce tenant isolation and optimize GPU utilization:

  1. VRAM Hard Caps: The environment variable WINE_VIRTUAL_VIDEOMEMORY=7168 (for a 7GB cap) is set in each tenant's launch script. This tricks the game engine into thinking it only has access to a constrained VRAM allocation, preventing Tenant 1 from spiking graphics settings and causing Tenant 2's game to crash with an Out-of-Memory (OOM) error.

  2. System-Wide FSR Upscaling: Since DLSS requires dedicated Tensor Cores (unavailable on V100 architecture), we substitute AMD's FidelityFX Super Resolution (FSR) via Proton's built-in system-wide upscaler. By adding WINE_FULLSCREEN_FSR=1 to game launch arguments, the game renders at a lower internal resolution (e.g., 720p) and cleanly upscales to 1080p before Sunshine encodes the stream. This dramatically reduces the GPU compute load per tenant, enabling higher density on shared hardware.

On modern A10 and RTXPRO architectures, DLSS is available natively, further improving visual quality at reduced compute cost.

4.3 Game Compatibility Tiers

Not all games are compatible with the Linux + Proton stack. We categorize supported titles into three tiers based on VRAM consumption, anti-cheat compatibility, and achievable tenant density:

Tier Density Representative Titles Notes
Tier 1: Esports 3+ Tenants (~5GB VRAM each) GTA V, Overwatch 2, Apex Legends, CS2, Rocket League, Dota 2 Ran under Proton/DXVK with no compatibility failures observed in testing. CPU-bound titles use OCI's high-frequency compute cores.
Tier 2: AAA 2 Tenants (~7.5GB VRAM each) Elden Ring, Cyberpunk 2077, Baldur's Gate 3, Red Dead Redemption 2, Helldivers 2 Ray Tracing off, FSR Quality mode enabled. Vulkan executables preferred over DX12 translation.
Tier 3: Blocked N/A Valorant, Fortnite, Call of Duty: Warzone, PUBG Kernel-level anti-cheat (Vanguard, Ricochet, BattlEye) explicitly blocks Linux, Proton, or VM execution.

Tier 3 games are hard-blocked at the platform level with clear user-facing warnings. This is a technical wall imposed by the anti-cheat vendors, not a limitation of the architecture.

4.4 Security & Anti-Abuse

Multi-tenant GPU infrastructure is a high-value target for abuse. We enforce the following security controls:

  • Token Security: Steam authentication tokens and ssfn session files are strictly encrypted at rest and held only in in-memory buffers during execution. Tokens are never written to persistent storage.
  • Tenant Isolation: Strict isolation boundaries via Linux containers, namespaces, and cgroups ensure one tenant's environment cannot access or impact another's on shared nodes.
  • Egress Lockdown: Network egress from tenant containers is locked down to only allow streaming traffic (Moonlight/Sunshine protocol) and essential Steam API calls. All other outbound connections are blocked.
  • Active Monitoring: Background worker processes continuously monitor CPU/GPU utilization heuristics and network patterns to immediately detect and terminate abuse, such as cryptocurrency mining or unauthorized network scanning.

5. Client Architecture & User Experience

5.1 Client Application Stack

The client application must provide a seamless wrapper around the Moonlight stream, handling authentication, session management, and UI interventions that the stock Moonlight client cannot support.

  • Desktop Application: A Tauri application (Rust backend, web frontend) or a custom fork of the Moonlight client handles stream wrapping and UI interventions. It monitors the Moonlight stream, takes over the screen for foreground processes (e.g., displaying UI during a hot-swap migration or showing the remaining session timer), and reliably blocks access to the underlying OS desktop, locking the user into the game/service environment.
  • Web Authentication: A React-based web application handles initial onboarding, the user dashboard, game library management, and the Steam OAuth authentication flow.
  • TV & Mobile Apps: Native development is mandatory for platforms like Android TV, Apple TV, and mobile devices. Browsers are fundamentally unsuited for competitive cloud gaming: input processing through a browser requires multiple event loop hops before being registered by the stream, introducing unacceptable input latency. Dedicated native applications are required to ensure ultra-low latency and the best possible user experience.

5.2 Queue User Experience

When all capacity is exhausted and users must wait, the queue experience must be engaging rather than frustrating:

  • Time-Based Estimation: Display an estimated wait time (e.g., "Expected wait: 3 mins") rather than a static queue number (e.g., "You are 453rd in line"). Time-based estimates are psychologically easier to tolerate and provide actionable information.
  • Interactive Loading Screens: Playable mini-games integrated directly into the loading screen, along with relevant content such as game patch notes, tips, special promotional codes, and highlights from popular streamers.

6. The Business ROI

6.1 Unit Economics at Scale

We transitioned a structurally fatal model into a highly profitable operation. The final architecture on the BM.GPU.RTXPRO.8 bare-metal node achieves the following unit economics:

graph TD
%% ── Dark Elegant Theme ─────────────────────────────────
classDef gold      fill:#1f1c15,stroke:#c8a96e,stroke-width:1.5px,color:#e8d5a8
classDef sage      fill:#131a14,stroke:#7a9e7e,stroke-width:1px,color:#a8c8ac
classDef steel     fill:#131620,stroke:#8896a8,stroke-width:1px,color:#b0bece
classDef crimson   fill:#1a1212,stroke:#a87878,stroke-width:1px,color:#d4a0a0
classDef ghost     fill:#111110,stroke:#2a2926,stroke-width:1px,color:#6a6860,stroke-dasharray:4 3
classDef prominent fill:#c8a96e,stroke:#c8a96e,color:#1a1508,font-weight:600

    subgraph Compute ["Compute Tier: High-Density Uninterruptible (BM.GPU.RTXPRO.8)"]
        Node["Bare Metal Node (On-Demand)<br>(8x RTX GPUs • 96GB VRAM per GPU)"]:::steel
        Density["High Density Allocation<br>(~56 Concurrent AAA Tenants per Node)"]:::sage
        ComputeCost["Compute Unit Cost<br>(~$0.60 - $0.70/hr per Tenant)"]:::gold
        
        Node --> Density
        Density --> ComputeCost
    end

    subgraph Storage ["Storage Tier: Multi-Attach OverlayFS Unit Economics"]
        SharedDrive["Read-Only Master Volume<br>($350/mo • Shared across 8 Nodes / 448 Tenants)"]:::steel
        SharedCost["Master Storage Unit Cost<br>(~$0.78/mo per Tenant)"]:::sage
        
        LocalDrive["Local Writable State Volume (Upperdir)<br>(1120GB for 56 Tenants • $47.60/mo per Node)"]:::steel
        LocalCost["State Storage Unit Cost<br>(~20GB per Tenant = ~$0.85/mo per Tenant)"]:::sage
        
        SharedDrive --> SharedCost
        LocalDrive --> LocalCost
    end

    subgraph Value ["End-User Experience & Final Architecture Viability"]
        UX["Premium Uninterrupted Gameplay<br>(AAA Titles • Ray Tracing • DLSS • Med/High Settings)"]:::prominent
        FinalCost["Final Operational Unit Economics per Tenant<br>Compute: ~$0.65/hr<br>Storage: ~$1.63/mo"]:::prominent
    end

    ComputeCost --> FinalCost
    SharedCost --> FinalCost
    LocalCost --> FinalCost
    
    Node -. "Ensures no spot interruptions" .-> UX
    UX --> FinalCost

    class Compute,Storage,Value ghost
  • Compute: ~$0.65/hr per tenant (on-demand, uninterruptible, no Spot risk).
  • Master Storage: ~$0.78/mo per tenant (shared 1.5TB read-only volume amortized across 448 tenants).
  • State Storage: ~$0.85/mo per tenant (~20GB OverlayFS upperdir).
  • Total Storage: ~$1.63/mo per tenant.

6.2 8-GPU Scaling Considerations

The BM.GPU.RTXPRO.8 represents the peak density target: 8x NVIDIA RTX PRO 6000 Blackwell GPUs with 768 GB of total VRAM and 32 dedicated NVENC encoding engines. However, scaling is not perfectly linear. While GPU resources multiply by 8, CPU resources (144 cores / 288 threads) remain constant, introducing a CPU starvation bottleneck:

Game Tier Concurrent Capacity Primary Bottleneck
AAA Heavy (Cyberpunk 2077, Black Myth: Wukong) 48-56 games GPU Compute (CPU at ~85%)
AA Moderate (Helldivers 2, Forza Horizon 5) 70-80 games CPU Compute (capped from theoretical 96-120)
Esports Light (Dota 2, Rocket League) 90-110 games System CPU & OS Orchestration (capped from theoretical 200+)

Technical Recommendations for 8-GPU Nodes:

  • Containers over vGPU: Setting up KVM virtual machines with sliced vGPU profiles for 80+ users introduces massive hypervisor memory overhead. Containerized solutions (Docker/Podman with GPU passthrough) share the host Linux kernel directly, drastically reducing CPU context-switching overhead.
  • NUMA Node Pinning: The dual Intel Xeon 6 setup splits the system into distinct NUMA (Non-Uniform Memory Access) zones. Specific GPUs must be pinned to the CPU socket they are physically wired to via PCIe. If a container running on GPU 7 (Socket 2) fetches memory managed by Socket 1, RAM latency spikes, ruining the stream.
  • NVENC Allocation: With 32 total NVENC chips, configuring Sunshine to use AV1 or HEVC encoding yields high-quality streams with near-zero encoding latency, even with 100 concurrent users.

By weaponizing the cloud against itself, we eliminated the CapEx requirement entirely. We optimized per-tenant compute economics to $0.56/hr at startup scale and $0.65/hr at 56-tenant bare-metal density. We consolidated master storage unit costs to $0.78/mo per tenant.

The architecture holds positive unit economics during low-traffic periods via the idle cost management lifecycle, and retains the option to scale deterministically via the compute tiering strategy — reaching per-tenant costs comparable to operators running their own hardware fleets, without the CapEx.

If your enterprise requires aggressive, high-agency technical architecture, or if unit economics are blocking your scale, we architect systems that mitigate systemic risk and punch drastically above their weight class. Memon Systems provides Fractional CTO advisory and infrastructure assurance for organizations demanding operational supremacy.

The Impact

We transitioned the compute topology to Oracle Cloud (OCI), decoupled game state at the kernel storage layer via OverlayFS, and implemented a multi-tier compute scaling strategy from cost-optimized A10 nodes to high-density 8-GPU bare-metal clusters. We eliminated the data egress bottleneck, secured sustainable unit economics from $0.56/hr per tenant at startup scale to $0.65/hr at 56-tenant density, and achieved the operational leverage of a multi-billion dollar hardware monopoly without upfront CapEx.

Run this measurement against your own system.

Deployment Audit: £500, fixed scope. Credited in full against the next stage.

What this costs
Back to Case Studies