Terraform to CloudFormation Converter

How to convert Terraform to a CloudFormation template

To convert Terraform to CloudFormation, paste your HCL into the editor above and press Convert to CloudFormation. Each resource becomes a typed entry under Resources, variables become Parameters, outputs become Outputs and references become Ref, Fn::GetAtt or Fn::Sub. Then validate the JSON template, review a change set and create the stack.

1. Add your TerraformPaste HCL into the Terraform (HCL) editor, use Open file for a .tf, .hcl or .txt file up to 500 KB, or drop one onto the editor. Include the variable and output blocks. Sample loads a VPC, a subnet and a security group.
2. Let the secret check runTerraform variables sometimes hold real keys or passwords. The page flags AWS access keys, secret keys, private keys and common API tokens before anything is sent, so you can replace them first.
3. Convert to CloudFormationClick Convert to CloudFormation or press Ctrl + Enter. The template streams in as it's written, and Stop cancels it. Each conversion takes up to 60,000 characters, so convert one module at a time.
4. Review the templateCheck the logical IDs, parameter defaults and resource list. JSON has no comments, so Terraform features with no CloudFormation equivalent are left out rather than flagged. Copy the result or Download it as template.json.
5. Validate and deployRun aws cloudformation validate-template, create a change set to preview the resources, then create the stack. If the resources already exist, import them instead of creating new ones.

Why convert Terraform to CloudFormation

The usual reason is a platform standard. Organizations that roll infrastructure out with CloudFormation StackSets across accounts, or through AWS Control Tower customizations, need templates rather than HCL. Others want CloudFormation to keep track of resources so they no longer run a Terraform state backend, or they're handing infrastructure to a team that already reviews change sets.

Rewriting HCL by hand means looking up the resource type and property name for every Terraform argument. aws_security_group ingress blocks become SecurityGroupIngress entries with IpProtocol and CidrIp, tag maps become lists of Key and Value pairs, and every reference becomes an intrinsic function. The converter drafts the whole template so your time goes on the parts that need judgment.

It rewrites code only. It doesn't read your state file or your AWS account, so the template describes resources to create. To bring existing resources under CloudFormation, use resource import. To go the other way, use the CloudFormation JSON to Terraform converter.

How Terraform concepts map to CloudFormation

Most of the mapping is direct. Each resource "aws_vpc" becomes an AWS::EC2::VPC entry under Resources, variable blocks become Parameters, and output blocks become Outputs. References such as aws_vpc.main.id turn into intrinsic functions like {"Ref": "MainVpc"} or Fn::GetAtt, and string interpolation becomes Fn::Sub.

Some Terraform features have no plain CloudFormation equivalent. count and for_each usually become repeated resources, unless you opt in to the AWS::LanguageExtensions transform and its Fn::ForEach. Data sources that look things up, such as data "aws_ami", need a parameter or an SSM parameter type instead.

Before you create a stack from the template, validate it with aws cloudformation validate-template and review a change set so you can see exactly what CloudFormation will create.

Terraform vs CloudFormation: quick reference

How common Terraform constructs are written in a CloudFormation template. Use it to check the converted JSON line by line.

Key features

• Resources mapped to AWS:: typesEach Terraform resource becomes its CloudFormation type, such as aws_vpc to AWS::EC2::VPC, with arguments renamed to the template's property names.
• Variables and outputs carried overvariable blocks become Parameters with their defaults, and output blocks become Outputs.
• References become intrinsic functionsAttribute references and interpolated strings are rewritten as Ref, Fn::GetAtt and Fn::Sub.
• Nested blocks reshapedBlocks such as ingress and egress become property lists, and tag maps become Key/Value lists.
• A JSON template ready to validateThe output is a JSON template you can pass straight to validate-template. Anything without a CloudFormation equivalent is left out, because JSON has no comments.
• Secret check before sendingAWS keys, private keys and common API tokens in your HCL are detected in your browser before any code leaves it.
• Streaming, copy and downloadThe template appears as it's written. Copy it, wrap long lines, or download it as template.json.
• Free, with no signupConvert right away. A free account raises your limits and lists recent conversions on your dashboard.

Examples: Terraform converted to CloudFormation

Three patterns that need more than renaming. Choose Try this example to load the HCL into the converter. The JSON shown is correct output for each snippet; the converter's logical IDs and formatting may differ.

variable "env" {
  type    = string
  default = "prod"
}

resource "aws_s3_bucket" "logs" {
  bucket = "${var.env}-app-logs"

  tags = {
    Team = "platform"
  }
}

resource "aws_s3_bucket_versioning" "logs" {
  bucket = aws_s3_bucket.logs.id

  versioning_configuration {
    status = "Enabled"
  }
}

output "logs_bucket_arn" {
  value = aws_s3_bucket.logs.arn
}

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "Env": {
      "Type": "String",
      "Default": "prod"
    }
  },
  "Resources": {
    "LogsBucket": {
      "Type": "AWS::S3::Bucket",
      "Properties": {
        "BucketName": { "Fn::Sub": "${Env}-app-logs" },
        "VersioningConfiguration": { "Status": "Enabled" },
        "Tags": [{ "Key": "Team", "Value": "platform" }]
      }
    }
  },
  "Outputs": {
    "LogsBucketArn": {
      "Value": { "Fn::GetAtt": ["LogsBucket", "Arn"] }
    }
  }
}

variable "enable_alarm" {
  type    = bool
  default = true
}

resource "aws_sns_topic" "alerts" {
  name = "ops-alerts"
}

resource "aws_cloudwatch_metric_alarm" "cpu_high" {
  count               = var.enable_alarm ? 1 : 0
  alarm_name          = "cpu-high"
  namespace           = "AWS/EC2"
  metric_name         = "CPUUtilization"
  statistic           = "Average"
  period              = 300
  evaluation_periods  = 2
  threshold           = 80
  comparison_operator = "GreaterThanThreshold"
  alarm_actions       = [aws_sns_topic.alerts.arn]
}

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "EnableAlarm": {
      "Type": "String",
      "Default": "true",
      "AllowedValues": ["true", "false"]
    }
  },
  "Conditions": {
    "AlarmEnabled": { "Fn::Equals": [{ "Ref": "EnableAlarm" }, "true"] }
  },
  "Resources": {
    "AlertsTopic": {
      "Type": "AWS::SNS::Topic",
      "Properties": { "TopicName": "ops-alerts" }
    },
    "CpuHighAlarm": {
      "Type": "AWS::CloudWatch::Alarm",
      "Condition": "AlarmEnabled",
      "Properties": {
        "AlarmName": "cpu-high",
        "Namespace": "AWS/EC2",
        "MetricName": "CPUUtilization",
        "Statistic": "Average",
        "Period": 300,
        "EvaluationPeriods": 2,
        "Threshold": 80,
        "ComparisonOperator": "GreaterThanThreshold",
        "AlarmActions": [{ "Ref": "AlertsTopic" }]
      }
    }
  }
}

variable "vpc_id" {
  type = string
}

resource "aws_security_group" "app" {
  description = "App servers"
  vpc_id      = var.vpc_id
}

resource "aws_security_group" "db" {
  description = "Database"
  vpc_id      = var.vpc_id

  ingress {
    description     = "Postgres from app servers"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
  }
}

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "VpcId": { "Type": "AWS::EC2::VPC::Id" }
  },
  "Resources": {
    "AppSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "App servers",
        "VpcId": { "Ref": "VpcId" }
      }
    },
    "DbSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "Database",
        "VpcId": { "Ref": "VpcId" },
        "SecurityGroupIngress": [
          {
            "Description": "Postgres from app servers",
            "IpProtocol": "tcp",
            "FromPort": 5432,
            "ToPort": 5432,
            "SourceSecurityGroupId": { "Fn::GetAtt": ["AppSecurityGroup", "GroupId"] }
          }
        ]
      }
    }
  }
}

Tips for better results

• Paste variables and outputs too. They become the template's Parameters and Outputs, so the stack stays configurable.
• Replace provider-level settings. The provider "aws" region isn't part of a template. You choose the region when you create the stack.
• Check logical IDs. Terraform names like private_a become CloudFormation logical IDs such as PrivateA. Pick names you're happy to keep, because renaming one later replaces the resource.
• Watch for fixed names. A hard-coded name, such as a security group's GroupName, stops CloudFormation from replacing that resource during an update. Leave names out unless you need them.
• Prefer YAML to read, JSON to generate. CloudFormation accepts both formats, so convert the JSON to YAML afterwards if your team prefers it.

Common mistakes to avoid

• Creating a stack over resources Terraform still manages. Two tools managing the same resource leads to drift and failed updates. Import the resources into CloudFormation, then run terraform state rm.
• Assuming security group egress is the same. Terraform strips the default allow-all egress rule when a group has no egress blocks. CloudFormation leaves it in place unless you set SecurityGroupEgress.
• Losing provider default_tags. Tags set on the provider aren't in any resource block, so they don't reach the template. Add them per resource, or pass stack-level tags when you create the stack.
• Hard-coding the region and account. Replace literal values such as us-east-1a or an account ID with AWS::Region, AWS::AccountId and Fn::GetAZs so the template works anywhere.
• Expecting boolean parameters. CloudFormation parameters have no boolean type. Use a String parameter with AllowedValues of "true" and "false", then a condition.

Frequently asked questions

Related tools and next steps

• CloudFormation JSON to Terraform converterGo the other way, from a JSON template back to Terraform HCL.
• CloudFormation YAML to Terraform converterConvert YAML templates to Terraform without reformatting them first.
• Terraform to CDK TypeScript converterPrefer code to templates? The CDK synthesizes CloudFormation for you.
• Terraform to Pulumi converterRewrite the same HCL as a Pulumi program in TypeScript.
• All AWS code convertersSDKs, infrastructure as code and IAM policy generators in one place.