AWS Parity Design Reference

Source: Marc Mercer (SRE Lead) — sre-iac repository, Rev 1.0, 2026-02-24

This document maps AWS services to their OpenStack equivalents. OpenStack is the production platform — this reference preserves future optionality and reduces onboarding friction for engineers with AWS background. AWS migration is not an immediate goal.

Core Service Mapping

Compute

AWS Service	OpenStack Equivalent	Compatibility	Notes
EC2	Nova	95%	VM provisioning and management
Auto Scaling Groups	Heat Autoscaling	85%	Instance scaling based on metrics
Elastic IPs	Neutron Floating IPs	90%	Static IP address assignment
Placement Groups	Nova Server Groups	80%	Instance placement control
Dedicated Hosts	Nova Aggregates	70%	Host isolation and affinity
EKS	EKS Anywhere	99%	Same Kubernetes distribution, same APIs
ECS / Fargate	N/A	—	Use EKS Anywhere / Kubernetes pods instead

Instance type → Nova flavor mapping:

t3.micro:   { vcpus: 1,  ram: 1024,  disk: 8   }
t3.small:   { vcpus: 1,  ram: 2048,  disk: 20  }
t3.medium:  { vcpus: 2,  ram: 4096,  disk: 30  }
t3.large:   { vcpus: 2,  ram: 8192,  disk: 40  }
m5.large:   { vcpus: 2,  ram: 8192,  disk: 40  }
m5.xlarge:  { vcpus: 4,  ram: 16384, disk: 80  }
c5.xlarge:  { vcpus: 4,  ram: 8192,  disk: 40  }
r5.xlarge:  { vcpus: 4,  ram: 32768, disk: 40  }
p3.xlarge:  { vcpus: 4,  ram: 16384, disk: 40, gpu: 1 }

Storage

AWS Service	OpenStack Equivalent	Compatibility	Notes
EBS	Cinder + Ceph RBD	90%	Block storage with SSD and HDD tiers
EFS	Manila + CephFS	85%	Shared NFS-compatible filesystem
S3	Ceph RadosGW	95%	Full S3 API compatibility
Glacier	Ceph HDD pool	70%	Archive storage tier

EBS type → Ceph pool mapping:

gp3:  # General Purpose SSD  → ssd_general pool
io2:  # High IOPS SSD        → ssd_high_iops pool
st1:  # Throughput HDD       → hdd_throughput pool
sc1:  # Cold HDD             → hdd_cold pool

Networking

AWS Service	OpenStack Equivalent	Compatibility	Notes
VPC	Neutron Networks	90%	Virtual private clouds with subnets
Subnets	Neutron Subnets	95%	Public/private subnet patterns
Internet Gateway	Neutron Router	90%	External connectivity
NAT Gateway	Neutron Router	85%	Outbound internet for private subnets
Security Groups	Neutron Security Groups	95%	Instance-level firewall rules
NACLs	Neutron Network Policies	80%	Subnet-level access control
ALB/NLB	Octavia Load Balancer	85%	App and network load balancing
Route53	Designate + external-dns	70%	DNS management and service discovery

Subnet pattern — identical in both environments:

public_subnets:      ["10.100.0.0/20",   "10.100.16.0/20",  "10.100.32.0/20"]
private_subnets:     ["10.100.48.0/20",  "10.100.64.0/20",  "10.100.80.0/20"]
database_subnets:    ["10.100.96.0/20",  "10.100.112.0/20", "10.100.128.0/20"]
elasticache_subnets: ["10.100.144.0/20", "10.100.160.0/20", "10.100.176.0/20"]
intra_subnets:       ["10.100.192.0/20", "10.100.208.0/20", "10.100.224.0/20"]

Database

AWS Service	OpenStack Equivalent	Compatibility	Notes
RDS PostgreSQL	Trove PostgreSQL	80%	Managed PostgreSQL instances
RDS MySQL	Trove MySQL	80%	Managed MySQL/MariaDB instances
ElastiCache Redis	Trove Redis	75%	Managed Redis instances
DynamoDB	N/A	—	Use PostgreSQL or MongoDB
Aurora	N/A	—	Use PostgreSQL with HA configuration

Security and Identity

AWS Service	OpenStack Equivalent	Compatibility	Notes
IAM	Keystone + RBAC	60%	Basic user/role management
Secrets Manager	Infisical	85%	Self-hosted; Kubernetes operator integration
KMS / Barbican	Barbican	40%	Basic key management only
Security Groups	Neutron Security Groups	95%	Network access control
Cognito	Authentik	75%	Already running Authentik for SSO

Management and Monitoring

AWS Service	OpenStack Equivalent	Compatibility	Notes
CloudWatch	Prometheus/Grafana	70%	Metrics, alerting, and dashboards
CloudTrail	Keystone Audit	50%	API call auditing
Systems Manager	Ansible	60%	Configuration management
CloudFormation	Heat	75%	Infrastructure orchestration

note

Prometheus/Grafana provides deeper Kubernetes-native monitoring than CloudWatch offers for EKS. The 70% compatibility rating understates practical monitoring capability — the gap is primarily in automatic service-level integration that CloudWatch provides natively.

Terraform Portability

OpenStack Provider

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

provider "openstack" {
  cloud = "staging"  # From clouds.yaml
}

resource "openstack_networking_network_v2" "main" {
  name           = "main-network"
  admin_state_up = "true"
}

resource "openstack_networking_subnet_v2" "private" {
  name       = "private-subnet"
  network_id = openstack_networking_network_v2.main.id
  cidr       = "10.100.48.0/20"
  ip_version = 4
}

Portability Patterns

Pattern 1: Conditional Providers

variable "environment" {
  description = "Target platform: openstack or aws"
  type        = string
}

provider "openstack" {
  count = var.environment == "openstack" ? 1 : 0
  cloud = "staging"
}

provider "aws" {
  count  = var.environment == "aws" ? 1 : 0
  region = "us-east-1"
}

Pattern 2: Environment-Specific Modules

module "infrastructure" {
  source = var.environment == "openstack" ?
    "./modules/openstack" :
    "./modules/aws"

  vpc_cidr = "10.100.0.0/16"
  name     = "my-app"
}

Pattern 3: Application Configuration

openstack:
  storage:
    class: "cinder-ssd"
    endpoint: "https://rgw.staging.anshinhealth.net"

aws:
  storage:
    class: "gp3"
    endpoint: "s3.amazonaws.com"

S3 API Compatibility (RadosGW)

Same client code works against both AWS S3 and RadosGW with only an endpoint URL change:

import boto3

s3_client = boto3.client(
    's3',
    endpoint_url='https://rgw.staging.anshinhealth.net',
    aws_access_key_id='ACCESS_KEY',
    aws_secret_access_key='SECRET_KEY'
)

# Standard S3 operations work identically
response = s3_client.list_buckets()
s3_client.put_object(Bucket='my-bucket', Key='my-key', Body=b'data')

Supported: bucket management, object CRUD, multipart uploads, pre-signed URLs, bucket policies, versioning. Partially supported: S3 Select, S3 Inventory, some advanced lifecycle configurations.

Performance Reference

Service	AWS	OpenStack	Notes
gp3	3,000-16,000 IOPS	2,000-12,000 IOPS	Ceph SSD pool
io2	Up to 64,000 IOPS	Up to 40,000 IOPS	High-performance SSD
st1	Up to 500 MB/s	Up to 400 MB/s	HDD throughput
VPC bandwidth	Up to 100 Gbps	Up to 12 Gbps	LACP bonding limit on ML350 G9

Services with No Direct OpenStack Equivalent

AWS Service	Recommended Alternative
Lambda	Kubernetes Jobs / CronJobs (or OpenFaaS, Knative)
API Gateway	Kong or Kubernetes Ingress
SQS/SNS	RabbitMQ or Redis pub/sub (Kubernetes services or Trove)
Elasticsearch Service	Self-managed OpenSearch on Kubernetes
CloudFront	Nginx/Varnish caching, or external CDN
SES	External transactional email provider
Step Functions	Argo Workflows or Temporal
WAF	ModSecurity at ingress controller level

Known Limitations vs. AWS

These are accepted trade-offs for data sovereignty, cost control, and operational independence:

1. IAM complexity — Keystone provides project-level RBAC but lacks AWS IAM's fine-grained policy language. Mitigated by FreeIPA group-based access and Infisical for secrets.
2. Single site/single AZ — No multi-region HA. Acceptable for staging; would require architectural changes for production PHI handling.
3. Managed service depth — Fewer managed services; most non-DB services are self-hosted on Kubernetes.
4. Compliance programs — AWS provides pre-certified HIPAA BAA, SOC 2 reports. OpenStack requires self-assessment. Anshin Health's controls align with these frameworks but are not yet formally certified.

---

Document Control

Rev	Date	Author	Description
1.0	2026-02-24	Marc Mercer	Initial release