Skip to content

Cloud Hierarchy Comparison (AWS, GCP, Azure, Nebius) vs GPUaaS

Purpose

Provide a single comparison artifact to justify and defend GPUaaS tenancy and ownership decisions.

Scope

This document compares: - Ownership boundary - Resource hierarchy shape - Identity/access model - Billing anchor - Context selection model - Service-account model

It is intended to support architecture reviews and stakeholder alignment.

Executive Summary

GPUaaS is aligned with the dominant cloud pattern: - Ownership root at tenant/org/account level - Operational scope at project/account/subscription level - User identity as actor attribution, not owner-of-record - Access enforced via membership/group bindings on hierarchical scopes

Our chosen model (tenant -> project -> resource) is closest to Nebius and GCP semantics, while still compatible with AWS/Azure operational expectations.

Terminology Mapping

Concept AWS GCP Azure Nebius GPUaaS
Ownership root Organization / Management Account Organization Tenant (Microsoft Entra tenant) + Management Group root Tenant Tenant (organizations)
Operational scope Account Project Subscription / Resource Group Project Project
Resource container Service resources in account Service resources in project Resources in resource group/subscription Service resources in project Allocations/storage/scheduler resources in project
Membership/access binding IAM principals (users/roles), account/org scope bindings IAM principals bound at org/folder/project scope Entra principals with RBAC assignments at mg/sub/rg/resource scope Tenant/project groups with membership bindings tenant_memberships + project_memberships
Policy model IAM policy docs + SCP guardrails IAM allow policies + org policy constraints Azure RBAC role assignments + policy initiatives Group + role based access permits across tenant/project scopes Policy chain global -> tenant -> project (most-specific wins)
RBAC / ABAC posture Primarily RBAC with policy conditions (ABAC-like) RBAC with IAM Conditions / tags (ABAC-like) RBAC with conditional access/policy controls Primarily RBAC via groups/roles RBAC in MVP; OPA-ready decision interface for ABAC extension

Side-by-Side Comparison

Dimension AWS GCP Azure Nebius GPUaaS (target model)
Default signup bootstrap Account created; can later join/create org Project created; org depends on domain/org setup Tenant + subscription context Tenant and project auto-created Personal tenant + default project auto-created
Hierarchy depth Org -> OU -> Account -> Resource Org -> Folder -> Project -> Resource Management Group -> Subscription -> Resource Group -> Resource Tenant -> Project -> Resource Tenant -> Project -> Resource
Policy inheritance SCP/IAM policies via org/ou/account IAM inheritance down org/folder/project RBAC scope inheritance down mg/sub/resource group Group-based access at tenant/project scopes Global -> tenant -> project policy chain
Billing ownership anchor Account / consolidated payer patterns Billing account + org/project mapping Subscription/billing account Tenant quotas + billing Tenant (organizations.stripe_customer_id)
Resource owner portability when user leaves Yes (account/org owns resources) Yes (project/org owns resources) Yes (subscription/tenant owns resources) Yes (tenant/project owns resources) Yes (tenant/project owns resources)
User is owner-of-record? No (except anti-pattern setups) No No No No (requested_by_user_id attribution only)
Service account scope Account-scoped IAM roles Project-scoped service accounts Tenant app registrations + scoped RBAC Project-scoped service accounts Project-scoped service accounts
Multi-tenant user model Supported Supported Supported Supported (can be added to multiple tenants) Deferred; MVP constrained by UNIQUE(user_id) in tenant membership
Authorization style at runtime Role/policy evaluation with explicit deny semantics Policy inheritance + conditional evaluation Scope-based role evaluation + policy controls Group/role permission evaluation Membership + scoped policy evaluation (RBAC-first, ABAC-ready)

Group Lifecycle (Operational View)

GPUaaS separates structure from lifecycle. Group-like access control exists through membership tables now, and richer group administration is deferred.

Lifecycle phases: 1. Scope creation - Tenant and default project are created at signup. - Initial owner memberships are created for the signing user. 2. Membership grant - User is granted tenant/project role (owner/admin/member/viewer variants by scope). - Every grant/revoke is audit logged with actor and correlation id. 3. Access evaluation - Runtime checks resolve membership + scope + policy chain (global -> tenant -> project). - User identity is attribution, not ownership. 4. Membership change - Role update or removal changes effective permissions without resource ownership rewrite. 5. Offboarding - User can be removed from memberships; resources remain tenant/project-owned. 6. Expansion (post-MVP) - Add first-class group entities and group-management UX. - Relax single-tenant constraint (UNIQUE(user_id) on tenant membership) for true multi-tenant users.

Why this matters: - Keeps MVP implementation simple. - Preserves a clean extension path to enterprise IAM without authz query rewrites.

Hierarchy vs Resource Identifier

These are related but distinct concerns:

  1. Hierarchy model
  2. Defines ownership and authorization boundaries (tenant -> project -> resource).

  3. Drives access checks, policy resolution, and billing ownership.

  4. Resource identifier model

  5. Defines a canonical name used across API responses, events, logs, and runbooks.
  6. Does not replace hierarchy; it encodes hierarchy context for portability and observability.

GPUaaS alignment rule: - Every tenant-owned runtime resource identifier must include tenant and project context: - core42:aicloud:{region}:{tenant_id}:{project_id}:{resource_type}:{resource_id} - Authorization uses structured scope checks; resource_name is the canonical cross-system reference.

Why GPUaaS Model Is Defensible

  1. Aligns to industry baseline: all compared providers separate actor identity from ownership boundary.
  2. Prevents orphaned resources: allocation ownership survives user churn because ownership is tenant/project rooted.
  3. Supports enterprise expansion without query rewrites: membership tables are present now; MVP single-tenant behavior is enforced by constraint, not hardcoded query shape.
  4. Keeps MVP simple while preserving extensibility: minimal role set now, explicit path to richer IAM later.
  5. Keeps billing coherent: tenant-level billing avoids per-user financial fragmentation when team accounts are introduced.
  6. Matches our canonical resource identifier spec (core42:aicloud:{region}:{tenant}:{project}:...), so policy and observability context are consistent.

Explicit Design Choices in GPUaaS

  1. Keep organizations table name for compatibility, but use tenant as architecture domain term.
  2. Enforce non-null tenant/project ownership on project-owned runtime resources.
  3. Treat requested_by_user_id / initiated_by_user_id as attribution only.
  4. Require request-scoped project context for project-owned operations (no implicit fallback).
  5. Use two-tier roles:
  6. Platform role (users.role) for platform superadmin paths
  7. Tenant/project membership roles for tenant-scoped authorization

Known Differences vs Hyperscalers (Intentional)

  1. No folder/OU/management-group layer in MVP.
  2. No full IAM group-management UX in MVP.
  3. No full multi-tenant context switch UX in MVP.

These are intentional MVP scope boundaries and deferred extensions. They can be added in later phases without changing the core ownership model (tenant -> project -> resource).

Design Principles (Short Form)

  • Ownership root is separate from user identity.
  • Tenant and project boundaries are first-class in authorization and billing.
  • Membership-query shape is future-ready for multi-tenant expansion.
  • Billing and access control remain tenant-rooted to avoid user-owned resource drift.

References

External: - AWS Organizations concepts: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html - Google Cloud resource hierarchy: https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy - Azure management groups and hierarchy: https://learn.microsoft.com/en-us/azure/governance/management-groups/overview - Nebius IAM overview: https://docs.nebius.com/iam/overview

Internal: - doc/architecture/Tenant_Project_Ownership_Baseline.md - doc/architecture/adrs/ADR-008-tenant-project-ownership-baseline.md - doc/architecture/ERD.md - doc/architecture/Resource_Identifier_Spec.md - doc/architecture/Service_Account_Model.md