Migrating from AWS to Quake AI
Coming from another cloud?
▸AWS·EC2 Instances, Amazon S3, IAM Users, Amazon Virtual Private Cloud, Stacks
EC2 Instances
- Uses EC2 RunInstances API instead of Nova servers.create.
- Requires predefined instance type selection.
- Supports per-second On-Demand billing and Spot/Reserved options.
- Includes hibernation state not standard in OpenStack.
Amazon Virtual Private Cloud
- AWS VPC is regional with CIDR /16-/28.
- OpenStack Networks project-scoped L2 with flexible CIDR.
- AWS requires IGW for public.
- OpenStack provider nets or floating IPs.
Stacks
- Quake AI offers Heat (legacy OpenStack orchestration) and recommends OpenTofu for new IaC work; EKS uses declarative console/CLI.
- EKS Auto Mode automates data plane; Quake AI uses OpenTofu modules for infrastructure provisioning.
- CloudFormation stacks are managed via AWS-specific REST API (e.g., cloudformation.us-east-1.amazonaws.com) requiring AWS SigV4 auth, while Heat (legacy) uses OpenStack Identity API v3 (keystoneauth) and OpenTofu uses the OpenStack provider with application credentials. Migrators notice different endpoint discovery and auth flows.
- Stacks support StackSets for cross-region/account deployment; Heat has no equivalent. OpenTofu workspaces offer a different multi-environment pattern.
IAM Users
- AWS IAM Users are tied exclusively to one AWS account with no native multi-account scoping without Organizations; OpenStack users exist in domains and get scoped to multiple projects via role assignments, allowing flexible multi-tenancy within a deployment.
- AWS emphasizes long-term credentials like access keys/passwords but strongly recommends federation/temporary creds for humans; OpenStack uses short-lived, scoped tokens natively.
- Naming: AWS ARNs like arn:aws:iam::ACCOUNT:user/NAME; OpenStack uses user@domain scoped to project@domain.
- API differences: AWS uses CreateUser, ListUsers in IAM API; OpenStack Keystone v3 API integrates user/project/role in assignments (e.g., POST /v3/role_assignments).
Migrating from AWS to Quake AI
This guide walks you through moving workloads from AWS to Quake AI, service by service. If you have not reviewed the concept differences between the two platforms, start with Coming from AWS for the full mapping table. This page assumes you understand the translation and are ready to execute.
Before you migrate#
- Review the concept translation guide to understand how AWS services map to Quake AI
- Check Quake AI pricing if billing model differences affect your planning
- Inventory your AWS resources: EC2 instances, S3 buckets, VPCs, security groups, CloudFormation stacks, and IAM credentials
Migration phases#
1. Evaluate and plan#
Inventory your AWS resources: EC2 instances, S3 buckets, VPCs, security groups, CloudFormation stacks. Identify resources with no Quake AI equivalent (Lambda, RDS, DynamoDB) and decide on self-managed alternatives. Estimate your timeline based on service count and S3 data volume.
2. Account setup#
Create your Quake AI project, generate application credentials, and install the OpenStack CLI.
- Quickstart
- Generate application credentials
- Access & Credentials for the OpenStack CLI
3. Object storage (S3 → Swift)#
S3 to Swift is the lowest-risk migration step. Quake AI exposes an S3-compatible API at object.<region>.rumble.cloud, so most AWS tooling works with an endpoint and credential change. Replace <region> with your Quake AI region: us-east-1, us-east-2, or us-west-1.
What transfers cleanly: Buckets (containers on Quake AI), object keys, prefixes, metadata, multipart uploads. Tools like rclone, aws-cli, and s3cmd handle the copy with no application changes beyond the endpoint.
What does not transfer: S3 lifecycle policies, event notifications, bucket policies, and S3 Object Lock. If your workflow depends on lifecycle rules, implement equivalent logic in your application or use rclone's built-in scheduling.
For the full cutover procedure, see Migrate from S3.
4. Infrastructure as Code (CloudFormation → OpenTofu)#
If you use CloudFormation or CDK, the target is OpenTofu (or Terraform) with the openstack provider. Terraform files port directly to OpenTofu with no syntax changes.
The key resource mappings:
| AWS (CloudFormation / Terraform) | Quake AI (OpenTofu) |
|---|---|
aws_instance | openstack_compute_instance_v2 |
aws_s3_bucket | openstack_objectstorage_container_v1 |
aws_security_group | openstack_networking_secgroup_v2 |
aws_vpc / aws_subnet | openstack_networking_network_v2 / openstack_networking_subnet_v2 |
aws_eip | openstack_networking_floatingip_v2 |
aws_lb | Edge reverse proxy, WAF, or API gateway on Nova with a Neutron floating IP |
For step-by-step translation, see Migrate from AWS CloudFormation.
5. Compute (EC2 → Nova)#
AWS provides VM Import/Export, but cross-platform image compatibility (drivers, cloud-init configuration, kernel choices) is often imperfect. The practical migration approach is to provision new instances and migrate application data, and the workload type drives the path:
Containerized applications: If your workload runs in Docker, ECS, or Fargate, see Migrate a Docker container app from AWS to Quake AI for the full guide, including ECS concept translation, ECR image export, and Docker Compose deployment on Nova. For EKS workloads, self-managed Kubernetes on Nova (via RKE2 or k3s) is the recommended path; see Migrate from EKS to Kubernetes on Quake AI for the full guide.
Non-containerized applications: Provision a new Nova instance with the same base image (Ubuntu, Debian, CentOS), install your application stack, and rsync data from the EC2 instance. Automate this with a cloud-init script or OpenTofu template to make it repeatable.
What you re-create on Quake AI:
- Key pairs: generate new ones or import your existing public key
- Security groups: re-create the same port/CIDR rules under Neutron security groups
- Floating IPs: allocate and associate per instance (the elastic IP equivalent)
See Create an instance for the full workflow. For the full guide, see Migrate from EC2 to Quake AI Compute.
6. Networking (VPC → Neutron)#
Re-create your VPC topology as three objects: a network, a subnet, and a router connected to the external network. Basic outbound access does not require an internet gateway or NAT gateway resource.
Security groups map directly: same protocol/port/CIDR rules, same default deny-inbound. Re-create each rule under a new Neutron security group ID.
Floating IPs are the elastic IP equivalent. Allocate a floating IP from the external pool, associate it with the port of a running instance, and update DNS records to point to the new address.
Key how-to guides:
For topology diagrams, three-tier security rule translation, and public-address migration, see Migrate from AWS VPC to Quake AI. Translate ALB routes and targets into an edge reverse proxy or API gateway.
7. Validation and cutover#
Before decommissioning AWS resources:
- Verify that applications respond on Quake AI instances with the expected behavior
- Confirm object storage data integrity: compare object counts and checksums between S3 and Swift
- Update DNS records to point to Quake AI floating IPs; use low TTLs during the transition
- Validate security group rules allow the same traffic patterns as your AWS configuration
- Confirm monitoring and alerting are in place (self-managed Prometheus, Grafana, or equivalent)
- Run IaC plans (
tofu plan) to verify infrastructure state matches expectations
Service mapping reference#
The table below shows how AWS services map to Quake AI equivalents, with confidence ratings and documented divergences. The <ProviderMappings> component reads from the platform knowledge graph.
Compute· 35 mappings
Access Control Lists (ACLs)
→ Rumble: Access control
high4 diffs›
Access Control Lists (ACLs)
→ Rumble: Access control
- •Limited to basic public/private via console; advanced via S3 bucket policies (JSON) emulating IAM.
- •No native ACL support like canned ACLs or fine-grained grantee permissions (Swift S3: Advanced ACLs No).
- •ARN uses project/tenant name instead of AWS account ID.
- •Relies on Ceph API for some user perms; bucket policies only for S3 API.
Accounts
→ Rumble: Projects
high4 diffs›
Accounts
→ Rumble: Projects
- •OpenStack Projects provide resource isolation (VMs, storage) within a single Keystone deployment; AWS Accounts are full billing/security boundaries requiring Organizations for multi-account management.
- •Projects in OS are lightweight, created via Keystone API; AWS Accounts involve separate signup or Organizations API, with inherent billing isolation.
- •Architecture: OS projects owned by domains; AWS accounts grouped in OUs under management account.
- •No direct API equivalence; OS list_projects vs AWS ListAccounts in Organizations service.
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
high4 diffs›
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
- •Direct same-AZ copy only; requires source encrypted, size >= source; background initialization with instant low-latency access.
- •One-time fee per GiB copied at init + standard volume charges; Cinder no standard fee.
- •Max 5 in-progress per Region, one per source at a time; Cinder scheduler-dependent.
- •Independent volume post-init, no ongoing link; Cinder may use COW depending on driver.
Amazon EBS volumes
→ Rumble: Volumes
high4 diffs›
Amazon EBS volumes
→ Rumble: Volumes
- •Strictly bound to a single Availability Zone where created; cannot be moved without snapshot.
- •Multiple volume types (gp3, io2, st1) with different performance/billing characteristics; Cinder uses volume_types but backend-defined.
- •Billed per provisioned GB-month regardless of usage; OpenStack typically quota-based without standard usage billing.
- •API via EC2 CreateVolume; differs from Cinder create_volume.
Amazon EC2
→ Rumble: Compute
›
Amazon EC2
→ Rumble: Compute
No specific divergences documented yet.
View AWS docs →Amazon EKS Cluster
→ Rumble: Kubernetes
high4 diffs›
Amazon EKS Cluster
→ Rumble: Kubernetes
- •EKS control plane fully AWS-managed, single-tenant, across 3 AZs with auto scale/replace; on Quake AI you run the control plane on Nova instances, provisioned through Magnum or self-managed with OpenTofu, and you operate it.
- •EKS regional API endpoint with SLA; Quake AI exposes the kube API via Neutron LB with floating IP.
- •EKS charges a per-hour cluster platform fee on top of the underlying compute; Quake AI charges only for underlying Nova/Neutron/Cinder resources with no K8s platform fee.
- •EKS managed nodes auto AMI updates, Spot integration; Quake AI self-managed nodes require manual OS image selection and update management.
Amazon Machine Images (AMIs)
→ Rumble: Images
high4 diffs›
Amazon Machine Images (AMIs)
→ Rumble: Images
- •Managed via EC2 APIs, not Glance.
- •Region-specific with cross-region copy.
- •Marketplace AMIs may charge hourly fees.
- •Includes block device mapping in AMI.
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
›
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
No specific divergences documented yet.
View AWS docs →Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
high4 diffs›
Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
- •AWS S3 is the reference protocol; Quake AI exposes S3 compatibility via OpenStack Swift s3api middleware over Ceph. Several S3 operations are unsupported by Swift s3api: S3 Select, Bucket Notifications, S3 Website hosting, Transfer Acceleration, and advanced ACLs.
- •AWS SigV4 is supported by Swift s3api, but presigned URL features and IAM bucket policies with complex condition keys are not implemented.
- •AWS S3 bucket namespace is global per AWS account; on Quake AI, buckets are scoped to the OpenStack project and endpoint is provider-defined (not s3.amazonaws.com).
- •S3 storage class transitions (Intelligent-Tiering, Glacier, One Zone-IA) have no equivalent in Swift; all Quake AI objects remain in a single storage tier.
Amazon Virtual Private Cloud
→ Rumble: Networks
high4 diffs›
Amazon Virtual Private Cloud
→ Rumble: Networks
- •AWS VPC is regional with CIDR /16-/28.
- •OpenStack Networks project-scoped L2 with flexible CIDR.
- •AWS requires IGW for public.
- •OpenStack provider nets or floating IPs.
Amazon VPC + VPC CNI
→ Rumble: Networking
high3 diffs›
Amazon VPC + VPC CNI
→ Rumble: Networking
- •Quake AI uses per-cluster private networks and routers for Kubernetes; EKS uses a customer VPC with ENI pod networking.
- •Quake AI K8s uses Flannel/Calico/Cilium CNI on Neutron; EKS uses VPC CNI with prefix delegation.
- •EKS bills cross-AZ control traffic; OpenStack no.
AWS API Changelog
→ Rumble: API
high1 diff›
AWS API Changelog
→ Rumble: API
- •AWS publishes API changes through What's New feed and service-specific changelogs; Quake AI uses a unified api-changelog page
AWS API Changelog
→ Rumble: API versioning
›
AWS API Changelog
→ Rumble: API versioning
No specific divergences documented yet.
View AWS docs →AWS Billing and Cost Management
→ Rumble: Billing
high4 diffs›
AWS Billing and Cost Management
→ Rumble: Billing
- •AWS has native consolidated billing via Organizations (single bill for all accounts); OpenStack has no standard billing service—usage metered via Ceilometer but billing is external/provider-implemented.
- •Cost allocation: AWS uses cost categories/tags, Cost Explorer; OS relies on custom integrations.
- •Architecture: AWS payer account charges; OS per-project quotas but billing not core.
- •No API equivalence; AWS Billing APIs for reports/budgets, OS no core billing API.
AWS Organizations
→ Rumble: Organizations
high4 diffs›
AWS Organizations
→ Rumble: Organizations
- •AWS Organizations provides hierarchical OUs, SCPs for governance, consolidated billing; OpenStack lacks native multi-deployment orgs, uses Keystone domains/projects for isolation but no built-in billing consolidation across deployments.
- •Billing model: AWS management account pays for all members; OpenStack billing is provider-specific, often per-project quotas but no standard consolidated billing service.
- •Policies: AWS SCPs limit max permissions; OS uses role assignments without equivalent guardrails.
- •API: AWS CreateOrganization, ListOrganizationalUnits; OS no equivalent, managed via Keystone domains.
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
high4 diffs›
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
- •AWS bills EC2 Linux instances per second with a 60-second minimum. Pricing is not embedded in the Nova/flavor API; AWS instance pricing requires querying the AWS Price List API (GET /offers/v1.0/aws/AmazonEC2/current/index.json) or the Pricing Calculator.
- •AWS pricing varies by region, instance type, tenancy, and OS; there are no monthly price caps. Hetzner and some OpenStack clouds offer monthly price caps per server.
- •AWS does not include outbound data transfer in instance pricing; egress is billed separately per-GB with a small free-tier allowance. Quake AI's egress pricing is operator-defined. See the AWS pricing page for current rates.
- •AWS offers reserved instances (1-year/3-year commitments), savings plans, and spot pricing as distinct purchasing models not available in standard OpenStack deployments.
AWS Security Pillar
→ Rumble: Security
›
AWS Security Pillar
→ Rumble: Security
No specific divergences documented yet.
View AWS docs →EBS Snapshots
→ Rumble: Snapshots
high4 diffs›
EBS Snapshots
→ Rumble: Snapshots
- •Per-EBS volume, incremental in S3; not full instance image.
- •Via EC2 CreateSnapshot API, not Nova/Cinder.
- •Async pending state, volume usable during snapshot.
- •Billed per GB-month stored.
EC2 Instances
→ Rumble: Instances
high4 diffs›
EC2 Instances
→ Rumble: Instances
- •Uses EC2 RunInstances API instead of Nova servers.create.
- •Requires predefined instance type selection.
- •Supports per-second On-Demand billing and Spot/Reserved options.
- •Includes hibernation state not standard in OpenStack.
EC2 Key Pairs
→ Rumble: Key pairs
high4 diffs›
EC2 Key Pairs
→ Rumble: Key pairs
- •Public key auto-injected to authorized_keys at boot.
- •Up to 5000 per region; AWS stores public key.
- •Supports import of external keys (RSA/ED25519).
- •No post-launch addition without userdata/SSM.
Elastic IP addresses
→ Rumble: Floating IPs
high4 diffs›
Elastic IP addresses
→ Rumble: Floating IPs
- •AWS charges idle EIPs.
- •OpenStack floating IPs free/pool-limited.
- •AWS regional instance/ENI.
- •OpenStack project port.
Elastic Load Balancing
→ Rumble: Load balancer
high4 diffs›
Elastic Load Balancing
→ Rumble: Load balancer
- •Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
- •AWS hourly/LCU billing.
- •OpenStack VM billing.
- •AWS global endpoints.
Elastic Network Interfaces
→ Rumble: Ports
›
Elastic Network Interfaces
→ Rumble: Ports
No specific divergences documented yet.
View AWS docs →IAM Users
→ Rumble: Authentication
high4 diffs›
IAM Users
→ Rumble: Authentication
- •AWS IAM Users are tied exclusively to one AWS account with no native multi-account scoping without Organizations; OpenStack users exist in domains and get scoped to multiple projects via role assignments, allowing flexible multi-tenancy within a deployment.
- •AWS emphasizes long-term credentials like access keys/passwords but strongly recommends federation/temporary creds for humans; OpenStack uses short-lived, scoped tokens natively.
- •Naming: AWS ARNs like arn:aws:iam::ACCOUNT:user/NAME; OpenStack uses user@domain scoped to project@domain.
- •API differences: AWS uses CreateUser, ListUsers in IAM API; OpenStack Keystone v3 API integrates user/project/role in assignments (e.g., POST /v3/role_assignments).
Instance Types
→ Rumble: Flavors
high4 diffs›
Instance Types
→ Rumble: Flavors
- •Fixed predefined configurations only; no custom flavor creation.
- •Extensive families for GPU/HPC/ARM etc.
- •InstanceType as string param in API, not ID reference.
- •Tied to specific hardware generations (Nitro/Xen).
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
high4 diffs›
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
- •AWS has no subscription concept. Billing is per AWS Account. Multiple accounts can be grouped under AWS Organizations with consolidated billing where the payer account receives a single invoice. OpenStack projects are resource boundaries within a single Keystone domain with no native billing hierarchy.
- •AWS accounts are completely isolated resource boundaries; resources do not cross account boundaries without explicit cross-account IAM roles and resource policies. OpenStack projects are resource boundaries within a shared Keystone domain, with cross-project access via role assignments.
- •AWS Organizations allows Service Control Policies (SCPs) applied at the organizational unit level, restricting what IAM policies can grant. OpenStack has no equivalent cascading policy restriction mechanism across projects.
- •AWS account-level service quotas are separate from organizational-level limits and must be increased per account. OpenStack project quotas are set per project by the admin.
NAT Gateway
→ Rumble: NAT
high4 diffs›
NAT Gateway
→ Rumble: NAT
- •AWS managed HA per AZ hourly/GB.
- •OpenStack router SNAT L3 agent/OVN.
- •OpenStack basic SNAT.
- •OpenStack router-limited.
Placement Groups
→ Rumble: Server groups
high4 diffs›
Placement Groups
→ Rumble: Server groups
- •Policies: cluster/partition/spread vs affinity/anti-affinity.
- •AZ-scoped, no instance moves/merges.
- •Specified at launch via PlacementGroupName.
- •Max 7 partitions per AZ for partition type.
Route Tables
→ Rumble: Routers
high4 diffs›
Route Tables
→ Rumble: Routers
- •AWS per subnet/VPC main.
- •OpenStack L3 routers distributed/central.
- •AWS local intra-VPC implicit.
- •OpenStack BGP-LS opt.
S3 Versioning
→ Rumble: Versioning
high4 diffs›
S3 Versioning
→ Rumble: Versioning
- •Supported via S3 API (enable/suspend, list/delete versions); counts all versions toward quota.
- •Console shows only latest size, no version listing.
- •Once enabled, cannot disable (only suspend, like S3).
- •Standard OpenStack Swift S3 behavior; no MFA Delete mentioned.
Security Groups
→ Rumble: Security groups
high4 diffs›
Security Groups
→ Rumble: Security groups
- •AWS stateful auto-response.
- •OpenStack stateless explicit.
- •OpenStack port/project.
- •AWS default inbound deny/outbound all.
Server-Side Encryption
→ Rumble: Encryption
high4 diffs›
Server-Side Encryption
→ Rumble: Encryption
- •SSE-C (customer keys, AES256) and SSE-OMK (Quake AI-managed AES256 per-object keys with root rotation).
- •No SSE-S3 or SSE-KMS; SSE-OMK differs (unique keys, no AWS KMS).
- •SSE-C: ETag not MD5 (salted hash), metadata retrieval needs key.
- •HTTPS required; per-version keys if versioning enabled.
Stacks
→ Rumble: Automation
high4 diffs›
Stacks
→ Rumble: Automation
- •Quake AI offers Heat (legacy OpenStack orchestration) and recommends OpenTofu for new IaC work; EKS uses declarative console/CLI.
- •EKS Auto Mode automates data plane; Quake AI uses OpenTofu modules for infrastructure provisioning.
- •CloudFormation stacks are managed via AWS-specific REST API (e.g., cloudformation.us-east-1.amazonaws.com) requiring AWS SigV4 auth, while Heat (legacy) uses OpenStack Identity API v3 (keystoneauth) and OpenTofu uses the OpenStack provider with application credentials. Migrators notice different endpoint discovery and auth flows.
- •Stacks support StackSets for cross-region/account deployment; Heat has no equivalent. OpenTofu workspaces offer a different multi-environment pattern.
Subnets
→ Rumble: Subnets
high4 diffs›
Subnets
→ Rumble: Subnets
- •AWS subnets single AZ.
- •AWS public/private by routes.
- •OpenStack by network type.
- •AWS IPv6-only; OpenStack dual-stack.
Terraform AWS provider
→ Rumble: Terraform
high2 diffs›
Terraform AWS provider
→ Rumble: Terraform
- •Uses aws_instance resource with AMI IDs; OpenStack uses openstack_compute_instance_v2 with image names/IDs.
- •AWS provider uses access_key/secret_key; OpenStack provider uses application credentials or Keystone tokens.
Network· 35 mappings
Access Control Lists (ACLs)
→ Rumble: Access control
high4 diffs›
Access Control Lists (ACLs)
→ Rumble: Access control
- •Limited to basic public/private via console; advanced via S3 bucket policies (JSON) emulating IAM.
- •No native ACL support like canned ACLs or fine-grained grantee permissions (Swift S3: Advanced ACLs No).
- •ARN uses project/tenant name instead of AWS account ID.
- •Relies on Ceph API for some user perms; bucket policies only for S3 API.
Accounts
→ Rumble: Projects
high4 diffs›
Accounts
→ Rumble: Projects
- •OpenStack Projects provide resource isolation (VMs, storage) within a single Keystone deployment; AWS Accounts are full billing/security boundaries requiring Organizations for multi-account management.
- •Projects in OS are lightweight, created via Keystone API; AWS Accounts involve separate signup or Organizations API, with inherent billing isolation.
- •Architecture: OS projects owned by domains; AWS accounts grouped in OUs under management account.
- •No direct API equivalence; OS list_projects vs AWS ListAccounts in Organizations service.
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
high4 diffs›
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
- •Direct same-AZ copy only; requires source encrypted, size >= source; background initialization with instant low-latency access.
- •One-time fee per GiB copied at init + standard volume charges; Cinder no standard fee.
- •Max 5 in-progress per Region, one per source at a time; Cinder scheduler-dependent.
- •Independent volume post-init, no ongoing link; Cinder may use COW depending on driver.
Amazon EBS volumes
→ Rumble: Volumes
high4 diffs›
Amazon EBS volumes
→ Rumble: Volumes
- •Strictly bound to a single Availability Zone where created; cannot be moved without snapshot.
- •Multiple volume types (gp3, io2, st1) with different performance/billing characteristics; Cinder uses volume_types but backend-defined.
- •Billed per provisioned GB-month regardless of usage; OpenStack typically quota-based without standard usage billing.
- •API via EC2 CreateVolume; differs from Cinder create_volume.
Amazon EC2
→ Rumble: Compute
›
Amazon EC2
→ Rumble: Compute
No specific divergences documented yet.
View AWS docs →Amazon EKS Cluster
→ Rumble: Kubernetes
high4 diffs›
Amazon EKS Cluster
→ Rumble: Kubernetes
- •EKS control plane fully AWS-managed, single-tenant, across 3 AZs with auto scale/replace; on Quake AI you run the control plane on Nova instances, provisioned through Magnum or self-managed with OpenTofu, and you operate it.
- •EKS regional API endpoint with SLA; Quake AI exposes the kube API via Neutron LB with floating IP.
- •EKS charges a per-hour cluster platform fee on top of the underlying compute; Quake AI charges only for underlying Nova/Neutron/Cinder resources with no K8s platform fee.
- •EKS managed nodes auto AMI updates, Spot integration; Quake AI self-managed nodes require manual OS image selection and update management.
Amazon Machine Images (AMIs)
→ Rumble: Images
high4 diffs›
Amazon Machine Images (AMIs)
→ Rumble: Images
- •Managed via EC2 APIs, not Glance.
- •Region-specific with cross-region copy.
- •Marketplace AMIs may charge hourly fees.
- •Includes block device mapping in AMI.
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
›
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
No specific divergences documented yet.
View AWS docs →Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
high4 diffs›
Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
- •AWS S3 is the reference protocol; Quake AI exposes S3 compatibility via OpenStack Swift s3api middleware over Ceph. Several S3 operations are unsupported by Swift s3api: S3 Select, Bucket Notifications, S3 Website hosting, Transfer Acceleration, and advanced ACLs.
- •AWS SigV4 is supported by Swift s3api, but presigned URL features and IAM bucket policies with complex condition keys are not implemented.
- •AWS S3 bucket namespace is global per AWS account; on Quake AI, buckets are scoped to the OpenStack project and endpoint is provider-defined (not s3.amazonaws.com).
- •S3 storage class transitions (Intelligent-Tiering, Glacier, One Zone-IA) have no equivalent in Swift; all Quake AI objects remain in a single storage tier.
Amazon Virtual Private Cloud
→ Rumble: Networks
high4 diffs›
Amazon Virtual Private Cloud
→ Rumble: Networks
- •AWS VPC is regional with CIDR /16-/28.
- •OpenStack Networks project-scoped L2 with flexible CIDR.
- •AWS requires IGW for public.
- •OpenStack provider nets or floating IPs.
Amazon VPC + VPC CNI
→ Rumble: Networking
high3 diffs›
Amazon VPC + VPC CNI
→ Rumble: Networking
- •Quake AI uses per-cluster private networks and routers for Kubernetes; EKS uses a customer VPC with ENI pod networking.
- •Quake AI K8s uses Flannel/Calico/Cilium CNI on Neutron; EKS uses VPC CNI with prefix delegation.
- •EKS bills cross-AZ control traffic; OpenStack no.
AWS API Changelog
→ Rumble: API
high1 diff›
AWS API Changelog
→ Rumble: API
- •AWS publishes API changes through What's New feed and service-specific changelogs; Quake AI uses a unified api-changelog page
AWS API Changelog
→ Rumble: API versioning
›
AWS API Changelog
→ Rumble: API versioning
No specific divergences documented yet.
View AWS docs →AWS Billing and Cost Management
→ Rumble: Billing
high4 diffs›
AWS Billing and Cost Management
→ Rumble: Billing
- •AWS has native consolidated billing via Organizations (single bill for all accounts); OpenStack has no standard billing service—usage metered via Ceilometer but billing is external/provider-implemented.
- •Cost allocation: AWS uses cost categories/tags, Cost Explorer; OS relies on custom integrations.
- •Architecture: AWS payer account charges; OS per-project quotas but billing not core.
- •No API equivalence; AWS Billing APIs for reports/budgets, OS no core billing API.
AWS Organizations
→ Rumble: Organizations
high4 diffs›
AWS Organizations
→ Rumble: Organizations
- •AWS Organizations provides hierarchical OUs, SCPs for governance, consolidated billing; OpenStack lacks native multi-deployment orgs, uses Keystone domains/projects for isolation but no built-in billing consolidation across deployments.
- •Billing model: AWS management account pays for all members; OpenStack billing is provider-specific, often per-project quotas but no standard consolidated billing service.
- •Policies: AWS SCPs limit max permissions; OS uses role assignments without equivalent guardrails.
- •API: AWS CreateOrganization, ListOrganizationalUnits; OS no equivalent, managed via Keystone domains.
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
high4 diffs›
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
- •AWS bills EC2 Linux instances per second with a 60-second minimum. Pricing is not embedded in the Nova/flavor API; AWS instance pricing requires querying the AWS Price List API (GET /offers/v1.0/aws/AmazonEC2/current/index.json) or the Pricing Calculator.
- •AWS pricing varies by region, instance type, tenancy, and OS; there are no monthly price caps. Hetzner and some OpenStack clouds offer monthly price caps per server.
- •AWS does not include outbound data transfer in instance pricing; egress is billed separately per-GB with a small free-tier allowance. Quake AI's egress pricing is operator-defined. See the AWS pricing page for current rates.
- •AWS offers reserved instances (1-year/3-year commitments), savings plans, and spot pricing as distinct purchasing models not available in standard OpenStack deployments.
AWS Security Pillar
→ Rumble: Security
›
AWS Security Pillar
→ Rumble: Security
No specific divergences documented yet.
View AWS docs →EBS Snapshots
→ Rumble: Snapshots
high4 diffs›
EBS Snapshots
→ Rumble: Snapshots
- •Per-EBS volume, incremental in S3; not full instance image.
- •Via EC2 CreateSnapshot API, not Nova/Cinder.
- •Async pending state, volume usable during snapshot.
- •Billed per GB-month stored.
EC2 Instances
→ Rumble: Instances
high4 diffs›
EC2 Instances
→ Rumble: Instances
- •Uses EC2 RunInstances API instead of Nova servers.create.
- •Requires predefined instance type selection.
- •Supports per-second On-Demand billing and Spot/Reserved options.
- •Includes hibernation state not standard in OpenStack.
EC2 Key Pairs
→ Rumble: Key pairs
high4 diffs›
EC2 Key Pairs
→ Rumble: Key pairs
- •Public key auto-injected to authorized_keys at boot.
- •Up to 5000 per region; AWS stores public key.
- •Supports import of external keys (RSA/ED25519).
- •No post-launch addition without userdata/SSM.
Elastic IP addresses
→ Rumble: Floating IPs
high4 diffs›
Elastic IP addresses
→ Rumble: Floating IPs
- •AWS charges idle EIPs.
- •OpenStack floating IPs free/pool-limited.
- •AWS regional instance/ENI.
- •OpenStack project port.
Elastic Load Balancing
→ Rumble: Load balancer
high4 diffs›
Elastic Load Balancing
→ Rumble: Load balancer
- •Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
- •AWS hourly/LCU billing.
- •OpenStack VM billing.
- •AWS global endpoints.
Elastic Network Interfaces
→ Rumble: Ports
›
Elastic Network Interfaces
→ Rumble: Ports
No specific divergences documented yet.
View AWS docs →IAM Users
→ Rumble: Authentication
high4 diffs›
IAM Users
→ Rumble: Authentication
- •AWS IAM Users are tied exclusively to one AWS account with no native multi-account scoping without Organizations; OpenStack users exist in domains and get scoped to multiple projects via role assignments, allowing flexible multi-tenancy within a deployment.
- •AWS emphasizes long-term credentials like access keys/passwords but strongly recommends federation/temporary creds for humans; OpenStack uses short-lived, scoped tokens natively.
- •Naming: AWS ARNs like arn:aws:iam::ACCOUNT:user/NAME; OpenStack uses user@domain scoped to project@domain.
- •API differences: AWS uses CreateUser, ListUsers in IAM API; OpenStack Keystone v3 API integrates user/project/role in assignments (e.g., POST /v3/role_assignments).
Instance Types
→ Rumble: Flavors
high4 diffs›
Instance Types
→ Rumble: Flavors
- •Fixed predefined configurations only; no custom flavor creation.
- •Extensive families for GPU/HPC/ARM etc.
- •InstanceType as string param in API, not ID reference.
- •Tied to specific hardware generations (Nitro/Xen).
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
high4 diffs›
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
- •AWS has no subscription concept. Billing is per AWS Account. Multiple accounts can be grouped under AWS Organizations with consolidated billing where the payer account receives a single invoice. OpenStack projects are resource boundaries within a single Keystone domain with no native billing hierarchy.
- •AWS accounts are completely isolated resource boundaries; resources do not cross account boundaries without explicit cross-account IAM roles and resource policies. OpenStack projects are resource boundaries within a shared Keystone domain, with cross-project access via role assignments.
- •AWS Organizations allows Service Control Policies (SCPs) applied at the organizational unit level, restricting what IAM policies can grant. OpenStack has no equivalent cascading policy restriction mechanism across projects.
- •AWS account-level service quotas are separate from organizational-level limits and must be increased per account. OpenStack project quotas are set per project by the admin.
NAT Gateway
→ Rumble: NAT
high4 diffs›
NAT Gateway
→ Rumble: NAT
- •AWS managed HA per AZ hourly/GB.
- •OpenStack router SNAT L3 agent/OVN.
- •OpenStack basic SNAT.
- •OpenStack router-limited.
Placement Groups
→ Rumble: Server groups
high4 diffs›
Placement Groups
→ Rumble: Server groups
- •Policies: cluster/partition/spread vs affinity/anti-affinity.
- •AZ-scoped, no instance moves/merges.
- •Specified at launch via PlacementGroupName.
- •Max 7 partitions per AZ for partition type.
Route Tables
→ Rumble: Routers
high4 diffs›
Route Tables
→ Rumble: Routers
- •AWS per subnet/VPC main.
- •OpenStack L3 routers distributed/central.
- •AWS local intra-VPC implicit.
- •OpenStack BGP-LS opt.
S3 Versioning
→ Rumble: Versioning
high4 diffs›
S3 Versioning
→ Rumble: Versioning
- •Supported via S3 API (enable/suspend, list/delete versions); counts all versions toward quota.
- •Console shows only latest size, no version listing.
- •Once enabled, cannot disable (only suspend, like S3).
- •Standard OpenStack Swift S3 behavior; no MFA Delete mentioned.
Security Groups
→ Rumble: Security groups
high4 diffs›
Security Groups
→ Rumble: Security groups
- •AWS stateful auto-response.
- •OpenStack stateless explicit.
- •OpenStack port/project.
- •AWS default inbound deny/outbound all.
Server-Side Encryption
→ Rumble: Encryption
high4 diffs›
Server-Side Encryption
→ Rumble: Encryption
- •SSE-C (customer keys, AES256) and SSE-OMK (Quake AI-managed AES256 per-object keys with root rotation).
- •No SSE-S3 or SSE-KMS; SSE-OMK differs (unique keys, no AWS KMS).
- •SSE-C: ETag not MD5 (salted hash), metadata retrieval needs key.
- •HTTPS required; per-version keys if versioning enabled.
Stacks
→ Rumble: Automation
high4 diffs›
Stacks
→ Rumble: Automation
- •Quake AI offers Heat (legacy OpenStack orchestration) and recommends OpenTofu for new IaC work; EKS uses declarative console/CLI.
- •EKS Auto Mode automates data plane; Quake AI uses OpenTofu modules for infrastructure provisioning.
- •CloudFormation stacks are managed via AWS-specific REST API (e.g., cloudformation.us-east-1.amazonaws.com) requiring AWS SigV4 auth, while Heat (legacy) uses OpenStack Identity API v3 (keystoneauth) and OpenTofu uses the OpenStack provider with application credentials. Migrators notice different endpoint discovery and auth flows.
- •Stacks support StackSets for cross-region/account deployment; Heat has no equivalent. OpenTofu workspaces offer a different multi-environment pattern.
Subnets
→ Rumble: Subnets
high4 diffs›
Subnets
→ Rumble: Subnets
- •AWS subnets single AZ.
- •AWS public/private by routes.
- •OpenStack by network type.
- •AWS IPv6-only; OpenStack dual-stack.
Terraform AWS provider
→ Rumble: Terraform
high2 diffs›
Terraform AWS provider
→ Rumble: Terraform
- •Uses aws_instance resource with AMI IDs; OpenStack uses openstack_compute_instance_v2 with image names/IDs.
- •AWS provider uses access_key/secret_key; OpenStack provider uses application credentials or Keystone tokens.
Object storage· 35 mappings
Access Control Lists (ACLs)
→ Rumble: Access control
high4 diffs›
Access Control Lists (ACLs)
→ Rumble: Access control
- •Limited to basic public/private via console; advanced via S3 bucket policies (JSON) emulating IAM.
- •No native ACL support like canned ACLs or fine-grained grantee permissions (Swift S3: Advanced ACLs No).
- •ARN uses project/tenant name instead of AWS account ID.
- •Relies on Ceph API for some user perms; bucket policies only for S3 API.
Accounts
→ Rumble: Projects
high4 diffs›
Accounts
→ Rumble: Projects
- •OpenStack Projects provide resource isolation (VMs, storage) within a single Keystone deployment; AWS Accounts are full billing/security boundaries requiring Organizations for multi-account management.
- •Projects in OS are lightweight, created via Keystone API; AWS Accounts involve separate signup or Organizations API, with inherent billing isolation.
- •Architecture: OS projects owned by domains; AWS accounts grouped in OUs under management account.
- •No direct API equivalence; OS list_projects vs AWS ListAccounts in Organizations service.
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
high4 diffs›
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
- •Direct same-AZ copy only; requires source encrypted, size >= source; background initialization with instant low-latency access.
- •One-time fee per GiB copied at init + standard volume charges; Cinder no standard fee.
- •Max 5 in-progress per Region, one per source at a time; Cinder scheduler-dependent.
- •Independent volume post-init, no ongoing link; Cinder may use COW depending on driver.
Amazon EBS volumes
→ Rumble: Volumes
high4 diffs›
Amazon EBS volumes
→ Rumble: Volumes
- •Strictly bound to a single Availability Zone where created; cannot be moved without snapshot.
- •Multiple volume types (gp3, io2, st1) with different performance/billing characteristics; Cinder uses volume_types but backend-defined.
- •Billed per provisioned GB-month regardless of usage; OpenStack typically quota-based without standard usage billing.
- •API via EC2 CreateVolume; differs from Cinder create_volume.
Amazon EC2
→ Rumble: Compute
›
Amazon EC2
→ Rumble: Compute
No specific divergences documented yet.
View AWS docs →Amazon EKS Cluster
→ Rumble: Kubernetes
high4 diffs›
Amazon EKS Cluster
→ Rumble: Kubernetes
- •EKS control plane fully AWS-managed, single-tenant, across 3 AZs with auto scale/replace; on Quake AI you run the control plane on Nova instances, provisioned through Magnum or self-managed with OpenTofu, and you operate it.
- •EKS regional API endpoint with SLA; Quake AI exposes the kube API via Neutron LB with floating IP.
- •EKS charges a per-hour cluster platform fee on top of the underlying compute; Quake AI charges only for underlying Nova/Neutron/Cinder resources with no K8s platform fee.
- •EKS managed nodes auto AMI updates, Spot integration; Quake AI self-managed nodes require manual OS image selection and update management.
Amazon Machine Images (AMIs)
→ Rumble: Images
high4 diffs›
Amazon Machine Images (AMIs)
→ Rumble: Images
- •Managed via EC2 APIs, not Glance.
- •Region-specific with cross-region copy.
- •Marketplace AMIs may charge hourly fees.
- •Includes block device mapping in AMI.
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
›
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
No specific divergences documented yet.
View AWS docs →Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
high4 diffs›
Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
- •AWS S3 is the reference protocol; Quake AI exposes S3 compatibility via OpenStack Swift s3api middleware over Ceph. Several S3 operations are unsupported by Swift s3api: S3 Select, Bucket Notifications, S3 Website hosting, Transfer Acceleration, and advanced ACLs.
- •AWS SigV4 is supported by Swift s3api, but presigned URL features and IAM bucket policies with complex condition keys are not implemented.
- •AWS S3 bucket namespace is global per AWS account; on Quake AI, buckets are scoped to the OpenStack project and endpoint is provider-defined (not s3.amazonaws.com).
- •S3 storage class transitions (Intelligent-Tiering, Glacier, One Zone-IA) have no equivalent in Swift; all Quake AI objects remain in a single storage tier.
Amazon Virtual Private Cloud
→ Rumble: Networks
high4 diffs›
Amazon Virtual Private Cloud
→ Rumble: Networks
- •AWS VPC is regional with CIDR /16-/28.
- •OpenStack Networks project-scoped L2 with flexible CIDR.
- •AWS requires IGW for public.
- •OpenStack provider nets or floating IPs.
Amazon VPC + VPC CNI
→ Rumble: Networking
high3 diffs›
Amazon VPC + VPC CNI
→ Rumble: Networking
- •Quake AI uses per-cluster private networks and routers for Kubernetes; EKS uses a customer VPC with ENI pod networking.
- •Quake AI K8s uses Flannel/Calico/Cilium CNI on Neutron; EKS uses VPC CNI with prefix delegation.
- •EKS bills cross-AZ control traffic; OpenStack no.
AWS API Changelog
→ Rumble: API
high1 diff›
AWS API Changelog
→ Rumble: API
- •AWS publishes API changes through What's New feed and service-specific changelogs; Quake AI uses a unified api-changelog page
AWS API Changelog
→ Rumble: API versioning
›
AWS API Changelog
→ Rumble: API versioning
No specific divergences documented yet.
View AWS docs →AWS Billing and Cost Management
→ Rumble: Billing
high4 diffs›
AWS Billing and Cost Management
→ Rumble: Billing
- •AWS has native consolidated billing via Organizations (single bill for all accounts); OpenStack has no standard billing service—usage metered via Ceilometer but billing is external/provider-implemented.
- •Cost allocation: AWS uses cost categories/tags, Cost Explorer; OS relies on custom integrations.
- •Architecture: AWS payer account charges; OS per-project quotas but billing not core.
- •No API equivalence; AWS Billing APIs for reports/budgets, OS no core billing API.
AWS Organizations
→ Rumble: Organizations
high4 diffs›
AWS Organizations
→ Rumble: Organizations
- •AWS Organizations provides hierarchical OUs, SCPs for governance, consolidated billing; OpenStack lacks native multi-deployment orgs, uses Keystone domains/projects for isolation but no built-in billing consolidation across deployments.
- •Billing model: AWS management account pays for all members; OpenStack billing is provider-specific, often per-project quotas but no standard consolidated billing service.
- •Policies: AWS SCPs limit max permissions; OS uses role assignments without equivalent guardrails.
- •API: AWS CreateOrganization, ListOrganizationalUnits; OS no equivalent, managed via Keystone domains.
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
high4 diffs›
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
- •AWS bills EC2 Linux instances per second with a 60-second minimum. Pricing is not embedded in the Nova/flavor API; AWS instance pricing requires querying the AWS Price List API (GET /offers/v1.0/aws/AmazonEC2/current/index.json) or the Pricing Calculator.
- •AWS pricing varies by region, instance type, tenancy, and OS; there are no monthly price caps. Hetzner and some OpenStack clouds offer monthly price caps per server.
- •AWS does not include outbound data transfer in instance pricing; egress is billed separately per-GB with a small free-tier allowance. Quake AI's egress pricing is operator-defined. See the AWS pricing page for current rates.
- •AWS offers reserved instances (1-year/3-year commitments), savings plans, and spot pricing as distinct purchasing models not available in standard OpenStack deployments.
AWS Security Pillar
→ Rumble: Security
›
AWS Security Pillar
→ Rumble: Security
No specific divergences documented yet.
View AWS docs →EBS Snapshots
→ Rumble: Snapshots
high4 diffs›
EBS Snapshots
→ Rumble: Snapshots
- •Per-EBS volume, incremental in S3; not full instance image.
- •Via EC2 CreateSnapshot API, not Nova/Cinder.
- •Async pending state, volume usable during snapshot.
- •Billed per GB-month stored.
EC2 Instances
→ Rumble: Instances
high4 diffs›
EC2 Instances
→ Rumble: Instances
- •Uses EC2 RunInstances API instead of Nova servers.create.
- •Requires predefined instance type selection.
- •Supports per-second On-Demand billing and Spot/Reserved options.
- •Includes hibernation state not standard in OpenStack.
EC2 Key Pairs
→ Rumble: Key pairs
high4 diffs›
EC2 Key Pairs
→ Rumble: Key pairs
- •Public key auto-injected to authorized_keys at boot.
- •Up to 5000 per region; AWS stores public key.
- •Supports import of external keys (RSA/ED25519).
- •No post-launch addition without userdata/SSM.
Elastic IP addresses
→ Rumble: Floating IPs
high4 diffs›
Elastic IP addresses
→ Rumble: Floating IPs
- •AWS charges idle EIPs.
- •OpenStack floating IPs free/pool-limited.
- •AWS regional instance/ENI.
- •OpenStack project port.
Elastic Load Balancing
→ Rumble: Load balancer
high4 diffs›
Elastic Load Balancing
→ Rumble: Load balancer
- •Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
- •AWS hourly/LCU billing.
- •OpenStack VM billing.
- •AWS global endpoints.
Elastic Network Interfaces
→ Rumble: Ports
›
Elastic Network Interfaces
→ Rumble: Ports
No specific divergences documented yet.
View AWS docs →IAM Users
→ Rumble: Authentication
high4 diffs›
IAM Users
→ Rumble: Authentication
- •AWS IAM Users are tied exclusively to one AWS account with no native multi-account scoping without Organizations; OpenStack users exist in domains and get scoped to multiple projects via role assignments, allowing flexible multi-tenancy within a deployment.
- •AWS emphasizes long-term credentials like access keys/passwords but strongly recommends federation/temporary creds for humans; OpenStack uses short-lived, scoped tokens natively.
- •Naming: AWS ARNs like arn:aws:iam::ACCOUNT:user/NAME; OpenStack uses user@domain scoped to project@domain.
- •API differences: AWS uses CreateUser, ListUsers in IAM API; OpenStack Keystone v3 API integrates user/project/role in assignments (e.g., POST /v3/role_assignments).
Instance Types
→ Rumble: Flavors
high4 diffs›
Instance Types
→ Rumble: Flavors
- •Fixed predefined configurations only; no custom flavor creation.
- •Extensive families for GPU/HPC/ARM etc.
- •InstanceType as string param in API, not ID reference.
- •Tied to specific hardware generations (Nitro/Xen).
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
high4 diffs›
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
- •AWS has no subscription concept. Billing is per AWS Account. Multiple accounts can be grouped under AWS Organizations with consolidated billing where the payer account receives a single invoice. OpenStack projects are resource boundaries within a single Keystone domain with no native billing hierarchy.
- •AWS accounts are completely isolated resource boundaries; resources do not cross account boundaries without explicit cross-account IAM roles and resource policies. OpenStack projects are resource boundaries within a shared Keystone domain, with cross-project access via role assignments.
- •AWS Organizations allows Service Control Policies (SCPs) applied at the organizational unit level, restricting what IAM policies can grant. OpenStack has no equivalent cascading policy restriction mechanism across projects.
- •AWS account-level service quotas are separate from organizational-level limits and must be increased per account. OpenStack project quotas are set per project by the admin.
NAT Gateway
→ Rumble: NAT
high4 diffs›
NAT Gateway
→ Rumble: NAT
- •AWS managed HA per AZ hourly/GB.
- •OpenStack router SNAT L3 agent/OVN.
- •OpenStack basic SNAT.
- •OpenStack router-limited.
Placement Groups
→ Rumble: Server groups
high4 diffs›
Placement Groups
→ Rumble: Server groups
- •Policies: cluster/partition/spread vs affinity/anti-affinity.
- •AZ-scoped, no instance moves/merges.
- •Specified at launch via PlacementGroupName.
- •Max 7 partitions per AZ for partition type.
Route Tables
→ Rumble: Routers
high4 diffs›
Route Tables
→ Rumble: Routers
- •AWS per subnet/VPC main.
- •OpenStack L3 routers distributed/central.
- •AWS local intra-VPC implicit.
- •OpenStack BGP-LS opt.
S3 Versioning
→ Rumble: Versioning
high4 diffs›
S3 Versioning
→ Rumble: Versioning
- •Supported via S3 API (enable/suspend, list/delete versions); counts all versions toward quota.
- •Console shows only latest size, no version listing.
- •Once enabled, cannot disable (only suspend, like S3).
- •Standard OpenStack Swift S3 behavior; no MFA Delete mentioned.
Security Groups
→ Rumble: Security groups
high4 diffs›
Security Groups
→ Rumble: Security groups
- •AWS stateful auto-response.
- •OpenStack stateless explicit.
- •OpenStack port/project.
- •AWS default inbound deny/outbound all.
Server-Side Encryption
→ Rumble: Encryption
high4 diffs›
Server-Side Encryption
→ Rumble: Encryption
- •SSE-C (customer keys, AES256) and SSE-OMK (Quake AI-managed AES256 per-object keys with root rotation).
- •No SSE-S3 or SSE-KMS; SSE-OMK differs (unique keys, no AWS KMS).
- •SSE-C: ETag not MD5 (salted hash), metadata retrieval needs key.
- •HTTPS required; per-version keys if versioning enabled.
Stacks
→ Rumble: Automation
high4 diffs›
Stacks
→ Rumble: Automation
- •Quake AI offers Heat (legacy OpenStack orchestration) and recommends OpenTofu for new IaC work; EKS uses declarative console/CLI.
- •EKS Auto Mode automates data plane; Quake AI uses OpenTofu modules for infrastructure provisioning.
- •CloudFormation stacks are managed via AWS-specific REST API (e.g., cloudformation.us-east-1.amazonaws.com) requiring AWS SigV4 auth, while Heat (legacy) uses OpenStack Identity API v3 (keystoneauth) and OpenTofu uses the OpenStack provider with application credentials. Migrators notice different endpoint discovery and auth flows.
- •Stacks support StackSets for cross-region/account deployment; Heat has no equivalent. OpenTofu workspaces offer a different multi-environment pattern.
Subnets
→ Rumble: Subnets
high4 diffs›
Subnets
→ Rumble: Subnets
- •AWS subnets single AZ.
- •AWS public/private by routes.
- •OpenStack by network type.
- •AWS IPv6-only; OpenStack dual-stack.
Terraform AWS provider
→ Rumble: Terraform
high2 diffs›
Terraform AWS provider
→ Rumble: Terraform
- •Uses aws_instance resource with AMI IDs; OpenStack uses openstack_compute_instance_v2 with image names/IDs.
- •AWS provider uses access_key/secret_key; OpenStack provider uses application credentials or Keystone tokens.
Block storage· 35 mappings
Access Control Lists (ACLs)
→ Rumble: Access control
high4 diffs›
Access Control Lists (ACLs)
→ Rumble: Access control
- •Limited to basic public/private via console; advanced via S3 bucket policies (JSON) emulating IAM.
- •No native ACL support like canned ACLs or fine-grained grantee permissions (Swift S3: Advanced ACLs No).
- •ARN uses project/tenant name instead of AWS account ID.
- •Relies on Ceph API for some user perms; bucket policies only for S3 API.
Accounts
→ Rumble: Projects
high4 diffs›
Accounts
→ Rumble: Projects
- •OpenStack Projects provide resource isolation (VMs, storage) within a single Keystone deployment; AWS Accounts are full billing/security boundaries requiring Organizations for multi-account management.
- •Projects in OS are lightweight, created via Keystone API; AWS Accounts involve separate signup or Organizations API, with inherent billing isolation.
- •Architecture: OS projects owned by domains; AWS accounts grouped in OUs under management account.
- •No direct API equivalence; OS list_projects vs AWS ListAccounts in Organizations service.
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
high4 diffs›
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
- •Direct same-AZ copy only; requires source encrypted, size >= source; background initialization with instant low-latency access.
- •One-time fee per GiB copied at init + standard volume charges; Cinder no standard fee.
- •Max 5 in-progress per Region, one per source at a time; Cinder scheduler-dependent.
- •Independent volume post-init, no ongoing link; Cinder may use COW depending on driver.
Amazon EBS volumes
→ Rumble: Volumes
high4 diffs›
Amazon EBS volumes
→ Rumble: Volumes
- •Strictly bound to a single Availability Zone where created; cannot be moved without snapshot.
- •Multiple volume types (gp3, io2, st1) with different performance/billing characteristics; Cinder uses volume_types but backend-defined.
- •Billed per provisioned GB-month regardless of usage; OpenStack typically quota-based without standard usage billing.
- •API via EC2 CreateVolume; differs from Cinder create_volume.
Amazon EC2
→ Rumble: Compute
›
Amazon EC2
→ Rumble: Compute
No specific divergences documented yet.
View AWS docs →Amazon EKS Cluster
→ Rumble: Kubernetes
high4 diffs›
Amazon EKS Cluster
→ Rumble: Kubernetes
- •EKS control plane fully AWS-managed, single-tenant, across 3 AZs with auto scale/replace; on Quake AI you run the control plane on Nova instances, provisioned through Magnum or self-managed with OpenTofu, and you operate it.
- •EKS regional API endpoint with SLA; Quake AI exposes the kube API via Neutron LB with floating IP.
- •EKS charges a per-hour cluster platform fee on top of the underlying compute; Quake AI charges only for underlying Nova/Neutron/Cinder resources with no K8s platform fee.
- •EKS managed nodes auto AMI updates, Spot integration; Quake AI self-managed nodes require manual OS image selection and update management.
Amazon Machine Images (AMIs)
→ Rumble: Images
high4 diffs›
Amazon Machine Images (AMIs)
→ Rumble: Images
- •Managed via EC2 APIs, not Glance.
- •Region-specific with cross-region copy.
- •Marketplace AMIs may charge hourly fees.
- •Includes block device mapping in AMI.
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
›
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
No specific divergences documented yet.
View AWS docs →Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
high4 diffs›
Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
- •AWS S3 is the reference protocol; Quake AI exposes S3 compatibility via OpenStack Swift s3api middleware over Ceph. Several S3 operations are unsupported by Swift s3api: S3 Select, Bucket Notifications, S3 Website hosting, Transfer Acceleration, and advanced ACLs.
- •AWS SigV4 is supported by Swift s3api, but presigned URL features and IAM bucket policies with complex condition keys are not implemented.
- •AWS S3 bucket namespace is global per AWS account; on Quake AI, buckets are scoped to the OpenStack project and endpoint is provider-defined (not s3.amazonaws.com).
- •S3 storage class transitions (Intelligent-Tiering, Glacier, One Zone-IA) have no equivalent in Swift; all Quake AI objects remain in a single storage tier.
Amazon Virtual Private Cloud
→ Rumble: Networks
high4 diffs›
Amazon Virtual Private Cloud
→ Rumble: Networks
- •AWS VPC is regional with CIDR /16-/28.
- •OpenStack Networks project-scoped L2 with flexible CIDR.
- •AWS requires IGW for public.
- •OpenStack provider nets or floating IPs.
Amazon VPC + VPC CNI
→ Rumble: Networking
high3 diffs›
Amazon VPC + VPC CNI
→ Rumble: Networking
- •Quake AI uses per-cluster private networks and routers for Kubernetes; EKS uses a customer VPC with ENI pod networking.
- •Quake AI K8s uses Flannel/Calico/Cilium CNI on Neutron; EKS uses VPC CNI with prefix delegation.
- •EKS bills cross-AZ control traffic; OpenStack no.
AWS API Changelog
→ Rumble: API
high1 diff›
AWS API Changelog
→ Rumble: API
- •AWS publishes API changes through What's New feed and service-specific changelogs; Quake AI uses a unified api-changelog page
AWS API Changelog
→ Rumble: API versioning
›
AWS API Changelog
→ Rumble: API versioning
No specific divergences documented yet.
View AWS docs →AWS Billing and Cost Management
→ Rumble: Billing
high4 diffs›
AWS Billing and Cost Management
→ Rumble: Billing
- •AWS has native consolidated billing via Organizations (single bill for all accounts); OpenStack has no standard billing service—usage metered via Ceilometer but billing is external/provider-implemented.
- •Cost allocation: AWS uses cost categories/tags, Cost Explorer; OS relies on custom integrations.
- •Architecture: AWS payer account charges; OS per-project quotas but billing not core.
- •No API equivalence; AWS Billing APIs for reports/budgets, OS no core billing API.
AWS Organizations
→ Rumble: Organizations
high4 diffs›
AWS Organizations
→ Rumble: Organizations
- •AWS Organizations provides hierarchical OUs, SCPs for governance, consolidated billing; OpenStack lacks native multi-deployment orgs, uses Keystone domains/projects for isolation but no built-in billing consolidation across deployments.
- •Billing model: AWS management account pays for all members; OpenStack billing is provider-specific, often per-project quotas but no standard consolidated billing service.
- •Policies: AWS SCPs limit max permissions; OS uses role assignments without equivalent guardrails.
- •API: AWS CreateOrganization, ListOrganizationalUnits; OS no equivalent, managed via Keystone domains.
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
high4 diffs›
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
- •AWS bills EC2 Linux instances per second with a 60-second minimum. Pricing is not embedded in the Nova/flavor API; AWS instance pricing requires querying the AWS Price List API (GET /offers/v1.0/aws/AmazonEC2/current/index.json) or the Pricing Calculator.
- •AWS pricing varies by region, instance type, tenancy, and OS; there are no monthly price caps. Hetzner and some OpenStack clouds offer monthly price caps per server.
- •AWS does not include outbound data transfer in instance pricing; egress is billed separately per-GB with a small free-tier allowance. Quake AI's egress pricing is operator-defined. See the AWS pricing page for current rates.
- •AWS offers reserved instances (1-year/3-year commitments), savings plans, and spot pricing as distinct purchasing models not available in standard OpenStack deployments.
AWS Security Pillar
→ Rumble: Security
›
AWS Security Pillar
→ Rumble: Security
No specific divergences documented yet.
View AWS docs →EBS Snapshots
→ Rumble: Snapshots
high4 diffs›
EBS Snapshots
→ Rumble: Snapshots
- •Per-EBS volume, incremental in S3; not full instance image.
- •Via EC2 CreateSnapshot API, not Nova/Cinder.
- •Async pending state, volume usable during snapshot.
- •Billed per GB-month stored.
EC2 Instances
→ Rumble: Instances
high4 diffs›
EC2 Instances
→ Rumble: Instances
- •Uses EC2 RunInstances API instead of Nova servers.create.
- •Requires predefined instance type selection.
- •Supports per-second On-Demand billing and Spot/Reserved options.
- •Includes hibernation state not standard in OpenStack.
EC2 Key Pairs
→ Rumble: Key pairs
high4 diffs›
EC2 Key Pairs
→ Rumble: Key pairs
- •Public key auto-injected to authorized_keys at boot.
- •Up to 5000 per region; AWS stores public key.
- •Supports import of external keys (RSA/ED25519).
- •No post-launch addition without userdata/SSM.
Elastic IP addresses
→ Rumble: Floating IPs
high4 diffs›
Elastic IP addresses
→ Rumble: Floating IPs
- •AWS charges idle EIPs.
- •OpenStack floating IPs free/pool-limited.
- •AWS regional instance/ENI.
- •OpenStack project port.
Elastic Load Balancing
→ Rumble: Load balancer
high4 diffs›
Elastic Load Balancing
→ Rumble: Load balancer
- •Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
- •AWS hourly/LCU billing.
- •OpenStack VM billing.
- •AWS global endpoints.
Elastic Network Interfaces
→ Rumble: Ports
›
Elastic Network Interfaces
→ Rumble: Ports
No specific divergences documented yet.
View AWS docs →IAM Users
→ Rumble: Authentication
high4 diffs›
IAM Users
→ Rumble: Authentication
- •AWS IAM Users are tied exclusively to one AWS account with no native multi-account scoping without Organizations; OpenStack users exist in domains and get scoped to multiple projects via role assignments, allowing flexible multi-tenancy within a deployment.
- •AWS emphasizes long-term credentials like access keys/passwords but strongly recommends federation/temporary creds for humans; OpenStack uses short-lived, scoped tokens natively.
- •Naming: AWS ARNs like arn:aws:iam::ACCOUNT:user/NAME; OpenStack uses user@domain scoped to project@domain.
- •API differences: AWS uses CreateUser, ListUsers in IAM API; OpenStack Keystone v3 API integrates user/project/role in assignments (e.g., POST /v3/role_assignments).
Instance Types
→ Rumble: Flavors
high4 diffs›
Instance Types
→ Rumble: Flavors
- •Fixed predefined configurations only; no custom flavor creation.
- •Extensive families for GPU/HPC/ARM etc.
- •InstanceType as string param in API, not ID reference.
- •Tied to specific hardware generations (Nitro/Xen).
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
high4 diffs›
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
- •AWS has no subscription concept. Billing is per AWS Account. Multiple accounts can be grouped under AWS Organizations with consolidated billing where the payer account receives a single invoice. OpenStack projects are resource boundaries within a single Keystone domain with no native billing hierarchy.
- •AWS accounts are completely isolated resource boundaries; resources do not cross account boundaries without explicit cross-account IAM roles and resource policies. OpenStack projects are resource boundaries within a shared Keystone domain, with cross-project access via role assignments.
- •AWS Organizations allows Service Control Policies (SCPs) applied at the organizational unit level, restricting what IAM policies can grant. OpenStack has no equivalent cascading policy restriction mechanism across projects.
- •AWS account-level service quotas are separate from organizational-level limits and must be increased per account. OpenStack project quotas are set per project by the admin.
NAT Gateway
→ Rumble: NAT
high4 diffs›
NAT Gateway
→ Rumble: NAT
- •AWS managed HA per AZ hourly/GB.
- •OpenStack router SNAT L3 agent/OVN.
- •OpenStack basic SNAT.
- •OpenStack router-limited.
Placement Groups
→ Rumble: Server groups
high4 diffs›
Placement Groups
→ Rumble: Server groups
- •Policies: cluster/partition/spread vs affinity/anti-affinity.
- •AZ-scoped, no instance moves/merges.
- •Specified at launch via PlacementGroupName.
- •Max 7 partitions per AZ for partition type.
Route Tables
→ Rumble: Routers
high4 diffs›
Route Tables
→ Rumble: Routers
- •AWS per subnet/VPC main.
- •OpenStack L3 routers distributed/central.
- •AWS local intra-VPC implicit.
- •OpenStack BGP-LS opt.
S3 Versioning
→ Rumble: Versioning
high4 diffs›
S3 Versioning
→ Rumble: Versioning
- •Supported via S3 API (enable/suspend, list/delete versions); counts all versions toward quota.
- •Console shows only latest size, no version listing.
- •Once enabled, cannot disable (only suspend, like S3).
- •Standard OpenStack Swift S3 behavior; no MFA Delete mentioned.
Security Groups
→ Rumble: Security groups
high4 diffs›
Security Groups
→ Rumble: Security groups
- •AWS stateful auto-response.
- •OpenStack stateless explicit.
- •OpenStack port/project.
- •AWS default inbound deny/outbound all.
Server-Side Encryption
→ Rumble: Encryption
high4 diffs›
Server-Side Encryption
→ Rumble: Encryption
- •SSE-C (customer keys, AES256) and SSE-OMK (Quake AI-managed AES256 per-object keys with root rotation).
- •No SSE-S3 or SSE-KMS; SSE-OMK differs (unique keys, no AWS KMS).
- •SSE-C: ETag not MD5 (salted hash), metadata retrieval needs key.
- •HTTPS required; per-version keys if versioning enabled.
Stacks
→ Rumble: Automation
high4 diffs›
Stacks
→ Rumble: Automation
- •Quake AI offers Heat (legacy OpenStack orchestration) and recommends OpenTofu for new IaC work; EKS uses declarative console/CLI.
- •EKS Auto Mode automates data plane; Quake AI uses OpenTofu modules for infrastructure provisioning.
- •CloudFormation stacks are managed via AWS-specific REST API (e.g., cloudformation.us-east-1.amazonaws.com) requiring AWS SigV4 auth, while Heat (legacy) uses OpenStack Identity API v3 (keystoneauth) and OpenTofu uses the OpenStack provider with application credentials. Migrators notice different endpoint discovery and auth flows.
- •Stacks support StackSets for cross-region/account deployment; Heat has no equivalent. OpenTofu workspaces offer a different multi-environment pattern.
Subnets
→ Rumble: Subnets
high4 diffs›
Subnets
→ Rumble: Subnets
- •AWS subnets single AZ.
- •AWS public/private by routes.
- •OpenStack by network type.
- •AWS IPv6-only; OpenStack dual-stack.
Terraform AWS provider
→ Rumble: Terraform
high2 diffs›
Terraform AWS provider
→ Rumble: Terraform
- •Uses aws_instance resource with AMI IDs; OpenStack uses openstack_compute_instance_v2 with image names/IDs.
- •AWS provider uses access_key/secret_key; OpenStack provider uses application credentials or Keystone tokens.
Kubernetes· 35 mappings
Access Control Lists (ACLs)
→ Rumble: Access control
high4 diffs›
Access Control Lists (ACLs)
→ Rumble: Access control
- •Limited to basic public/private via console; advanced via S3 bucket policies (JSON) emulating IAM.
- •No native ACL support like canned ACLs or fine-grained grantee permissions (Swift S3: Advanced ACLs No).
- •ARN uses project/tenant name instead of AWS account ID.
- •Relies on Ceph API for some user perms; bucket policies only for S3 API.
Accounts
→ Rumble: Projects
high4 diffs›
Accounts
→ Rumble: Projects
- •OpenStack Projects provide resource isolation (VMs, storage) within a single Keystone deployment; AWS Accounts are full billing/security boundaries requiring Organizations for multi-account management.
- •Projects in OS are lightweight, created via Keystone API; AWS Accounts involve separate signup or Organizations API, with inherent billing isolation.
- •Architecture: OS projects owned by domains; AWS accounts grouped in OUs under management account.
- •No direct API equivalence; OS list_projects vs AWS ListAccounts in Organizations service.
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
high4 diffs›
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
- •Direct same-AZ copy only; requires source encrypted, size >= source; background initialization with instant low-latency access.
- •One-time fee per GiB copied at init + standard volume charges; Cinder no standard fee.
- •Max 5 in-progress per Region, one per source at a time; Cinder scheduler-dependent.
- •Independent volume post-init, no ongoing link; Cinder may use COW depending on driver.
Amazon EBS volumes
→ Rumble: Volumes
high4 diffs›
Amazon EBS volumes
→ Rumble: Volumes
- •Strictly bound to a single Availability Zone where created; cannot be moved without snapshot.
- •Multiple volume types (gp3, io2, st1) with different performance/billing characteristics; Cinder uses volume_types but backend-defined.
- •Billed per provisioned GB-month regardless of usage; OpenStack typically quota-based without standard usage billing.
- •API via EC2 CreateVolume; differs from Cinder create_volume.
Amazon EC2
→ Rumble: Compute
›
Amazon EC2
→ Rumble: Compute
No specific divergences documented yet.
View AWS docs →Amazon EKS Cluster
→ Rumble: Kubernetes
high4 diffs›
Amazon EKS Cluster
→ Rumble: Kubernetes
- •EKS control plane fully AWS-managed, single-tenant, across 3 AZs with auto scale/replace; on Quake AI you run the control plane on Nova instances, provisioned through Magnum or self-managed with OpenTofu, and you operate it.
- •EKS regional API endpoint with SLA; Quake AI exposes the kube API via Neutron LB with floating IP.
- •EKS charges a per-hour cluster platform fee on top of the underlying compute; Quake AI charges only for underlying Nova/Neutron/Cinder resources with no K8s platform fee.
- •EKS managed nodes auto AMI updates, Spot integration; Quake AI self-managed nodes require manual OS image selection and update management.
Amazon Machine Images (AMIs)
→ Rumble: Images
high4 diffs›
Amazon Machine Images (AMIs)
→ Rumble: Images
- •Managed via EC2 APIs, not Glance.
- •Region-specific with cross-region copy.
- •Marketplace AMIs may charge hourly fees.
- •Includes block device mapping in AMI.
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
›
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
No specific divergences documented yet.
View AWS docs →Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
high4 diffs›
Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
- •AWS S3 is the reference protocol; Quake AI exposes S3 compatibility via OpenStack Swift s3api middleware over Ceph. Several S3 operations are unsupported by Swift s3api: S3 Select, Bucket Notifications, S3 Website hosting, Transfer Acceleration, and advanced ACLs.
- •AWS SigV4 is supported by Swift s3api, but presigned URL features and IAM bucket policies with complex condition keys are not implemented.
- •AWS S3 bucket namespace is global per AWS account; on Quake AI, buckets are scoped to the OpenStack project and endpoint is provider-defined (not s3.amazonaws.com).
- •S3 storage class transitions (Intelligent-Tiering, Glacier, One Zone-IA) have no equivalent in Swift; all Quake AI objects remain in a single storage tier.
Amazon Virtual Private Cloud
→ Rumble: Networks
high4 diffs›
Amazon Virtual Private Cloud
→ Rumble: Networks
- •AWS VPC is regional with CIDR /16-/28.
- •OpenStack Networks project-scoped L2 with flexible CIDR.
- •AWS requires IGW for public.
- •OpenStack provider nets or floating IPs.
Amazon VPC + VPC CNI
→ Rumble: Networking
high3 diffs›
Amazon VPC + VPC CNI
→ Rumble: Networking
- •Quake AI uses per-cluster private networks and routers for Kubernetes; EKS uses a customer VPC with ENI pod networking.
- •Quake AI K8s uses Flannel/Calico/Cilium CNI on Neutron; EKS uses VPC CNI with prefix delegation.
- •EKS bills cross-AZ control traffic; OpenStack no.
AWS API Changelog
→ Rumble: API
high1 diff›
AWS API Changelog
→ Rumble: API
- •AWS publishes API changes through What's New feed and service-specific changelogs; Quake AI uses a unified api-changelog page
AWS API Changelog
→ Rumble: API versioning
›
AWS API Changelog
→ Rumble: API versioning
No specific divergences documented yet.
View AWS docs →AWS Billing and Cost Management
→ Rumble: Billing
high4 diffs›
AWS Billing and Cost Management
→ Rumble: Billing
- •AWS has native consolidated billing via Organizations (single bill for all accounts); OpenStack has no standard billing service—usage metered via Ceilometer but billing is external/provider-implemented.
- •Cost allocation: AWS uses cost categories/tags, Cost Explorer; OS relies on custom integrations.
- •Architecture: AWS payer account charges; OS per-project quotas but billing not core.
- •No API equivalence; AWS Billing APIs for reports/budgets, OS no core billing API.
AWS Organizations
→ Rumble: Organizations
high4 diffs›
AWS Organizations
→ Rumble: Organizations
- •AWS Organizations provides hierarchical OUs, SCPs for governance, consolidated billing; OpenStack lacks native multi-deployment orgs, uses Keystone domains/projects for isolation but no built-in billing consolidation across deployments.
- •Billing model: AWS management account pays for all members; OpenStack billing is provider-specific, often per-project quotas but no standard consolidated billing service.
- •Policies: AWS SCPs limit max permissions; OS uses role assignments without equivalent guardrails.
- •API: AWS CreateOrganization, ListOrganizationalUnits; OS no equivalent, managed via Keystone domains.
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
high4 diffs›
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
- •AWS bills EC2 Linux instances per second with a 60-second minimum. Pricing is not embedded in the Nova/flavor API; AWS instance pricing requires querying the AWS Price List API (GET /offers/v1.0/aws/AmazonEC2/current/index.json) or the Pricing Calculator.
- •AWS pricing varies by region, instance type, tenancy, and OS; there are no monthly price caps. Hetzner and some OpenStack clouds offer monthly price caps per server.
- •AWS does not include outbound data transfer in instance pricing; egress is billed separately per-GB with a small free-tier allowance. Quake AI's egress pricing is operator-defined. See the AWS pricing page for current rates.
- •AWS offers reserved instances (1-year/3-year commitments), savings plans, and spot pricing as distinct purchasing models not available in standard OpenStack deployments.
AWS Security Pillar
→ Rumble: Security
›
AWS Security Pillar
→ Rumble: Security
No specific divergences documented yet.
View AWS docs →EBS Snapshots
→ Rumble: Snapshots
high4 diffs›
EBS Snapshots
→ Rumble: Snapshots
- •Per-EBS volume, incremental in S3; not full instance image.
- •Via EC2 CreateSnapshot API, not Nova/Cinder.
- •Async pending state, volume usable during snapshot.
- •Billed per GB-month stored.
EC2 Instances
→ Rumble: Instances
high4 diffs›
EC2 Instances
→ Rumble: Instances
- •Uses EC2 RunInstances API instead of Nova servers.create.
- •Requires predefined instance type selection.
- •Supports per-second On-Demand billing and Spot/Reserved options.
- •Includes hibernation state not standard in OpenStack.
EC2 Key Pairs
→ Rumble: Key pairs
high4 diffs›
EC2 Key Pairs
→ Rumble: Key pairs
- •Public key auto-injected to authorized_keys at boot.
- •Up to 5000 per region; AWS stores public key.
- •Supports import of external keys (RSA/ED25519).
- •No post-launch addition without userdata/SSM.
Elastic IP addresses
→ Rumble: Floating IPs
high4 diffs›
Elastic IP addresses
→ Rumble: Floating IPs
- •AWS charges idle EIPs.
- •OpenStack floating IPs free/pool-limited.
- •AWS regional instance/ENI.
- •OpenStack project port.
Elastic Load Balancing
→ Rumble: Load balancer
high4 diffs›
Elastic Load Balancing
→ Rumble: Load balancer
- •Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
- •AWS hourly/LCU billing.
- •OpenStack VM billing.
- •AWS global endpoints.
Elastic Network Interfaces
→ Rumble: Ports
›
Elastic Network Interfaces
→ Rumble: Ports
No specific divergences documented yet.
View AWS docs →IAM Users
→ Rumble: Authentication
high4 diffs›
IAM Users
→ Rumble: Authentication
- •AWS IAM Users are tied exclusively to one AWS account with no native multi-account scoping without Organizations; OpenStack users exist in domains and get scoped to multiple projects via role assignments, allowing flexible multi-tenancy within a deployment.
- •AWS emphasizes long-term credentials like access keys/passwords but strongly recommends federation/temporary creds for humans; OpenStack uses short-lived, scoped tokens natively.
- •Naming: AWS ARNs like arn:aws:iam::ACCOUNT:user/NAME; OpenStack uses user@domain scoped to project@domain.
- •API differences: AWS uses CreateUser, ListUsers in IAM API; OpenStack Keystone v3 API integrates user/project/role in assignments (e.g., POST /v3/role_assignments).
Instance Types
→ Rumble: Flavors
high4 diffs›
Instance Types
→ Rumble: Flavors
- •Fixed predefined configurations only; no custom flavor creation.
- •Extensive families for GPU/HPC/ARM etc.
- •InstanceType as string param in API, not ID reference.
- •Tied to specific hardware generations (Nitro/Xen).
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
high4 diffs›
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
- •AWS has no subscription concept. Billing is per AWS Account. Multiple accounts can be grouped under AWS Organizations with consolidated billing where the payer account receives a single invoice. OpenStack projects are resource boundaries within a single Keystone domain with no native billing hierarchy.
- •AWS accounts are completely isolated resource boundaries; resources do not cross account boundaries without explicit cross-account IAM roles and resource policies. OpenStack projects are resource boundaries within a shared Keystone domain, with cross-project access via role assignments.
- •AWS Organizations allows Service Control Policies (SCPs) applied at the organizational unit level, restricting what IAM policies can grant. OpenStack has no equivalent cascading policy restriction mechanism across projects.
- •AWS account-level service quotas are separate from organizational-level limits and must be increased per account. OpenStack project quotas are set per project by the admin.
NAT Gateway
→ Rumble: NAT
high4 diffs›
NAT Gateway
→ Rumble: NAT
- •AWS managed HA per AZ hourly/GB.
- •OpenStack router SNAT L3 agent/OVN.
- •OpenStack basic SNAT.
- •OpenStack router-limited.
Placement Groups
→ Rumble: Server groups
high4 diffs›
Placement Groups
→ Rumble: Server groups
- •Policies: cluster/partition/spread vs affinity/anti-affinity.
- •AZ-scoped, no instance moves/merges.
- •Specified at launch via PlacementGroupName.
- •Max 7 partitions per AZ for partition type.
Route Tables
→ Rumble: Routers
high4 diffs›
Route Tables
→ Rumble: Routers
- •AWS per subnet/VPC main.
- •OpenStack L3 routers distributed/central.
- •AWS local intra-VPC implicit.
- •OpenStack BGP-LS opt.
S3 Versioning
→ Rumble: Versioning
high4 diffs›
S3 Versioning
→ Rumble: Versioning
- •Supported via S3 API (enable/suspend, list/delete versions); counts all versions toward quota.
- •Console shows only latest size, no version listing.
- •Once enabled, cannot disable (only suspend, like S3).
- •Standard OpenStack Swift S3 behavior; no MFA Delete mentioned.
Security Groups
→ Rumble: Security groups
high4 diffs›
Security Groups
→ Rumble: Security groups
- •AWS stateful auto-response.
- •OpenStack stateless explicit.
- •OpenStack port/project.
- •AWS default inbound deny/outbound all.
Server-Side Encryption
→ Rumble: Encryption
high4 diffs›
Server-Side Encryption
→ Rumble: Encryption
- •SSE-C (customer keys, AES256) and SSE-OMK (Quake AI-managed AES256 per-object keys with root rotation).
- •No SSE-S3 or SSE-KMS; SSE-OMK differs (unique keys, no AWS KMS).
- •SSE-C: ETag not MD5 (salted hash), metadata retrieval needs key.
- •HTTPS required; per-version keys if versioning enabled.
Stacks
→ Rumble: Automation
high4 diffs›
Stacks
→ Rumble: Automation
- •Quake AI offers Heat (legacy OpenStack orchestration) and recommends OpenTofu for new IaC work; EKS uses declarative console/CLI.
- •EKS Auto Mode automates data plane; Quake AI uses OpenTofu modules for infrastructure provisioning.
- •CloudFormation stacks are managed via AWS-specific REST API (e.g., cloudformation.us-east-1.amazonaws.com) requiring AWS SigV4 auth, while Heat (legacy) uses OpenStack Identity API v3 (keystoneauth) and OpenTofu uses the OpenStack provider with application credentials. Migrators notice different endpoint discovery and auth flows.
- •Stacks support StackSets for cross-region/account deployment; Heat has no equivalent. OpenTofu workspaces offer a different multi-environment pattern.
Subnets
→ Rumble: Subnets
high4 diffs›
Subnets
→ Rumble: Subnets
- •AWS subnets single AZ.
- •AWS public/private by routes.
- •OpenStack by network type.
- •AWS IPv6-only; OpenStack dual-stack.
Terraform AWS provider
→ Rumble: Terraform
high2 diffs›
Terraform AWS provider
→ Rumble: Terraform
- •Uses aws_instance resource with AMI IDs; OpenStack uses openstack_compute_instance_v2 with image names/IDs.
- •AWS provider uses access_key/secret_key; OpenStack provider uses application credentials or Keystone tokens.
Automation· 35 mappings
Access Control Lists (ACLs)
→ Rumble: Access control
high4 diffs›
Access Control Lists (ACLs)
→ Rumble: Access control
- •Limited to basic public/private via console; advanced via S3 bucket policies (JSON) emulating IAM.
- •No native ACL support like canned ACLs or fine-grained grantee permissions (Swift S3: Advanced ACLs No).
- •ARN uses project/tenant name instead of AWS account ID.
- •Relies on Ceph API for some user perms; bucket policies only for S3 API.
Accounts
→ Rumble: Projects
high4 diffs›
Accounts
→ Rumble: Projects
- •OpenStack Projects provide resource isolation (VMs, storage) within a single Keystone deployment; AWS Accounts are full billing/security boundaries requiring Organizations for multi-account management.
- •Projects in OS are lightweight, created via Keystone API; AWS Accounts involve separate signup or Organizations API, with inherent billing isolation.
- •Architecture: OS projects owned by domains; AWS accounts grouped in OUs under management account.
- •No direct API equivalence; OS list_projects vs AWS ListAccounts in Organizations service.
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
high4 diffs›
Amazon EBS Volume Copies (Clones)
→ Rumble: Clones
- •Direct same-AZ copy only; requires source encrypted, size >= source; background initialization with instant low-latency access.
- •One-time fee per GiB copied at init + standard volume charges; Cinder no standard fee.
- •Max 5 in-progress per Region, one per source at a time; Cinder scheduler-dependent.
- •Independent volume post-init, no ongoing link; Cinder may use COW depending on driver.
Amazon EBS volumes
→ Rumble: Volumes
high4 diffs›
Amazon EBS volumes
→ Rumble: Volumes
- •Strictly bound to a single Availability Zone where created; cannot be moved without snapshot.
- •Multiple volume types (gp3, io2, st1) with different performance/billing characteristics; Cinder uses volume_types but backend-defined.
- •Billed per provisioned GB-month regardless of usage; OpenStack typically quota-based without standard usage billing.
- •API via EC2 CreateVolume; differs from Cinder create_volume.
Amazon EC2
→ Rumble: Compute
›
Amazon EC2
→ Rumble: Compute
No specific divergences documented yet.
View AWS docs →Amazon EKS Cluster
→ Rumble: Kubernetes
high4 diffs›
Amazon EKS Cluster
→ Rumble: Kubernetes
- •EKS control plane fully AWS-managed, single-tenant, across 3 AZs with auto scale/replace; on Quake AI you run the control plane on Nova instances, provisioned through Magnum or self-managed with OpenTofu, and you operate it.
- •EKS regional API endpoint with SLA; Quake AI exposes the kube API via Neutron LB with floating IP.
- •EKS charges a per-hour cluster platform fee on top of the underlying compute; Quake AI charges only for underlying Nova/Neutron/Cinder resources with no K8s platform fee.
- •EKS managed nodes auto AMI updates, Spot integration; Quake AI self-managed nodes require manual OS image selection and update management.
Amazon Machine Images (AMIs)
→ Rumble: Images
high4 diffs›
Amazon Machine Images (AMIs)
→ Rumble: Images
- •Managed via EC2 APIs, not Glance.
- •Region-specific with cross-region copy.
- •Marketplace AMIs may charge hourly fees.
- •Includes block device mapping in AMI.
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
›
Amazon Machine Images (AMIs)
→ Rumble: Snapshots
No specific divergences documented yet.
View AWS docs →Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
high4 diffs›
Amazon S3 (native reference implementation)
→ Rumble: S3 compatibility
- •AWS S3 is the reference protocol; Quake AI exposes S3 compatibility via OpenStack Swift s3api middleware over Ceph. Several S3 operations are unsupported by Swift s3api: S3 Select, Bucket Notifications, S3 Website hosting, Transfer Acceleration, and advanced ACLs.
- •AWS SigV4 is supported by Swift s3api, but presigned URL features and IAM bucket policies with complex condition keys are not implemented.
- •AWS S3 bucket namespace is global per AWS account; on Quake AI, buckets are scoped to the OpenStack project and endpoint is provider-defined (not s3.amazonaws.com).
- •S3 storage class transitions (Intelligent-Tiering, Glacier, One Zone-IA) have no equivalent in Swift; all Quake AI objects remain in a single storage tier.
Amazon Virtual Private Cloud
→ Rumble: Networks
high4 diffs›
Amazon Virtual Private Cloud
→ Rumble: Networks
- •AWS VPC is regional with CIDR /16-/28.
- •OpenStack Networks project-scoped L2 with flexible CIDR.
- •AWS requires IGW for public.
- •OpenStack provider nets or floating IPs.
Amazon VPC + VPC CNI
→ Rumble: Networking
high3 diffs›
Amazon VPC + VPC CNI
→ Rumble: Networking
- •Quake AI uses per-cluster private networks and routers for Kubernetes; EKS uses a customer VPC with ENI pod networking.
- •Quake AI K8s uses Flannel/Calico/Cilium CNI on Neutron; EKS uses VPC CNI with prefix delegation.
- •EKS bills cross-AZ control traffic; OpenStack no.
AWS API Changelog
→ Rumble: API
high1 diff›
AWS API Changelog
→ Rumble: API
- •AWS publishes API changes through What's New feed and service-specific changelogs; Quake AI uses a unified api-changelog page
AWS API Changelog
→ Rumble: API versioning
›
AWS API Changelog
→ Rumble: API versioning
No specific divergences documented yet.
View AWS docs →AWS Billing and Cost Management
→ Rumble: Billing
high4 diffs›
AWS Billing and Cost Management
→ Rumble: Billing
- •AWS has native consolidated billing via Organizations (single bill for all accounts); OpenStack has no standard billing service—usage metered via Ceilometer but billing is external/provider-implemented.
- •Cost allocation: AWS uses cost categories/tags, Cost Explorer; OS relies on custom integrations.
- •Architecture: AWS payer account charges; OS per-project quotas but billing not core.
- •No API equivalence; AWS Billing APIs for reports/budgets, OS no core billing API.
AWS Organizations
→ Rumble: Organizations
high4 diffs›
AWS Organizations
→ Rumble: Organizations
- •AWS Organizations provides hierarchical OUs, SCPs for governance, consolidated billing; OpenStack lacks native multi-deployment orgs, uses Keystone domains/projects for isolation but no built-in billing consolidation across deployments.
- •Billing model: AWS management account pays for all members; OpenStack billing is provider-specific, often per-project quotas but no standard consolidated billing service.
- •Policies: AWS SCPs limit max permissions; OS uses role assignments without equivalent guardrails.
- •API: AWS CreateOrganization, ListOrganizationalUnits; OS no equivalent, managed via Keystone domains.
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
high4 diffs›
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
- •AWS bills EC2 Linux instances per second with a 60-second minimum. Pricing is not embedded in the Nova/flavor API; AWS instance pricing requires querying the AWS Price List API (GET /offers/v1.0/aws/AmazonEC2/current/index.json) or the Pricing Calculator.
- •AWS pricing varies by region, instance type, tenancy, and OS; there are no monthly price caps. Hetzner and some OpenStack clouds offer monthly price caps per server.
- •AWS does not include outbound data transfer in instance pricing; egress is billed separately per-GB with a small free-tier allowance. Quake AI's egress pricing is operator-defined. See the AWS pricing page for current rates.
- •AWS offers reserved instances (1-year/3-year commitments), savings plans, and spot pricing as distinct purchasing models not available in standard OpenStack deployments.
AWS Security Pillar
→ Rumble: Security
›
AWS Security Pillar
→ Rumble: Security
No specific divergences documented yet.
View AWS docs →EBS Snapshots
→ Rumble: Snapshots
high4 diffs›
EBS Snapshots
→ Rumble: Snapshots
- •Per-EBS volume, incremental in S3; not full instance image.
- •Via EC2 CreateSnapshot API, not Nova/Cinder.
- •Async pending state, volume usable during snapshot.
- •Billed per GB-month stored.
EC2 Instances
→ Rumble: Instances
high4 diffs›
EC2 Instances
→ Rumble: Instances
- •Uses EC2 RunInstances API instead of Nova servers.create.
- •Requires predefined instance type selection.
- •Supports per-second On-Demand billing and Spot/Reserved options.
- •Includes hibernation state not standard in OpenStack.
EC2 Key Pairs
→ Rumble: Key pairs
high4 diffs›
EC2 Key Pairs
→ Rumble: Key pairs
- •Public key auto-injected to authorized_keys at boot.
- •Up to 5000 per region; AWS stores public key.
- •Supports import of external keys (RSA/ED25519).
- •No post-launch addition without userdata/SSM.
Elastic IP addresses
→ Rumble: Floating IPs
high4 diffs›
Elastic IP addresses
→ Rumble: Floating IPs
- •AWS charges idle EIPs.
- •OpenStack floating IPs free/pool-limited.
- •AWS regional instance/ENI.
- •OpenStack project port.
Elastic Load Balancing
→ Rumble: Load balancer
high4 diffs›
Elastic Load Balancing
→ Rumble: Load balancer
- •Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
- •AWS hourly/LCU billing.
- •OpenStack VM billing.
- •AWS global endpoints.
Elastic Network Interfaces
→ Rumble: Ports
›
Elastic Network Interfaces
→ Rumble: Ports
No specific divergences documented yet.
View AWS docs →IAM Users
→ Rumble: Authentication
high4 diffs›
IAM Users
→ Rumble: Authentication
- •AWS IAM Users are tied exclusively to one AWS account with no native multi-account scoping without Organizations; OpenStack users exist in domains and get scoped to multiple projects via role assignments, allowing flexible multi-tenancy within a deployment.
- •AWS emphasizes long-term credentials like access keys/passwords but strongly recommends federation/temporary creds for humans; OpenStack uses short-lived, scoped tokens natively.
- •Naming: AWS ARNs like arn:aws:iam::ACCOUNT:user/NAME; OpenStack uses user@domain scoped to project@domain.
- •API differences: AWS uses CreateUser, ListUsers in IAM API; OpenStack Keystone v3 API integrates user/project/role in assignments (e.g., POST /v3/role_assignments).
Instance Types
→ Rumble: Flavors
high4 diffs›
Instance Types
→ Rumble: Flavors
- •Fixed predefined configurations only; no custom flavor creation.
- •Extensive families for GPU/HPC/ARM etc.
- •InstanceType as string param in API, not ID reference.
- •Tied to specific hardware generations (Nitro/Xen).
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
high4 diffs›
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
- •AWS has no subscription concept. Billing is per AWS Account. Multiple accounts can be grouped under AWS Organizations with consolidated billing where the payer account receives a single invoice. OpenStack projects are resource boundaries within a single Keystone domain with no native billing hierarchy.
- •AWS accounts are completely isolated resource boundaries; resources do not cross account boundaries without explicit cross-account IAM roles and resource policies. OpenStack projects are resource boundaries within a shared Keystone domain, with cross-project access via role assignments.
- •AWS Organizations allows Service Control Policies (SCPs) applied at the organizational unit level, restricting what IAM policies can grant. OpenStack has no equivalent cascading policy restriction mechanism across projects.
- •AWS account-level service quotas are separate from organizational-level limits and must be increased per account. OpenStack project quotas are set per project by the admin.
NAT Gateway
→ Rumble: NAT
high4 diffs›
NAT Gateway
→ Rumble: NAT
- •AWS managed HA per AZ hourly/GB.
- •OpenStack router SNAT L3 agent/OVN.
- •OpenStack basic SNAT.
- •OpenStack router-limited.
Placement Groups
→ Rumble: Server groups
high4 diffs›
Placement Groups
→ Rumble: Server groups
- •Policies: cluster/partition/spread vs affinity/anti-affinity.
- •AZ-scoped, no instance moves/merges.
- •Specified at launch via PlacementGroupName.
- •Max 7 partitions per AZ for partition type.
Route Tables
→ Rumble: Routers
high4 diffs›
Route Tables
→ Rumble: Routers
- •AWS per subnet/VPC main.
- •OpenStack L3 routers distributed/central.
- •AWS local intra-VPC implicit.
- •OpenStack BGP-LS opt.
S3 Versioning
→ Rumble: Versioning
high4 diffs›
S3 Versioning
→ Rumble: Versioning
- •Supported via S3 API (enable/suspend, list/delete versions); counts all versions toward quota.
- •Console shows only latest size, no version listing.
- •Once enabled, cannot disable (only suspend, like S3).
- •Standard OpenStack Swift S3 behavior; no MFA Delete mentioned.
Security Groups
→ Rumble: Security groups
high4 diffs›
Security Groups
→ Rumble: Security groups
- •AWS stateful auto-response.
- •OpenStack stateless explicit.
- •OpenStack port/project.
- •AWS default inbound deny/outbound all.
Server-Side Encryption
→ Rumble: Encryption
high4 diffs›
Server-Side Encryption
→ Rumble: Encryption
- •SSE-C (customer keys, AES256) and SSE-OMK (Quake AI-managed AES256 per-object keys with root rotation).
- •No SSE-S3 or SSE-KMS; SSE-OMK differs (unique keys, no AWS KMS).
- •SSE-C: ETag not MD5 (salted hash), metadata retrieval needs key.
- •HTTPS required; per-version keys if versioning enabled.
Stacks
→ Rumble: Automation
high4 diffs›
Stacks
→ Rumble: Automation
- •Quake AI offers Heat (legacy OpenStack orchestration) and recommends OpenTofu for new IaC work; EKS uses declarative console/CLI.
- •EKS Auto Mode automates data plane; Quake AI uses OpenTofu modules for infrastructure provisioning.
- •CloudFormation stacks are managed via AWS-specific REST API (e.g., cloudformation.us-east-1.amazonaws.com) requiring AWS SigV4 auth, while Heat (legacy) uses OpenStack Identity API v3 (keystoneauth) and OpenTofu uses the OpenStack provider with application credentials. Migrators notice different endpoint discovery and auth flows.
- •Stacks support StackSets for cross-region/account deployment; Heat has no equivalent. OpenTofu workspaces offer a different multi-environment pattern.
Subnets
→ Rumble: Subnets
high4 diffs›
Subnets
→ Rumble: Subnets
- •AWS subnets single AZ.
- •AWS public/private by routes.
- •OpenStack by network type.
- •AWS IPv6-only; OpenStack dual-stack.
Terraform AWS provider
→ Rumble: Terraform
high2 diffs›
Terraform AWS provider
→ Rumble: Terraform
- •Uses aws_instance resource with AMI IDs; OpenStack uses openstack_compute_instance_v2 with image names/IDs.
- •AWS provider uses access_key/secret_key; OpenStack provider uses application credentials or Keystone tokens.
Account· 3 mappings
Accounts
→ Rumble: Projects
high4 diffs›
Accounts
→ Rumble: Projects
- •OpenStack Projects provide resource isolation (VMs, storage) within a single Keystone deployment; AWS Accounts are full billing/security boundaries requiring Organizations for multi-account management.
- •Projects in OS are lightweight, created via Keystone API; AWS Accounts involve separate signup or Organizations API, with inherent billing isolation.
- •Architecture: OS projects owned by domains; AWS accounts grouped in OUs under management account.
- •No direct API equivalence; OS list_projects vs AWS ListAccounts in Organizations service.
AWS Organizations
→ Rumble: Organizations
high4 diffs›
AWS Organizations
→ Rumble: Organizations
- •AWS Organizations provides hierarchical OUs, SCPs for governance, consolidated billing; OpenStack lacks native multi-deployment orgs, uses Keystone domains/projects for isolation but no built-in billing consolidation across deployments.
- •Billing model: AWS management account pays for all members; OpenStack billing is provider-specific, often per-project quotas but no standard consolidated billing service.
- •Policies: AWS SCPs limit max permissions; OS uses role assignments without equivalent guardrails.
- •API: AWS CreateOrganization, ListOrganizationalUnits; OS no equivalent, managed via Keystone domains.
IAM Users
→ Rumble: Authentication
high4 diffs›
IAM Users
→ Rumble: Authentication
- •AWS IAM Users are tied exclusively to one AWS account with no native multi-account scoping without Organizations; OpenStack users exist in domains and get scoped to multiple projects via role assignments, allowing flexible multi-tenancy within a deployment.
- •AWS emphasizes long-term credentials like access keys/passwords but strongly recommends federation/temporary creds for humans; OpenStack uses short-lived, scoped tokens natively.
- •Naming: AWS ARNs like arn:aws:iam::ACCOUNT:user/NAME; OpenStack uses user@domain scoped to project@domain.
- •API differences: AWS uses CreateUser, ListUsers in IAM API; OpenStack Keystone v3 API integrates user/project/role in assignments (e.g., POST /v3/role_assignments).
Billing· 3 mappings
AWS Billing and Cost Management
→ Rumble: Billing
high4 diffs›
AWS Billing and Cost Management
→ Rumble: Billing
- •AWS has native consolidated billing via Organizations (single bill for all accounts); OpenStack has no standard billing service—usage metered via Ceilometer but billing is external/provider-implemented.
- •Cost allocation: AWS uses cost categories/tags, Cost Explorer; OS relies on custom integrations.
- •Architecture: AWS payer account charges; OS per-project quotas but billing not core.
- •No API equivalence; AWS Billing APIs for reports/budgets, OS no core billing API.
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
high4 diffs›
AWS Pay-As-You-Go (per-second billing, 60-second minimum for Linux EC2)
→ Rumble: Pricing
- •AWS bills EC2 Linux instances per second with a 60-second minimum. Pricing is not embedded in the Nova/flavor API; AWS instance pricing requires querying the AWS Price List API (GET /offers/v1.0/aws/AmazonEC2/current/index.json) or the Pricing Calculator.
- •AWS pricing varies by region, instance type, tenancy, and OS; there are no monthly price caps. Hetzner and some OpenStack clouds offer monthly price caps per server.
- •AWS does not include outbound data transfer in instance pricing; egress is billed separately per-GB with a small free-tier allowance. Quake AI's egress pricing is operator-defined. See the AWS pricing page for current rates.
- •AWS offers reserved instances (1-year/3-year commitments), savings plans, and spot pricing as distinct purchasing models not available in standard OpenStack deployments.
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
high4 diffs›
N/A (No subscription concept — AWS Accounts with optional consolidated billing via AWS Organizations)
→ Rumble: Subscriptions
- •AWS has no subscription concept. Billing is per AWS Account. Multiple accounts can be grouped under AWS Organizations with consolidated billing where the payer account receives a single invoice. OpenStack projects are resource boundaries within a single Keystone domain with no native billing hierarchy.
- •AWS accounts are completely isolated resource boundaries; resources do not cross account boundaries without explicit cross-account IAM roles and resource policies. OpenStack projects are resource boundaries within a shared Keystone domain, with cross-project access via role assignments.
- •AWS Organizations allows Service Control Policies (SCPs) applied at the organizational unit level, restricting what IAM policies can grant. OpenStack has no equivalent cascading policy restriction mechanism across projects.
- •AWS account-level service quotas are separate from organizational-level limits and must be increased per account. OpenStack project quotas are set per project by the admin.
Platform· 2 mappings
AWS API Changelog
→ Rumble: API versioning
›
AWS API Changelog
→ Rumble: API versioning
No specific divergences documented yet.
View AWS docs →AWS Security Pillar
→ Rumble: Security
›
AWS Security Pillar
→ Rumble: Security
No specific divergences documented yet.
View AWS docs →Tools· 1 mapping
AWS API Changelog
→ Rumble: API
high1 diff›
AWS API Changelog
→ Rumble: API
- •AWS publishes API changes through What's New feed and service-specific changelogs; Quake AI uses a unified api-changelog page
Self-managed services and deployment patterns#
Quake AI provides infrastructure primitives. Application-level managed services are not part of the platform.
| AWS service | Status on Quake AI | Alternative |
|---|---|---|
| Lambda / serverless | Not available | Containers on VMs or Kubernetes |
| RDS / Aurora | Not available | Self-managed PostgreSQL or MySQL on a VM |
| DynamoDB | Not available | Self-managed Redis, MongoDB, or PostgreSQL |
| SQS / SNS | Not available | Self-managed RabbitMQ, Redis, or NATS |
| CloudWatch | Not available | Self-managed Prometheus + Grafana |
| Route 53 | Not available | External DNS provider (Cloudflare or similar) |
| Cognito | Not available | Self-managed auth (Keycloak, Auth0, or similar) |
For the full comparison, see Coming from AWS: What Quake AI does not have.
Next steps#
- Coming from AWS: concept translation reference
- Infrastructure as Code with OpenTofu
- Resource tiers: Developer Plan details and upgrade paths
- All migration guides
Usage Guidelines
The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.
Comparisons to third-party providers in this material reflect publicly documented behavior as of the validation date below. Pricing, quotas, service limits, and feature availability change frequently on every cloud. Verify provider-specific claims against the provider's own current documentation before relying on them for a procurement, architecture, or migration decision.
For the full policy, see Usage Guidelines.
Last validated: 22.06.2026
See Also
Migrating from Azure to Quake AI
Shares: Automation, Migration
Migrating from DigitalOcean to Quake AI
Shares: Automation, Migration
Migrating from GCP to Quake AI
Shares: Automation, Migration
Migrating from Hetzner Cloud to Quake AI
Shares: Automation, Migration
Migrating from Linode (Akamai Cloud Computing) to Quake AI
Shares: Automation, Migration