Sankofa/docs/phoenix/CLOUD_PROVIDER_MAPPING.md

Phoenix Cloud Provider Mapping & Competitive Analysis

Mapping Phoenix Operating Model to Azure, AWS, and Competitive Positioning

This document maps the Phoenix operating model to Azure and AWS equivalents, provides competitive analysis, feature comparison, and migration considerations for sovereign governments.

---

Executive Summary

Phoenix is purpose-built for international and multi-national sovereign governments and competes directly with Azure, AWS, and other cloud providers. This document shows how Phoenix's operating model maps to Azure/AWS concepts while highlighting competitive advantages, especially for sovereign deployments.

Key Competitive Advantages:

• Superior Multi-Tenancy: Finer-grained control than Azure
• Superior Billing: Per-second granularity vs Azure's hourly
• Sovereign Identity: Keycloak-based, no Azure dependencies
• Multi-Region Native: Built for international/multi-national deployments
• Decentralized Architecture: Supports distributed sovereignty
• Landing Zone Patterns: Sovereign cloud deployments per region

---

I. Mapping to Azure

Entity Mapping

Phoenix Entity	Azure Equivalent	Key Differences
Client (Billing Profile)	Azure Billing Account / Customer	Phoenix separates billing from identity
Tenant	Azure AD Tenant	Phoenix Tenant = identity + domain + security boundary
Subscription	Azure Subscription	Phoenix Subscription = service bundle + quotas + policies
Environment	Azure Resource Group	Phoenix Environment = lifecycle stage + isolation
Landing Zone	Azure Landing Zone	Phoenix Landing Zone = sovereign cloud per region

Detailed Mapping

Client (Billing Profile) → Azure Billing Account

Azure Model:

• Billing Account contains billing profiles
• Billing profiles contain subscriptions
• Direct billing-to-subscription relationship

Phoenix Model:

• Client (Billing Profile) owns multiple Tenants
• Tenants contain Subscriptions
• Billing aggregates at Client level, not directly tied to Subscriptions

Advantage: Phoenix separates commercial governance from technical tenancy, enabling more flexible billing structures for multi-national governments.

Tenant → Azure AD Tenant

Azure Model:

• Azure AD Tenant = identity boundary
• One tenant can have multiple subscriptions
• Tenant is primarily for identity/access management

Phoenix Model:

• Tenant = identity + domain + security boundary
• Tenant is the security blast-radius
• One tenant can have multiple subscriptions
• Tenant includes data residency and compliance profiles

Advantages:

• Phoenix Tenant includes domain ownership and sovereignty flags
• Phoenix Tenant is explicitly the security boundary
• Phoenix supports multi-region tenants with regional data residency

Subscription → Azure Subscription

Azure Model:

• Azure Subscription = billing + resource container
• Subscriptions belong to Azure AD Tenant
• Resource Groups organize resources within subscriptions

Phoenix Model:

• Subscription = service bundle + quotas + policies
• Subscriptions belong to Tenant
• Environments organize resources within subscriptions
• Subscriptions are mapped to Client for billing

Advantages:

• Phoenix separates billing (Client) from resource provisioning (Subscription)
• Phoenix Subscriptions include policy packs (security, networking, data access)
• Phoenix supports subscription types (Shared Platform, Product, Sandbox)

Environment → Azure Resource Group

Azure Model:

• Resource Group = logical container for resources
• Resources can be moved between resource groups
• Resource groups don't enforce lifecycle stages

Phoenix Model:

• Environment = lifecycle stage (DEV, INT, UAT, STAGING, PROD, etc.)
• Environments enforce deployment policies
• Environments have network and data isolation
• Promotion flows are policy-driven between environments

Advantages:

• Phoenix Environments explicitly represent lifecycle stages
• Phoenix Environments enforce promotion policies
• Phoenix supports specialized environments (REGULATED, SOVEREIGN, AIR-GAPPED)

Landing Zone → Azure Landing Zone

Azure Model:

• Azure Landing Zone = reference architecture
• Typically single-region or multi-region within same cloud
• Centralized governance

Phoenix Model:

• Landing Zone = sovereign cloud deployment per region/nation
• Decentralized governance with coordination
• Regional autonomy with cross-region coordination

Advantages:

• Phoenix Landing Zones support complete regional sovereignty
• Phoenix supports air-gapped landing zones
• Phoenix Landing Zones enable decentralized governance

Architecture Comparison

Azure Architecture:

Azure AD Tenant
  └── Azure Subscription (billing + resources)
      └── Resource Group (logical container)
          └── Resources (VMs, storage, etc.)

Phoenix Architecture:

Client (Billing Profile)
  └── Tenant (identity + domain + security)
      └── Subscription (service bundle + quotas)
          └── Environment (lifecycle stage + isolation)
              └── Resources (VMs, storage, etc.)

Key Difference: Phoenix separates commercial (Client), identity (Tenant), provisioning (Subscription), and lifecycle (Environment) into distinct planes.

---

II. Mapping to AWS

Entity Mapping

Phoenix Entity	AWS Equivalent	Key Differences
Client (Billing Profile)	AWS Customer / Billing Account	Phoenix separates billing from organization
Tenant	AWS Organization (partial)	Phoenix Tenant = identity + domain + security
Subscription	AWS Account	Phoenix Subscription = service bundle + quotas
Environment	AWS Resource Group / Tag	Phoenix Environment = lifecycle stage + isolation
Landing Zone	AWS Landing Zone	Phoenix Landing Zone = sovereign cloud per region

Detailed Mapping

Client (Billing Profile) → AWS Customer / Billing Account

AWS Model:

• AWS Customer = billing entity
• Billing Account contains AWS Accounts
• Direct billing-to-account relationship

Phoenix Model:

• Client (Billing Profile) owns multiple Tenants
• Tenants contain Subscriptions
• Billing aggregates at Client level

Advantage: Phoenix separates commercial governance from technical tenancy.

Tenant → AWS Organization

AWS Model:

• AWS Organization = account management + billing
• Organizations contain AWS Accounts
• Organizations can have multiple accounts

Phoenix Model:

• Tenant = identity + domain + security boundary
• Tenants contain Subscriptions
• Tenant is the security blast-radius

Advantages:

• Phoenix Tenant includes identity provider and domain ownership
• Phoenix Tenant explicitly defines security boundaries
• Phoenix supports multi-region tenants with regional data residency

Subscription → AWS Account

AWS Model:

• AWS Account = billing + resource container
• Accounts belong to AWS Organization
• Resources are organized within accounts

Phoenix Model:

• Subscription = service bundle + quotas + policies
• Subscriptions belong to Tenant
• Environments organize resources within subscriptions

Advantages:

• Phoenix separates billing (Client) from resource provisioning (Subscription)
• Phoenix Subscriptions include policy packs
• Phoenix supports subscription types

Environment → AWS Resource Group / Tag

AWS Model:

• Resource Groups = logical grouping of resources
• Tags = metadata for organization
• No explicit lifecycle stage enforcement

Phoenix Model:

• Environment = lifecycle stage with enforcement
• Environments enforce deployment policies
• Promotion flows are policy-driven

Advantages:

• Phoenix Environments explicitly represent lifecycle stages
• Phoenix Environments enforce promotion policies
• Phoenix supports specialized environments

Landing Zone → AWS Landing Zone

AWS Model:

• AWS Landing Zone = reference architecture
• Typically multi-account within same organization
• Centralized governance

Phoenix Model:

• Landing Zone = sovereign cloud deployment per region/nation
• Decentralized governance with coordination
• Regional autonomy

Advantages:

• Phoenix Landing Zones support complete regional sovereignty
• Phoenix supports air-gapped landing zones
• Phoenix Landing Zones enable decentralized governance

Architecture Comparison

AWS Architecture:

AWS Organization
  └── AWS Account (billing + resources)
      └── Resource Group / Tag (logical grouping)
          └── Resources (EC2, S3, etc.)

Phoenix Architecture:

Client (Billing Profile)
  └── Tenant (identity + domain + security)
      └── Subscription (service bundle + quotas)
          └── Environment (lifecycle stage + isolation)
              └── Resources (VMs, storage, etc.)

Key Difference: Phoenix separates commercial (Client), identity (Tenant), provisioning (Subscription), and lifecycle (Environment) into distinct planes.

---

III. Hybrid Deployments

Sovereign + Public Cloud Patterns

Phoenix supports hybrid deployments combining sovereign Phoenix clouds with public cloud providers.

Pattern 1: Sovereign Primary, Public Cloud Secondary

Use Case: Sovereign government with primary workloads in Phoenix, using public cloud for non-sensitive workloads.

Architecture:

• Primary: Phoenix sovereign cloud (data residency, compliance)
• Secondary: Azure/AWS for public-facing, non-sensitive workloads
• Integration: Federated identity, coordinated governance

Pattern 2: Multi-Cloud with Phoenix Coordination

Use Case: Multi-national government using multiple clouds with Phoenix as coordination layer.

Architecture:

• Phoenix: Control plane and coordination
• Azure/AWS: Regional deployments
• Integration: Phoenix manages identity, billing, and governance across clouds

Pattern 3: Phoenix Landing Zones with Public Cloud Services

Use Case: Sovereign landing zones using public cloud services where appropriate.

Architecture:

• Phoenix Landing Zones: Core infrastructure and data
• Public Cloud Services: Specific services (AI, analytics) where data residency allows
• Integration: Policy-driven service selection based on data residency

Integration Strategies

1. Federated Identity: Phoenix Keycloak federates with Azure AD / AWS IAM
2. Coordinated Billing: Phoenix aggregates costs across clouds
3. Unified Governance: Phoenix policies apply across hybrid deployments
4. Data Residency Enforcement: Phoenix ensures data stays in appropriate clouds

---

IV. Multi-Region Landing Zones

Comparison: Azure vs AWS vs Phoenix

Feature	Azure	AWS	Phoenix
Landing Zone Model	Reference architecture	Reference architecture	Sovereign cloud per region
Regional Autonomy	Limited	Limited	Complete
Data Residency	Regional options	Regional options	Hard enforcement per region
Air-Gapped Support	Limited	Limited	Native support
Decentralized Governance	No	No	Yes
Cross-Region Coordination	Centralized	Centralized	Federated
Sovereign Cloud	Azure Government	AWS GovCloud	Native sovereign clouds

Phoenix Advantages

1. Sovereign Cloud Per Region: Each region/nation can have complete sovereign cloud
2. Air-Gapped Support: Native support for air-gapped deployments
3. Decentralized Governance: Regional autonomy with coordination
4. Hard Data Residency: Enforced data residency per region
5. Multi-National Support: Built for international/multi-national governments

---

V. Decentralized Architecture

How Phoenix Differs from Centralized Azure/AWS

Azure/AWS Model:

• Centralized control plane
• Single point of governance
• Regional deployments but centralized management

Phoenix Model:

• Distributed control planes per region
• Federated governance
• Regional autonomy with coordination
• No single point of control

Advantages for Sovereign Governments

1. Sovereignty: Complete regional control
2. Resilience: No single point of failure
3. Compliance: Regional compliance per region
4. Data Residency: Hard enforcement per region
5. Governance: Regional autonomy with coordination

---

VI. Feature Comparison Matrix

Multi-Tenancy Capabilities

Feature	Azure	AWS	Phoenix
Custom Domains per Tenant	Limited	Limited	Full support
Cross-Tenant Resource Sharing	Limited	Limited	Full support
Tenant Isolation	Logical	Logical	Logical + optional physical
RBAC Granularity	RBAC only	IAM policies	RBAC + JSON permissions
Tenant Tiers	Limited	Limited	FREE, STANDARD, ENTERPRISE, SOVEREIGN

Phoenix Advantage: Superior multi-tenancy with finer-grained control and flexibility.

Billing Granularity

Feature	Azure	AWS	Phoenix
Billing Granularity	Hourly	Per-second (some services)	Per-second (all services)
Real-Time Tracking	Limited	Limited	Full real-time
Cost Forecasting	Basic	Basic	ML-based
Optimization Recommendations	Manual	Manual	Automated
Blockchain Billing	No	No	Yes (optional)
Multi-Currency	Limited	Limited	Full support
Custom Pricing Models	Limited	Limited	Per-tenant models

Phoenix Advantage: Superior billing with per-second granularity, ML-based forecasting, and blockchain support.

Identity Management

Feature	Azure	AWS	Phoenix
Identity Provider	Azure AD only	AWS IAM	Keycloak (sovereign)
Self-Hosted	No	No	Yes
Multi-Realm Support	Limited	Limited	Full support (one per tenant)
Custom Authentication Flows	Limited	Limited	Full support
Federated Identity	Yes	Yes	Yes (Keycloak-based)
Blockchain Identity	No	No	Yes (optional)
Sovereign Identity	No	No	Yes (no Azure dependencies)

Phoenix Advantage: Sovereign identity management with Keycloak, no Azure dependencies, full self-hosting.

Multi-Region Support

Feature	Azure	AWS	Phoenix
Regional Autonomy	Limited	Limited	Complete
Sovereign Cloud Per Region	Azure Government	AWS GovCloud	Native sovereign clouds
Air-Gapped Support	Limited	Limited	Native support
Decentralized Governance	No	No	Yes
Cross-Region Coordination	Centralized	Centralized	Federated
Data Residency Enforcement	Soft	Soft	Hard (per region)
Multi-National Support	Limited	Limited	Built-in

Phoenix Advantage: Native multi-region support with sovereign clouds, air-gapped deployments, and decentralized governance.

Compliance and Security

Feature	Azure	AWS	Phoenix
Compliance Standards	ISO, SOC, HIPAA, FedRAMP	ISO, SOC, HIPAA, FedRAMP	ISO, SOC, HIPAA, FedRAMP, Custom
Audit Trails	Yes	Yes	Yes (blockchain-optional)
Data Residency	Regional options	Regional options	Hard enforcement per region
Sovereign Cloud	Azure Government	AWS GovCloud	Native sovereign clouds
Air-Gapped	Limited	Limited	Native support
Regulated Environments	Limited	Limited	REGULATED, SOVEREIGN, AIR-GAPPED types

Phoenix Advantage: Native support for sovereign, regulated, and air-gapped environments with hard data residency enforcement.

DevOps and Content Management

Feature	Azure	AWS	Phoenix
Enterprise Content Hierarchy	No	No	Yes (Enterprise → Portfolio → Product → Application → Component)
Git Integration	Yes	Yes	Yes (with governance)
CI/CD Integration	Yes	Yes	Yes (with policy gates)
Promotion Flows	Manual/scripted	Manual/scripted	Policy-driven
Content Governance	Limited	Limited	Full (approval workflows, compliance tagging)
GitOps	Yes	Yes	Yes (ArgoCD integration)

Phoenix Advantage: Enterprise content hierarchy with full governance, policy-driven promotion flows.

---

VII. Migration Considerations

Migration Complexity Assessment

From Azure to Phoenix

Low Complexity:

• Identity migration (Keycloak can import from Azure AD)
• Resource migration (standard VM/storage migration)
• Application migration (standard application deployment)

Medium Complexity:

• Billing model migration (Client/Tenant/Subscription structure)
• Governance migration (policy packs, approval workflows)
• Multi-region migration (landing zone setup)

High Complexity:

• Air-gapped migration (complete isolation setup)
• Sovereign cloud migration (regional sovereignty setup)
• Decentralized governance migration (federated governance setup)

From AWS to Phoenix

Low Complexity:

• Identity migration (Keycloak can import from AWS IAM)
• Resource migration (standard VM/storage migration)
• Application migration (standard application deployment)

Medium Complexity:

• Organization structure migration (Client/Tenant/Subscription)
• Governance migration (policy packs, approval workflows)
• Multi-region migration (landing zone setup)

High Complexity:

• Air-gapped migration (complete isolation setup)
• Sovereign cloud migration (regional sovereignty setup)
• Decentralized governance migration (federated governance setup)

Data Migration Strategies

Strategy 1: Lift and Shift

Approach: Migrate resources as-is to Phoenix.

Use Cases:

• Non-sensitive workloads
• Standard applications
• Quick migration requirements

Process:

1. Export resources from Azure/AWS
2. Import to Phoenix
3. Update networking and identity
4. Validate and cutover

Strategy 2: Refactor for Phoenix

Approach: Refactor applications to leverage Phoenix capabilities.

Use Cases:

• Applications requiring sovereign capabilities
• Multi-region deployments
• Air-gapped requirements

Process:

1. Analyze application architecture
2. Refactor for Phoenix operating model
3. Implement Phoenix-specific features (sovereign identity, landing zones)
4. Migrate and validate

Strategy 3: Hybrid Migration

Approach: Gradual migration with hybrid operations.

Use Cases:

• Large-scale migrations
• Mission-critical applications
• Phased migration requirements

Process:

1. Set up Phoenix alongside Azure/AWS
2. Migrate non-critical workloads first
3. Gradually migrate critical workloads
4. Complete migration and decommission Azure/AWS

Identity Migration Strategies

From Azure AD to Keycloak

Process:

1. Export users and groups from Azure AD
2. Import to Keycloak realm
3. Configure identity provider federation (if needed)
4. Update applications to use Keycloak
5. Migrate authentication flows

Tools:

• Keycloak user import
• Azure AD Graph API export
• Custom migration scripts

From AWS IAM to Keycloak

Process:

1. Export users and roles from AWS IAM
2. Import to Keycloak realm
3. Configure identity provider federation (if needed)
4. Update applications to use Keycloak
5. Migrate authentication flows

Tools:

• Keycloak user import
• AWS IAM API export
• Custom migration scripts

Application Migration Strategies

Containerized Applications

Process:

1. Export container images
2. Import to Phoenix container registry
3. Update deployment configurations
4. Deploy to Phoenix Kubernetes/container platform
5. Update networking and identity

Virtual Machine Applications

Process:

1. Export VM images
2. Convert to Phoenix VM format
3. Import to Phoenix
4. Update networking and identity
5. Deploy and validate

Serverless Applications

Process:

1. Analyze serverless functions
2. Port to Phoenix serverless platform (if available)
3. Update event sources and triggers
4. Deploy and validate

Cost Migration Analysis

Cost Comparison Framework

Factors to Consider:

• Compute costs (VM, container, serverless)
• Storage costs (object, block, archive)
• Network costs (egress, cross-region)
• Identity costs (Azure AD vs Keycloak)
• Compliance costs (sovereign vs public cloud)

Phoenix Cost Advantages

1. Per-Second Billing: More accurate than hourly
2. No Vendor Lock-In: Avoid Azure/AWS lock-in costs
3. Sovereign Cloud: Potentially lower costs for sovereign deployments
4. Custom Pricing: Per-tenant pricing models

Migration Cost Considerations

• Migration Tools: Cost of migration tools and services
• Downtime: Cost of downtime during migration
• Training: Cost of training teams on Phoenix
• Integration: Cost of integrating with existing systems

Timeline Estimates

Small-Scale Migration (< 100 resources)

Timeline: 1-3 months

• Planning: 2 weeks
• Migration: 4-8 weeks
• Validation: 2-4 weeks

Medium-Scale Migration (100-1000 resources)

Timeline: 3-6 months

• Planning: 1 month
• Migration: 2-4 months
• Validation: 1 month

Large-Scale Migration (> 1000 resources)

Timeline: 6-12 months

• Planning: 2 months
• Migration: 4-8 months
• Validation: 2 months

Sovereign/Air-Gapped Migration

Timeline: 6-18 months (additional complexity)

• Planning: 3 months
• Migration: 6-12 months
• Validation: 3 months

Step-by-Step Migration Guides

Migration from Azure

Phase 1: Planning

1. Assess current Azure deployment
2. Map Azure entities to Phoenix entities
3. Plan Client/Tenant/Subscription structure
4. Plan identity migration
5. Plan resource migration

Phase 2: Setup

1. Create Phoenix Client
2. Create Phoenix Tenants
3. Create Phoenix Subscriptions
4. Set up Keycloak realms
5. Configure landing zones

Phase 3: Migration

1. Migrate identity (Azure AD → Keycloak)
2. Migrate resources (Azure → Phoenix)
3. Update applications
4. Update networking
5. Validate functionality

Phase 4: Cutover

1. Final validation
2. Cutover plan
3. Execute cutover
4. Monitor and support
5. Decommission Azure resources

Migration from AWS

Phase 1: Planning

1. Assess current AWS deployment
2. Map AWS entities to Phoenix entities
3. Plan Client/Tenant/Subscription structure
4. Plan identity migration
5. Plan resource migration

Phase 2: Setup

1. Create Phoenix Client
2. Create Phoenix Tenants
3. Create Phoenix Subscriptions
4. Set up Keycloak realms
5. Configure landing zones

Phase 3: Migration

1. Migrate identity (AWS IAM → Keycloak)
2. Migrate resources (AWS → Phoenix)
3. Update applications
4. Update networking
5. Validate functionality

Phase 4: Cutover

1. Final validation
2. Cutover plan
3. Execute cutover
4. Monitor and support
5. Decommission AWS resources

---

VIII. Competitive Advantages Summary

For Sovereign Governments

1. Sovereign Identity: Keycloak-based, no Azure/AWS dependencies
2. Multi-Region Native: Built for international/multi-national deployments
3. Decentralized Architecture: Supports distributed sovereignty
4. Landing Zone Patterns: Sovereign cloud deployments per region
5. Air-Gapped Support: Native support for classified workloads
6. Hard Data Residency: Enforced data residency per region
7. Superior Multi-Tenancy: Finer-grained control than Azure/AWS
8. Superior Billing: Per-second granularity vs hourly

For Enterprise Deployments

1. Enterprise Content Hierarchy: Full governance from Enterprise to Component
2. Policy-Driven Promotion: Automated, auditable promotion flows
3. Superior RBAC: RBAC + JSON permissions
4. Custom Pricing: Per-tenant pricing models
5. Blockchain Integration: Optional blockchain for billing and identity

---

IX. Conclusion

Phoenix provides a superior operating model for sovereign governments compared to Azure and AWS, with:

• Separation of Concerns: Five orthogonal control planes
• Sovereign Capabilities: Native support for sovereign, regulated, and air-gapped deployments
• Multi-Region Native: Built for international/multi-national governments
• Decentralized Architecture: Supports distributed sovereignty
• Superior Features: Better multi-tenancy, billing, and identity management

Migration from Azure/AWS to Phoenix is feasible with proper planning and execution, and provides significant advantages for sovereign government deployments.

---

References

Phoenix Operating Model Documentation

• Operating Model - Core operating model documentation
• Architecture Diagrams - Visual diagrams of the operating model
• MVP Control Plane - Minimum viable product specification
• Multi-Region Landing Zones - Landing zone patterns and deployment
• Migration Guide - Migration from existing systems and cloud providers
• Product Specification - Client-facing product specification

---

Last Updated: 2025-01-09
Version: 1.0
Status: Complete Cloud Provider Mapping & Competitive Analysis