Q1
Do you require AWS CloudFormation as the deployment engine?
If CloudFormation is mandatory, only tools that deploy through CloudFormation should be considered.
Yes, CloudFormation is requiredNoNot sure
How this works
This site uses tool facts, a short questionnaire, and transparent rules to help compare options. Everything below is drawn from the JSON data files.
Want the details? See the contributing guide.
Tools (10)
Browse the full comparison table with official references.
See all tools side by side, including focus area, definition model, supported languages, and state model.
Go to compare tableQuestions (6)
The quiz uses these prompts and options.
Q2
How do you want to define infrastructure or automation?
Declarative includes templates (YAML/JSON), HCL, or Kubernetes-style manifests. General-purpose means writing code in languages like TypeScript or Python.
General-purpose programming languagesDeclarative configurationNo preference
Q3
What are you primarily trying to automate?
This helps distinguish infrastructure provisioning, configuration management, and control-plane orchestration.
Provisioning and managing cloud infrastructureConfiguring and maintaining servers and appsBuilding a platform control plane on KubernetesNot sure
Q4
Which target scope best matches your needs?
AWS-native favors tools built around AWS services. AWS-only means AWS today, but portability may still matter. Multi-cloud targets multiple providers.
AWS-native integrationAWS only (portability still matters)Multi-cloudNot sure
Q5
Who should be responsible for managing infrastructure state?
Some tools require you to run and maintain a state backend yourself. Others manage state internally as part of the deployment engine.
The tool should manage state for meI’m fine managing a state backend myselfNot sure
Q6
Do you prefer a managed state service (SaaS)?
A managed service handles storage, locking, and history for state. This is separate from provider-native engines like CloudFormation.
Yes, prefer a managed state serviceNo, self-managed is fineNot sure
Rules (11)
Rules first exclude tools, then apply weights to rank the rest.
Must-have exclusions
These rules remove tools that don’t meet a required condition.
Must-have
mh-cloudformation
Requires AWS CloudFormation as the deployment engine.
Weighted preferences
These rules add weight based on your preferences.
Weight
w-general-purpose
Prefers general-purpose programming languages.
aws-cdk: +3
pulumi: +3
Weight
w-declarative
Prefers declarative configuration and templates.
terraform: +3
opentofu: +3
aws-cloudformation: +3
pulumi: +1
formae: +2
ansible: +2
puppet: +2
chef: +1
crossplane: +3
Weight
w-focus-infra
Primary focus is infrastructure provisioning.
aws-cdk: +3
aws-cloudformation: +3
terraform: +3
opentofu: +3
pulumi: +3
formae: +2
crossplane: +1
Weight
w-focus-config
Primary focus is configuration management.
ansible: +3
puppet: +3
chef: +3
terraform: +1
opentofu: +1
pulumi: +1
Weight
w-focus-control-plane
Primary focus is Kubernetes control-plane orchestration.
crossplane: +3
terraform: +1
opentofu: +1
pulumi: +1
Weight
w-aws-native
Prefers AWS-native integration.
aws-cdk: +3
aws-cloudformation: +3
pulumi: +1
terraform: +1
opentofu: +1
Weight
w-aws-only
AWS is the only provider today, but portability still matters.
aws-cdk: +2
aws-cloudformation: +2
pulumi: +2
terraform: +2
opentofu: +2
formae: +1
ansible: +1
puppet: +1
chef: +1
crossplane: +1
Weight
w-multi-cloud
Targets multiple cloud providers.
terraform: +3
opentofu: +3
pulumi: +3
crossplane: +2
ansible: +1
puppet: +1
chef: +1
Weight
w-avoid-state-backend
Prefers tools that manage state for you.
aws-cdk: +3
aws-cloudformation: +3
formae: +3
pulumi: +2
crossplane: +2
Weight
w-managed-state
Prefers a managed state service.
pulumi: +3
terraform: +2
opentofu: +1
crossplane: +1