Migrate from AWS EC2 to Quake AI compute

You use this guide to move virtual machine workloads from AWS EC2 to Quake AI (OpenStack Nova). For most workloads, you rebuild and rsync: you provision a fresh Nova instance, install your application stack, and transfer data. You can export custom AMIs, but the pipeline adds complexity and often takes longer than rebuild and rsync.

Service mapping#

Prerequisites#

• A Quake AI account with application credentials
• The OpenStack CLI installed and configured
• SSH access to your EC2 instances
• An SSH key pair imported to Quake AI (openstack keypair create --public-key)

Image portability#

AWS supports exporting custom AMIs to S3 in VMDK, VHD, or RAW format using the aws ec2 export-image command. Downloaded images require conversion to QCOW2 before uploading to Glance.

aws ec2 export-image \
  --image-id MY_AMI_ID \
  --disk-image-format RAW \
  --s3-export-location S3Bucket=MY_EXPORT_BUCKET,S3Prefix=exports/

# Download from S3, convert to QCOW2
qemu-img convert -f raw -O qcow2 MY_EXPORTED_RAW MY_OUTPUT_QCOW2

# Upload to Glance
openstack image create MY_IMAGE_NAME \
  --disk-format qcow2 --container-format bare \
  --file MY_OUTPUT_QCOW2

When to use image export: Only for custom AMIs with significant baked-in software that would take longer to rebuild than to export, convert, and upload. The pipeline adds 30-60 minutes per image depending on size. For most workloads, rebuild and rsync is faster.

Flavor mapping#

AWS instance families map to Quake AI flavor families by their RAM-to-vCPU ratio. M-series (general purpose, 4:1) maps to m2a, C-series (compute optimized, 2:1) maps to c2a, R-series (memory optimized, 8:1) maps to r2a, and T-series (burstable) maps to s1a for light workloads.

T-series instances at high sustained utilization should move to m2a rather than s1a, since T-series bursting masks continuous CPU demand.

The same vCPU-to-RAM ratios apply to newer instance generations (m7i, c7i, r7i). Choose the Quake AI flavor based on the ratio, not the generation number.

Migration approach#

Option 1: Containerized workloads (recommended)#

If your EC2 workloads run in Docker or on ECS/EKS, migrate the container images and redeploy.

1. Push images from ECR to a portable registry (Docker Hub, GitHub Container Registry, or self-hosted):

docker pull MY_ACCOUNT_ID.dkr.ecr.MY_AWS_REGION.amazonaws.com/MY_APP:latest
docker tag MY_ACCOUNT_ID.dkr.ecr.MY_AWS_REGION.amazonaws.com/MY_APP:latest \
  MY_REGISTRY/MY_APP:latest
docker push MY_REGISTRY/MY_APP:latest

1. Provision a Nova instance on Quake AI:

openstack server create \
  --image "Ubuntu-22.04" \
  --flavor m2a.xlarge \
  --network MY_NETWORK \
  --key-name MY_KEY \
  --security-group MY_SECURITY_GROUP \
  MY_INSTANCE_NAME

1. Install Docker and deploy:

ssh ubuntu@FLOATING_IP
sudo apt update && sudo apt install -y docker.io
sudo docker pull MY_REGISTRY/MY_APP:latest
sudo docker run -d -p 80:8080 MY_REGISTRY/MY_APP:latest

Option 2: Rebuild and rsync (non-containerized)#

For traditional application stacks, provision a fresh instance and transfer data.

1. Provision a Nova instance with the same base OS:

openstack server create \
  --image "Ubuntu-22.04" \
  --flavor m2a.xlarge \
  --network MY_NETWORK \
  --key-name MY_KEY \
  --security-group MY_SECURITY_GROUP \
  MY_INSTANCE_NAME

1. Assign a floating IP for SSH access:

openstack floating ip create PublicStatic
openstack server add floating ip MY_INSTANCE_NAME FLOATING_IP

1. Install your application stack on the Quake AI instance. Reuse existing cloud-init configs, Ansible playbooks, or shell scripts.

2. Transfer application data from the EC2 instance:

rsync -avz --progress -e "ssh -i ~/.ssh/MY_KEY" \
  ubuntu@EC2_PUBLIC_IP:/path/to/app/data \
  ubuntu@FLOATING_IP:/path/to/app/data

1. Migrate databases:

# PostgreSQL
pg_dump -h EC2_PUBLIC_IP -U MY_USER MY_DATABASE | \
  psql -h FLOATING_IP -U MY_USER MY_DATABASE

# MySQL
mysqldump -h EC2_PUBLIC_IP -u MY_USER -p MY_DATABASE | \
  mysql -h FLOATING_IP -u MY_USER -p MY_DATABASE

Key pair and security setup#

Import your SSH key#

If you already have an SSH key pair used with EC2, import the public key to Quake AI:

openstack keypair create --public-key ~/.ssh/id_ed25519.pub MY_KEY

Or generate a new key pair:

openstack keypair create MY_KEY > MY_KEY.pem
chmod 600 MY_KEY.pem

Recreate security groups#

EC2 security groups map closely to Neutron security groups. Both default to deny-inbound, allow-outbound. Translate your rules with the same protocol, port, and CIDR values:

openstack security group create web-tier
openstack security group rule create web-tier \
  --protocol tcp --dst-port 22 --remote-ip 0.0.0.0/0
openstack security group rule create web-tier \
  --protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0
openstack security group rule create web-tier \
  --protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0

Validation checklist#

After migrating each workload, verify:

• Application responds correctly on the Quake AI instance
• All expected ports are accessible through the security group
• Data integrity: compare file checksums or row counts between source and destination
• Database connectivity from the application to any migrated databases
• DNS records updated to point to the new Quake AI floating IP
• Monitoring in place (self-managed Prometheus + Grafana to replace CloudWatch)
• cloud-init or configuration management runs cleanly on the new instance
• SSL/TLS certificates installed and renewed with Let's Encrypt, Certbot, or your chosen certificate service

Provider-specific gotchas#

See also#

• Migrating from AWS to Quake AI: full cross-service migration hub
• Coming from AWS: concept translation reference
• Create an instance: full instance provisioning workflow
• Compute migration guides: all provider guides