Perplexity AI Verified by Perplexity AI

Appendix X: OpenStack vs. Apache CloudStack

Technical comparison of IaaS control planes for sovereign hyperscale cloud

X.1 Purpose

This appendix clarifies the role of OpenStack and Apache CloudStack as candidate IaaS control planes for a sovereign, hyperscale cloud platform, and assesses to what extent the United States could constrain their use.

X.2 Licensing, Sovereignty and US Denial Risk

X.2.1 Open Source Licensing

Platform Governance Licence
OpenStack OpenInfra Foundation Apache License 2.0 (permissive, non-copyleft)[1][2]
Apache CloudStack Apache Software Foundation Apache License 2.0[3][4]

In both cases, source code is globally available; any jurisdiction can fork, mirror, build, and operate it without needing permission from the US government.

X.2.2 Practical US Levers

For a sovereignty analysis, the key question is not whether the US can "turn off" OpenStack/CloudStack as it can with AWS/Azure/GCP, but whether it can materially constrain their use.

What the US Cannot Practically Deny

  • Use of the open-source codebases: Both are Apache-licensed and widely mirrored; the US cannot revoke your rights under Apache 2.0 once granted[1][2][3][4]
  • Sovereign builds that use locally hosted mirrors and non-US foundations/entities for governance and distribution

What the US Could Potentially Influence

  • US-based commercial support vendors could be ordered to cease business with certain jurisdictions under sanctions
  • US-origin hardware, chips, or specialised components could be restricted through export controls
  • US-hosted Git forges (e.g., GitHub) could be pressured to geoblock—though easily mitigated by mirroring

Conclusion on US Denial Risk

If the platform is architected from the outset to avoid single points of dependency on US-jurisdiction services or vendors (mirrored repos, EU/UK-based support organisations, diversified hardware supply), then the United States has no realistic mechanism to deny use of OpenStack or Apache CloudStack in the same way it can deny access to proprietary hyperscale clouds. Any residual leverage is via generic hardware/export channels, not the software itself.[1][2][3][4]

X.3 Hyperscale Capability

X.3.1 Definitions

For this initiative, "hyperscale-capable IaaS control plane" means:

  • Able to manage ≥100,000 hypervisor hosts and millions of virtual machines/instances
  • Designed for multi-datacentre, multi-region operation with appropriate performance and fault tolerance

X.3.2 Apache CloudStack Hyperscale Work

100,000
Hypervisor Hosts[5]
Millions
VM Instances[6]
4.20+
Version with scaling work[7]

Recent work explicitly targets hyperscale. The Apache CloudStack 4.20 release and associated work from ShapeBlue and community contributors focused on:

  • Management server clustering and stateless scale-out
  • Database performance, indexing and query patterns
  • Agent communication, event handling, and distributed caching[5][6]
Published conclusion: Version 4.20 "establishes a solid foundation for operating at scales of 100,000 Hosts and millions of Instances", with further enhancements expected in subsequent releases.[5][6][8]

X.3.3 OpenStack Hyperscale Deployments

Exabyte
Scale Storage[9]
Tens of Millions
Cores in Production[10]
Telco/5G
Carrier-Grade Use[11]

OpenStack's hyperscale story is grounded in large, real-world deployments:

  • Open Telekom Cloud and other operators with hundreds of thousands of vCPUs, multiple petabytes of RAM, and exabyte-scale storage[9]
  • Tens of millions of cores in production across service providers, telcos, research clouds, and enterprises[10][11]
  • National and "sovereign" public clouds (e.g., Open Telekom Cloud as reference)[9]
  • Telecom/NFV and 5G cores where carrier-grade scalability is mandatory[11][12]
Implication: OpenStack is proven in production at hyperscale across multiple operators and geographies, even if its narrative emphasises "many large deployments" rather than a single 100k-host benchmark.[9][10][11]

X.4 Architectural and Ecosystem Differences

X.4.1 High-Level Comparison Table

Aspect OpenStack Apache CloudStack
Governance OpenInfra Foundation Apache Software Foundation
License Apache 2.0 across core projects[1][2] Apache 2.0[3][4]
Architecture Highly modular (Nova, Neutron, Cinder, etc.); many services with separate APIs[13] More integrated cloud management platform with fewer components to assemble[13][14][15]
Operational Complexity Higher: flexible but complex to deploy and operate; often needs dedicated large teams[13][15] Lower: "turnkey" orientation; simpler deployment and day-2 ops[13][15][16]
Ecosystem Very large: many distributions, vendors, telcos, national clouds[9][11][13] Smaller but focused: strong in service providers and VMware/KVM replacement[14][16][5]
Hyperscale Evidence Real-world production at national/telco scale (tens of millions of cores)[9][10][11] Explicit 100k-host / millions-of-instances scaling work (v4.20+)[5][6][8]
Typical Best Fit Large, highly customised clouds, telco/5G, research clouds, operators with significant in-house expertise[11][12][13] Mid-to-large IaaS clouds, governments/operators seeking simpler build-out with single integrated CMP[13][15][16]

X.4.2 Practical Implications

OpenStack

Strengths:

  • Very broad ecosystem and vendor choice, including European telcos and sovereign cloud providers[9][10][11]
  • Deep feature set in networking, storage, NFV, and integration with Kubernetes/AI stacks[11][12][13]

Trade-offs:

  • Higher learning curve and operational overhead; effectively running your own AWS-scale control plane

Apache CloudStack

Strengths:

  • Simplified deployment and lifecycle management; often described as "turnkey, easy to operate"[13][15][16]
  • Clear, published hyperscale engineering target and optimisation roadmap[5][6][8]

Trade-offs:

  • Smaller vendor ecosystem; fewer very large published production references than OpenStack (gap narrowing)

X.5 Fit for Multi-Nation Sovereign Cloud Platform

X.5.1 Sovereignty and US Denial

From a sovereignty perspective, both OpenStack and Apache CloudStack meet the core requirement:

  • Open-source, Apache-style licensing; no built-in technical mechanism for unilateral US service denial[1][2][3][4]
  • Any denial would have to occur through generic channels (sanctions on US support vendors, export controls on hardware)

Mitigation measures:

  • Use EU/UK-based integrators and support entities
  • Diversify hardware and component supply chains
  • Maintain complete local mirrors of all code, images, and dependencies
Therefore: There is no direct, code-level dependency that the US can revoke for either OpenStack or Apache CloudStack, unlike AWS/Azure/GCP.[1][2][3][4]

X.5.2 Technical Positioning for the Initiative

For a "global cloud-replacement" involving UK, EU, Canada, and Australia:

  • Both platforms are credible hyperscale control-plane substrates
    • OpenStack: proven at scale in production, especially with telcos and national clouds[9][10][11]
    • CloudStack: explicitly engineered and benchmarked to 100k hosts / millions of instances[5][6][8]

Recommended Strategic Pattern

  • Standardise the higher layers (Kubernetes, object storage API, database layer, IAM, logging/monitoring) so they are agnostic to the IaaS flavour beneath
  • Allow jurisdictions/operators to choose OpenStack or Apache CloudStack as the underlying IaaS, provided they meet defined capability and assurance criteria
  • This avoids a single architectural bet and reduces risk if one ecosystem stalls

X.5.3 If a Single "Primary Reference" Must Be Named

If political documents require naming a single primary reference IaaS:

  • Apache CloudStack can be presented as the primary reference because:
    • Clear, published hyperscale target (100k hosts / millions of instances) easy to communicate[5][6][8]
    • Operational simplicity reduces early execution risk for government platform teams[15][16][13]
  • OpenStack should still be explicitly recognised as a fully supported alternative substrate for operators (especially telcos and existing OpenStack national clouds) that already run it at scale[9][10][11]

X.6 Summary for Decision-Makers

  1. Both OpenStack and Apache CloudStack are open-source, Apache-licensed IaaS control planes. The US cannot directly "switch them off" if you self-host and avoid single-vendor US dependencies.[1][2][3][4]
  2. Both are hyperscale-capable when engineered appropriately:
    • Apache CloudStack 4.20+ has explicit engineering demonstrating scalability to 100k hosts and millions of instances[5][6][8]
    • OpenStack underpins large national and telecom clouds with hundreds of thousands to millions of cores[9][10][11]
  3. Choice between them is not about US denial risk, but about ecosystem and operational fit.
    • OpenStack: broader ecosystem, telco and national cloud track record; higher operational complexity
    • CloudStack: simpler operations and clear hyperscale benchmark story, but smaller ecosystem
  4. For the multi-nation initiative, the safest architectural posture is to support both as valid IaaS substrates under a common sovereign stack, while avoiding any US-jurisdiction support or hosting dependencies that could be used as a leverage point.

References

  1. [1] BTech.id, "All you need to know about OpenStack license." http://btech.id/en/news/all-you-need-to-know-about-openstack-license/
  2. [2] OpenStack Governance, "Licensing." https://governance.openstack.org/reference/licensing.html
  3. [3] Wikipedia, "Apache CloudStack." https://en.wikipedia.org/wiki/Apache_CloudStack
  4. [4] Wikipedia, "CloudStack." https://en.wikipedia.org/wiki/CloudStack
  5. [5] ShapeBlue, "Scaling Apache CloudStack to 100,000 Hosts and Millions of Instances." https://www.shapeblue.com/scaling-apache-cloudstack-to-100000-hosts-and-millions-of-instances/
  6. [6] CloudStack Collab, "CCC 2024 Scaling CloudStack - Abhishek Kumar." PDF
  7. [7] Rohit Yadav, "What's new in CloudStack - CCC24." PDF
  8. [8] ShapeBlue LinkedIn, "Scaling Apache CloudStack." LinkedIn
  9. [9] Open Telekom Cloud, "OpenStack: the standard for the sovereign public cloud." https://www.open-telekom-cloud.com/en/blog/benefits/openstack-the-standard-for-the-sovereign-public-cloud
  10. [10] TechSci Research, "OpenStack Services Market." https://www.techsciresearch.com/report/openstack-services-market/25252.html
  11. [11] VEXXHOST, "OpenStack, Kubernetes and AI: What 2025 taught us." https://vexxhost.com/blog/openstack-kubernetes-and-ai-what-2025-taught-us-about-the-future-of-cloud/
  12. [12] OpenMetal, "A Blueprint for a Private 5G Core on OpenStack." https://openmetal.io/resources/blog/a-blueprint-for-a-private-5g-core-on-openstack/
  13. [13] Simplyblock, "CloudStack vs OpenStack." https://www.simplyblock.io/blog/cloudstack-vs-openstack/
  14. [14] ShapeBlue, "CloudStack vs OpenStack Comparison." https://www.shapeblue.com/cloudstack-vs-openstack-comparison/
  15. [15] Apiculus, "CloudStack vs OpenStack: A Showdown for Simplicity and Speed." https://www.apiculus.com/blog/cloudstack-vs-openstack-a-showdown-for-simplicity-and-speed/
  16. [16] ShapeBlue, "Apache CloudStack Overview." https://www.shapeblue.com/apache-cloudstack-overview/

Document Status

Version: 1.0 | Last updated: January 2026
Classification: Official - Technical
Audience: Technical Architects, CTOs, Platform Engineers
Source: Verified by Perplexity AI

Back to Supplementary Analysis