# Migrate from AWS EC2 to Quake AI compute

Source: https://docs.quake.ai/docs/compute/migration/migrate-from-ec2
Markdown: https://docs.quake.ai/docs/compute/migration/migrate-from-ec2.md

---

# 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

<MigrationTable provider="aws" service="compute" />


## Prerequisites

- A Quake AI account with [application credentials](/docs/tools/generate-app-credentials)
- The [OpenStack CLI](/docs/tools/install-openstack-client) 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.

```bash
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
```



Marketplace AMIs, Windows/SQL Server images, and images with encrypted EBS snapshots cannot be exported. Standard OS images (Ubuntu, Debian, Rocky Linux) are available as Quake AI public images and do not need to be exported.



**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.

| AWS Instance Type | vCPUs | RAM (GiB) | Quake AI Flavor | vCPUs | RAM (GiB) | Notes |
|---|---|---|---|---|---|---|
| t3.micro | 2 | 1 | s1a.micro | 1 | 1 | Burstable → shared; fewer vCPUs on Quake AI |
| t3.medium | 2 | 4 | s1a.medium | 2 | 4 | Both 2 vCPU / 4 GiB |
| t3.large | 2 | 8 | m2a.large | 2 | 8 | Exact ratio match |
| m6i.large | 2 | 8 | m2a.large | 2 | 8 | Exact ratio match |
| m6i.xlarge | 4 | 16 | m2a.xlarge | 4 | 16 | Exact ratio match |
| m6i.2xlarge | 8 | 32 | m2a.2xlarge | 8 | 32 | Exact ratio match |
| m6i.4xlarge | 16 | 64 | m2a.4xlarge | 16 | 64 | Exact ratio match |
| m6i.8xlarge | 32 | 128 | m2a.8xlarge | 32 | 128 | Exact ratio match |
| m6i.16xlarge | 64 | 256 | m2a.16xlarge | 64 | 256 | Exact ratio match |
| c6i.large | 2 | 4 | c2a.large | 2 | 4 | Exact ratio match |
| c6i.xlarge | 4 | 8 | c2a.xlarge | 4 | 8 | Exact ratio match |
| c6i.2xlarge | 8 | 16 | c2a.2xlarge | 8 | 16 | Exact ratio match |
| c6i.4xlarge | 16 | 32 | c2a.4xlarge | 16 | 32 | Exact ratio match |
| r6i.large | 2 | 16 | r2a.large | 2 | 16 | Exact ratio match |
| r6i.xlarge | 4 | 32 | r2a.xlarge | 4 | 32 | Exact ratio match |
| r6i.2xlarge | 8 | 64 | r2a.2xlarge | 8 | 64 | Exact ratio match |
| r6i.4xlarge | 16 | 128 | r2a.4xlarge | 16 | 128 | Exact ratio match |

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):

```bash
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
```

2. Provision a Nova instance on Quake AI:

```bash
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
```

3. Install Docker and deploy:

```bash
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:

```bash
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
```

2. Assign a floating IP for SSH access:

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

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

4. Transfer application data from the EC2 instance:

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

5. Migrate databases:

```bash
# 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
```



AWS bills egress per-GB after a small free allowance. For large data transfers, budget for this cost. AWS offers a free data transfer waiver for customers migrating away, but it is not automatic: you must contact AWS Support to request it, and AWS reviews each request at the account level. See the [AWS free egress program blog post](https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-internet-when-moving-out-of-aws/) and the [AWS pricing page](https://aws.amazon.com/pricing/).



## 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:

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

Or generate a new key pair:

```bash
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:

```bash
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
```



AWS NACLs (network ACLs) have no Neutron equivalent. NACLs are stateless and support deny rules with priority ordering. If your security posture relies on NACLs, translate the intent into Neutron security group rules (allow-only, stateful). See the [network migration guide](/docs/network/migration/migrate-from-aws-vpc) for full security rule translation.



## 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

| Topic | Detail |
|---|---|
| Egress costs | AWS bills egress per-GB after a small free allowance. AWS offers a free egress waiver for migrations, but you must request it from AWS Support; it is not automatic. See [AWS pricing](https://aws.amazon.com/pricing/). |
| Reserved Instances | Check for active RI or Savings Plan commitments before decommissioning. Break fees may apply. |
| Marketplace AMIs | Cannot be exported. Rebuild from scratch with equivalent open-source software. |
| IAM credentials | AWS IAM has no Quake AI equivalent. Switch to [OpenStack application credentials](/docs/tools/generate-app-credentials). |
| Instance metadata | Both use the `169.254.169.254` metadata endpoint. AWS-specific keys (instance profile, IAM role) do not exist on OpenStack. cloud-init is compatible, but remove EC2-specific datasource references. AWS IMDSv2 uses session-oriented PUT+GET requests; OpenStack uses the older GET-only (IMDSv1-style) interface. Applications that enforce IMDSv2 need changes on Quake AI. |
| EBS volumes | No direct volume export. Attach, mount, and rsync data to a Cinder volume on Quake AI. |
| Elastic IPs | AWS Elastic IPs cannot be transferred. Update DNS to point to new Quake AI floating IPs during cutover. Use low TTLs during the transition. |
| Secondary ENIs | Multiple ENIs for network isolation or failover have no direct equivalent. Replicate the topology using Neutron ports and multiple security groups. |
| Windows licensing | BYOL from Software Assurance is required. Cloud-only Windows licenses are provider-locked and cannot transfer. |

## See also

- [Migrating from AWS to Quake AI](/resources/migration/from-aws): full cross-service migration hub
- [Coming from AWS](/resources/migration/coming-from-aws): concept translation reference
- [Create an instance](/docs/compute/how-to/create-instance): full instance provisioning workflow
- [Compute migration guides](/docs/compute/migration): all provider guides