# OpenStack for AWS developers

Source: https://docs.quake.ai/docs/platform/migration/openstack-for-aws-developers
Markdown: https://docs.quake.ai/docs/platform/migration/openstack-for-aws-developers.md

---

# OpenStack for AWS developers

OpenStack is an open-source cloud computing platform used by thousands of organizations, from CERN to Walmart to government agencies. Quake AI runs on OpenStack, so Quake AI APIs follow standard OpenStack interfaces with upstream documentation.

If you have AWS experience, you already understand the concepts. This page maps OpenStack projects to AWS equivalents and notes where the models diverge.


## The service map

Under the Quake AI product names, the stack lines up with OpenStack projects you see in CLIs, APIs, and Terraform: the Compute service (OpenStack Nova), the Network service (OpenStack Neutron), Block Storage (OpenStack Cinder), Object Storage (OpenStack Swift), the Image service (OpenStack Glance), Kubernetes (OpenStack Magnum), Automation (OpenStack Heat), and Identity (OpenStack Keystone). The table below matches each public Quake AI service to its AWS analog and calls out what you relearn at the boundary.

Scan the **Quake AI service** column when you read Quake AI docs or the Console. Scan **OpenStack project** when you read CLI errors, Heat events, or Terraform provider docs. Scan **AWS equivalent** when you translate runbooks. Scan **What changes** when you estimate migration work: that column is the delta.

| Quake AI service | OpenStack project | AWS equivalent | What changes |
|---|---|---|---|
| Compute | Nova | EC2 | Flavor model instead of instance types; `openstack server create` instead of `aws ec2 run-instances` |
| Network | Neutron | VPC + Subnets + Security Groups | No IGW, NAT gateway, or route tables for basic internet access |
| Block Storage | Cinder | EBS | Same attach/detach; NVMe at every tier; no IOPS tiers |
| Object Storage | Swift | S3 | S3-compatible API; no lifecycle policies or event notifications |
| Images | Glance | AMIs | Standard formats (QCOW2, RAW); community images available |
| Self-managed edge | Nova + Neutron | ELB / ALB | Run a reverse proxy, WAF, or API gateway on a VM with a floating IP |
| Kubernetes | Magnum | EKS | Cluster templates; worker nodes are Nova instances |
| Automation | Heat | CloudFormation | HOT YAML templates; OpenTofu fits new projects |
| Identity | Keystone | IAM + STS | Project-scoped credentials; three roles (admin, member, reader) |


  Heat remains the native OpenStack orchestration API. For greenfield work on Quake AI, OpenTofu or Terraform with the OpenStack provider is the usual path instead of porting large CloudFormation habits verbatim. See [Infrastructure as Code with OpenTofu](/docs/automation/how-to/getting-started-iac).


Magnum clusters consume flavors and quotas the same way standalone instances do: Magnum manages the control plane, and the workers are Nova servers you size explicitly. Edge routing runs on Compute through templates such as [edge reverse proxy](/build/iac-templates/edge-reverse-proxy) and [API gateway](/build/iac-templates/api-gateway).

Heat orchestration applies when you inherit OpenStack-native templates: a stack expands into `OS::Nova::Server`, `OS::Neutron::Net`, and related HOT resource types that call the same APIs OpenTofu wraps. If your team already lives in HCL, you often mirror the dependency graph with `openstack_*` resources and let state management replace stack events instead of authoring new HOT by hand.

Swift behaves like S3 from the application's perspective when you point SDKs at the Quake AI object endpoint. You still think in buckets (containers), keys, and multipart uploads. You lose S3-specific control-plane features called out in the table; Swift preserves the core read/write path. For a compatibility checklist, start from [Object storage](/docs/object) before you assume Lambda triggers or lifecycle rules follow you.

Magnum templates encode Kubernetes version, network driver, and volume settings the way EKS cluster configs encode control plane version, add-ons, and node groups, except worker **nodes remain Nova instances** you see in `openstack server list`, which makes capacity debugging familiar: if the cluster cannot scale, you check flavor quota and Neutron ports before you blame the control plane.

## Fewer objects to manage

Nova, Neutron, and Keystone trim categories of objects AWS treats as mandatory. Storage stays familiar once you map the nouns; networking and identity carry the largest workflow changes.

Cinder snapshots and clones mirror the EBS snapshot story: you freeze a volume, copy data to a new image or volume, and attach it elsewhere. Translate ALB listeners and target groups into routes, backend lists, and health checks on Caddy, SafeLine, or APISIX.

A 401 surfaces in Keystone traces; a 409 on port binding points at Neutron; slow boots often lead back to Glance or Cinder attachment order. The service column in the table above maps which docs section to open. The split ownership matches AWS service boundaries closely enough that your escalation instincts transfer.

### Networking without the ceremony

On AWS, giving a VM internet access requires: a VPC, a subnet, an Internet Gateway, a route table entry, and a security group. On Quake AI and OpenStack, you create a network, create a subnet, create a router connected to the external network, and create your instance. Neutron does not require an IGW concept, a NAT gateway for private subnets, or route table management in the AWS sense.

Compare a minimal public-facing layout in Terraform/OpenTofu:

AWS (Terraform):

```hcl
resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" }
resource "aws_subnet" "web" { vpc_id = aws_vpc.main.id; cidr_block = "10.0.1.0/24" }
resource "aws_internet_gateway" "igw" { vpc_id = aws_vpc.main.id }
resource "aws_route_table" "rt" { vpc_id = aws_vpc.main.id }
resource "aws_route" "internet" { route_table_id = aws_route_table.rt.id; destination_cidr_block = "0.0.0.0/0"; gateway_id = aws_internet_gateway.igw.id }
resource "aws_route_table_association" "a" { subnet_id = aws_subnet.web.id; route_table_id = aws_route_table.rt.id }
```

Quake AI (OpenTofu):

```hcl
resource "openstack_networking_network_v2" "main" { name = "main" }
resource "openstack_networking_subnet_v2" "web" { network_id = openstack_networking_network_v2.main.id; cidr = "10.0.1.0/24" }
resource "openstack_networking_router_v2" "router" { external_network_id = data.openstack_networking_network_v2.external.id }
resource "openstack_networking_router_interface_v2" "ri" { router_id = openstack_networking_router_v2.router.id; subnet_id = openstack_networking_subnet_v2.web.id }
```

You declare six resources on AWS and four on OpenStack for this layout.

Neutron still has **security groups**: you attach rules to groups and associate those groups with instance ports, matching the mental model you use in a default VPC. What you drop is the extra graph of gateway objects and explicit `0.0.0.0/0` routes for a simple public subnet. When you need isolation between tiers, you add networks and routers the same way you would add subnets, without cloning another IGW per VPC.

For stable inbound addresses you allocate **floating IPs** (the Elastic IP analog) and associate them with instance ports. The workflow is attach port, associate address; no separate "public subnet" requirement beyond the router path you already built.

Outbound internet access for instances on a routed subnet flows through the same router without you standing up a NAT gateway object. When you need stricter egress control, you still use **security groups** and, if required, additional Neutron features, but the default path does not mirror the "private subnet + NAT GW + route table" triad from a three-tier VPC reference architecture.

### Authentication without policy language

AWS IAM gives you users, groups, roles, policies (JSON documents with Actions, Resources, Conditions), STS assume-role chains, permission boundaries, and service control policies.

Keystone gives you projects, users, roles (`admin`, `member`, `reader`), and application credentials. An application credential is scoped to a single project and carries a single role. No policy JSON exists. Where AWS chains `sts:AssumeRole` across accounts, Quake AI keeps trust inside the project boundary: you mint application credentials or use password-based users with a role on that project.

Keystone's model is less granular than IAM. You cannot restrict a credential to "only create instances in subnet X." If you need resource-level isolation, you use separate projects. For most development workflows, project-level scoping is enough.

Rotation looks like creating a new application credential in the Console or CLI, updating your CI secret, and deleting the old secret: closer to swapping IAM access keys than rewiring an assume-role chain. You still protect JSON downloads the same way you protect long-lived AWS keys.


  Treat each Quake AI **project** as its own trust boundary, similar to splitting AWS accounts or OU-scoped roles, without a policy compiler in the middle.


### Fewer choices, less decision fatigue

AWS EC2 exposes hundreds of instance types across many families. Choosing between `m5.large`, `m5a.large`, `m5n.large`, `m6i.large`, and `m7g.large` forces you to track hardware generations, network tiers, and processor families.

Quake AI publishes **26 flavors across four families**. Names follow `{family}{generation}{architecture}.{size}` (for example, `m2a.large` is **General Purpose** (balanced, 1:4 vCPU:RAM) on **Gen 2**, **AMD**, at the **large** size (2 vCPU, 8 GiB)). **c2a** is compute optimized (1:2), **r2a** is memory optimized (1:8), and **s1a** is shared CPU (1:1). See [Flavors](/docs/compute/concepts/flavors) for the full catalog. Your [resource tier](/docs/platform/account/resource-tiers) still caps aggregate quota: capacity planning is flavor plus headroom.

Resizing a Nova server means changing flavor. The operation is a deliberate migration step, closer to stopping an instance, changing type, and starting again, so you document it in runbooks the same way you document EC2 vertical scale, with fewer hidden SKU dependencies.

Glance images are plain disk artifacts referenced by name or ID. Sharing looks like publishing to the catalog your project can see; the project boundary is the access boundary.

## What's different

- **CLI:** You use the `openstack` command instead of `aws`. The syntax differs; the concepts do not. You run `openstack server list` instead of `aws ec2 describe-instances`.
- **Console:** You get a Horizon-based web UI with a different layout than the AWS Console. The capabilities for resource management align; muscle memory does not.
- **No resource tagging system:** OpenStack exposes instance metadata (key-value pairs on servers), but nothing matches AWS's unified tagging and Tag Editor across every resource type.
- **US regions:** Quake AI operates three US regions (`us-east-1`, `us-east-2`, `us-west-1`).
- **Terraform provider:** You use `terraform-provider-openstack/openstack` instead of `hashicorp/aws`. Resource names change: `aws_instance` maps to `openstack_compute_instance_v2`, `aws_vpc` patterns map to `openstack_networking_network_v2`, and so on. State moves; topology does not.


  Plan time to translate modules and data sources. The OpenStack provider exposes fewer synthetic resources than AWS: you often declare networks and routers explicitly, which matches what you already saw in the Neutron example above.


Most operational habits still apply. You still scope credentials, rotate secrets, and avoid sharing admin keys: you express blast radius with Keystone projects instead of IAM policy documents. You still bake images, version infrastructure definitions, and prefer replacing servers over endless SSH repair: Nova snapshots and Glance images sit where AMI pipelines lived.

You still combine **security groups**, private networks, and jump hosts when a tier must not face the public internet; Neutron exposes the same levers with different resource names. You still export metrics, keep audit logs, and page on SLO breaches: you pick Prometheus, Grafana Cloud, Datadog, or another stack instead of inheriting CloudWatch by default.

CI/CD integrations follow the same pattern as AWS: store an application credential or cloud config secret, run `openstack` or Terraform in the job, and gate promotions on plans. The artifacts change from `aws sts assume-role` output to `clouds.yaml` snippets; the pipeline shape does not.

## What OpenStack doesn't try to do

OpenStack provides infrastructure primitives. Quake AI does not ship Lambda, DynamoDB, SQS, CloudWatch, or a managed database service. By design, OpenStack and Quake AI deliver the compute, networking, and storage layer. Application services run on top.

You bring your own queues, functions, metrics, and managed data planes, or you run them on Nova with Cinder and Neutron underneath, the same way you might run RabbitMQ or Prometheus on EC2 today. Quake AI does not bill per API call for those higher layers because it does not ship them as first-party products.

Need functions-on-schedule? Run a small worker instance with `cron`, systemd timers, or a minimal job runner. Need a document store? Deploy MongoDB or use an external Atlas-equivalent. Need traces? Run OpenTelemetry collectors on your network. The pattern repeats: pick a workload you used to buy as AWS PaaS, decide whether it belongs in a container on Nova or outside the cloud, then wire Cinder volumes and Neutron security groups around it.

If you are the kind of developer who runs PostgreSQL in Docker, deploys with Terraform, and manages your own monitoring stack, OpenStack gives you the infrastructure layer to do that, without paying for or navigating services you do not use.

If your workload requires HA PostgreSQL, the common pattern is two Nova instances with Cinder volumes, Patroni for failover, and Neutron security groups as the perimeter: the same as self-managed PostgreSQL on EC2, with fewer ancillary networking objects involved. If your workload uses Lambda, the equivalent is containers on Magnum with a lightweight queue (self-hosted RabbitMQ or a SaaS broker) and workers sized with flavors, not concurrency limits billed per millisecond.

Neither path is automatic; both are explicit engineering choices.

When you miss a specific AWS managed offering, search the docs for the workload pattern (database HA, message bus, batch jobs) before you assume the platform hides the implementation: Quake AI documents a template or reference layout you can adopt.

## CLI comparison cheat sheet

The `openstack` CLI wraps the same REST APIs the Console uses. Flags differ from `aws` subcommands, but the verbs are the same: list, create, show, delete. Source your `openrc.sh` or set `OS_CLOUD` to a `clouds.yaml` stanza; inject either in CI the same way you inject `AWS_ACCESS_KEY_ID`.

| Task | AWS CLI | OpenStack CLI |
|---|---|---|
| List instances | `aws ec2 describe-instances` | `openstack server list` |
| Create instance | `aws ec2 run-instances --image-id ami-xxx --instance-type t3.micro` | `openstack server create --flavor m2a.large --image "Ubuntu 24.04" my-server` |
| List volumes | `aws ec2 describe-volumes` | `openstack volume list` |
| Create volume | `aws ec2 create-volume --size 50` | `openstack volume create --size 50 my-volume` |
| List networks | `aws ec2 describe-vpcs` | `openstack network list` |
| List images | `aws ec2 describe-images --owners self` | `openstack image list` |
| Get credentials | `aws sts get-session-token` | `openstack application credential create my-cred` |

Add `-f json` or `-f yaml` for machine-readable output. Resource IDs are UUIDs, not `i-`/`vpc-` prefixes. Run `openstack help server` to drill into compute verbs; `openstack help` lists all command groups.

## Further reading

Upstream OpenStack docs are the authoritative reference for each project's API and behavior.

- [How Quake AI uses OpenStack](/docs/platform/migration/openstack): detailed service-to-project mapping
- [Coming from AWS](/docs/platform/migration/coming-from-aws): concept translation guide
- [Quickstart](/docs/quickstart): launch your first VM via Console, CLI, or OpenTofu
- [Infrastructure as Code with OpenTofu](/docs/automation/how-to/getting-started-iac): Terraform/OpenTofu on Quake AI
- [Kubernetes](/docs/kubernetes): Magnum clusters, worker sizing, and lifecycle
- [Networks](/docs/network/concepts/networks): Neutron topology on Quake AI (routers, subnets, floating IPs)
- [Object storage](/docs/object): Swift S3 compatibility and migration notes
- [How to monitor your Quake AI workload with Prometheus and Grafana](/docs/operations/monitoring/how-to-deploy-monitoring): bring your own metrics stack instead of CloudWatch
- [OpenStack upstream documentation](https://docs.openstack.org/): official project docs