# Coming from AWS

Source: https://docs.quake.ai/docs/platform/migration/coming-from-aws
Markdown: https://docs.quake.ai/docs/platform/migration/coming-from-aws.md

---

# Coming from AWS

If you have been using AWS, here is how Quake AI maps to what you already know. Quake AI runs on [OpenStack](/docs/platform/migration/openstack): the services below expose standard OpenStack APIs with upstream documentation. When a CLI command, error message, or Terraform resource uses a project name like Nova or Neutron, refer to [How Quake AI uses OpenStack](/docs/platform/migration/openstack) for the full mapping table.

## Quick reference

| AWS | Quake AI | OpenStack project | Key difference |
|---|---|---|---|
| EC2 Instance | Instance | Nova | Flavor model vs instance types; fixed monthly pricing, no per-second billing |
| S3 Bucket | Container | Swift | S3-compatible API; endpoint change for most tools |
| IAM Role / Policy | Application Credential | Keystone | Project-scoped, not account-wide; no policy language |
| VPC | Network | Neutron | Subnet-router-port model; no IGW, NAT gateway, or route table management |
| Security Group | Security Group | Neutron | Nearly identical concept; applied per-instance; no cross-account references |
| CloudFormation / CDK | Heat Stack / OpenTofu | Heat | HOT YAML templates; OpenTofu fits new projects |
| ELB (ALB / NLB / GWLB) | Self-managed edge proxy or API gateway | Nova + Neutron | Run Caddy, SafeLine, or APISIX on a VM with a floating IP |
| EKS | Kubernetes Cluster | Magnum | Managed control plane; worker nodes are Nova instances |
| EBS Volume | Volume | Cinder | Same attach/detach model; NVMe at all tiers |
| AWS Account | Project | Keystone | Project is the billing and resource isolation unit |

## Compute: EC2 → Nova instances

**What maps directly:** You still launch virtual machines from images, attach networks and volumes, and use SSH keys for access. The Compute service ([OpenStack Nova](https://docs.openstack.org/nova/latest/)) owns the same lifecycle operations you expect from EC2.

**What is different:** AWS publishes hundreds of instance types with per-second billing, Spot, and Reserved options. Quake AI exposes a curated catalog of **flavors** (for example, `m2a.large` for 2 vCPU and 8 GiB RAM on a general-purpose shape) with **fixed monthly pricing** tied to your resource tier: there is no per-second meter and no Spot market. Capacity planning maps to flavor + quota, not to a long instance-type catalog. See [Flavors](/docs/compute/concepts/flavors) for sizes and families.

Create a server with the OpenStack CLI (Nova):

```bash
openstack server create \
  --flavor m2a.large \
  --image "Ubuntu 24.04" \
  --network PublicEphemeral \
  --key-name MY_KEY \
  my-server
```

For the full workflow, see [Create an instance](/docs/compute/how-to/create-instance). For workload migration steps, see [Migrate from EC2](/docs/compute/migration/migrate-from-ec2).

## Object storage: S3 → Swift (S3-compatible)

**What maps directly:** You store objects in containers (the S3 “bucket” analog), use keys and prefixes, and talk to an S3-compatible API. Object storage is backed by [OpenStack Swift](https://docs.openstack.org/swift/latest/).

**What is different:** AWS S3 adds lifecycle policies, event notifications, and rich bucket policies. Quake AI exposes an S3-compatible endpoint at `object.us-east-2.rumble.cloud`: boto3, aws-cli, rclone, and s3cmd work when you point them at that endpoint. You do not get S3 lifecycle rules, S3 event notifications, or AWS-style bucket policy documents; behavior is defined by Swift and the S3 gateway layer. S3 Express One Zone (high-performance directory buckets) is a separate AWS product with no Quake AI equivalent.

```python
import boto3

client = boto3.client(
    "s3",
    endpoint_url="https://object.us-east-2.rumble.cloud",
    aws_access_key_id="ACCESS_KEY_ID",
    aws_secret_access_key="SECRET_ACCESS_KEY",
    region_name="REGION",
)

client.list_buckets()
```


  Replace `ACCESS_KEY_ID`, `SECRET_ACCESS_KEY`, and `REGION` with values from your Quake AI object storage credentials. The endpoint hostname is the technical contract: without it, SDKs default to AWS and fail authentication.


Read [Object storage](/docs/object) and [Migrate from S3](/docs/object/migration/migrate-from-s3) for compatibility detail and cutover steps.

## Identity: IAM → Keystone application credentials

**What maps directly:** You still authenticate principals, rotate secrets, and scope access to a project. Identity is handled by [OpenStack Keystone](https://docs.openstack.org/keystone/latest/).

**What is different:** AWS IAM is a policy language with JSON documents, resource-level grants, roles, users, and groups spanning an organization. Quake AI uses **project-scoped application credentials** and three roles: `admin`, `member`, and `reader`. **No IAM-style policy language exists**; authorization is coarser, so you isolate blast radius with separate projects rather than writing fine-grained policy documents.


  Treat each Quake AI **project** as its own trust boundary. Split production, staging, and tooling into different projects when you need separation that AWS would have expressed with policies.


Generate credentials in the Console: [Generate application credentials](/docs/platform/access/generate-app-credentials).

## Networking: VPC → Neutron networks

**What maps directly:** You still define private address space, attach instances to subnets, and control reachability with routing and security groups. The Network service is backed by [OpenStack Neutron](https://docs.openstack.org/neutron/latest/).

**What is different:** A classic AWS VPC layers subnets, an internet gateway, NAT gateways, route tables, and optional NACLs. On Quake AI you create a **network**, attach a **subnet**, and connect it to a **router**. **No internet gateway object exists**; routers attach to the external network directly. For basic outbound internet access you do not manage NAT gateways or route tables the way you do in a default VPC mental model.

See [Networks](/docs/network/concepts/networks) for the topology Quake AI expects. For network migration steps, see [Migrate from AWS VPC](/docs/network/migration/migrate-from-aws-vpc).

## Security groups: same concept, different API

**What maps directly:** Security groups still default to **deny inbound** and **allow outbound**, and you express rules as protocol, port, and remote CIDR. The same Neutron security group objects apply whether you attach them during instance creation (Nova) or to ports (Neutron).

**What is different:** The API surface is OpenStack, not EC2 `AuthorizeSecurityGroupIngress`. Rule bodies use **UUIDs** for group references and **remote_ip_prefix** for CIDRs. The semantics match AWS closely enough that most migration work is re-creating the same port/CIDR matrix under new IDs. One AWS feature has no Neutron equivalent: cross-account security group references (rules that point at another security group by ID across accounts). Neutron security groups are project-scoped, so express that isolation with project boundaries instead.

Compare the CLIs: on AWS you might run `aws ec2 authorize-security-group-ingress` with group IDs and `--ip-permissions`. On Quake AI you add rules with Neutron:

```bash
openstack security group rule create \
  --protocol tcp \
  --dst-port 443 \
  --remote-ip 0.0.0.0/0 \
  SECURITY_GROUP_NAME_OR_ID
```

Follow [Create a security group](/docs/network/how-to/create-security-group).

## Automation: CloudFormation → Heat / OpenTofu

**What maps directly:** You still declare infrastructure as structured templates and apply them as atomic stacks. [OpenStack Heat](https://docs.openstack.org/heat/latest/) is the native orchestrator; templates use **HOT** (Heat Orchestration Template) YAML with types such as `OS::Nova::Server`.

**What is different:** AWS CloudFormation and CDK compile down to service-specific resources with deep AWS coupling. On Quake AI, **OpenTofu** (or Terraform) with the [`openstack` provider](https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs) is the usual path for new projects: it is broadly compatible with Terraform for the `openstack` provider, and most existing Terraform configurations port without changes. OpenTofu and Terraform have diverged since the fork, so complex configurations that rely on HashiCorp-specific features may need review; the `openstack` provider itself works the same on both tools. Heat remains available for stack-native workflows.

```hcl
resource "openstack_compute_instance_v2" "web" {
  name            = "web-01"
  flavor_name     = "m2a.large"
  image_name      = "Ubuntu 24.04"
  key_pair        = "MY_KEY"
  security_groups = ["default"]

  network {
    name = "PublicEphemeral"
  }
}
```

Start with [Infrastructure as Code with OpenTofu](/docs/automation/concepts/terraform) and, if you are translating templates, [Migrate from AWS CloudFormation](/docs/automation/migration/from-aws-cloudformation).

## Load balancing: ELB to a self-managed edge

ELB concepts still apply at the application edge: terminate traffic, define backends, and health-check them. On Quake AI, run an [edge reverse proxy](/build/iac-templates/edge-reverse-proxy), [edge WAF](/build/iac-templates/edge-waf), or [API gateway](/build/iac-templates/api-gateway) on a VM with a floating IP.

Translate ALB listeners and target groups into routes, backend lists, and health checks. Caddy handles automatic HTTPS, SafeLine adds application-layer filtering, and APISIX adds API routing and rate limits. Network Load Balancer and Gateway Load Balancer features require software appliances or an external service selected for the protocol and throughput your workload needs.

## Kubernetes: EKS → Magnum

**What maps directly:** You get a Kubernetes API, worker nodes, and cluster-scoped objects. Clusters are provisioned through [OpenStack Magnum](https://docs.openstack.org/magnum/latest/).

**What is different:** EKS separates the control plane (managed by AWS) from managed node groups or Fargate profiles. Magnum gives you a **managed control plane** from a **cluster template**, but **worker nodes are Nova instances** you size, patch, and scale: there is **no Fargate-style serverless worker** equivalent. You choose a template (Kubernetes version, COE driver, network integration) and Magnum wires the cluster API to Nova for nodes.

Cluster operations and templates are covered in [Kubernetes](/docs/kubernetes). For cluster migration steps, see [Migrate from EKS](/docs/kubernetes/migration/migrate-from-eks).

## Block storage: EBS → Cinder volumes

**What maps directly:** You create volumes, attach them to one instance at a time, snapshot, and detach. Block storage is backed by [OpenStack Cinder](https://docs.openstack.org/cinder/latest/).

**What is different:** AWS segments EBS into gp3, io2, st1, and other types with provisioned IOPS tiers. Quake AI exposes **Cinder volumes backed by NVMe at every tier** with the same attach/detach workflow: there are **no separate IOPS SKUs**; performance characteristics are uniform across the offering described in docs.

Create a volume, then attach it to a running instance (Cinder):

```bash
openstack volume create --size VOLUME_SIZE_GB MY_VOLUME
openstack server add volume INSTANCE_NAME_OR_ID MY_VOLUME
```

See [Create a volume](/docs/block/how-to/create-volume).

## Account model: AWS account to Quake AI project

**What maps directly:** You still have users, credentials, and a boundary that owns resources and billing records.

**What is different:** AWS nests accounts under Organizations with centralized IAM. On Quake AI, the **project** is the **billing and resource isolation unit**, typically **one project per resource tier**. Keystone holds users and roles **inside** that project instead of spanning a multi-account org tree.

Account structure is summarized in [Account](/docs/platform/account).

## Self-managed services and deployment patterns

Quake AI provides infrastructure primitives: compute, networking, storage, Kubernetes, and automation. Application-level managed services are not part of the platform. You compose your own stack from these primitives, using the same open-source tools you already know.

| AWS service | Status on Quake AI | Alternative |
|---|---|---|
| Lambda / serverless | Not available | Run containers on a VM or on Kubernetes |
| RDS / Aurora | Not available | Self-managed PostgreSQL or MySQL on a VM: start from [automation templates](/build/iac-templates) |
| DynamoDB | Not available | Self-managed Redis, MongoDB, or PostgreSQL on a VM |
| SQS / SNS | Not available | Self-managed RabbitMQ, Redis, or NATS |
| CloudWatch | Not available | Run Prometheus, Grafana, or other agents on your instances |
| Route 53 | Not available | Use an external DNS provider (Cloudflare, or another registrar) |
| Cognito | Not available | Self-managed auth (Keycloak, Auth0, or similar) |

## Platform differences

- **Outbound transfer:** AWS bills for per-GB data egress from most regions (see [AWS EC2 on-demand pricing](https://aws.amazon.com/ec2/pricing/on-demand/)). Quake AI includes outbound transfer in plan pricing, so there is no separate egress line item to model.
- **Fixed monthly pricing:** Compute is billed per flavor per month rather than per second. Core networking objects such as networks, routers, floating IPs, and security groups are included in plan pricing instead of metered as separate hourly line items.
- **Flat authorization:** Three project-scoped roles (admin, member, reader) replace IAM JSON policy documents. This is less granular than IAM; you compensate with project-level isolation.
- **Baseline networking:** Quake AI networks reach the internet through a router attached to an external network. No internet gateway resource, NAT gateway SKU, or custom route table is required for the default path.

## Next steps

Work through these in order if you are onboarding a team, or jump to the topic that matches your migration phase.

- [Quickstart](/docs/quickstart)
- [Access & Credentials](/docs/platform/access/) for the OpenStack CLI
- [Infrastructure as Code with OpenTofu](/docs/automation/how-to/getting-started-iac)
- [Migrate from AWS S3](/docs/object/migration/migrate-from-s3)
- [Resource tiers](/docs/platform/account/resource-tiers): Developer Plan details
- [How Quake AI uses OpenStack](/docs/platform/migration/openstack)


  See the [full AWS migration guide](/docs/platform/migration/from-aws) for a service-by-service migration journey.