Skip to content
mulga

Moving an AWS Workload to Mulga

Move existing AWS workloads onto Spinifex using compatible APIs, SDKs, and Terraform across EC2, VPC, EBS, S3, IAM, STS, ELBv2, ACM, ECR, ECS, and EKS.

migrationawsterraform
OverviewPrerequisitesTroubleshooting

Overview

Spinifex provides drop-in compatibility with AWS APIs, making it possible to migrate existing workloads with minimal changes.

Supported Services: EC2, VPC, EBS, S3, IAM, STS, ELBv2 (ALB/NLB), ACM, ECR, ECS, EKS

Compatible Tools: AWS CLI, AWS SDKs, Terraform, kubectl (via aws eks get-token), any S3-compatible client

Prerequisites

bash
export AWS_PROFILE=spinifex

Configure AWS CLI

bash
aws ec2 describe-instances
aws s3 ls

Terraform

hcl
provider "aws" {
  region     = "ap-southeast-2"
  access_key = "your-spinifex-access-key"
  secret_key = "your-spinifex-secret-key"

  endpoints {
    ec2                = "https://localhost:9999"
    iam                = "https://localhost:9999"
    sts                = "https://localhost:9999"
    elbv2              = "https://localhost:9999"
    acm                = "https://localhost:9999"
    ecr                = "https://localhost:9999"
    ecs                = "https://localhost:9999"
    eks                = "https://localhost:9999"
    s3                 = "https://localhost:8443"
  }

  skip_metadata_api_check = true
  skip_region_validation  = true
}

Hybrid S3 Sync

bash
aws s3 sync s3://local-bucket/ s3://cloud-bucket/ --source-region spinifex --region us-east-1

Troubleshooting

Terraform Provider Errors

Ensure these two skip flags are set in your provider configuration:

hcl
skip_metadata_api_check = true
skip_region_validation  = true

Without them, Terraform queries the EC2 instance metadata service for credentials and rejects a region name AWS does not know.

Leave skip_credentials_validation and skip_requesting_account_id unset, and point the sts endpoint at Spinifex. The provider then learns the account ID from GetCallerIdentity as it does on AWS. With the account ID blank, a security group rule that references a group in the same account reads back as <account>/sg-... and never reaches a clean plan.

Tagged S3 buckets need both flags set

There is one exception, and it applies to a provider block that manages an aws_s3_bucket with tags. AWS provider 6.x reads bucket tags through S3 Control, whose endpoint puts the account ID in the hostname — so the provider dials https://000000000001.<your-endpoint>, which cannot resolve when your endpoint is an IP address:

Error: listing tags for S3 (Simple Storage) Bucket (uploads): operation error S3 Control:
ListTagsForResource, ... dial tcp: lookup 000000000001.10.0.0.10: no such host

Set both flags in that provider block. With no account ID the provider reads tags through S3 GetBucketTagging instead, which Spinifex serves:

hcl
skip_requesting_account_id  = true
skip_credentials_validation = true

Both are needed — skip_requesting_account_id on its own has no effect, because the credentials check calls sts:GetCallerIdentity and supplies the account ID before the account lookup is ever skipped. If the same configuration also needs the account ID, for aws_ecr_repository or a security group rule that references another group, put the bucket in a second, aliased provider block rather than setting the flags globally.

S3 Signature Errors

Spinifex uses AWS Signature V4. Ensure your AWS CLI is version 2.0 or higher:

bash
aws --version

If using an older version, upgrade:

bash
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install --update