How to migrate from AWS CloudFormation to OpenTofu on Quake AI

If your infrastructure runs on AWS and is defined in CloudFormation, moving to Quake AI means rewriting those stack definitions in OpenTofu HCL. This guide maps common CloudFormation resource types to their Quake AI OpenTofu equivalents and outlines a practical migration workflow.

Conceptual mapping#

CloudFormation and OpenTofu serve the same purpose (declarative infrastructure definition) but differ in execution:

Resource equivalents#

Migration workflow#

1. Audit your CloudFormation stacks#

Export your current stack resources:

aws cloudformation describe-stack-resources \
  --stack-name YOUR_STACK_NAME \
  --query 'StackResources[].{Type:ResourceType,Logical:LogicalResourceId,Physical:PhysicalResourceId}' \
  --output table

Document each resource type and its configuration. Pay attention to:

• Instance types and AMIs (map to Quake AI flavors and images)
• VPC CIDR ranges and subnet layout
• Security group rules
• Load balancer listeners and target groups
• S3 bucket policies and lifecycle rules

2. Map to Quake AI resources#

For each CloudFormation resource, identify the OpenTofu equivalent from the table above. Start with the Quake AI template library; many common patterns are already authored:

• EC2 instance with EIP → Simple VM template
• VPC + subnets + ALB → Edge Reverse Proxy template or API Gateway template
• Multi-tier app (web + app + DB) → Three-Tier Application template
• RDS PostgreSQL → Self-Managed PostgreSQL template

3. Write OpenTofu configuration#

Start with a single resource (typically a compute instance) and validate the provider setup:

terraform {
  required_version = ">= 1.6.0"

  required_providers {
    openstack = {
      source  = "terraform-provider-openstack/openstack"
      version = "~> 2.0"
    }
  }
}

provider "openstack" {}

data "openstack_images_image_v2" "ubuntu" {
  name        = "Ubuntu-24.04"
  most_recent = true
}

resource "openstack_compute_instance_v2" "web" {
  name        = "web-server"
  flavor_name = "s1a.medium"

  block_device {
    uuid                  = data.openstack_images_image_v2.ubuntu.id
    source_type           = "image"
    destination_type      = "volume"
    volume_size           = 20
    boot_index            = 0
    delete_on_termination = true
  }

  network {
    name = "PublicStatic"
  }
}

Run tofu plan to verify the configuration is valid, then iterate to add the rest of your resources.

4. Set up remote state#

Before applying, configure remote state with Quake AI S3 so your team can collaborate on the infrastructure.

5. Apply incrementally#

Deploy resources in dependency order:

1. Networking (networks, subnets, security groups)
2. Storage (block volumes, S3 buckets)
3. Compute (instances, cloud-init)
4. Edge proxy or API gateway and DNS

Key differences from AWS#

• No managed databases. Use the Self-Managed PostgreSQL template, or pair Quake AI with the managed database service your architecture uses externally.
• Network translation. Instances use floating IPs or direct network attachment for internet access. Put a self-managed edge reverse proxy or API gateway on one floating IP when several private backends need a shared public entry point.
• No IAM roles. Authentication uses OpenStack Keystone credentials via environment variables.
• Fixed monthly pricing. No per-hour billing surprises; plan capacity based on monthly cost rather than usage estimates.

See also#

• Migration Explorer: interactive service comparison across cloud providers
• IaC on Quake AI
• Infrastructure Templates
• How to get started with Infrastructure as Code on Quake AI