# Migrating from AWS to Quake AI Source: https://docs.quake.ai/docs/platform/migration/from-aws Markdown: https://docs.quake.ai/docs/platform/migration/from-aws.md --- # 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](/docs/platform/migration/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](/docs/platform/migration/coming-from-aws) to understand how AWS services map to Quake AI - Check [Quake AI pricing](https://www.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](/docs/quickstart) - [Generate application credentials](/docs/platform/access/generate-app-credentials) - [Access & Credentials](/docs/platform/access/) 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..rumble.cloud`, so most AWS tooling works with an endpoint and credential change. Replace `` 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](/docs/object/migration/migrate-from-s3). ### 4. Infrastructure as Code (CloudFormation → OpenTofu) If you use CloudFormation or CDK, the target is [OpenTofu](https://opentofu.org/) (or Terraform) with the [`openstack` provider](https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs). 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](/docs/automation/migration/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](/docs/compute/migration/migrate-docker-app-from-aws) 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](/docs/kubernetes/migration/migrate-from-eks) 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](/docs/compute/how-to/create-instance) for the full workflow. For the full guide, see [Migrate from EC2 to Quake AI Compute](/docs/compute/migration/migrate-from-ec2). ### 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: - [Create a network](/docs/network/how-to/create-network) - [Create a security group](/docs/network/how-to/create-security-group) - [Allocate floating IPs](/docs/network/how-to/allocate-floating-ips) For topology diagrams, three-tier security rule translation, and public-address migration, see [Migrate from AWS VPC to Quake AI](/docs/network/migration/migrate-from-aws-vpc). Translate ALB routes and targets into an [edge reverse proxy](/build/iac-templates/edge-reverse-proxy) or [API gateway](/build/iac-templates/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 `` component reads from the platform knowledge graph. ## 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](/docs/platform/migration/coming-from-aws#what-rumble-does-not-have). ## Next steps - [Coming from AWS](/docs/platform/migration/coming-from-aws): concept translation reference - [Infrastructure as Code with OpenTofu](/docs/automation/how-to/getting-started-iac) - [Resource tiers](/docs/platform/account/resource-tiers): Developer Plan details and upgrade paths - [All migration guides](/docs/platform/migration)