What is the MetaCloud¶

The MetaCloud makes the cloud accessible to everyone. It is a simplification and automation layer that lets researchers, educators, data scientists, and engineers provision and manage cloud resources without needing cloud expertise. A researcher can launch an HPC cluster, a student can start a Jupyter lab, and a data scientist can spin up GPU instances -- all with a few clicks, on any cloud, without ever opening the AWS Console or learning gcloud commands.

Beyond simplification, the MetaCloud is also a cross-cloud unification layer. The same operations -- provisioning machines, storing data, launching containers -- work identically whether the target is AWS, Azure, GCP, Alibaba Cloud, or any other connected provider. A formation written once deploys on any cloud without modification.

Who is the MetaCloud For?¶

Audience	What the MetaCloud Gives Them
Researchers	Self-service HPC, GPU, and general-purpose compute. Reproducible environments via formations. No IT tickets, no cloud expertise needed.
Educators and Students	One-click virtual labs (Jupyter, RStudio, Linux/Windows desktops). Students never see a cloud console.
Data Scientists	Notebook environments, Spark clusters, and model training pipelines with shared datasets -- all managed through formations.
Engineers and DevOps	Cross-cloud IaC, automated deployments, and shareable infrastructure templates. Even cloud experts benefit from formations' reproducibility and sharing model.

The MetaCloud does not replace native cloud access

The MetaCloud abstracts the most common cloud operations -- compute, storage, networking, containers -- but it does not cover every native cloud service. Services such as AWS Bedrock, SageMaker, Lambda, Athena, Redshift, Glue, Azure OpenAI, Azure Functions, Cosmos DB, Synapse, GCP Vertex AI, BigQuery, Cloud Run, Dataflow, and Alibaba Cloud PAI, MaxCompute, Function Compute require direct cloud console access. RosettaOps provides federated console access so users can work in native consoles within their governed sandbox. The MetaCloud and direct cloud access are complementary -- not mutually exclusive.

The Converged Cloud Meta-model¶

At its core, the MetaCloud is a cloud-agnostic meta-model layered on top of the native APIs of all supported providers:

Provider Category	Clouds
Hyperscalers	AWS, Microsoft Azure, Google Cloud Platform, Alibaba Cloud (Aliyun)
Secondary / Private	OVH, Oracle Cloud Infrastructure (OCI), OpenStack, VMware

A single API call provisions the same logical resource -- a virtual machine, a storage bucket, a container cluster -- on any of those clouds. The platform translates the request into the provider-specific calls, credentials, and region mappings required to fulfill it.

Many-to-one artifact mapping

MetaCloud artifacts do not require a one-to-one mapping to cloud resources. Multiple Cloud Keys can reference the same cloud account, multiple storage artifacts can point to different folders within the same S3 bucket, and multiple formations can share the same underlying image. This flexibility lets teams create focused, scoped views of shared cloud infrastructure.

Formations as Cloud-Agnostic Infrastructure as Code¶

Formations are the MetaCloud's declarative templates. A Formation combines several building blocks into a complete, deployable architecture pattern:

Building Block	Description
Meta Cloud Keys	Pre-defined access to cloud regions, VPCs, and network contexts
Machine Images	Custom, shared, or public images for virtual machines
SSL Certificates	Managed TLS certificates for secure endpoints
Cloud Storages	Key-value stores, block volumes, and file systems on any cloud
Instance Types	Memory, CPU, and GPU specifications mapped across providers
Container Images	Private and public repositories, Kubernetes cluster definitions
Applications	Scripts, installers, and application packages
IaC Templates	CloudFormation, CDK, Terraform, OpenTofu, and Pulumi definitions

Multi-cloud and cross-cloud by design

Formations are multi-cloud and cross-cloud templates capable of provisioning repeatable architecture patterns for service delivery. A single Formation can target multiple providers simultaneously.

Cross-Cloud Operations¶

The MetaCloud makes cloud boundaries transparent. Resources on one provider can interoperate with resources on another as if they belonged to the same environment.

Example: An AWS S3 storage bucket can be auto-mounted on a GCP Compute Engine instance. The platform handles the credential brokering, network bridging, and mount configuration -- the user simply declares the relationship in the Formation.

This enables architectures that would otherwise require extensive custom integration:

Storage on one cloud, compute on another
Disaster recovery across providers
Data-sovereignty routing (keep data in-region, process elsewhere)

The MetaCloud treats deployable architectures as shareable, first-class artifacts.

URL-based deployment -- any Formation can be shared as a link; recipients deploy it into their own cloud accounts with a single click
Institutional collaboration -- share across organizational boundaries without exchanging credentials or cloud account details
Marketplaces and service catalogs -- publish Formations to private catalogs for internal teams or to public marketplaces for broader consumption
Cross-cloud portability -- a Formation authored against AWS can be re-targeted to Azure or GCP; the meta-model adapts the underlying resources

Share like a document, deploy like infrastructure

Sharing a Formation is as simple as sharing a link. The recipient selects a target cloud and launches -- no manual configuration required.

The Formations Lifecycle¶

Every Formation follows a seven-step lifecycle:

Clone -- start from an existing Formation or a blank template
Customize -- adjust building blocks, instance types, regions, and parameters
Configure -- set environment variables, secrets, and network topology
Launch -- deploy to one or more target clouds
Connect / Install -- access running instances and install applications or services
Snapshot -- capture the running state as a reusable image or template
Share / Publish -- distribute the Formation via URL, catalog, or marketplace

Repeat the cycle to iterate on the architecture.

Architecture¶

The MetaCloud is structured as a layered abstraction:

Domain Services (education, research, enterprise)
        |
APIs / CLIs / Portals
        |
Unified Operations (monitoring, logging, alerting)
        |
Cross-Cloud Services (networking, storage bridging)
        |
Formations (declarative templates)
        |
Converged Meta-model (unified resource API)
        |
Cloud Providers (AWS, Azure, GCP, OVH, OCI, OpenStack, ...)

Each layer depends only on the one below it, ensuring that higher-level services remain cloud-agnostic.

The MetaCloud Standalone¶

The MetaCloud can be used independently, without the full cloud operations layer. On its own, it provides:

Multi-account key management -- access keys from multiple cloud accounts across providers
Cloud-agnostic IaC -- Formations deploy to any supported cloud
Cost visibility -- per-key cost tracking and estimation
Instance type restrictions -- control which instance types are available per cloud key
Machine count limits -- cap the number of machines per key
Cross-cloud operations -- mount storage across providers, share images

Full Supercloud with Cloud Operations¶

When the MetaCloud is combined with Cloud Operations (RosettaOps), you get the full Supercloud -- a closed-loop platform where governance and provisioning are inseparable:

Budget enforcement -- hard spending limits that block launches when budgets are exhausted
Account vending -- automated cloud account provisioning with guardrails
Compliance policies -- Cloud Custodian enforcement applied to every resource
Organization hierarchy -- nested delegation of budgets, roles, and permissions
Automated landing zones -- pre-configured, compliant environments

Closed-loop governance

The same platform that provisions resources also enforces the budgets and policies that govern them. There is no gap between provisioning and compliance.

What's in This Section¶

Page	Description
Formations	Declarative, cloud-agnostic infrastructure templates
Sessions	Connect to machines and containers launched by formations
Images	Machine images -- custom, shared, and public
Cloud Keys	Region and VPC access credentials for multi-cloud
Key Pairs	SSH keys for secure connections to instances
Storages	Key-value, block, and file storage across providers
Container Images	Docker and OCI container images
Container Repositories	Private registries for container images
Kubernetes	Managed Kubernetes clusters and node groups
IP Addresses	Elastic and static IP addresses
Domains	DNS domain management
SSL Certificates	TLS/SSL certificates for formations
Startup Scripts	Reusable bootstrap scripts