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.

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

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

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.

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 for the full catalog. Your resource tier 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.

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.

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: detailed service-to-project mapping
• Coming from AWS: concept translation guide
• Quickstart: launch your first VM via Console, CLI, or OpenTofu
• Infrastructure as Code with OpenTofu: Terraform/OpenTofu on Quake AI
• Kubernetes: Magnum clusters, worker sizing, and lifecycle
• Networks: Neutron topology on Quake AI (routers, subnets, floating IPs)
• Object storage: Swift S3 compatibility and migration notes
• How to monitor your Quake AI workload with Prometheus and Grafana: bring your own metrics stack instead of CloudWatch
• OpenStack upstream documentation: official project docs